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

一、計算框架篇

大數據的價值

只有在能指導人們做出有價值的決定時，數據才能體現其自身的價值。因此，大數據技術要服務于實際的用途，才是有意義的。一般來說，大數據可以從以下三個方面指導人們做出有價值的決定：

1、報表生成(比如根據用戶歷史點擊行為的跟蹤和綜合分析、應用程序活躍程度和用戶粘性計算等)；

2、診斷分析(例如分析為何用戶粘性下降、根據日志分析系統為何性能下降、垃圾郵件以及病毒的特征檢測等)；

3、決策(例如個性化新聞閱讀或歌曲推薦、預測增加哪些功能能增加用戶粘性、幫助廣告主進行廣告精準投放、設定垃圾郵件和病毒攔截策略等)。

進一步來看，大數據技術從以下三個方面解決了傳統技術難以達成的目標：

在歷史數據上的低延遲(交互式)查詢，目標是加快決策過程和時間，例如分析一個站點為何變緩慢并嘗試修復它；

在實時數據上的低延遲查詢，目的是幫助用戶和應用程序在實時數據上做出決策，例如實時檢測并阻攔病毒蠕蟲(一個病毒蠕蟲可以在1.3秒內攻擊1百萬臺主機)；

更加精細高級的數據處理算法，這可以幫助用戶做出“更好”的決策，例如圖數據處理、異常點檢測、趨勢分析及其他機器學習算法。

蛋糕模式

從將數據轉換成價值的角度來說，在Hadoop生態圈十年蓬勃成長的過程中，YARN和Spark這二者可以算得上是里程碑事件。Yarn的出現使得集群資源管理和數據處理流水線分離，大大革新并推動了大數據應用層面各種框架的發展(SQLonHadoop框架，流數據，圖數據，機器學習)。

它使得用戶不再受到MapReduce開發模式的約束，而是可以創建種類更為豐富的分布式應用程序，并讓各類應用程序運行在統一的架構上，消除了為其他框架維護獨有資源的開銷。就好比一個多層蛋糕，下面兩層是HDFS和Yarn，而MapReduce就只是蛋糕上層的一根蠟燭而已，在蛋糕上還能插各式各樣的蠟燭。

在這一架構體系中，總體數據處理分析作業分三塊(圖2)，在HBase上做交互式查詢(ApachePhoenix，ClouderaImpala等)，在歷史數據集上編寫MapReduce程序抑或利用Hive等做批處理業務，另外對于實時流數據分析ApacheStorm則會是一種標準選擇方案。

雖然Yarn的出現極大地豐富了Hadoop生態圈的應用場景，但仍存有兩個顯而易見的挑戰：一是在一個平臺上需要維護三個開發堆棧；二是在不同框架內很難共享數據，比如很難在一個框架內對流數據做交互式查詢。這也意味著我們需要一個更為統一和支持更好抽象的計算框架的出現。

一統江湖Spark的出現使得批處理任務，交互式查詢，實時流數據處理被整合到一個統一的框架內，同時Spark和現有的開源生態系統也能夠很好地兼容(Hadoop，HDFS，Yarn，Hive，Flume)。通過啟用內存分布數據集，優化迭代工作負載，用戶能夠更簡單地操作數據，并在此基礎上開發更為精細的算法，如機器學習和圖算法等。

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

1、Spark可以擴展部署到超過8000節點并處理PB級別的數據，同時也提供了很多不錯的工具供應用開發者進行管理和部署；

2、Spark提供了一個交互式shell供開發者可以用Scala或者Python即時性試驗不同的功能；

3、Spark提供了很多內置函數使得開發者能夠比較容易地寫出低耦合的并且能夠并發執行的代碼，這樣開發人員就更能集中精力地為用戶提供更多的業務功能而不是花費時間在優化并行化代碼之上。

當然Spark也和當年的MapReduce一樣不是萬靈藥，比如對實時性要求很高的流數據處理上ApacheStorm還是被作為主流選擇，因為SparkStreaming實際上是microbatch(將一個流數據按時間片切成batch，每個batch提交一個job)而不是事件觸發實時系統，所以雖然支持者們認為microbatch在系統延時性上貢獻并不多，但在生產環境中和ApacheStorm相比還不是特別能滿足對低延時要求很高的應用場景。

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

但同時我們不能不注意到，在許多用例當中，與流數據的交互以及和靜態數據集的結合是很有必要的，例如我們需要在靜態數據集上進行分類器的模型計算，并在已有分類器模型的基礎上，對實時進入系統的流數據進行交互計算來判定類別。

由于Spark的系統設計對各類工作(批處理、流處理以及交互式工作)進行了一個共有抽象，并且生態圈內延伸出了許多豐富的庫(MLlib機器學習庫、SQL語言API、GraphX)，使得用戶可以在每一批流數據上進行靈活的Spark相關操作，在開發上提供了許多便利。

