大數據生態及其技術棧

大數據生態及其技術棧

原文：大數據生態及其技術棧

如何用形象的比喻描述大數據的技術生態？Hadoop、Hive、Spark 之間是什麼關係？對於大部分人來講都是傻傻分不清楚。

今年來大數據、人工智能得到了IT界大量的關注。若是一個企業不玩大數據，都很差意思說本身是在IT圈混的。我敢打賭，你在中關村西二旗地鐵站溜一圈，保準你會聽到以下名詞：Hadoop、Spark、MapReduce、NoSQL、離線計算、實時計算、實時推送等等一大串名稱。程序猿哥哥們就是有這麼實在，坐在地鐵上還能那麼投入的討論技術問題。那麼，這些聽起來高大上的技術，究竟都是幹什麼用的呢？他們之間的有什麼區別和聯繫？

一般，一個技術的興起，都是由現實需求驅動的。瞭解了咱們面臨的問題，就能更好的理解各個大數據技術的使用場景，各種大數據技術的區別也就顯而易見了。

網易大數據工程師@Xiaoyu Ma對大數據的話題進行了通俗的解讀，各位準備好小板凳，開講啦...

首先上一張大數據生態系統的圖：

Hadoop生態系統概覽

而後瞭解大數據技術棧中常見的概念：

Hadoop:Hadoop實現了一個分佈式文件系統（Hadoop Distributed File System），簡稱HDFS。HDFS有高容錯性的特色，而且設計用來部署在低廉的（low-cost）硬件上；並且它提供高吞吐量（high throughput）來訪問應用程序的數據，適合那些有着超大數據集（large data set）的應用程序。HDFS放寬了（relax）POSIX的要求，能夠以流的形式訪問（streaming access）文件系統中的數據。

Hadoop的框架最核心的設計就是：HDFS和MapReduce。HDFS爲海量的數據提供了存儲，則MapReduce爲海量的數據提供了計算。

HDFS:Hadoop分佈式文件系統(HDFS)被設計成適合運行在通用硬件(commodity hardware)上的分佈式文件系統。它和現有的分佈式文件系統有不少共同點。但同時，它和其餘的分佈式文件系統的區別也是很明顯的。HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。HDFS能提供高吞吐量的數據訪問，很是適合大規模數據集上的應用。HDFS放寬了一部分POSIX約束，來實現流式讀取文件系統數據的目的。HDFS在最開始是做爲Apache Nutch搜索引擎項目的基礎架構而開發的。HDFS是Apache Hadoop Core項目的一部分。HDFS有着高容錯性（fault-tolerant）的特色，而且設計用來部署在低廉的（low-cost）硬件上。並且它提供高吞吐量（high throughput）來訪問應用程序的數據，適合那些有着超大數據集（large data set）的應用程序。HDFS放寬了（relax）POSIX的要求（requirements）這樣能夠實現流的形式訪問（streaming access）文件系統中的數據。

Spark: Spark是一個高效的分佈式計算系統，相比Hadoop的Mapreduce計算框架，它在性能上比Mapreduce要高100倍。Spark提供比Hadoop更上層的API，一樣的算法在Spark中實現每每只有Hadoop的1/10或者1/100的長度。Shark相似「SQL on Spark」，是一個在Spark上數據倉庫的實現，在兼容Hive的狀況下，性能最高能夠達到Hive的一百倍。

HBase：是一個高可靠性、高性能、面向列、可伸縮的分佈式存儲系統，利用HBase技術可在廉價PC Server上搭建起大規模結構化數據集羣。像Facebook，都拿它作大型實時應用 Facebook's New Realtime Analytics System: HBase to Process 20 Billion Events Per Day

Pig：Yahoo開發的，並行地執行數據流處理的引擎，它包含了一種腳本語言，稱爲Pig Latin，用來描述這些數據流。Pig Latin自己提供了許多傳統的數據操做，同時容許用戶本身開發一些自定義函數用來讀取、處理和寫數據。在LinkedIn也是大量使用。

