那么問題來了，上述的機(jī)器學(xué)習(xí)/模式識(shí)別算法往往都是迭代型的計(jì)算，一般會(huì)迭代幾十至幾百輪，那么在Hadoop上就是連續(xù)的幾十至幾百個(gè)串行的任務(wù)，前后兩個(gè)任務(wù)之間都要經(jīng)過大量的IO來傳遞數(shù)據(jù)，據(jù)不完全統(tǒng)計(jì)，多數(shù)的迭代型算法在Hadoop上的耗時(shí)，IO占了80%左右，如果可以省掉這些IO開銷，那么對(duì)計(jì)算速度的提升將是巨大的，因此業(yè)界興起了一股基于內(nèi)存計(jì)算的潮流，而Spark則是這方面的佼佼者。它提出了RDD的概念，通過對(duì)RDD的使用將每輪的計(jì)算結(jié)果分布式地放在內(nèi)存中，下一輪直接從內(nèi)存中讀取上一輪的數(shù)據(jù)，節(jié)省了大量的IO開銷。同時(shí)它提供了比Hadoop的MapReduce方式更加豐富的數(shù)據(jù)操作方式，有些需要分解成幾輪的Hadoop操作，可在Spark里一輪實(shí)現(xiàn)。因此對(duì)于機(jī)器學(xué)習(xí)/模式識(shí)別等迭代型計(jì)算，比起Hadoop平臺(tái)，在Spark上的計(jì)算速度往往會(huì)有幾倍到幾十倍的提升。另一方面，Spark的設(shè)計(jì)初衷就是想兼顧MapReduce模式和迭代型計(jì)算，因此老的MapReduce計(jì)算也可以遷移至spark平臺(tái)。由于Spark對(duì)Hadoop計(jì)算的兼容，以及對(duì)迭代型計(jì)算的優(yōu)異表現(xiàn)，成熟之后的Spark平臺(tái)得到迅速的普及。
人們逐漸發(fā)現(xiàn)，Spark所具有的優(yōu)點(diǎn)，可以擴(kuò)展到更多的領(lǐng)域，現(xiàn)在Spark已經(jīng)向通用多功能大數(shù)據(jù)平臺(tái)的方向邁進(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ù)的查詢分析，以及支持直接對(duì)原生RDD對(duì)象進(jìn)行關(guān)系查詢，顯著降低了使用門檻。在實(shí)時(shí)計(jì)算領(lǐng)域，Spark streaming項(xiàng)目構(gòu)建了Spark上的實(shí)時(shí)計(jì)算框架，它將數(shù)據(jù)流切分成小的時(shí)間片段（例如幾秒），批量執(zhí)行。得益于Spark的內(nèi)存計(jì)算模式和低延時(shí)執(zhí)行引擎，在Hadoop上做不到的實(shí)時(shí)計(jì)算，在Spark上變得可行。雖然時(shí)效性比專門的實(shí)時(shí)處理系統(tǒng)有一點(diǎn)差距，但也可用于不少實(shí)時(shí)/準(zhǔn)實(shí)時(shí)場景。另外Spark上還有圖模型領(lǐng)域的Bagel，其實(shí)就是Google的Pregel在Spark上的實(shí)現(xiàn)。它提供基于圖的計(jì)算模式，后來被新的Spark圖模型API——GraphX所替代。
當(dāng)大數(shù)據(jù)集群越來越大，出現(xiàn)局部故障的概率也越來越高，集群核心數(shù)據(jù)的分布式一致性變得越來越難保證。Zookeeper的出現(xiàn)很好地解決了這個(gè)棘手的問題，它實(shí)現(xiàn)了著名的Fast Paxos算法，提供了一個(gè)集群化的分布式一致性服務(wù)，使得其他平臺(tái)和應(yīng)用可以通過簡單地調(diào)用它的服務(wù)來實(shí)現(xiàn)數(shù)據(jù)的分布式一致性，不需要自己關(guān)心具體的實(shí)現(xiàn)細(xì)節(jié)，使大數(shù)據(jù)平臺(tái)開發(fā)人員可以將精力更加集中在平臺(tái)自身特性上。例如Storm平臺(tái)就是使用Zookeeper來存儲(chǔ)集群元信息（如節(jié)點(diǎn)信息、狀態(tài)信息、任務(wù)信息等），從而可以簡單高效地實(shí)現(xiàn)容錯(cuò)機(jī)制。即使某個(gè)組件出現(xiàn)故障，新的替代者可以快速地在Zookeeper上注冊(cè)以及獲取所需的元信息，從而恢復(fù)失敗的任務(wù)。除了分布式一致性以外，Zookeeper還可以用作leader選取、熱備切換、資源定位、分布式鎖、配置管理等場景。
數(shù)據(jù)在其生命周期是流動(dòng)的，往往會(huì)有產(chǎn)生、收集、存儲(chǔ)、計(jì)算、銷毀等不同狀態(tài)，數(shù)據(jù)可以在不同狀態(tài)之間流動(dòng)，也可以從同一個(gè)狀態(tài)的內(nèi)部進(jìn)行流動(dòng)（例如計(jì)算狀態(tài)），流動(dòng)時(shí)上下游的載體有很多種，例如終端、線上日志服務(wù)器、存儲(chǔ)集群、計(jì)算集群等。在后臺(tái)，多數(shù)情況下都是在大數(shù)據(jù)平臺(tái)之間流動(dòng)，因此各個(gè)大數(shù)據(jù)平臺(tái)并不是孤立的，處理數(shù)據(jù)時(shí)，它們往往成為上下游的關(guān)系，而數(shù)據(jù)從上游流往下游，就需要一個(gè)數(shù)據(jù)管道，來正確連接每份數(shù)據(jù)正確的上下游，這個(gè)場景的需求可以使用Kafka集群來很好地解決。Kafka最初是由LinkedIn開發(fā)的，是一個(gè)分布式的消息發(fā)布與訂閱系統(tǒng)。Kafka集群可以充當(dāng)一個(gè)大數(shù)據(jù)管道的角色，負(fù)責(zé)正確連接每種數(shù)據(jù)的上下游。各個(gè)上游產(chǎn)生的數(shù)據(jù)都發(fā)往Kafka集群，而下游則通過向Kafka集群訂閱的方式，靈活選擇自己所需的上游數(shù)據(jù)。Kafka支持多個(gè)下游訂閱同一個(gè)上游數(shù)據(jù)。當(dāng)上游產(chǎn)生了數(shù)據(jù)，Kafka會(huì)把數(shù)據(jù)進(jìn)行一定時(shí)間窗口內(nèi)的持久化，等待下游來讀取數(shù)據(jù)。Kafka的數(shù)據(jù)持久化方式及內(nèi)部容錯(cuò)機(jī)制，提供了較好的數(shù)據(jù)可靠性，它同時(shí)適合于離線和在線消息消費(fèi)。
以上平臺(tái)的誕生時(shí)間點(diǎn)如下圖所示：
