大資料的價值

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

1. 報表生成（比如根據使用者歷史點選行為的跟蹤和綜合分析、 應用程式活躍程度和使用者粘性計算等）；

2. 診斷分析（例如分析為何使用者粘性下降、根據日誌分析系統為何效能下降、垃圾郵件以及病毒的特徵檢測等）；

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

圖 1

進一步來看，大資料技術從以下三個方面解決了傳統技術難以達成的目標（如圖1）：

1. 在歷史資料上的低延遲（互動式）查詢，目標是加快決策過程和時間， 例如分析一個站點為何變緩慢並嘗試修復它； 

2. 在實時資料上的低延遲查詢，目的是幫助使用者和應用程式在實時資料上做出決策， 例如實時檢測並阻攔病毒蠕蟲（一個病毒蠕蟲可以在1.3秒內攻擊1百萬臺主機）；

3. 更加精細高階的資料處理演算法，這可以幫助使用者做出“更好”的決策， 例如圖資料處理、異常點檢測、趨勢分析及其他機器學習演算法。

蛋糕模式

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

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

在這一架構體系中，總體資料處理分析作業分三塊（圖2），在HBase上做互動式查詢（Apache Phoenix, Cloudera Impala等）， 在歷史資料集上編寫MapReduce程式抑或利用Hive等做批處理業務， 另外對於實時流資料分析Apache Storm則會是一種標準選擇方案。

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

圖 2

一統江湖

Spark的出現使得批處理任務，互動式查詢，實時流資料處理被整合到一個統一的框架內（圖3），同時Spark和現有的開源生態系統也能夠很好地相容（Hadoop, HDFS, Yarn, Hive, Flume）。 通過啟用記憶體分佈資料集，優化迭代工作負載， 使用者能夠更簡單地操作資料，並在此基礎上開發更為精細的演算法，如機器學習和圖演算法等。

有三個最主要的原因促使Spark目前成為了時下最火的大資料開源社群（擁有超過來自200多個公司的800多個contributors）：

1. Spark可以擴充套件部署到超過8000節點並處理PB級別的資料，同時也提供了很多不錯的工具供應用開發者進行管理和部署；

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

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

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

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

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

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

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

另外在這裡簡要對比一下互動式分析任務中各類SQL on Hadoop框架，因為這也是我們在實際專案實施中經常遇到的問題。我們主要將注意力集中在Spark SQL, Impala和Hive on Tez上, 其中Spark SQL是三者之中歷史最短的，論文發表在15年的SIGMOD會議上， 原文對比了資料倉庫上不同型別的查詢在Shark（Spark最早對SQL介面提供的支援）、Spark SQL和Impala上的效能比較。

也就是說， 雖然Spark SQL在Shark的基礎上利用Catalyst optimizer在程式碼生成上做了很多優化，但總體效能還是比不上Impala, 尤其是當做join操作的時候， Impala可以利用“predicate pushdown”更早對錶進行選擇操作從而提高效能。

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

圖 3

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

近一年比較吸引人眼球的Apache Flink（與Spark一樣已有5年曆史，前身已經是柏林理工大學一個研究性專案，被其擁躉推崇為繼MapReduce, Yarn，Spark之後第四代大資料分析處理框架）。 與Spark相反，Flink是一個真正的實時流資料處理系統，它將批處理看作是流資料的特例，同Spark一樣它也在嘗試建立一個統一的平臺執行批量，流資料，互動式作業以及機器學習，圖演算法等應用。

Flink有一些設計思路是明顯區別於Spark的，一個典型的例子是記憶體管理，Flink從一開始就堅持自己精確的控制記憶體使用並且直接操作二進位制資料，而Spark一直到1.5版本都還是試用java的記憶體管理來做資料快取，這也導致了Spark很容易遭受OOM以及JVM GC帶來的效能損失。

但是從另外一個角度來說, Spark中的RDD在執行時被存成java objects的設計模式也大大降低了使用者程式設計設計門檻， 同時隨著Tungsten專案的引入，Spark現在也逐漸轉向自身的記憶體管理， 具體表現為Spark生態圈內從傳統的圍繞RDD（分散式java物件集合）為核心的開發逐漸轉向以DataFrame(分散式行物件集合)為核心。

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

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