Hive：Facebook領導的一個數據倉庫工具，能夠將結構化的數據文件映射爲一張數據庫表，並提供完整的sql查詢功能，能夠將sql語句轉換爲MapReduce任務進行運行。其優勢是學習成本低，能夠經過類SQL語句快速實現簡單的MapReduce統計。像一些data scientist 就能夠直接查詢，不須要學習其餘編程接口。

Cascading/Scalding：Cascading是Twitter收購的一個公司技術，主要是提供數據管道的一些抽象接口，而後又推出了基於Cascading的Scala版本就叫Scalding。Coursera是用Scalding做爲MapReduce的編程接口放在Amazon的EMR運行。

Zookeeper：一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現。

Oozie：一個基於工做流引擎的開源框架。由Cloudera公司貢獻給Apache的，它可以提供對Hadoop MapReduce和Pig Jobs的任務調度與協調。

Azkaban: 跟上面很像，Linkedin開源的面向Hadoop的開源工做流系統，提供了相似於cron 的管理任務。

Tez：Hortonworks主推的優化MapReduce執行引擎，與MapReduce相比較，Tez在性能方面更加出色。

Mesos：一個分佈式環境的資源管理平臺，它使得Hadoop、MPI、Spark做業在統一資源管理環境下執行。它對Hadoop2.0支持很好。Twitter，Coursera都在使用。

Tachyon：是一個高容錯的分佈式文件系統，容許文件之內存的速度在集羣框架中進行可靠的共享，就像Spark和MapReduce那樣。有幸跟項目發起人李浩源聊過幾回，這個項目目前發展很是快，甚至比Spark當時還要驚人。目前到0.6版本，參與開源的規模和版本迭代速度都很快。已經拿到著名VC A16Z 750萬美金的投資，https://www.crunchbase.com/organization/tachyon-networks

看了這麼多大數據相關概念，相信你對大數據技術棧更迷糊了。下面是一段更加通俗的解讀：

大數據自己是個很寬泛的概念，Hadoop生態圈（或者泛生態圈）基本上都是爲了處理超過單機尺度的數據處理而誕生的。你能夠把它比做一個廚房因此須要的各類工具。鍋碗瓢盆，各有各的用處，互相之間又有重合。你能夠用湯鍋直接當碗吃飯喝湯，你能夠用小刀或者刨子去皮。可是每一個工具備本身的特性，雖然奇怪的組合也能工做，可是未必是最佳選擇。

大數據，首先你要能存的下大數據。
傳統的文件系統是單機的，不能橫跨不一樣的機器。HDFS（Hadoop Distributed FileSystem）的設計本質上是爲了大量的數據能橫跨成百上千臺機器，可是你看到的是一個文件系統而不是不少文件系統。好比你說我要獲取/hdfs/tmp/file1的數據，你引用的是一個文件路徑，可是實際的數據存放在不少不一樣的機器上。你做爲用戶，不須要知道這些，就比如在單機上你不關心文件分散在什麼磁道什麼扇區同樣。HDFS爲你管理這些數據。

