一說到開源大數(shù)據(jù)處理平臺，就不得不說此領(lǐng)域的開山鼻祖Hadoop，它是GFS和MapReduce的開源實(shí)現(xiàn)。雖然在此之前有很多類似的分布式存儲和計算平臺，但真正能實(shí)現(xiàn)工業(yè)級應(yīng)用、降低使用門檻、帶動業(yè)界大規(guī)模部署的就是Hadoop。得益于MapReduce框架的易用性和容錯性，以及同時包含存儲系統(tǒng)和計算系統(tǒng)，使得Hadoop成為大數(shù)據(jù)處理平臺的基石之一。Hadoop能夠滿足大部分的離線存儲和離線計算需求，且性能表現(xiàn)不俗；小部分離線存儲和計算需求，在對性能要求不高的情況下，也可以使用Hadoop實(shí)現(xiàn)。因此，在搭建大數(shù)據(jù)處理平臺的初期，Hadoop能滿足90%以上的離線存儲和離線計算需求，成為了各大公司初期平臺的首選。
隨著Hadoop集群越來越大，單點(diǎn)的namenode漸漸成為了問題：第一個問題是單機(jī)內(nèi)存有限，承載不了越來越多的文件數(shù)目；第二個問題是單點(diǎn)故障，嚴(yán)重影響集群的高可用性。因此業(yè)界出現(xiàn)了幾種分布式namenode的方案，用以解決單點(diǎn)問題。此外，為了實(shí)現(xiàn)多種計算框架可以運(yùn)行在同一個集群中，充分復(fù)用機(jī)器資源，Hadoop引進(jìn)了YARN。YARN是一個通用資源管理器，負(fù)責(zé)資源調(diào)度和資源隔離。它試圖成為各個計算框架的統(tǒng)一資源管理中心，使得同一個集群可以同時跑MapReduce、storm、Tez等實(shí)例。
Hadoop解決了大數(shù)據(jù)平臺的有無問題，隨著業(yè)務(wù)和需求的精細(xì)化發(fā)展，在一些細(xì)分領(lǐng)域人們對大數(shù)據(jù)平臺提出了更高的期望和要求，因此誕生了一批在不同領(lǐng)域下的更高效更有針對性的平臺。首先基于對Hadoop框架自身的改良，出現(xiàn)了haloop和dryad等變種平臺，不過這些平臺后來基本上都沒有被大規(guī)模部署，其原因要么是改良效果不明顯，要么是被跳出Hadoop框架重新設(shè)計的新平臺所取代了。
為了解決在hadoop平臺上更好地進(jìn)行海量網(wǎng)頁分析，進(jìn)而實(shí)現(xiàn)通用的分布式NoSQL數(shù)據(jù)庫的問題，HBase誕生了。Hadoop參照了Google的GFS和MapReduce的設(shè)計。而Google的BigTable在Hadoop的生態(tài)圈里對應(yīng)的則是HBase。HBase豐富了Hadoop的存儲方式，在hdfs的文件式存儲的基礎(chǔ)上，提供了表格式存儲，使得可以將網(wǎng)頁的眾多屬性提取出來按字段存放，提升網(wǎng)頁查詢分析的效率。同時，HBase也廣泛被用作通用的NoSQL存儲系統(tǒng)，它是基于列存儲的非關(guān)系型數(shù)據(jù)庫，彌補(bǔ)了hdfs在隨機(jī)讀寫方面的不足，提供低延時的數(shù)據(jù)訪問能力。但HBase本身沒有提供腳本語言式（如SQL）的數(shù)據(jù)訪問方式，為了克服數(shù)據(jù)訪問的不便捷問題，最開始用于Hadoop的PIG語言開始支持HBase。PIG是一種操作Hadoop和Hbase的輕量級腳本語言，不想編寫MapReduce作業(yè)的人員可以用PIG方便地訪問數(shù)據(jù)。
跟HBase類似的另一個較為有名的系統(tǒng)是C++編寫的Hypertable，也是BigTable的開源實(shí)現(xiàn)，不過由于后來維護(hù)的人員越來越少，以及Hadoop生態(tài)系統(tǒng)越來越活躍，漸漸地Hypertable被人們遺忘了。還有一個不得不提的系統(tǒng)是Cassandra，它最初由Facebook開發(fā)，也是一個分布式的NoSQL數(shù)據(jù)庫。但與HBase和Hypertable是Bigtable的復(fù)制者不同，Cassandra結(jié)合了Amazon的Dynamo的存儲模型和Bigtable的數(shù)據(jù)模型。它的一大特點(diǎn)是使用Gossip協(xié)議實(shí)現(xiàn)了去中心化的P2P存儲方式，所有服務(wù)器都是等價的，不存在任何一個單點(diǎn)問題。Cassandra與HBase的區(qū)別在于：Cassandra配置簡單，平臺組件少，集群化部署和運(yùn)維較容易，CAP定理側(cè)重于Availability和Partition tolerance，不提供行鎖，不適合存儲超大文件；HBase配置相對復(fù)雜，平臺組件多，集群化部署和運(yùn)維稍微麻煩，CAP定理側(cè)重于Consistency和Availability，提供行鎖，可處理超大文件。
雖然Hadoop的MapReduce框架足夠易用，但是對于傳統(tǒng)使用SQL操作的數(shù)據(jù)倉庫類需求時，直接調(diào)用Map和Reduce接口來達(dá)到類似效果，還是相對繁瑣，而且對不熟悉MapReduce框架的使用者來說是一個門檻，因此hive就是為了解決此問題而誕生。它在Hadoop上建立了一個數(shù)據(jù)倉庫框架，可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射成一張數(shù)據(jù)庫表，并提供類似SQL的查詢接口，彌補(bǔ)了Hadoop和數(shù)據(jù)倉庫操作的鴻溝，大大提高了數(shù)據(jù)查詢和展示類業(yè)務(wù)的生產(chǎn)效率。一方面，熟悉SQL的使用者只需要很小的成本就可以遷移至hive平臺，另一方面，由于量級大而在傳統(tǒng)數(shù)據(jù)倉庫架構(gòu)下已無法存放的數(shù)據(jù)，也可以較為容易地遷移到hive平臺。因此hive平臺已經(jīng)成為了很多公司的大數(shù)據(jù)倉庫的核心方案。
Hive跟hbase在功能上也有小部分重疊的地方，它們的主要區(qū)別是：Hbase本質(zhì)是一個數(shù)據(jù)庫，提供在存儲層的低延時數(shù)據(jù)讀寫能力，可用在實(shí)時場景，但沒有提供類SQL語言的查詢方式，所以數(shù)據(jù)查詢和計算不太方便（PIG學(xué)習(xí)成本較高）；hive本質(zhì)是將SQL語句映射成MapReduce作業(yè)，延時較高但使用方便，適合離線場景，自身不做存儲。此外，hive可以搭建在Hbase之上，訪問Hbase的數(shù)據(jù)。
Hive的出現(xiàn)橋接了Hadoop與數(shù)據(jù)倉庫領(lǐng)域，但隨著hive的逐步應(yīng)用，人們發(fā)現(xiàn)hive的效率并不是太高，原因是hive的查詢是使用MapReduce作業(yè)的方式實(shí)現(xiàn)的，是在計算層而不是存儲層，因此受到了MapReduce框架單一的數(shù)據(jù)傳輸和交互方式的局限、以及作業(yè)調(diào)度開銷的影響。為了讓基于Hadoop的數(shù)據(jù)倉庫操作效率更高，在hive之后出現(xiàn)了另一個不同的實(shí)現(xiàn)方案——impala，它的基于Hadoop的數(shù)據(jù)查詢操作，并不是使用MapReduce作業(yè)的方式實(shí)現(xiàn)，而是跳過了Hadoop的計算層，直接讀寫hadoop的存儲層——hdfs來實(shí)現(xiàn)。由于省去了計算層，因此也就省去了計算層所有的開銷，避免了計算層的單一數(shù)據(jù)交互方式的問題，以及多輪計算之間的磁盤IO問題。直接讀寫hdfs，可以實(shí)現(xiàn)更加靈活的數(shù)據(jù)交互方式，提高讀寫效率。它實(shí)現(xiàn)了嵌套型數(shù)據(jù)的列存儲，同時采用了多層查詢樹，使得它可以在數(shù)千節(jié)點(diǎn)中快速地并行執(zhí)行查詢與結(jié)果聚合。據(jù)一些公開的資料顯示，impala在各個場景下的效率可以比hive提升3~68倍，尤其在某些特殊場景下的效率提升甚至可達(dá)90倍。
Hadoop極大降低了海量數(shù)據(jù)計算能力的門檻，使得各個業(yè)務(wù)都可以快速使用Hadoop進(jìn)行大數(shù)據(jù)分析，隨著分析計算的不斷深入，差異化的需求慢慢浮現(xiàn)了。人們開始發(fā)現(xiàn)，某些計算，如果時效性更快，收益會變得更大，能提供給用戶更好的體驗(yàn)。一開始，在Hadoop平臺上為了提高時效性，往往會將一整批計算的海量數(shù)據(jù)，切割成小時級數(shù)據(jù)，甚至亞小時級數(shù)據(jù)，從而變成相對輕量的計算任務(wù)，使得在Hadoop上可以較快地計算出當(dāng)前片段的結(jié)果，再把當(dāng)前片段結(jié)果跟之前的累積結(jié)果進(jìn)行合并，就可以較快地得出當(dāng)前所需的整體結(jié)果，實(shí)現(xiàn)較高的時效性。但隨著互聯(lián)網(wǎng)行業(yè)競爭越來越激烈，對時效性越來越看重，尤其是實(shí)時分析統(tǒng)計的需求大量涌現(xiàn)，分鐘級甚至秒級輸出結(jié)果，是大家所期望的。hadoop計算的時效性所能達(dá)到的極限一般為10分鐘左右，受限于集群負(fù)載和調(diào)度策略，要想持續(xù)穩(wěn)定地低于10分鐘是非常困難的，除非是專用集群。因此，為了實(shí)現(xiàn)更高的時效性，在分鐘級、秒級、甚至毫秒級內(nèi)計算出結(jié)果，Storm應(yīng)運(yùn)而生，它完全擺脫了MapReduce架構(gòu)，重新設(shè)計了一個適用于流式計算的架構(gòu)，以數(shù)據(jù)流為驅(qū)動，觸發(fā)計算，因此每來一條數(shù)據(jù)，就可以產(chǎn)生一次計算結(jié)果，時效性非常高，一般可以達(dá)到秒級。而且它的有向無環(huán)圖計算拓?fù)涞脑O(shè)計，提供了非常靈活豐富的計算方式，覆蓋了常見的實(shí)時計算需求，因此在業(yè)界得到了大量的部署應(yīng)用。
Storm的核心框架保證數(shù)據(jù)流可靠性方式是：每條數(shù)據(jù)會被至少發(fā)送一次，即正常情況會發(fā)送一次，異常情況會重發(fā)。這樣會導(dǎo)致中間處理邏輯有可能會收到兩條重復(fù)的數(shù)據(jù)。大多數(shù)業(yè)務(wù)中這樣不會帶來額外的問題，或者是能夠容忍這樣的誤差，但對于有嚴(yán)格事務(wù)性要求的業(yè)務(wù)，則會出現(xiàn)問題，例如扣錢重復(fù)扣了兩次這是用戶不可接受的。為了解決此問題，Storm引入了事務(wù)拓?fù)�，�?shí)現(xiàn)了精確處理一次的語義，后來被新的Trident機(jī)制所取代。Trident同時還提供了實(shí)時數(shù)據(jù)的join、groupby、filter等聚合查詢操作。
跟storm類似的系統(tǒng)還有yahoo的S4，不過storm的用戶遠(yuǎn)遠(yuǎn)多于S4，因此storm的發(fā)展比較迅速，功能也更加完善。
隨著大數(shù)據(jù)平臺的逐步普及，人們不再滿足于如數(shù)據(jù)統(tǒng)計、數(shù)據(jù)關(guān)聯(lián)等簡單的挖掘，漸漸開始嘗試將機(jī)器學(xué)習(xí)/模式識別的算法用于海量數(shù)據(jù)的深度挖掘中。因?yàn)闄C(jī)器學(xué)習(xí)/模式識別的算法往往比較復(fù)雜，屬于計算密集型的算法，且是單機(jī)算法，所以在沒有Hadoop之前，將這些算法用于海量數(shù)據(jù)上幾乎是不可行，至少是工業(yè)應(yīng)用上不可行：一是單機(jī)計算不了如此大量的數(shù)據(jù)；二是就算單機(jī)能夠支撐，但計算時間太長，通常一次計算耗時從幾個星期到幾個月不等，這對于工業(yè)界來說資源和時間的消耗不可接受；三是沒有一個很易用的并行計算平臺，可以將單機(jī)算法快速改成并行算法，導(dǎo)致算法的并行化成本很高。而有了Hadoop之后，這些問題迎刃而解，一大批機(jī)器學(xué)習(xí)/模式識別的算法得以快速用MapReduce框架并行化，被廣泛用在搜索、廣告、自然語言處理、個性化推薦、安全等業(yè)務(wù)中。
那么問題來了，上述的機(jī)器學(xué)習(xí)/模式識別算法往往都是迭代型的計算，一般會迭代幾十至幾百輪，那么在Hadoop上就是連續(xù)的幾十至幾百個串行的任務(wù)，前后兩個任務(wù)之間都要經(jīng)過大量的IO來傳遞數(shù)據(jù)，據(jù)不完全統(tǒng)計，多數(shù)的迭代型算法在Hadoop上的耗時，IO占了80%左右，如果可以省掉這些IO開銷，那么對計算速度的提升將是巨大的，因此業(yè)界興起了一股基于內(nèi)存計算的潮流，而Spark則是這方面的佼佼者。它提出了RDD的概念，通過對RDD的使用將每輪的計算結(jié)果分布式地放在內(nèi)存中，下一輪直接從內(nèi)存中讀取上一輪的數(shù)據(jù)，節(jié)省了大量的IO開銷。同時它提供了比Hadoop的MapReduce方式更加豐富的數(shù)據(jù)操作方式，有些需要分解成幾輪的Hadoop操作，可在Spark里一輪實(shí)現(xiàn)。因此對于機(jī)器學(xué)習(xí)/模式識別等迭代型計算，比起Hadoop平臺，在Spark上的計算速度往往會有幾倍到幾十倍的提升。另一方面，Spark的設(shè)計初衷就是想兼顧MapReduce模式和迭代型計算，因此老的MapReduce計算也可以遷移至spark平臺。由于Spark對Hadoop計算的兼容，以及對迭代型計算的優(yōu)異表現(xiàn)，成熟之后的Spark平臺得到迅速的普及。
人們逐漸發(fā)現(xiàn)，Spark所具有的優(yōu)點(diǎn)，可以擴(kuò)展到更多的領(lǐng)域，現(xiàn)在Spark已經(jīng)向通用多功能大數(shù)據(jù)平臺的方向邁進(jìn)。為了讓Spark可以用在數(shù)據(jù)倉庫領(lǐng)域，開發(fā)者們推出了Shark，它在Spark的框架上提供了類SQL查詢接口，與Hive QL完全兼容，但最近被用戶體驗(yàn)更好的Spark SQL所取代。Spark SQL涵蓋了Shark的所有特性，并能夠加速現(xiàn)有Hive數(shù)據(jù)的查詢分析，以及支持直接對原生RDD對象進(jìn)行關(guān)系查詢，顯著降低了使用門檻。在實(shí)時計算領(lǐng)域，Spark streaming項(xiàng)目構(gòu)建了Spark上的實(shí)時計算框架，它將數(shù)據(jù)流切分成小的時間片段（例如幾秒），批量執(zhí)行。得益于Spark的內(nèi)存計算模式和低延時執(zhí)行引擎，在Hadoop上做不到的實(shí)時計算，在Spark上變得可行。雖然時效性比專門的實(shí)時處理系統(tǒng)有一點(diǎn)差距，但也可用于不少實(shí)時/準(zhǔn)實(shí)時場景。另外Spark上還有圖模型領(lǐng)域的Bagel，其實(shí)就是Google的Pregel在Spark上的實(shí)現(xiàn)。它提供基于圖的計算模式，后來被新的Spark圖模型API——GraphX所替代。
當(dāng)大數(shù)據(jù)集群越來越大，出現(xiàn)局部故障的概率也越來越高，集群核心數(shù)據(jù)的分布式一致性變得越來越難保證。Zookeeper的出現(xiàn)很好地解決了這個棘手的問題，它實(shí)現(xiàn)了著名的Fast Paxos算法，提供了一個集群化的分布式一致性服務(wù)，使得其他平臺和應(yīng)用可以通過簡單地調(diào)用它的服務(wù)來實(shí)現(xiàn)數(shù)據(jù)的分布式一致性，不需要自己關(guān)心具體的實(shí)現(xiàn)細(xì)節(jié)，使大數(shù)據(jù)平臺開發(fā)人員可以將精力更加集中在平臺自身特性上。例如Storm平臺就是使用Zookeeper來存儲集群元信息（如節(jié)點(diǎn)信息、狀態(tài)信息、任務(wù)信息等），從而可以簡單高效地實(shí)現(xiàn)容錯機(jī)制。即使某個組件出現(xiàn)故障，新的替代者可以快速地在Zookeeper上注冊以及獲取所需的元信息，從而恢復(fù)失敗的任務(wù)。除了分布式一致性以外，Zookeeper還可以用作leader選取、熱備切換、資源定位、分布式鎖、配置管理等場景。
數(shù)據(jù)在其生命周期是流動的，往往會有產(chǎn)生、收集、存儲、計算、銷毀等不同狀態(tài)，數(shù)據(jù)可以在不同狀態(tài)之間流動，也可以從同一個狀態(tài)的內(nèi)部進(jìn)行流動（例如計算狀態(tài)），流動時上下游的載體有很多種，例如終端、線上日志服務(wù)器、存儲集群、計算集群等。在后臺，多數(shù)情況下都是在大數(shù)據(jù)平臺之間流動，因此各個大數(shù)據(jù)平臺并不是孤立的，處理數(shù)據(jù)時，它們往往成為上下游的關(guān)系，而數(shù)據(jù)從上游流往下游，就需要一個數(shù)據(jù)管道，來正確連接每份數(shù)據(jù)正確的上下游，這個場景的需求可以使用Kafka集群來很好地解決。Kafka最初是由LinkedIn開發(fā)的，是一個分布式的消息發(fā)布與訂閱系統(tǒng)。Kafka集群可以充當(dāng)一個大數(shù)據(jù)管道的角色，負(fù)責(zé)正確連接每種數(shù)據(jù)的上下游。各個上游產(chǎn)生的數(shù)據(jù)都發(fā)往Kafka集群，而下游則通過向Kafka集群訂閱的方式，靈活選擇自己所需的上游數(shù)據(jù)。Kafka支持多個下游訂閱同一個上游數(shù)據(jù)。當(dāng)上游產(chǎn)生了數(shù)據(jù)，Kafka會把數(shù)據(jù)進(jìn)行一定時間窗口內(nèi)的持久化，等待下游來讀取數(shù)據(jù)。Kafka的數(shù)據(jù)持久化方式及內(nèi)部容錯機(jī)制，提供了較好的數(shù)據(jù)可靠性，它同時適合于離線和在線消息消費(fèi)。
以上平臺的誕生時間點(diǎn)如下圖所示：
大數(shù)據(jù)平臺極大地提高了業(yè)界的生產(chǎn)力，使得海量數(shù)據(jù)的存儲、計算變得更加容易和高效。通過這些平臺的使用，可以快速搭建出一個承載海量用戶的應(yīng)用，移動互聯(lián)網(wǎng)正是在它們的催化下不斷高速發(fā)展，改變我們的生活。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題：談?wù)勯_源大數(shù)據(jù)平臺的演變
相關(guān)文章