Spark的成熟使得Hadoop生態圈在短短一年之間發生了翻天覆地的變化，Cloudera和Hortonworks紛紛加入了Spark陣營，而Hadoop項目群中除了Yarn之外已經沒有項目是必須的了(雖然Mesos已在一些場合替代了Yarn)，因為就連HDFS，Spark都可以不依賴。但很多時候我們仍然需要像Impala這樣的依賴分布式文件系統的MPP解決方案并利用Hive管理文件到表的映射，因此Hadoop傳統生態圈依然有很強的生命力。

另外在這里簡要對比一下交互式分析任務中各類SQLonHadoop框架，因為這也是我們在實際項目實施中經常遇到的問題。我們主要將注意力集中在SparkSQL，Impala和HiveonTez上，其中SparkSQL是三者之中歷史最短的，論文發表在15年的SIGMOD會議上，原文對比了數據倉庫上不同類型的查詢在Shark(Spark最早對SQL接口提供的支持)、SparkSQL和Impala上的性能比較。

也就是說，雖然SparkSQL在Shark的基礎上利用Catalystoptimizer在代碼生成上做了很多優化，但總體性能還是比不上Impala，尤其是當做join操作的時候，Impala可以利用“predicatepushdown”更早對表進行選擇操作從而提高性能。

不過SparkSQL的Catalystoptimizer一直在持續優化中，相信未來會有更多更好的進展。Cloudera的Benchmark評測中Impala一直比其他SQLonHadoop框架性能更加優越，但同時Hortonworks評測則指出雖然單個數據倉庫查詢Impala可以在很短的時間內完成，但是一旦并發多個查詢HiveonTez的優勢就展示出來。另外HiveonTez在SQL表達能力也要比Impala更強(主要是因為Impala的嵌套存儲模型導致的)，因此根據不同的場景選取不同的解決方案是很有必要的。

各領風騷抑或代有才人出？

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

Flink有一些設計思路是明顯區別于Spark的，一個典型的例子是內存管理，Flink從一開始就堅持自己精確的控制內存使用并且直接操作二進制數據，而Spark一直到1.5版本都還是試用java的內存管理來做數據緩存，這也導致了Spark很容易遭受OOM以及JVMGC帶來的性能損失。

但是從另外一個角度來說，Spark中的RDD在運行時被存成javaobjects的設計模式也大大降低了用戶編程設計門檻，同時隨著Tungsten項目的引入，Spark現在也逐漸轉向自身的內存管理，具體表現為Spark生態圈內從傳統的圍繞RDD(分布式java對象集合)為核心的開發逐漸轉向以DataFrame(分布式行對象集合)為核心。

總的來說，這兩個生態圈目前都在互相學習，Flink的設計基因更為超前一些，但Spark社區活躍度大很多，發展到目前毫無疑問是更為成熟的選擇，比如對數據源的支持(HBase，Cassandra，Parquet，JSON，ORC)更為豐富以及更為統一簡潔的計算表示。另一方面，ApacheFlink作為一個由歐洲大陸發起的項目，目前已經擁有來自北美、歐洲以及亞洲的許多貢獻者，這是否能夠一改歐洲在開源世界中一貫的被動角色，我們將在未來拭目以待。

二、NoSQL數據庫篇

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

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

下面來主要談談Cassandra和HBase之間的比較選擇。Cassandra和HBase有著截然不同的基因血統。HBase和其底層依賴的系統架構源自于著名的GoogleFileSystem(發表于2003年)和GoogleBigTable設計(發表于2006年)，其克服了HDFS注重吞吐量卻犧牲I/O的缺點，提供了一個存儲中間層使得用戶或者應用程序可以隨機讀寫數據。

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

這使得應用程序在向內存MemStore寫入數據后，所做的修改馬上就能得到反映，用戶讀到的數據絕不會是陳舊的數據，保證了I/O高性能和數據完全一致性；另一方面來說，HBase基于Hadoop生態系統的基因就已經決定了他自身的高度可擴展性、容錯性。

在數據模型上，Cassandra和HBase類似實現了一個key-value提供面向列式存儲服務，其系統設計參考了AmazonDynamo(發表于2007年)分布式哈希(DHT)的P2P結構(實際上大部分Cassandra的初始工作都是由兩位從Amazon的Dynamo組跳槽到Facebook的工程師完成)，同樣具有很高的可擴展性和容錯性等特點。

除此之外，相對HBase的主從結構，Cassandra去中心化的P2P結構能夠更簡單地部署和維護，比如增加一臺機器只需告知Cassandra系統新節點在哪，剩下的交給系統完成就行了。同時，Cassandra對多數據中心的支持也更好，如果需要在多個數據中心進行數據遷移Cassandra會是一個更優的選擇。