存的下數據以後，你就開始考慮怎麼處理數據。雖然HDFS能夠爲你總體管理不一樣機器上的數據，可是這些數據太大了。一臺機器讀取成T上P的數據（很大的數據哦，好比整個東京熱有史以來全部高清電影的大小甚至更大），一臺機器慢慢跑也許須要好幾天甚至好幾周。對於不少公司來講，單機處理是不可忍受的，好比微博要更新24小時熱博，它必須在24小時以內跑完這些處理。那麼我若是要用不少臺機器處理，我就面臨瞭如何分配工做，若是一臺機器掛了如何從新啓動相應的任務，機器之間如何互相通訊交換數據以完成複雜的計算等等。這就是MapReduce / Tez / Spark的功能。MapReduce是第一代計算引擎，Tez和Spark是第二代。MapReduce的設計，採用了很簡化的計算模型，只有Map和Reduce兩個計算過程（中間用Shuffle串聯），用這個模型，已經能夠處理大數據領域很大一部分問題了。
那什麼是Map什麼是Reduce？
考慮若是你要統計一個巨大的文本文件存儲在相似HDFS上，你想要知道這個文本里各個詞的出現頻率。你啓動了一個MapReduce程序。Map階段，幾百臺機器同時讀取這個文件的各個部分，分別把各自讀到的部分分別統計出詞頻，產生相似
（hello, 12100次），（world，15214次）等等這樣的Pair（我這裏把Map和Combine放在一塊兒說以便簡化）；這幾百臺機器各自都產生了如上的集合，而後又有幾百臺機器啓動Reduce處理。Reducer機器A將從Mapper機器收到全部以A開頭的統計結果，機器B將收到B開頭的詞彙統計結果（固然實際上不會真的以字母開頭作依據，而是用函數產生Hash值以免數據串化。由於相似X開頭的詞確定比其餘要少得多，而你不但願數據處理各個機器的工做量相差懸殊）。而後這些Reducer將再次彙總，（hello，12100）＋（hello，12311）＋（hello，345881）= （hello，370292）。每一個Reducer都如上處理，你就獲得了整個文件的詞頻結果。
這看似是個很簡單的模型，但不少算法均可以用這個模型描述了。
Map＋Reduce的簡單模型很黃很暴力，雖然好用，可是很笨重。第二代的Tez和Spark除了內存Cache之類的新feature，本質上來講，是讓Map/Reduce模型更通用，讓Map和Reduce之間的界限更模糊，數據交換更靈活，更少的磁盤讀寫，以便更方便地描述複雜算法，取得更高的吞吐量。

有了MapReduce，Tez和Spark以後，程序員發現，MapReduce的程序寫起來真麻煩。他們但願簡化這個過程。這就比如你有了彙編語言，雖然你幾乎什麼都能幹了，可是你仍是以爲繁瑣。你但願有個更高層更抽象的語言層來描述算法和數據處理流程。因而就有了Pig和Hive。Pig是接近腳本方式去描述MapReduce，Hive則用的是SQL。它們把腳本和SQL語言翻譯成MapReduce程序，丟給計算引擎去計算，而你就從繁瑣的MapReduce程序中解脫出來，用更簡單更直觀的語言去寫程序了。

有了Hive以後，人們發現SQL對比Java有巨大的優點。一個是它太容易寫了。剛纔詞頻的東西，用SQL描述就只有一兩行，MapReduce寫起來大約要幾十上百行。而更重要的是，非計算機背景的用戶終於感覺到了愛：我也會寫SQL！因而數據分析人員終於從乞求工程師幫忙的窘境解脫出來，工程師也從寫奇怪的一次性的處理程序中解脫出來。你們都開心了。Hive逐漸成長成了大數據倉庫的核心組件。甚至不少公司的流水線做業集徹底是用SQL描述，由於易寫易改，一看就懂，容易維護。

自從數據分析人員開始用Hive分析數據以後，它們發現，Hive在MapReduce上跑，真雞巴慢！流水線做業集也許沒啥關係，好比24小時更新的推薦，反正24小時內跑完就算了。可是數據分析，人們老是但願能跑更快一些。好比我但願看過去一個小時內多少人在充氣娃娃頁面駐足，分別停留了多久，對於一個巨型網站海量數據下，這個處理過程也許要花幾十分鐘甚至不少小時。而這個分析也許只是你萬里長征的第一步，你還要看多少人瀏覽了跳蛋多少人看了拉赫曼尼諾夫的CD，以便跟老闆彙報，咱們的用戶是猥瑣男悶騷女更多仍是文藝青年／少女更多。你沒法忍受等待的折磨，只能跟帥帥的工程師蟈蟈說，快，快，再快一點！
因而Impala，Presto，Drill誕生了（固然還有無數非著名的交互SQL引擎，就不一一列舉了）。三個系統的核心理念是，MapReduce引擎太慢，由於它太通用，太強壯，太保守，咱們SQL須要更輕量，更激進地獲取資源，更專門地對SQL作優化，並且不須要那麼多容錯性保證（由於系統出錯了大不了從新啓動任務，若是整個處理時間更短的話，好比幾分鐘以內）。這些系統讓用戶更快速地處理SQL任務，犧牲了通用性穩定性等特性。若是說MapReduce是大砍刀，砍啥都不怕，那上面三個就是剔骨刀，靈巧鋒利，可是不能搞太大太硬的東西。

