[[193071]]

要建立一個(gè)大數(shù)據(jù)系統(tǒng)，我們需要從數(shù)據(jù)流的源頭跟蹤到最后有價(jià)值的輸出，并在現(xiàn)有的 Hadoop 和大數(shù)據(jù)生態(tài)圈內(nèi)根據(jù)實(shí)際需求挑選并整合各部分合適的組件來構(gòu)建一個(gè)能夠支撐多種查詢和分析功能的系統(tǒng)平臺(tái)。這其中既包括了對(duì)數(shù)據(jù)存儲(chǔ)的選擇，也涵蓋了數(shù)據(jù)線上和線下處理分離等方面的思考和權(quán)衡。此外，沒有任何一個(gè)引入大數(shù)據(jù)解決方案的商業(yè)應(yīng)用在生產(chǎn)環(huán)境上承擔(dān)的起安全隱患。

1. 計(jì)算框架篇

大數(shù)據(jù)的價(jià)值

只有在能指導(dǎo)人們做出有價(jià)值的決定時(shí)，數(shù)據(jù)才能體現(xiàn)其自身的價(jià)值。因此，大數(shù)據(jù)技術(shù)要服務(wù)于實(shí)際的用途，才是有意義的。一般來說，大數(shù)據(jù)可以從以下三個(gè)方面指導(dǎo)人們做出有價(jià)值的決定：

1. 報(bào)表生成(比如根據(jù)用戶歷史點(diǎn)擊行為的跟蹤和綜合分析、 應(yīng)用程序活躍程度和用戶粘性計(jì)算等);
2. 診斷分析(例如分析為何用戶粘性下降、根據(jù)日志分析系統(tǒng)為何性能下降、垃圾郵件以及病毒的特征檢測(cè)等);
3. 決策(例如個(gè)性化新聞閱讀或歌曲推薦、預(yù)測(cè)增加哪些功能能增加用戶粘性、幫助廣告主進(jìn)行廣告精準(zhǔn)投放、設(shè)定垃圾郵件和病毒攔截策略等)。 

圖 1

進(jìn)一步來看，大數(shù)據(jù)技術(shù)從以下三個(gè)方面解決了傳統(tǒng)技術(shù)難以達(dá)成的目標(biāo)(如圖 1)：

1. 在歷史數(shù)據(jù)上的低延遲(交互式)查詢，目標(biāo)是加快決策過程和時(shí)間， 例如分析一個(gè)站點(diǎn)為何變緩慢并嘗試修復(fù)它;
2. 在實(shí)時(shí)數(shù)據(jù)上的低延遲查詢，目的是幫助用戶和應(yīng)用程序在實(shí)時(shí)數(shù)據(jù)上做出決策， 例如實(shí)時(shí)檢測(cè)并阻攔病毒蠕蟲(一個(gè)病毒蠕蟲可以在 1.3 秒內(nèi)攻擊 1 百萬臺(tái)主機(jī));
3. 更加精細(xì)高級(jí)的數(shù)據(jù)處理算法，這可以幫助用戶做出“更好”的決策， 例如圖數(shù)據(jù)處理、異常點(diǎn)檢測(cè)、趨勢(shì)分析及其他機(jī)器學(xué)習(xí)算法。

蛋糕模式

從將數(shù)據(jù)轉(zhuǎn)換成價(jià)值的角度來說，在 Hadoop 生態(tài)圈十年蓬勃成長(zhǎng)的過程中，YARN 和 Spark 這二者可以算得上是里程碑事件。Yarn 的出現(xiàn)使得集群資源管理和數(shù)據(jù)處理流水線分離，大大革新并推動(dòng)了大數(shù)據(jù)應(yīng)用層面各種框架的發(fā)展(SQL on Hadoop 框架, 流數(shù)據(jù)，圖數(shù)據(jù)，機(jī)器學(xué)習(xí))。

