一說到開源大數據處理平臺，就不得不說此領域的開山鼻祖Hadoop，它是GFS和MapReduce的開源實現。雖然在此之前有很多類似的分布式存儲和計算平臺，但真正能實現工業級應用、降低使用門檻、帶動業界大規模部署的就是Hadoop。得益于MapReduce框架的易用性和容錯性，以及同時包含存儲系統和計算系統，使得Hadoop成為大數據處理平臺的基石之一。Hadoop能夠滿足大部分的離線存儲和離線計算需求，且性能表現不俗；小部分離線存儲和計算需求，在對性能要求不高的情況下，也可以使用Hadoop實現。因此，在搭建大數據處理平臺的初期，Hadoop能滿足90%以上的離線存儲和離線計算需求，成為了各大公司初期平臺的首選。
隨著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選取、熱備切換、資源定位、分布式鎖、配置管理等場景。
數據在其生命周期是流動的，往往會有產生、收集、存儲、計算、銷毀等不同狀態，數據可以在不同狀態之間流動，也可以從同一個狀態的內部進行流動（例如計算狀態），流動時上下游的載體有很多種，例如終端、線上日志服務器、存儲集群、計算集群等。在后臺，多數情況下都是在大數據平臺之間流動，因此各個大數據平臺并不是孤立的，處理數據時，它們往往成為上下游的關系，而數據從上游流往下游，就需要一個數據管道，來正確連接每份數據正確的上下游，這個場景的需求可以使用Kafka集群來很好地解決。Kafka最初是由LinkedIn開發的，是一個分布式的消息發布與訂閱系統。Kafka集群可以充當一個大數據管道的角色，負責正確連接每種數據的上下游。各個上游產生的數據都發往Kafka集群，而下游則通過向Kafka集群訂閱的方式，靈活選擇自己所需的上游數據。Kafka支持多個下游訂閱同一個上游數據。當上游產生了數據，Kafka會把數據進行一定時間窗口內的持久化，等待下游來讀取數據。Kafka的數據持久化方式及內部容錯機制，提供了較好的數據可靠性，它同時適合于離線和在線消息消費。
以上平臺的誕生時間點如下圖所示：
大數據平臺極大地提高了業界的生產力，使得海量數據的存儲、計算變得更加容易和高效。通過這些平臺的使用，可以快速搭建出一個承載海量用戶的應用，移動互聯網正是在它們的催化下不斷高速發展，改變我們的生活。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：談談開源大數據平臺的演變
相關文章