這些系統，說實話，一直沒有達到人們指望的流行度。由於這時候又兩個異類被造出來了。他們是Hive on Tez / Spark和SparkSQL。它們的設計理念是，MapReduce慢，可是若是我用新一代通用計算引擎Tez或者Spark來跑SQL，那我就能跑的更快。並且用戶不須要維護兩套系統。這就比如若是你廚房小，人又懶，對吃的精細程度要求有限，那你能夠買個電飯煲，能蒸能煲能燒，省了好多廚具。

上面的介紹，基本就是一個數據倉庫的構架了。底層HDFS，上面跑MapReduce／Tez／Spark，在上面跑Hive，Pig。或者HDFS上直接跑Impala，Drill，Presto。這解決了中低速數據處理的要求。

那若是我要更高速的處理呢？
若是我是一個相似微博的公司，我但願顯示不是24小時熱博，我想看一個不斷變化的熱播榜，更新延遲在一分鐘以內，上面的手段都將沒法勝任。因而又一種計算模型被開發出來，這就是Streaming（流）計算。Storm是最流行的流計算平臺。流計算的思路是，若是要達到更實時的更新，我何不在數據流進來的時候就處理了？好比仍是詞頻統計的例子，個人數據流是一個一個的詞，我就讓他們一邊流過我就一邊開始統計了。流計算很牛逼，基本無延遲，可是它的短處是，不靈活，你想要統計的東西必須預先知道，畢竟數據流過就沒了，你沒算的東西就沒法補算了。所以它是個很好的東西，可是沒法替代上面數據倉庫和批處理系統。

還有一個有些獨立的模塊是KV Store，好比Cassandra，HBase，MongoDB以及不少不少不少不少其餘的（多到沒法想象）。因此KV Store就是說，我有一堆鍵值，我能很快速滴獲取與這個Key綁定的數據。好比我用身份證號，能取到你的身份數據。這個動做用MapReduce也能完成，可是極可能要掃描整個數據集。而KV Store專用來處理這個操做，全部存和取都專門爲此優化了。從幾個P的數據中查找一個身份證號，也許只要零點幾秒。這讓大數據公司的一些專門操做被大大優化了。好比我網頁上有個根據訂單號查找訂單內容的頁面，而整個網站的訂單數量沒法單機數據庫存儲，我就會考慮用KV Store來存。KV Store的理念是，基本沒法處理複雜的計算，大多無法JOIN，也許無法聚合，沒有強一致性保證（不一樣數據分佈在不一樣機器上，你每次讀取也許會讀到不一樣的結果，也沒法處理相似銀行轉帳那樣的強一致性要求的操做）。可是丫就是快。極快。
每一個不一樣的KV Store設計都有不一樣取捨，有些更快，有些容量更高，有些能夠支持更復雜的操做。必有一款適合你。

除此以外，還有一些更特製的系統／組件，好比Mahout是分佈式機器學習庫，Protobuf是數據交換的編碼和庫，ZooKeeper是高一致性的分佈存取協同系統，等等。

有了這麼多亂七八糟的工具，都在同一個集羣上運轉，你們須要互相尊重有序工做。因此另一個重要組件是，調度系統。如今最流行的是Yarn。你能夠把他看做中央管理，比如你媽在廚房監工，哎，你妹妹切菜切完了，你能夠把刀拿去殺雞了。只要你們都服從你媽分配，那你們都能愉快滴燒菜。

你能夠認爲，大數據生態圈就是一個廚房工具生態圈。爲了作不一樣的菜，中國菜，日本菜，法國菜，你須要各類不一樣的工具。並且客人的需求正在複雜化，你的廚具不斷被髮明，也沒有一個萬用的廚具能夠處理全部狀況，所以它會變的愈來愈複雜。