它使得用戶不再受到 MapReduce 開發(fā)模式的約束，而是可以創(chuàng)建種類更為豐富的分布式應(yīng)用程序，并讓各類應(yīng)用程序運(yùn)行在統(tǒng)一的架構(gòu)上，消除了為其他框架維護(hù)獨(dú)有資源的開銷。就好比一個(gè)多層蛋糕，下面兩層是 HDFS 和 Yarn, 而 MapReduce 就只是蛋糕上層的一根蠟燭而已，在蛋糕上還能插各式各樣的蠟燭。

在這一架構(gòu)體系中，總體數(shù)據(jù)處理分析作業(yè)分三塊(圖 2)，在 HBase 上做交互式查詢(Apache Phoenix, Cloudera Impala 等)， 在歷史數(shù)據(jù)集上編寫 MapReduce 程序抑或利用 Hive 等做批處理業(yè)務(wù)， 另外對(duì)于實(shí)時(shí)流數(shù)據(jù)分析 Apache Storm 則會(huì)是一種標(biāo)準(zhǔn)選擇方案。

雖然 Yarn 的出現(xiàn)極大地豐富了 Hadoop 生態(tài)圈的應(yīng)用場(chǎng)景，但仍存有兩個(gè)顯而易見的挑戰(zhàn)：一是在一個(gè)平臺(tái)上需要維護(hù)三個(gè)開發(fā)堆棧;二是在不同框架內(nèi)很難共享數(shù)據(jù)，比如很難在一個(gè)框架內(nèi)對(duì)流數(shù)據(jù)做交互式查詢。這也意味著我們需要一個(gè)更為統(tǒng)一和支持更好抽象的計(jì)算框架的出現(xiàn)。 

圖 2

一統(tǒng)江湖

Spark 的出現(xiàn)使得批處理任務(wù)，交互式查詢，實(shí)時(shí)流數(shù)據(jù)處理被整合到一個(gè)統(tǒng)一的框架內(nèi)(圖 3)，同時(shí) Spark 和現(xiàn)有的開源生態(tài)系統(tǒng)也能夠很好地兼容(Hadoop, HDFS, Yarn, Hive, Flume)。 通過啟用內(nèi)存分布數(shù)據(jù)集，優(yōu)化迭代工作負(fù)載， 用戶能夠更簡(jiǎn)單地操作數(shù)據(jù)，并在此基礎(chǔ)上開發(fā)更為精細(xì)的算法，如機(jī)器學(xué)習(xí)和圖算法等。

有三個(gè)最主要的原因促使 Spark 目前成為了時(shí)下最火的大數(shù)據(jù)開源社區(qū)(擁有超過來自 200 多個(gè)公司的 800 多個(gè) contributors)：

1. Spark 可以擴(kuò)展部署到超過 8000 節(jié)點(diǎn)并處理 PB 級(jí)別的數(shù)據(jù)，同時(shí)也提供了很多不錯(cuò)的工具供應(yīng)用開發(fā)者進(jìn)行管理和部署;
2. Spark 提供了一個(gè)交互式 shell 供開發(fā)者可以用 Scala 或者 Python 即時(shí)性試驗(yàn)不同的功能;
3. Spark 提供了很多內(nèi)置函數(shù)使得開發(fā)者能夠比較容易地寫出低耦合的并且能夠并發(fā)執(zhí)行的代碼，這樣開發(fā)人員就更能集中精力地為用戶提供更多的業(yè)務(wù)功能而不是花費(fèi)時(shí)間在優(yōu)化并行化代碼之上。

當(dāng)然 Spark 也和當(dāng)年的 MapReduce 一樣不是萬靈藥，比如對(duì)實(shí)時(shí)性要求很高的流數(shù)據(jù)處理上 Apache Storm 還是被作為主流選擇， 因?yàn)? Spark Streaming 實(shí)際上是 microbatch(將一個(gè)流數(shù)據(jù)按時(shí)間片切成 batch, 每個(gè) batch 提交一個(gè) job)而不是事件觸發(fā)實(shí)時(shí)系統(tǒng)，所以雖然支持者們認(rèn)為 microbatch 在系統(tǒng)延時(shí)性上貢獻(xiàn)并不多，但在生產(chǎn)環(huán)境中和 Apache Storm 相比還不是特別能滿足對(duì)低延時(shí)要求很高的應(yīng)用場(chǎng)景。

