下一代大數(shù)據(jù)計算引擎
自從數(shù)據(jù)處理需求超過了傳統(tǒng)數(shù)據(jù)庫能有效處理的數(shù)據(jù)量之后，Hadoop 等各種基于 MapReduce 的海量數(shù)據(jù)處理系統(tǒng)應(yīng)運而生。從 2004 年 Google 發(fā)表 MapReduce 論文開始，經(jīng)過近 10 年的發(fā)展，基于 Hadoop 開源生態(tài)或者其它相應(yīng)系統(tǒng)的海量數(shù)據(jù)處理已經(jīng)成為業(yè)界的基本需求。
但是，很多機構(gòu)在開發(fā)自己的數(shù)據(jù)處理系統(tǒng)時都會發(fā)現(xiàn)需要面臨一系列的問題。從數(shù)據(jù)中獲取價值需要的投入遠遠超過預(yù)期。常見的問題包括：
非常陡峭的學(xué)習(xí)曲線。剛接觸這個領(lǐng)域的人經(jīng)常會被需要學(xué)習(xí)的技術(shù)的數(shù)量砸暈。不像經(jīng)過幾十年發(fā)展的數(shù)據(jù)庫一個系統(tǒng)可以解決大部分數(shù)據(jù)處理需求，Hadoop 等大數(shù)據(jù)生態(tài)里的一個系統(tǒng)往往在一些數(shù)據(jù)處理場景上比較擅長，另一些場景湊合能用，還有一些場景完全無法滿足需求。結(jié)果就是需要好幾個系統(tǒng)來處理不同的場景。
上圖是一個典型的 lambda 架構(gòu)，只是包含了批處理和流處理兩種場景，就已經(jīng)牽涉到至少四五種技術(shù)了，還不算每種技術(shù)的可替代選擇。再加上實時查詢、交互式分析、機器學(xué)習(xí)等場景，每個場景都有幾種技術(shù)可以選擇，每個技術(shù)涵蓋的領(lǐng)域還有不同方式的重疊。結(jié)果就是一個業(yè)務(wù)經(jīng)常需要使用四五種以上的技術(shù)才能支持好一個完整的數(shù)據(jù)處理流程。加上調(diào)研選型，需要了解的數(shù)目還要多得多。
下圖是大數(shù)據(jù)領(lǐng)域的全景。暈了沒?
開發(fā)和運行效率低下。因為牽涉到多種系統(tǒng)，每種系統(tǒng)有自己的開發(fā)語言和工具，開發(fā)效率可想而知。而因為采用了多套系統(tǒng)，數(shù)據(jù)需要在各個系統(tǒng)之間傳輸，也造成了額外的開發(fā)和運行代價，數(shù)據(jù)的一致也難以保證。在很多機構(gòu)，實際上一半以上的開發(fā)精力花在了數(shù)據(jù)在各個系統(tǒng)之間的傳輸上。
復(fù)雜的運維。多個系統(tǒng)，每個需要自己的運維，帶來更高的運維代價的同時也提高了系統(tǒng)出問題的可能。
數(shù)據(jù)質(zhì)量難以保證。數(shù)據(jù)出了問題難以跟蹤解決。
最后，還有人的問題。在很多機構(gòu)，由于系統(tǒng)的復(fù)雜性，各個子系統(tǒng)的支持和使用落實在不同部門負責(zé)。
了解了這些問題以后，對 Spark 從 2014 年左右開始迅速流行就比較容易理解了。Spark 在當(dāng)時除了在某些場景比 Hadoop MapReduce 帶來幾十到上百倍的性能提升外，還提出了用一個統(tǒng)一的引擎支持批處理、流處理、交互式查詢、機器學(xué)習(xí)等常見的數(shù)據(jù)處理場景。看過在一個 Notebook 里完成上述所有場景的 Spark 演示，對比之前的數(shù)據(jù)流程開發(fā)，對很多開發(fā)者來說不難做出選擇。經(jīng)過幾年的發(fā)展，Spark 已經(jīng)被視為可以完全取代 Hadoop 中的 MapReduce 引擎。
正在 Spark 如日中天高速發(fā)展的時候，2016 年左右 Flink 開始進入大眾的視野并逐漸廣為人知。為什么呢?原來在人們開始使用 Spark 之后，發(fā)現(xiàn) Spark 雖然支持各種常見場景，但并不是每一種都同樣好用。數(shù)據(jù)流的實時處理就是其中相對較弱的一環(huán)。Flink 憑借更優(yōu)的流處理引擎，同時也支持各種處理場景，成為 Spark 的有力挑戰(zhàn)者。
Spark 和 Flink 是怎么做到這些的，它們之間又有那些異同，下面我們來具體看一下。
這一部分主要著眼于 Spark 和 Flink 引擎的架構(gòu)方面，更看重架構(gòu)帶來的潛力和限制。現(xiàn)階段的實現(xiàn)成熟度和局限會在后續(xù)生態(tài)部分探討。
數(shù)據(jù)模型和處理模型
要理解 Spark 和 Flink 的引擎特點，首先從數(shù)據(jù)模型開始。
Spark 的數(shù)據(jù)模型是彈性分布式數(shù)據(jù)集 RDD(Resilient Distributed Datasets)。 比起 MapReduce 的文件模型，RDD 是一個更抽象的模型，RDD 靠血緣(lineage) 等方式來保證可恢復(fù)性。很多時候 RDD 可以實現(xiàn)為分布式共享內(nèi)存或者完全虛擬化(即有的中間結(jié)果 RDD 當(dāng)下游處理完全在本地時可以直接優(yōu)化省略掉)。這樣可以省掉很多不必要的 I/O，是早期 Spark 性能優(yōu)勢的主要原因。
Spark 用 RDD 上的變換(算子)來描述數(shù)據(jù)處理。每個算子(如 map，filter，join)生成一個新的 RDD。所有的算子組成一個有向無環(huán)圖(DAG)。Spark 比較簡單地把邊分為寬依賴和窄依賴。上下游數(shù)據(jù)不需要 shuffle 的即為窄依賴，可以把上下游的算子放在一個階段(stage) 里在本地連續(xù)處理，這時上游的結(jié)果 RDD 可以 省略。下圖展示了相關(guān)的基本概念。更詳細的介紹在網(wǎng)上比較容易找到，這里就不花太多篇幅了。
Flink 的基本數(shù)據(jù)模型是數(shù)據(jù)流，及事件(Event)的序列。數(shù)據(jù)流作為數(shù)據(jù)的基本模型可能沒有表或者數(shù)據(jù)塊直觀熟悉，但是可以證明是完全等效的。流可以是無邊界的無限流，即一般意義上的流處理。也可以是有邊界的有限流，這樣就是批處理。
