要建立一個大數據系統，我們需要從數據流的源頭跟蹤到最後有價值的輸出，並在現有的 Hadoop 和大數據生態圈內根據實際需求挑選並整合各部分合適的組件來構建一個能夠支撐多種查詢和分析功能的系統平臺。這其中既包括了對數據存儲的選擇，也涵蓋了數據線上和線下處理分離等方面的思考和權衡。此外，沒有任何一個引入大數據解決方案的商業應用在生產環境上承擔的起安全隱患。
1. 計算框架篇
大數據的價值
只有在能指導人們做出有價值的決定時，數據才能體現其自身的價值。因此，大數據技術要服務於實際的用途，才是有意義的。一般來說，大數據可以從以下三個方面指導人們做出有價值的決定：
- 報表生成（比如根據用戶歷史點擊行為的跟蹤和綜合分析、 應用程序活躍程度和用戶粘性計算等）；
- 診斷分析 （例如分析為何用戶粘性下降、根據日誌分析系統為何性能下降、垃圾郵件以及病毒的特徵檢測等）；
- 決策（例如個性化新聞閱讀或歌曲推薦、預測增加哪些功能能增加用戶粘性、幫助廣告主進行廣告精準投放、設定垃圾郵件和病毒攔截策略等）。
進一步來看，大數據技術從以下三個方面解決了傳統技術難以達成的目標（如上圖）：
- 在歷史數據上的低延遲（交互式）查詢，目標是加快決策過程和時間， 例如分析一個站點為何變緩慢並嘗試修復它；
- 在實時數據上的低延遲查詢，目的是幫助用戶和應用程序在實時數據上做出決策， 例如實時檢測並阻攔病毒蠕蟲（一個病毒蠕蟲可以在 1.3 秒內攻擊 1 百萬臺主機）；
- 更加精細高級的數據處理算法，這可以幫助用戶做出“更好”的決策， 例如圖數據處理、異常點檢測、趨勢分析及其他機器學習算法。
蛋糕模式
從將數據轉換成價值的角度來說，在 Hadoop 生態圈十年蓬勃成長的過程中，YARN 和 Spark 這二者可以算得上是里程碑事件。Yarn 的出現使得集群資源管理和數據處理流水線分離，大大革新並推動了大數據應用層面各種框架的發展（SQL on Hadoop 框架, 流數據，圖數據，機器學習）。
它使得用戶不再受到 MapReduce 開發模式的約束，而是可以創建種類更為豐富的分佈式應用程序，並讓各類應用程序運行在統一的架構上，消除了為其他框架維護獨有資源的開銷。就好比一個多層蛋糕，下面兩層是 HDFS 和 Yarn, 而 MapReduce 就只是蛋糕上層的一根蠟燭而已，在蛋糕上還能插各式各樣的蠟燭。
在這一架構體系中，總體數據處理分析作業分三塊（圖 2），在 HBase 上做交互式查詢（Apache Phoenix, Cloudera Impala 等）， 在歷史數據集上編寫 MapReduce 程序抑或利用 Hive 等做批處理業務， 另外對於實時流數據分析 Apache Storm 則會是一種標準選擇方案。
雖然 Yarn 的出現極大地豐富了 Hadoop 生態圈的應用場景，但仍存有兩個顯而易見的挑戰：一是在一個平臺上需要維護三個開發堆棧；二是在不同框架內很難共享數據，比如很難在一個框架內對流數據做交互式查詢。這也意味著我們需要一個更為統一和支持更好抽象的計算框架的出現。
一統江湖
Spark 的出現使得批處理任務，交互式查詢，實時流數據處理被整合到一個統一的框架內（圖 3），同時 Spark 和現有的開源生態系統也能夠很好地兼容（Hadoop, HDFS, Yarn, Hive, Flume）。 通過啟用內存分佈數據集，優化迭代工作負載， 用戶能夠更簡單地操作數據，並在此基礎上開發更為精細的算法，如機器學習和圖算法等。
有三個最主要的原因促使 Spark 目前成為了時下最火的大數據開源社區（擁有超過來自 200 多個公司的 800 多個 contributors）：
- Spark 可以擴展部署到超過 8000 節點並處理 PB 級別的數據，同時也提供了很多不錯的工具供應用開發者進行管理和部署；
- Spark 提供了一個交互式 shell 供開發者可以用 Scala 或者 Python 即時性試驗不同的功能；
- 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 的嵌套存儲模型導致的）， 因此根據不同的場景選取不同的解決方案是很有必要的。
各領風騷抑或代有才人出？
近一年比較吸引人眼球的 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 作為一個由歐洲大陸發起的項目，目前已經擁有來自北美、歐洲以及亞洲的許多貢獻者，這是否能夠一改歐洲在開源世界中一貫的被動角色，我們將在未來拭目以待。
2. NoSQL 數據庫篇
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 作為線上服務數據庫會是一種很好的選擇。
3. 大數據安全篇
隨著越來越多各式各樣的數據被存儲在大數據系統中，任何對企業級數據的破壞都是災難性的，從侵犯隱私到監管違規，甚至會造成公司品牌的破壞並最終影響到股東收益。給大數據系統提供全面且有效的安全解決方案的需求已經十分迫切：
- 大數據系統存儲著許多重要且敏感的數據，這些數據是企業長久以來的財富
- 與大數據系統互動的外部系統是動態變化的，這會給系統引入新的安全隱患
- 在一個企業的內部，不同 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 的大數據平臺我們是能夠構建一個集中、一致、全面且有效的安全解決方案。
4. 總結
本文主要介紹瞭如何將 Hadoop 和大數據生態圈的各部分重要組件有機地聯繫在一起去創建一個能夠支撐批處理、交互式和實時分析工作的大數據平臺系統。其中，我們重點嘗試從計算框架、 NoSQL 數據庫以及大數據平臺安全這三方面分析了在不同的應用場景中相應的技術選型以及需要考慮到的權衡點，希望讓大家對如何建立一個完整可用的安全大數據平臺能有一個直觀的認識。
閱讀更多 UMapper 的文章