比如在實(shí)踐過程中， 如果統(tǒng)計(jì)每條消息的平均處理時(shí)間，很容易達(dá)到毫秒級(jí)別，但一旦統(tǒng)計(jì)類似 service assurance(確保某條消息在毫秒基本能被處理完成)的指標(biāo)， 系統(tǒng)的瓶頸有時(shí)還是不能避免。

但同時(shí)我們不能不注意到，在許多用例當(dāng)中，與流數(shù)據(jù)的交互以及和靜態(tài)數(shù)據(jù)集的結(jié)合是很有必要的, 例如我們需要在靜態(tài)數(shù)據(jù)集上進(jìn)行分類器的模型計(jì)算，并在已有分類器模型的基礎(chǔ)上，對(duì)實(shí)時(shí)進(jìn)入系統(tǒng)的流數(shù)據(jù)進(jìn)行交互計(jì)算來判定類別。

由于 Spark 的系統(tǒng)設(shè)計(jì)對(duì)各類工作(批處理、流處理以及交互式工作)進(jìn)行了一個(gè)共有抽象，并且生態(tài)圈內(nèi)延伸出了許多豐富的庫(MLlib 機(jī)器學(xué)習(xí)庫、SQL 語言 API、GraphX), 使得用戶可以在每一批流數(shù)據(jù)上進(jìn)行靈活的 Spark 相關(guān)操作，在開發(fā)上提供了許多便利。

Spark 的成熟使得 Hadoop 生態(tài)圈在短短一年之間發(fā)生了翻天覆地的變化， Cloudera 和 Hortonworks 紛紛加入了 Spark 陣營，而 Hadoop 項(xiàng)目群中除了 Yarn 之外已經(jīng)沒有項(xiàng)目是必須的了(雖然 Mesos 已在一些場(chǎng)合替代了 Yarn), 因?yàn)榫瓦B HDFS，Spark 都可以不依賴。但很多時(shí)候我們?nèi)匀恍枰?Impala 這樣的依賴分布式文件系統(tǒng)的 MPP 解決方案并利用 Hive 管理文件到表的映射，因此 Hadoop 傳統(tǒng)生態(tài)圈依然有很強(qiáng)的生命力。

另外在這里簡(jiǎn)要對(duì)比一下交互式分析任務(wù)中各類 SQL on Hadoop 框架，因?yàn)檫@也是我們?cè)趯?shí)際項(xiàng)目實(shí)施中經(jīng)常遇到的問題。我們主要將注意力集中在 Spark SQL, Impala 和 Hive on Tez 上, 其中 Spark SQL 是三者之中歷史最短的，論文發(fā)表在 15 年的 SIGMOD 會(huì)議上， 原文對(duì)比了數(shù)據(jù)倉庫上不同類型的查詢?cè)?Shark(Spark 最早對(duì) SQL 接口提供的支持)、Spark SQL 和 Impala 上的性能比較。

也就是說， 雖然 Spark SQL 在 Shark 的基礎(chǔ)上利用 Catalyst optimizer 在代碼生成上做了很多優(yōu)化，但總體性能還是比不上 Impala, 尤其是當(dāng)做 join 操作的時(shí)候， Impala 可以利用“predicate pushdown”更早對(duì)表進(jìn)行選擇操作從而提高性能。

不過 Spark SQL 的 Catalyst optimizer 一直在持續(xù)優(yōu)化中，相信未來會(huì)有更多更好的進(jìn)展。Cloudera 的 Benchmark 評(píng)測(cè)中 Impala 一直比其他 SQL on Hadoop 框架性能更加優(yōu)越，但同時(shí) Hortonworks 評(píng)測(cè)則指出雖然單個(gè)數(shù)據(jù)倉庫查詢 Impala 可以在很短的時(shí)間內(nèi)完成，但是一旦并發(fā)多個(gè)查詢 Hive on Tez 的優(yōu)勢(shì)就展示出來。另外 Hive on Tez 在 SQL 表達(dá)能力也要比 Impala 更強(qiáng)(主要是因?yàn)?Impala 的嵌套存儲(chǔ)模型導(dǎo)致的)， 因此根據(jù)不同的場(chǎng)景選取不同的解決方案是很有必要的。 

