大資料演變軌跡

標籤：tag   毫秒級   擴充   ssi   自然語言   傳遞   資料模型   開始   book   

一說到開源大資料處理平台，就不得不說此領域的開山鼻祖Hadoop，它是GFS和MapReduce的開源實現。雖然在此之前有很多類似的分布式儲存和計算平台，但真正能實現工業級應用、降低使用門檻、帶動業界大規模部署的就是Hadoop。得益於MapReduce架構的易用性和容錯性，以及同時包含儲存系統和計算系統，使得Hadoop成為大資料處理平台的基石之一。Hadoop能夠滿足大部分的離線儲存和離線計算需求，且效能表現不俗；小部分離線儲存和計算需求，在對效能要求不高的情況下，也可以使用Hadoop實現。因此，在搭建大資料處理平台的初期，Hadoop能滿足90%以上的離線儲存和離線計算需求，成為了各大公司初期平台的首選。

一共81個，開源大資料處理工具匯總（上）

一共81個，開源大資料處理工具匯總（下），包括日誌收集系統/叢集管理/RPC等

隨著Hadoop叢集越來越大，單點的namenode漸漸成為了問題：第一個問題是單機記憶體有限，承載不了越來越多的檔案數目；第二個問題是單點故障，嚴重影響叢集的高可用性。因此業界出現了幾種分布式namenode的方案，用以解決單點問題。此外，為了實現多種計算架構可以運行在同一個叢集中，充分複用機器資源，Hadoop引進了YARN。YARN是一個通用資源管理員，負責資源調度和資源隔離。它試圖成為各個計算架構的統一資源管理中心，使得同一個叢集可以同時跑MapReduce、storm、Tez等執行個體。

Hadoop解決了大資料平台的有無問題，隨著業務和需求的精細化發展，在一些細分領域人們對大資料平台提出了更高的期望和要求，因此誕生了一批在不同領域下的更高效更有針對性的平台。首先基於對Hadoop架構自身的改良，出現了haloop和dryad等變種平台，不過這些平台後來基本上都沒有被大規模部署，其原因要麼是改良效果不明顯，要麼是被跳出Hadoop架構重新設計的新平台所取代了。

為瞭解決在hadoop平台上更好地進行海量網頁分析，進而實現通用的分布式NoSQL資料庫的問題，HBase誕生了。Hadoop參照了Google的GFS和MapReduce的設計。而Google的BigTable在Hadoop的生態圈裡對應的則是HBase。HBase豐富了Hadoop的儲存方式，在hdfs的檔案式儲存的基礎上，提供了表格式儲存，使得可以將網頁的眾多屬性提取出來按欄位存放，提升網頁查詢分析的效率。同時，HBase也廣泛被用作通用的NoSQL儲存系統，它是基於列儲存的非關係型資料庫，彌補了hdfs在隨機讀寫方面的不足，提供低延時的資料訪問能力。但HBase本身沒有提供指令碼語言式（如SQL）的資料訪問方式，為了克服資料訪問的不便捷問題，最開始用於Hadoop的PIG語言開始支援HBase。PIG是一種操作Hadoop和Hbase的輕量級指令碼語言，不想編寫MapReduce作業的人員可以用PIG方便地訪問資料。

跟HBase類似的另一個較為有名的系統是C++編寫的Hypertable，也是BigTable的開源實現，不過由於後來維護的人員越來越少，以及Hadoop生態系統越來越活躍，漸漸地Hypertable被人們遺忘了。還有一個不得不提的系統是Cassandra，它最初由Facebook開發，也是一個分布式的NoSQL資料庫。但與HBase和Hypertable是Bigtable的複製者不同，Cassandra結合了Amazon的Dynamo的儲存模型和Bigtable的資料模型。它的一大特點是使用Gossip協議實現了去中心化的P2P儲存方式，所有伺服器都是等價的，不存在任何一個單點問題。Cassandra與HBase的區別在於：Cassandra配置簡單，平台組件少，叢集化部署和營運較容易，CAP定理側重於Availability和Partition tolerance，不提供行鎖，不適合儲存超大檔案；HBase配置相對複雜，平台組件多，叢集化部署和營運稍微麻煩，CAP定理側重於Consistency和Availability，提供行鎖，可處理超大檔案。

雖然Hadoop的MapReduce架構足夠易用，但是對於傳統使用SQL操作的資料倉儲類需求時，直接調用Map和Reduce介面來達到類似效果，還是相對繁瑣，而且對不熟悉MapReduce架構的使用者來說是一個門檻，因此hive就是為瞭解決此問題而誕生。它在Hadoop上建立了一個資料倉儲架構，可以將結構化的資料檔案映射成一張資料庫表，並提供類似SQL的查詢介面，彌補了Hadoop和資料倉儲操作的鴻溝，大大提高了資料查詢和展示類業務的生產效率。一方面，熟悉SQL的使用者只需要很小的成本就可以遷移至hive平台，另一方面，由於量級大而在傳統資料倉儲架構下已無法存放的資料，也可以較為容易地遷移到hive平台。因此hive平台已經成為了很多公司的大資料倉儲的核心方案。