EricBrewer教授提出的經典CAP理論認為任何基于網絡的數據共享系統，最多只能滿足數據一致性、可用性、分區容忍性三要素中的兩個要素。實際分布式系統的設計過程往往都是在一致性與可用性上進行取舍，相比于HBase數據完全一致性的系統設計，Cassandra選擇了在優先考慮數據可用性的基礎上讓用戶自己根據應用程序需求決定系統一致性級別。

比如：用戶可以配置QUONUM參數來決定系統需要幾個節點返回數據才能向客戶端做出響應，ONE指只要有一個節點返回數據就可以對客戶端做出響應，ALL指等于數據復制份數的所有節點都返回結果才能向客戶端做出響應，對于數據一致性要求不是特別高的可以選擇ONE，它是最快的一種方式。

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

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

理由也很簡單，HBase出身就與Hadoop的生態系統緊密集成，其能夠很容易與其他SQLonHadoop框架(ClouderaImpala，ApachePhoenix，orHiveonTez)進行整合，而不需要重新部署一套分布式數據庫系統，而且可以很方便地將同樣的數據內容在同一個生態系統中根據不同框架需要來變換存儲格式(比如存儲成Hive表或者Parquet格式)。

我們在很多項目中都有需要用到多種SQLonHadoop框架，來應對不同應用場景的情況，也體會到了在同一生態系統下部署多種框架的簡便性。但同時我們也遇到了一些問題，因為HBase項目本身與HDFS和Zookeeper系統分別是由不同開源團隊進行維護的，所以在系統整合時我們需要先對HBase所依賴的其他模塊進行設置再對HBase進行配置，在一定程度上降低了系統維護的友好性。

目前我們也已經在考慮將Cassandra應用到一些新的客戶項目中，因為很多企業級的應用都需要將線上線下數據庫進行分離，HBase更適合存儲離線處理的結果和數據倉庫，而更適合用作實時事務和并發交互性能更好的Cassandra作為線上服務數據庫會是一種很好的選擇。

三、大數據安全篇

隨著越來越多各式各樣的數據被存儲在大數據系統中，任何對企業級數據的破壞都是災難性的，從侵犯隱私到監管違規，甚至會造成公司品牌的破壞并最終影響到股東收益。給大數據系統提供全面且有效的安全解決方案的需求已經十分迫切：

大數據系統存儲著許多重要且敏感的數據，這些數據是企業長久以來的財富

與大數據系統互動的外部系統是動態變化的，這會給系統引入新的安全隱患

在一個企業的內部，不同BusinessUnits會用不同的方式與大數據系統進行交互，比如線上的系統會實時給集群推送數據、數據科學家團隊則需要分析存儲在數據倉庫內的歷史數據、運維團隊則會需要對大數據系統擁有管理權限。

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

一般來說，一個完整的企業級安全框架包括五個部分：

Administration:大數據集群系統的集中式管理，設定全局一致的安全策略

Authentication:對用戶和系統的認證

Authorization：授權個人用戶和組對數據的訪問權限

Audit：維護數據訪問的日志記錄

DataProtection：數據脫敏和加密以達到保護數據的目的

系統管理員要能夠提供覆蓋以上五個部分的企業級安全基礎設施，否則任何一環的缺失都可能給整個系統引入安全性風險。

在大數據系統安全集中式管理平臺這塊，由Hortonworks推出的開源項目ApacheRanger就可以十分全面地為用戶提供Hadoop生態圈的集中安全策略的管理，并解決授權(Authorization)和審計(Audit)。例如，運維管理員可以輕松地為個人用戶和組對文件、數據等的訪問策略，然后審計對數據源的訪問。

與Ranger提供相似功能的還有Cloudera推出的ApacheSentry項目，相比較而言Ranger的功能會更全面一些。

而在認證(Authentication)方面，一種普遍采用的解決方案是將基于Kerberos的認證方案對接到企業內部的LDAP環境中，Kerberos也是唯一為Hadoop全面實施的驗證技術。

另外值得一提的是ApacheKnoxGateway項目，與Ranger提高集群內部組件以及用戶互相訪問的安全不同，Knox提供的是Hadoop集群與外界的唯一交互接口，也就是說所有與集群交互的RESTAPI都通過Knox處理。這樣，Knox就給大數據系統提供了一個很好的基于邊緣的安全(perimeter-basedsecurity)。

基于以上提到的五個安全指標和Hadoop生態圈安全相關的開源項目，已經足已證明基于Hadoop的大數據平臺我們是能夠構建一個集中、一致、全面且有效的安全解決方案。

四、總結

本文主要介紹了如何將Hadoop和大數據生態圈的各部分重要組件有機地聯系在一起去創建一個能夠支撐批處理、交互式和實時分析工作的大數據平臺系統。其中，我們重點嘗試從計算框架、NoSQL數據庫以及大數據平臺安全這三方面分析了在不同的應用場景中相應的技術選型以及需要考慮到的權衡點，希望讓大家對如何建立一個完整可用的安全大數據平臺能有一個直觀的認識。（來源：大數據雜談 文/江金陵）