圖 3

各領(lǐng)風(fēng)騷抑或代有才人出?

近一年比較吸引人眼球的 Apache Flink(與 Spark 一樣已有 5 年歷史，前身已經(jīng)是柏林理工大學(xué)一個(gè)研究性項(xiàng)目，被其擁躉推崇為繼 MapReduce, Yarn，Spark 之后第四代大數(shù)據(jù)分析處理框架)。 與 Spark 相反，F(xiàn)link 是一個(gè)真正的實(shí)時(shí)流數(shù)據(jù)處理系統(tǒng)，它將批處理看作是流數(shù)據(jù)的特例，同 Spark 一樣它也在嘗試建立一個(gè)統(tǒng)一的平臺(tái)運(yùn)行批量，流數(shù)據(jù)，交互式作業(yè)以及機(jī)器學(xué)習(xí)，圖算法等應(yīng)用。

Flink 有一些設(shè)計(jì)思路是明顯區(qū)別于 Spark 的，一個(gè)典型的例子是內(nèi)存管理，F(xiàn)link 從一開始就堅(jiān)持自己精確的控制內(nèi)存使用并且直接操作二進(jìn)制數(shù)據(jù)，而 Spark 一直到 1.5 版本都還是試用 java 的內(nèi)存管理來做數(shù)據(jù)緩存，這也導(dǎo)致了 Spark 很容易遭受 OOM 以及 JVM GC 帶來的性能損失。

但是從另外一個(gè)角度來說, Spark 中的 RDD 在運(yùn)行時(shí)被存成 java objects 的設(shè)計(jì)模式也大大降低了用戶編程設(shè)計(jì)門檻， 同時(shí)隨著 Tungsten 項(xiàng)目的引入，Spark 現(xiàn)在也逐漸轉(zhuǎn)向自身的內(nèi)存管理， 具體表現(xiàn)為 Spark 生態(tài)圈內(nèi)從傳統(tǒng)的圍繞 RDD(分布式 java 對(duì)象集合)為核心的開發(fā)逐漸轉(zhuǎn)向以 DataFrame(分布式行對(duì)象集合) 為核心。

總的來說，這兩個(gè)生態(tài)圈目前都在互相學(xué)習(xí)，F(xiàn)link 的設(shè)計(jì)基因更為超前一些，但 Spark 社區(qū)活躍度大很多，發(fā)展到目前毫無疑問是更為成熟的選擇，比如對(duì)數(shù)據(jù)源的支持(HBase, Cassandra, Parquet, JSON, ORC)更為豐富以及更為統(tǒng)一簡(jiǎn)潔的計(jì)算表示。另一方面，Apache Flink 作為一個(gè)由歐洲大陸發(fā)起的項(xiàng)目，目前已經(jīng)擁有來自北美、歐洲以及亞洲的許多貢獻(xiàn)者，這是否能夠一改歐洲在開源世界中一貫的被動(dòng)角色，我們將在未來拭目以待。

2. NoSQL 數(shù)據(jù)庫篇

NoSQL 數(shù)據(jù)庫在主流選擇上依舊集中在 MongoDB, HBase 和 Cassandra 這三者之間。在所有的 NoSQL 選擇中，用 C++ 編寫的 MongoDB 幾乎應(yīng)該是開發(fā)者最快也最易部署的選擇。MongoDB 是一個(gè)面向文檔的數(shù)據(jù)庫，每個(gè)文檔/記錄/數(shù)據(jù)(包括爬取的網(wǎng)頁數(shù)據(jù)及其他大型對(duì)象如視頻等)是以一種 BSON(Binary JSON)的二進(jìn)制數(shù)據(jù)格式存儲(chǔ), 這使得 MongoDB 并不需要事先定義任何模式, 也就是模式自由(可以把完全不同結(jié)構(gòu)的記錄放在同一個(gè)數(shù)據(jù)庫里)。