MongoDB對於完全索引的支援在應用上是很方便的，同時也具備一般NoSQL分散式資料庫中可擴充套件，支援複製和故障恢復等功能。 MongoDB一般應用於高度伸縮性的快取及大尺寸的JSON資料儲存業務中，但不能執行“JOIN”操作，而且資料佔用空間也比較大，最被使用者詬病的就是由於MongoDB提供的是資料庫級鎖粒度導致在一些情況下建索引操作會引發整個資料庫阻塞。一般來說，MongoDB完全可以滿足一些快速迭代的中小型專案的需求。

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

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

這使得應用程式在向記憶體MemStore寫入資料後，所做的修改馬上就能得到反映，使用者讀到的資料絕不會是陳舊的資料，保證了I/O高效能和資料完全一致性； 另一方面來說， HBase基於Hadoop生態系統的基因就已經決定了他自身的高度可擴充套件性、容錯性。 

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

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

Eric Brewer教授提出的經典CAP理論認為任何基於網路的資料共享系統，最多隻能滿足資料一致性、可用性、分割槽容忍性三要素中的兩個要素。實際分散式系統的設計過程往往都是在一致性與可用性上進行取捨，相比於HBase資料完全一致性的系統設計，Cassandra選擇了在優先考慮資料可用性的基礎上讓使用者自己根據應用程式需求決定系統一致性級別。

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

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

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

理由也很簡單，HBase出身就與Hadoop的生態系統緊密整合，其能夠很容易與其他SQL on Hadoop框架（Cloudera Impala, Apache Phoenix, or Hive on Tez）進行整合，而不需要重新部署一套分散式資料庫系統，而且可以很方便地將同樣的資料內容在同一個生態系統中根據不同框架需要來變換儲存格式（比如儲存成Hive表或者Parquet格式）。

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

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

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

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

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

• 在一個企業的內部，不同Business Units會用不同的方式與大資料系統進行互動，比如線上的系統會實時給叢集推送資料、資料科學家團隊則需要分析儲存在資料倉庫內的歷史資料、運維團隊則會需要對大資料系統擁有管理許可權。

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

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

• Administration: 大資料集群系統的集中式管理，設定全域性一致的安全策略

• Authentication: 對使用者和系統的認證

• Authorization：授權個人使用者和組對資料的訪問許可權

• Audit：維護資料訪問的日誌記錄

• Data Protection：資料脫敏和加密以達到保護資料的目的

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

在大資料系統安全集中式管理平臺這塊，由Hortonworks推出的開源專案Apache Ranger就可以十分全面地為使用者提供Hadoop生態圈的集中安全策略的管理，並解決授權(Authorization)和審計(Audit)。例如，運維管理員可以輕鬆地為個人使用者和組對檔案、資料等的訪問策略，然後審計對資料來源的訪問。

與Ranger提供相似功能的還有Cloudera推出的Apache Sentry專案，相比較而言Ranger的功能會更全面一些。

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

另外值得一提的是Apache Knox Gateway專案，與Ranger提高叢集內部元件以及使用者互相訪問的安全不同，Knox提供的是Hadoop叢集與外界的唯一互動介面，也就是說所有與叢集互動的REST API都通過Knox處理。這樣，Knox就給大資料系統提供了一個很好的基於邊緣的安全（perimeter-based security）。

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

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

江金陵，明略資料資料科學家，中山大學本科，碩士畢業於沙烏地阿拉伯阿卜杜拉國王科技大學，博士就讀於丹麥奧爾堡大學，攻讀博士期間赴斯德歌爾摩參與創立一款個性化新聞閱讀工具並提名瑞典最佳新媒體類移動應用，後加入歐洲前三大博彩公司Unibet負責實時個性化賽事推薦系統的大資料平臺開發工作。他曾在ICDE、ICDM等資料庫和資料探勘頂級會議中發表過學術文章，對大資料環境下的搜尋、推薦、自然語言處理等方面均有十分豐富的經驗。目前供職於明略資料資料科學家團隊，負責公安和金融領域的大資料建模與開發工作。