Hive跟hbase在功能上也有小部分重疊的地方，它們的主要區別是：Hbase本質是一個資料庫，提供在儲存層的低延時資料讀寫能力，可用在即時情境，但沒有提供類SQL語言的查詢方式，所以資料查詢和計算不太方便（PIG學習成本較高）；hive本質是將SQL語句映射成MapReduce作業，延時較高但使用方便，適合離線情境，自身不做儲存。此外，hive可以搭建在Hbase之上，訪問Hbase的資料。

Hive的出現橋接了Hadoop與資料倉儲領域，但隨著hive的逐步應用，人們發現hive的效率並不是太高，原因是hive的查詢是使用MapReduce作業的方式實現的，是在計算層而不是儲存層，因此受到了MapReduce架構單一的資料轉送和互動方式的局限、以及作業調度開銷的影響。為了讓基於Hadoop的資料倉儲操作效率更高，在hive之後出現了另一個不同的實現方案——impala，它的基於Hadoop的資料查詢操作，並不是使用MapReduce作業的方式實現，而是跳過了Hadoop的計算層，直接讀寫hadoop的儲存層——hdfs來實現。由於省去了計算層，因此也就省去了計算層所有的開銷，避免了計算層的單一資料互動方式的問題，以及多輪計算之間的磁碟IO問題。直接讀寫hdfs，可以實現更加靈活的資料互動方式，提高讀寫效率。它實現了嵌套型資料的列儲存，同時採用了多層查詢樹，使得它可以在數千節點中快速地並存執行查詢與結果彙總。據一些公開的資料顯示，impala在各個情境下的效率可以比hive提升3~68倍，尤其在某些特殊情境下的效率提升甚至可達90倍。

Hadoop極大降低了海量資料計算能力的門檻，使得各個業務都可以快速使用Hadoop進行大資料分析，隨著分析計算的不斷深入，差異化的需求慢慢浮現了。人們開始發現，某些計算，如果時效性更快，收益會變得更大，能提供給使用者更好的體驗。一開始，在Hadoop平台上為了提高時效性，往往會將一整批次計算的海量資料，切割成小時級資料，甚至亞小時級資料，從而變成相對輕量的計算任務，使得在Hadoop上可以較快地計算出當前片段的結果，再把當前片段結果跟之前的累積結果進行合并，就可以較快地得出當前所需的整體結果，實現較高的時效性。但隨著互連網行業競爭越來越激烈，對時效性越來越看重，尤其是即時分析統計的需求大量湧現，分鐘級甚至秒級輸出結果，是大家所期望的。hadoop計算的時效性所能達到的極限一般為10分鐘左右，受限於叢集負載和調度策略，要想持續穩定地低於10分鐘是非常困難的，除非是專用叢集。因此，為了實現更高的時效性，在分鐘級、秒級、甚至毫秒級內計算出結果，Storm應運而生，它完全擺脫了MapReduce架構，重新設計了一個適用於流式計算的架構，以資料流為驅動，觸發計算，因此每來一條資料，就可以產生一次計算結果，時效性非常高，一般可以達到秒級。而且它的有向非循環圖計算拓撲的設計，提供了非常靈活豐富的計算方式，覆蓋了常見的即時計算需求，因此在業界得到了大量的部署應用。

Storm的核心架構保證資料流可靠性方式是：每條資料會被至少發送一次，即正常情況會發送一次，異常情況會重發。這樣會導致中間處理邏輯有可能會收到兩條重複的資料。大多數業務中這樣不會帶來額外的問題，或者是能夠容忍這樣的誤差，但對於有嚴格事務性要求的業務，則會出現問題，例如扣錢重複扣了兩次這是使用者不可接受的。為瞭解決此問題，Storm引入了事務拓撲，實現了精確處理一次的語義，後來被新的Trident機制所取代。Trident同時還提供了即時資料的join、groupby、filter等彙總查詢操作。

跟storm類似的系統還有yahoo的S4，不過storm的使用者遠遠多於S4，因此storm的發展比較迅速，功能也更加完善。

隨著大資料平台的逐步普及，人們不再滿足於如資料統計、資料關聯等簡單的挖掘，漸漸開始嘗試將機器學習/模式識別的演算法用于海量資料的深度挖掘中。因為機器學習/模式識別的演算法往往比較複雜，屬於計算密集型的演算法，且是單機演算法，所以在沒有Hadoop之前，將這些演算法用于海量資料上幾乎是不可行，至少是工業應用上不可行：一是單機計算不了如此大量的資料；二是就算單機能夠支撐，但計算時間太長，通常一次計算耗時從幾個星期到幾個月不等，這對於工業界來說資源和時間的消耗不可接受；三是沒有一個很易用的並行計算平台，可以將單機演算法快速改成並行演算法，導致演算法的並行化成本很高。而有了Hadoop之後，這些問題迎刃而解，一大批機器學習/模式識別的演算法得以快速用MapReduce架構並行化，被廣泛用在搜尋、廣告、自然語言處理、個人化推薦、安全等業務中。