MongoDB 對(duì)于完全索引的支持在應(yīng)用上是很方便的，同時(shí)也具備一般 NoSQL 分布式數(shù)據(jù)庫中可擴(kuò)展，支持復(fù)制和故障恢復(fù)等功能。 MongoDB 一般應(yīng)用于高度伸縮性的緩存及大尺寸的 JSON 數(shù)據(jù)存儲(chǔ)業(yè)務(wù)中，但不能執(zhí)行“JOIN”操作，而且數(shù)據(jù)占用空間也比較大，最被用戶詬病的就是由于 MongoDB 提供的是數(shù)據(jù)庫級(jí)鎖粒度導(dǎo)致在一些情況下建索引操作會(huì)引發(fā)整個(gè)數(shù)據(jù)庫阻塞。一般來說，MongoDB 完全可以滿足一些快速迭代的中小型項(xiàng)目的需求。

下面來主要談?wù)?Cassandra 和 HBase 之間的比較選擇。Cassandra 和 HBase 有著截然不同的基因血統(tǒng)。HBase 和其底層依賴的系統(tǒng)架構(gòu)源自于著名的 Google FileSystem(發(fā)表于 2003 年)和 Google BigTable 設(shè)計(jì)(發(fā)表于 2006 年)， 其克服了 HDFS 注重吞吐量卻犧牲 I/O 的缺點(diǎn)，提供了一個(gè)存儲(chǔ)中間層使得用戶或者應(yīng)用程序可以隨機(jī)讀寫數(shù)據(jù)。

具體來說，HBase 的更新和刪除操作實(shí)際上是先發(fā)生在內(nèi)存 MemStore 中， 當(dāng) MemStore 滿了以后會(huì) Flush 到 StoreFile, 之后當(dāng) StoreFile 文件數(shù)量增長(zhǎng)到一定閾值后會(huì)觸發(fā) Compact 合并操作，因此 HBase 的更新操作其實(shí)是不斷追加的操作，而最終所有更新和刪除數(shù)據(jù)的持久化操作都是在之后 Compact 過程中進(jìn)行的。

這使得應(yīng)用程序在向內(nèi)存 MemStore 寫入數(shù)據(jù)后，所做的修改馬上就能得到反映，用戶讀到的數(shù)據(jù)絕不會(huì)是陳舊的數(shù)據(jù)，保證了 I/O 高性能和數(shù)據(jù)完全一致性; 另一方面來說， HBase 基于 Hadoop 生態(tài)系統(tǒng)的基因就已經(jīng)決定了他自身的高度可擴(kuò)展性、容錯(cuò)性。

在數(shù)據(jù)模型上，Cassandra 和 HBase 類似實(shí)現(xiàn)了一個(gè) key-value 提供面向列式存儲(chǔ)服務(wù)，其系統(tǒng)設(shè)計(jì)參考了 Amazon Dynamo (發(fā)表于 2007 年) 分布式哈希(DHT)的 P2P 結(jié)構(gòu)(實(shí)際上大部分 Cassandra 的初始工作都是由兩位從 Amazon 的 Dynamo 組跳槽到 Facebook 的工程師完成)，同樣具有很高的可擴(kuò)展性和容錯(cuò)性等特點(diǎn)。

除此之外， 相對(duì) HBase 的主從結(jié)構(gòu)，Cassandra 去中心化的 P2P 結(jié)構(gòu)能夠更簡(jiǎn)單地部署和維護(hù)，比如增加一臺(tái)機(jī)器只需告知 Cassandra 系統(tǒng)新節(jié)點(diǎn)在哪，剩下的交給系統(tǒng)完成就行了。同時(shí)，Cassandra 對(duì)多數(shù)據(jù)中心的支持也更好，如果需要在多個(gè)數(shù)據(jù)中心進(jìn)行數(shù)據(jù)遷移 Cassandra 會(huì)是一個(gè)更優(yōu)的選擇。

Eric Brewer 教授提出的經(jīng)典 CAP 理論認(rèn)為任何基于網(wǎng)絡(luò)的數(shù)據(jù)共享系統(tǒng)，最多只能滿足數(shù)據(jù)一致性、可用性、分區(qū)容忍性三要素中的兩個(gè)要素。實(shí)際分布式系統(tǒng)的設(shè)計(jì)過程往往都是在一致性與可用性上進(jìn)行取舍，相比于 HBase 數(shù)據(jù)完全一致性的系統(tǒng)設(shè)計(jì)，Cassandra 選擇了在優(yōu)先考慮數(shù)據(jù)可用性的基礎(chǔ)上讓用戶自己根據(jù)應(yīng)用程序需求決定系統(tǒng)一致性級(jí)別。

比如：用戶可以配置 QUONUM 參數(shù)來決定系統(tǒng)需要幾個(gè)節(jié)點(diǎn)返回?cái)?shù)據(jù)才能向客戶端做出響應(yīng)，ONE 指只要有一個(gè)節(jié)點(diǎn)返回?cái)?shù)據(jù)就可以對(duì)客戶端做出響應(yīng)，ALL 指等于數(shù)據(jù)復(fù)制份數(shù)的所有節(jié)點(diǎn)都返回結(jié)果才能向客戶端做出響應(yīng)，對(duì)于數(shù)據(jù)一致性要求不是特別高的可以選擇 ONE，它是最快的一種方式。

從基因和發(fā)展歷史上來說，HBase 更適合用做數(shù)據(jù)倉庫和大規(guī)模數(shù)據(jù)處理與分析(比如對(duì)網(wǎng)頁數(shù)據(jù)建立索引)， 而 Cassandra 則更適合用作實(shí)時(shí)事務(wù)和交互式查詢服務(wù)。Cassandra 在國外市場(chǎng)占有比例和發(fā)展要遠(yuǎn)比國內(nèi)紅火， 在不少權(quán)威測(cè)評(píng)網(wǎng)站上排名都已經(jīng)超過了 HBase。目前 Apache Cassandra 的商業(yè)化版本主要由軟件公司 DataStax 進(jìn)行開發(fā)和銷售推廣。另外還有一些 NoSQL 分布式數(shù)據(jù)庫如 Riak, CouchDB 也都在各自支持的廠商推動(dòng)下取得了不錯(cuò)的發(fā)展。

雖然我們也考慮到了 HBase 在實(shí)際應(yīng)用中的不便之處比如對(duì)二級(jí)索引的支持程度不夠(只支持通過單個(gè)行鍵訪問，通過行鍵的范圍查詢，全表掃描)，不過在明略的大數(shù)據(jù)基礎(chǔ)平臺(tái)上，目前整合的是依然是 HBase。

理由也很簡(jiǎn)單，HBase 出身就與 Hadoop 的生態(tài)系統(tǒng)緊密集成，其能夠很容易與其他 SQL on Hadoop 框架(Cloudera Impala, Apache Phoenix, or Hive on Tez)進(jìn)行整合，而不需要重新部署一套分布式數(shù)據(jù)庫系統(tǒng)，而且可以很方便地將同樣的數(shù)據(jù)內(nèi)容在同一個(gè)生態(tài)系統(tǒng)中根據(jù)不同框架需要來變換存儲(chǔ)格式(比如存儲(chǔ)成 Hive 表或者 Parquet 格式)。

我們?cè)诤芏囗?xiàng)目中都有需要用到多種 SQL on Hadoop 框架，來應(yīng)對(duì)不同應(yīng)用場(chǎng)景的情況，也體會(huì)到了在同一生態(tài)系統(tǒng)下部署多種框架的簡(jiǎn)便性。 但同時(shí)我們也遇到了一些問題， 因?yàn)?HBase 項(xiàng)目本身與 HDFS 和 Zookeeper 系統(tǒng)分別是由不同開源團(tuán)隊(duì)進(jìn)行維護(hù)的，所以在系統(tǒng)整合時(shí)我們需要先對(duì) HBase 所依賴的其他模塊進(jìn)行設(shè)置再對(duì) HBase 進(jìn)行配置，在一定程度上降低了系統(tǒng)維護(hù)的友好性。