那麼問題來了，上述的機器學習/模式識別演算法往往都是迭代型的計算，一般會迭代幾十至幾百輪，那麼在Hadoop上就是連續的幾十至幾百個串列的任務，前後兩個任務之間都要經過大量的IO來傳遞資料，據不完全統計，多數的迭代型演算法在Hadoop上的耗時，IO佔了80%左右，如果可以省掉這些IO開銷，那麼對計算速度的提升將是巨大的，因此業界興起了一股基於記憶體計算的潮流，而Spark則是這方面的佼佼者。它提出了RDD的概念，通過對RDD的使用將每輪的計算結果分布式地放在記憶體中，下一輪直接從記憶體中讀取上一輪的資料，節省了大量的IO開銷。同時它提供了比Hadoop的MapReduce方式更加豐富的資料操作方式，有些需要分解成幾輪的Hadoop操作，可在Spark裡一輪實現。因此對於機器學習/模式識別等迭代型計算，比起Hadoop平台，在Spark上的計算速度往往會有幾倍到幾十倍的提升。另一方面，Spark的設計初衷就是想兼顧MapReduce模式和迭代型計算，因此老的MapReduce計算也可以遷移至spark平台。由於Spark對Hadoop計算的相容，以及對迭代型計算的優異表現，成熟之後的Spark平台得到迅速的普及。

人們逐漸發現，Spark所具有的優點，可以擴充到更多的領域，現在Spark已經向通用多功能大資料平台的方向邁進。為了讓Spark可以用在資料倉儲領域，開發人員們推出了Shark，它在Spark的架構上提供了類SQL查詢介面，與Hive QL完全相容，但最近被使用者體驗更好的Spark SQL所取代。Spark SQL涵蓋了Shark的所有特性，並能夠加速現有Hive資料的查詢分析，以及支援直接對原生RDD對象進行關係查詢，顯著降低了使用門檻。在即時計算領域，Spark streaming項目構建了Spark上的即時計算架構，它將資料流切分成小的時間片段（例如幾秒），批量執行。得益於Spark的記憶體計算模式和低延時執行引擎，在Hadoop上做不到的即時計算，在Spark上變得可行。雖然時效性比專門的即時處理系統有一點差距，但也可用於不少即時/准即時情境。另外Spark上還有圖模型領域的Bagel，其實就是Google的Pregel在Spark上的實現。它提供基於圖的計算模式，後來被新的Spark圖模型API——GraphX所替代。

當大資料集群越來越大，出現局部故障的機率也越來越高，叢集核心資料的分布式一致性變得越來越難保證。Zookeeper的出現很好地解決了這個棘手的問題，它實現了著名的Fast Paxos演算法，提供了一個叢集化的分布式一致性服務，使得其他平台和應用可以通過簡單地調用它的服務來實現資料的分布式一致性，不需要自己關心具體的實現細節，使大資料平台開發人員可以將精力更加集中在平台自身特性上。例如Storm平台就是使用Zookeeper來儲存叢集元資訊（如節點資訊、狀態資訊、任務資訊等），從而可以簡單高效地實現容錯機制。即使某個組件出現故障，新的替代者可以快速地在Zookeeper上註冊以及擷取所需的元資訊，從而恢複失敗的任務。除了分布式一致性以外，Zookeeper還可以用作leader選取、熱備切換、資源定位、分布式鎖、組態管理等情境。

資料在其生命週期是流動的，往往會有產生、收集、儲存、計算、銷毀等不同狀態，資料可以在不同狀態之間流動，也可以從同一個狀態的內部進行流動（例如計算狀態），流動時上下遊的載體有很多種，例如終端、線上Log Service器、儲存叢集、計算叢集等。在後台，多數情況下都是在大資料平台之間流動，因此各個大資料平台並不是孤立的，處理資料時，它們往往成為上下遊的關係，而資料從上遊流往下遊，就需要一個資料管道，來正確串連每份資料正確的上下遊，這個情境的需求可以使用Kafka叢集來很好地解決。Kafka最初是由LinkedIn開發的，是一個分布式的訊息發布與訂閱系統。Kafka叢集可以充當一個大資料管道的角色，負責正確串連每種資料的上下遊。各個上遊產生的資料都發往Kafka叢集，而下遊則通過向Kafka叢集訂閱的方式，靈活選擇自己所需的上遊資料。Kafka支援多個下遊訂閱同一個上遊資料。當上遊產生了資料，Kafka會把資料進行一定時間視窗內的持久化，等待下遊來讀取資料。Kafka的資料持久化方式及內部容錯機制，提供了較好的資料可靠性，它同時適合於離線和線上訊息消費。

以上平台的誕生時間點如所示：

大資料平台極大地提高了業界的生產力，使得海量資料的儲存、計算變得更加容易和高效。通過這些平台的使用，可以快速搭建出一個承載海量使用者的應用，移動互連網正是在它們的催化下不斷高速發展，改變我們的生活。

大資料演變軌跡