目前我們也已經(jīng)在考慮將 Cassandra 應(yīng)用到一些新的客戶項(xiàng)目中，因?yàn)楹芏嗥髽I(yè)級(jí)的應(yīng)用都需要將線上線下數(shù)據(jù)庫進(jìn)行分離，HBase 更適合存儲(chǔ)離線處理的結(jié)果和數(shù)據(jù)倉庫，而更適合用作實(shí)時(shí)事務(wù)和并發(fā)交互性能更好的 Cassandra 作為線上服務(wù)數(shù)據(jù)庫會(huì)是一種很好的選擇。

3. 大數(shù)據(jù)安全篇

隨著越來越多各式各樣的數(shù)據(jù)被存儲(chǔ)在大數(shù)據(jù)系統(tǒng)中，任何對(duì)企業(yè)級(jí)數(shù)據(jù)的破壞都是災(zāi)難性的，從侵犯隱私到監(jiān)管違規(guī)，甚至?xí)斐晒酒放频钠茐牟⒆罱K影響到股東收益。給大數(shù)據(jù)系統(tǒng)提供全面且有效的安全解決方案的需求已經(jīng)十分迫切：

• 大數(shù)據(jù)系統(tǒng)存儲(chǔ)著許多重要且敏感的數(shù)據(jù)，這些數(shù)據(jù)是企業(yè)長(zhǎng)久以來的財(cái)富
• 與大數(shù)據(jù)系統(tǒng)互動(dòng)的外部系統(tǒng)是動(dòng)態(tài)變化的，這會(huì)給系統(tǒng)引入新的安全隱患
• 在一個(gè)企業(yè)的內(nèi)部，不同 Business Units 會(huì)用不同的方式與大數(shù)據(jù)系統(tǒng)進(jìn)行交互，比如線上的系統(tǒng)會(huì)實(shí)時(shí)給集群推送數(shù)據(jù)、數(shù)據(jù)科學(xué)家團(tuán)隊(duì)則需要分析存儲(chǔ)在數(shù)據(jù)倉庫內(nèi)的歷史數(shù)據(jù)、運(yùn)維團(tuán)隊(duì)則會(huì)需要對(duì)大數(shù)據(jù)系統(tǒng)擁有管理權(quán)限。

因此為了保護(hù)公司業(yè)務(wù)、客戶、財(cái)務(wù)和名譽(yù)免于被侵害，大數(shù)據(jù)系統(tǒng)運(yùn)維團(tuán)隊(duì)必須將系統(tǒng)安全高度提高到和其他遺留系統(tǒng)一樣的級(jí)別。同時(shí)大數(shù)據(jù)系統(tǒng)并不意味著引入大的安全隱患，通過精細(xì)完整的設(shè)計(jì)，仍然能夠把一些傳統(tǒng)的系統(tǒng)安全解決方案對(duì)接到最新的大數(shù)據(jù)集群系統(tǒng)中。

一般來說，一個(gè)完整的企業(yè)級(jí)安全框架包括五個(gè)部分：

• Administration: 大數(shù)據(jù)集群系統(tǒng)的集中式管理，設(shè)定全局一致的安全策略
• Authentication: 對(duì)用戶和系統(tǒng)的認(rèn)證
• Authorization：授權(quán)個(gè)人用戶和組對(duì)數(shù)據(jù)的訪問權(quán)限
• Audit：維護(hù)數(shù)據(jù)訪問的日志記錄
• Data Protection：數(shù)據(jù)脫敏和加密以達(dá)到保護(hù)數(shù)據(jù)的目的

系統(tǒng)管理員要能夠提供覆蓋以上五個(gè)部分的企業(yè)級(jí)安全基礎(chǔ)設(shè)施，否則任何一環(huán)的缺失都可能給整個(gè)系統(tǒng)引入安全性風(fēng)險(xiǎn)。

在大數(shù)據(jù)系統(tǒng)安全集中式管理平臺(tái)這塊，由 Hortonworks 推出的開源項(xiàng)目 Apache Ranger 就可以十分全面地為用戶提供 Hadoop 生態(tài)圈的集中安全策略的管理，并解決授權(quán) (Authorization) 和審計(jì) (Audit)。例如，運(yùn)維管理員可以輕松地為個(gè)人用戶和組對(duì)文件、數(shù)據(jù)等的訪問策略，然后審計(jì)對(duì)數(shù)據(jù)源的訪問。

與 Ranger 提供相似功能的還有 Cloudera 推出的 Apache Sentry 項(xiàng)目，相比較而言 Ranger 的功能會(huì)更全面一些。

而在認(rèn)證(Authentication)方面, 一種普遍采用的解決方案是將基于 Kerberos 的認(rèn)證方案對(duì)接到企業(yè)內(nèi)部的 LDAP 環(huán)境中， Kerberos 也是唯一為 Hadoop 全面實(shí)施的驗(yàn)證技術(shù)。

另外值得一提的是 Apache Knox Gateway 項(xiàng)目，與 Ranger 提高集群內(nèi)部組件以及用戶互相訪問的安全不同，Knox 提供的是 Hadoop 集群與外界的唯一交互接口，也就是說所有與集群交互的 REST API 都通過 Knox 處理。這樣，Knox 就給大數(shù)據(jù)系統(tǒng)提供了一個(gè)很好的基于邊緣的安全(perimeter-based security)。

基于以上提到的五個(gè)安全指標(biāo)和 Hadoop 生態(tài)圈安全相關(guān)的開源項(xiàng)目， 已經(jīng)足已證明基于 Hadoop 的大數(shù)據(jù)平臺(tái)我們是能夠構(gòu)建一個(gè)集中、一致、全面且有效的安全解決方案。

4. 總結(jié)

本文主要介紹了如何將 Hadoop 和大數(shù)據(jù)生態(tài)圈的各部分重要組件有機(jī)地聯(lián)系在一起去創(chuàng)建一個(gè)能夠支撐批處理、交互式和實(shí)時(shí)分析工作的大數(shù)據(jù)平臺(tái)系統(tǒng)。其中，我們重點(diǎn)嘗試從計(jì)算框架、 NoSQL 數(shù)據(jù)庫以及大數(shù)據(jù)平臺(tái)安全這三方面分析了在不同的應(yīng)用場(chǎng)景中相應(yīng)的技術(shù)選型以及需要考慮到的權(quán)衡點(diǎn)，希望讓大家對(duì)如何建立一個(gè)完整可用的安全大數(shù)據(jù)平臺(tái)能有一個(gè)直觀的認(rèn)識(shí)。

作者介紹

江金陵，明略數(shù)據(jù)數(shù)據(jù)科學(xué)家，中山大學(xué)本科，碩士畢業(yè)于沙特阿拉伯阿卜杜拉國王科技大學(xué)，博士就讀于丹麥奧爾堡大學(xué)，攻讀博士期間赴斯德歌爾摩參與創(chuàng)立一款個(gè)性化新聞閱讀工具并提名瑞典最佳新媒體類移動(dòng)應(yīng)用，后加入歐洲前三大博彩公司 Unibet 負(fù)責(zé)實(shí)時(shí)個(gè)性化賽事推薦系統(tǒng)的大數(shù)據(jù)平臺(tái)開發(fā)工作。他曾在 ICDE、ICDM 等數(shù)據(jù)庫和數(shù)據(jù)挖掘頂級(jí)會(huì)議中發(fā)表過學(xué)術(shù)文章，對(duì)大數(shù)據(jù)環(huán)境下的搜索、推薦、自然語言處理等方面均有十分豐富的經(jīng)驗(yàn)。目前供職于明略數(shù)據(jù)數(shù)據(jù)科學(xué)家團(tuán)隊(duì)，負(fù)責(zé)公安和金融領(lǐng)域的大數(shù)據(jù)建模與開發(fā)工作。