Spark 是最活躍的 Apache 項(xiàng)目之一。從 2014 年左右開始得到廣泛關(guān)注。Spark 的開源社區(qū)一度達(dá)到上千的活躍貢獻(xiàn)者。最主要推動(dòng)者是 Databricks，由最初的 Spark 創(chuàng)造者們成立的公司。今年 6 月的 Spark+AI 峰會(huì)參加人數(shù)超過 4000。 Spark 因?yàn)樵谝娣矫姹?MapReduce 全面占優(yōu)，經(jīng)過幾年發(fā)展和 Hadoop 生態(tài)結(jié)合較好，已經(jīng)被廣泛視為 Hadoop MapReduce 引擎的取代者。
Flink 也是 Apache 頂級(jí)項(xiàng)目，創(chuàng)始者們成立了 Data Artisans。社區(qū)規(guī)模還無法和 Spark 相比。不過在業(yè)界，特別是流處理方面，有不錯(cuò)的口碑。在大規(guī)模流處理方面走在最前沿，也是需求最強(qiáng)的幾個(gè)美國(guó)公司，包括 Netflix、 LinkedIn、Uber、Lyft 等，除 LinkedIn 有自己的 Samza 外，都已經(jīng)采用 Flink 作為流處理引擎或者有了較大投入。
阿里集團(tuán)在 Flink 社區(qū)也有較大影響力。最近 Flink 1.3 到 1.5 里都有幾個(gè)重磅功能是阿里和 Data Artisans 合作或者獨(dú)立開發(fā)的。阿里還有可能是世界上最大的流計(jì)算集群，也是在 Flink 的基礎(chǔ)上開發(fā)的。
最近的 Spark+AI 峰會(huì)上， Databricks 主打的主題是統(tǒng)一分析平臺(tái)（Unified Analytics Platform）。三大新發(fā)布：Databricks delta、Databricks Runtime for ML和 ML flow，都是圍繞這一主題。隨著近年來機(jī)器學(xué)習(xí)（包括深度學(xué)習(xí)）在數(shù)據(jù)處理中占比越來越高，可以說 Databricks 又一次把握住了時(shí)代的脈搏。
統(tǒng)一分析平臺(tái)回應(yīng)了 Spark 的初衷。經(jīng)過幾年的探索，對(duì)初始問題，即用戶可以在一個(gè)系統(tǒng)里解決絕大部分大數(shù)據(jù)的需求，有了一個(gè)比較明確具體的解決方案。
不過有意思的是可以看出 Databricks 在 AI 方面策略的轉(zhuǎn)變。在深度學(xué)習(xí)流行前，Spark 自帶的 MLLib 功能上應(yīng)該是夠用的，但是可能是由于兼容性原因并沒有取得預(yù)期中的廣泛采用。
對(duì)深度學(xué)習(xí)的新寵 TensorFlow，Spark 曾經(jīng)推出過 TensorFrames 和 Spark 引擎做了一些集成。結(jié)果應(yīng)該不是很成功，可能還沒有 Yahoo 從外面搭建的 TensorFlowOnSpark 影響力大。
從這次來看，Spark 轉(zhuǎn)向了集成的策略。Databricks Runtime for ML 實(shí)際上就是預(yù)裝了各個(gè)機(jī)器學(xué)習(xí)框架，然后支持在 Spark 任務(wù)里啟動(dòng)一個(gè)比如 TensorFlow 自己的集群。Spark 引擎方面做的主要改進(jìn)就是 gang scheduling，即支持一次申請(qǐng)多個(gè) executor 以便 TensorFlow 集群能正常啟動(dòng)。
MLFlow 更是和 Spark 引擎無關(guān)。作為一個(gè)工作流工具，MLFlow 的目標(biāo)是幫助數(shù)據(jù)科學(xué)家提高工作效率。主要功能是以項(xiàng)目為單位記錄和管理所做的機(jī)器學(xué)習(xí)試驗(yàn)，并支持分享。設(shè)計(jì)要點(diǎn)是可重復(fù)試驗(yàn)，以及對(duì)各種工具的靈活易用的支持。看起來 Spark 暫時(shí)在作為 AI 引擎方面可能沒什么大動(dòng)作了。
Flink 的目標(biāo)其實(shí)和 Spark 很相似。包含 AI 的統(tǒng)一平臺(tái)也是 Flink 的發(fā)展方向。Flink 從技術(shù)上也是可以支持較好的機(jī)器學(xué)習(xí)集成和整條鏈路的，而且有一些大規(guī)模線上學(xué)習(xí)的使用實(shí)例。不過看起來在現(xiàn)階段 Flink 這方面的平臺(tái)化還沒有 Spark 成熟。值得一提的是 Flink 由于流處理引擎的優(yōu)勢(shì)，在線上學(xué)習(xí)方面可能能支持得更好一些。
產(chǎn)品和生態(tài)歸根結(jié)底是要解決大數(shù)據(jù)使用者的問題，從數(shù)據(jù)中產(chǎn)生價(jià)值。了解數(shù)據(jù)的使用者和他們的需求可以幫助我們?cè)谠谟懻撋鷳B(tài)的各方面時(shí)有一個(gè)比較清晰的脈絡(luò)。
數(shù)據(jù)相關(guān)的工作者大致可以分為以下角色。實(shí)際情況中一個(gè)組織里很可能幾個(gè)角色在人員上是重合的。各個(gè)角色也沒有公認(rèn)的定義和明確的界限。
這些構(gòu)成了一個(gè)完整的環(huán)。上面的順序是數(shù)據(jù)流動(dòng)的方向，而需求的驅(qū)動(dòng)是反過來的方向。
本文所說的 Spark 和 Flink 的生態(tài)主要是對(duì)應(yīng)到數(shù)據(jù)平臺(tái)這一層。直接面向的用戶主要是數(shù)據(jù)工程師、數(shù)據(jù)分析師和數(shù)據(jù)科學(xué)家。好的生態(tài)能夠大大簡(jiǎn)化數(shù)據(jù)平臺(tái)和數(shù)據(jù)工程師的工作，并使得數(shù)據(jù)分析師和數(shù)據(jù)科學(xué)家更加自主化同時(shí)提高效率。
從 API 上來看，Spark 和 Flink 提供的功能領(lǐng)域大致相當(dāng)。當(dāng)然具體看各個(gè)方向支持的程度會(huì)有差異?？傮w來看 Spark 的 API 經(jīng)過幾輪迭代，在易用性，特別是機(jī)器學(xué)習(xí)的集成方面，更強(qiáng)一些。Flink 在流計(jì)算方面更成熟一些。
支持的語言也大致相當(dāng)。Spark 發(fā)展的時(shí)間長(zhǎng)一些還是有優(yōu)勢(shì)，特別是數(shù)據(jù)分析常用的 Python 和 R。
有了 API，再有數(shù)據(jù)就可以開工了。Spark 和 Flink 都能對(duì)接大部分比較常用的系統(tǒng)。如果暫時(shí)還沒有支持的，也都能比較好地支持自己寫一個(gè) connector。
https://databricks.com/spark/about
https://www.slideshare.net/chobeat/data-intensive-applications-with-apache-flink
這方面數(shù)據(jù)工程師和數(shù)據(jù)分析的需求有一些不同。
數(shù)據(jù)分析的工作性質(zhì)比較偏探索性，更強(qiáng)調(diào)交互性和分享。Notebook 能比較好地滿足這些需求，是比較理想的開發(fā)工具，用來做演示效果也相當(dāng)不錯(cuò)。比較流行的 Notebook 有 Apache Zeppelin，Jupyter 等。Databricks 更是自己開發(fā)了 Databricks Notebook 并將之作為服務(wù)的主要入口。Zeppelin 支持 Spark 和 Flink，Jupyter 還只支持 Spark。
數(shù)據(jù)工程師的工作更傾向于把比較確定的數(shù)據(jù)處理生產(chǎn)化，能快速把代碼寫出來是一方面。另外還有項(xiàng)目管理，版本管理，測(cè)試，配置，調(diào)試，部署，監(jiān)控等等工作，需求和傳統(tǒng)的集成開發(fā)工具比較相似。 還經(jīng)常出現(xiàn)需要復(fù)用已有的業(yè)務(wù)邏輯代碼庫的情況。Notebook 對(duì)其中一些需求并不能很好地滿足。比較理想的開發(fā)工具可能是類似 IntelliJ 加上 Spark/Flink 插件，再加上一些插件能直接提交任務(wù)到集群并進(jìn)行調(diào)試，并對(duì)接 Apache Oozie 之類的工作流管理等等。在開源社區(qū)還沒有見到能把這些集成到一起的。在商業(yè)產(chǎn)品中倒是見過一些比較接近的。Spark 和 Flink 在這方面差不多。
部署模式 / 集群管理 / 開源閉源
應(yīng)用開發(fā)完后要提交到運(yùn)行環(huán)境。Spark 和 Flink 都支持各種主流的部署環(huán)境，在這方面都算做得比較好的。
既然 Spark 和 Flink 都支持各種部署方式，那一個(gè)企業(yè)是否可以使用開源代碼快速搭建一個(gè)支持 Spark 或者 Flink 的平臺(tái)呢？
這個(gè)要看想要達(dá)到什么效果了。最簡(jiǎn)單的模式可能是給每個(gè)任務(wù)起一個(gè)獨(dú)占集群，或著給小團(tuán)隊(duì)一個(gè)獨(dú)立集群。這個(gè)確實(shí)可以很快做到，但是用戶多了以后，統(tǒng)一運(yùn)維的成本可能太高，需要用戶參與運(yùn)維。還有一個(gè)缺點(diǎn)是資源分配固定，而負(fù)載會(huì)有變化，導(dǎo)致資源利用率上不去。比較理想的是多租戶的共享大集群，可以提高運(yùn)維效率的同時(shí)最大限度地提高資源利用率。而這就需要一系列的工作，比如不同的作業(yè)提交方式，數(shù)據(jù)安全與隔離等等。對(duì)一些企業(yè)來說，可能利用托管服務(wù)（包括云服務(wù)）是一種值得考慮的開始方式。
Spark 社區(qū)在規(guī)模和活躍程度上都是領(lǐng)先的，畢竟多了幾年發(fā)展時(shí)間。而且作為一個(gè)德國(guó)公司，Data Artisans 想在美國(guó)擴(kuò)大影響力要更難一些。不過 Flink 社區(qū)也有一批穩(wěn)定的支持者，達(dá)到了可持續(xù)發(fā)展的規(guī)模。
在中國(guó)情況可能會(huì)不一樣一些。比起美國(guó)公司，中國(guó)公司做事情速度更快，更愿意嘗試新技術(shù)。中國(guó)的一些創(chuàng)新場(chǎng)景也對(duì)實(shí)時(shí)性有更高的需求。這些都對(duì) Flink 更友好一些。
近期 Flink 的中國(guó)社區(qū)有一系列動(dòng)作，是了解 Flink 的好機(jī)會(huì)。
Spark 的中文文檔在 http://www.apachecn.org/bigdata/spark/27.html。
Flink 的中文社區(qū)在 http://flink-china.org/。
另外，今年年底 Flink 中文社區(qū)也會(huì)在北京舉辦 Flink Forward China 大會(huì)，感興趣的朋友可以關(guān)注。
近兩年一個(gè)明顯的趨勢(shì)就是機(jī)器學(xué)習(xí)在數(shù)據(jù)處理中的比重增長(zhǎng)。Spark 和 Flink 都能支持在一個(gè)系統(tǒng)中做機(jī)器學(xué)習(xí)和其它數(shù)據(jù)處理。誰能做得更好就能掌握先機(jī)。
另一個(gè)可能沒有那么明顯的趨勢(shì)是，隨著 IOT 的增長(zhǎng)以及計(jì)算資源和網(wǎng)絡(luò)的持續(xù)發(fā)展，實(shí)時(shí)處理需求會(huì)越來越多?，F(xiàn)在其實(shí)真正對(duì)低延遲有很高追求的業(yè)務(wù)并沒有那么多，所以每一次流計(jì)算新技術(shù)的出現(xiàn)都能看到那幾家公司的身影。隨著新應(yīng)用場(chǎng)景的出現(xiàn)和競(jìng)爭(zhēng)環(huán)境的發(fā)展，實(shí)時(shí)處理可能會(huì)變得越來越重要。Flink 現(xiàn)在在這方面是領(lǐng)先的，如果發(fā)揮得好可以成為核心優(yōu)勢(shì)。
還有一點(diǎn)值得一提的是，因?yàn)橛脩舨幌腈i定供應(yīng)商，擔(dān)心持續(xù)的支持等原因，是否開源已經(jīng)成為用戶選擇數(shù)據(jù)產(chǎn)品的一個(gè)重要考量。閉源產(chǎn)品如果沒有決定性優(yōu)勢(shì)會(huì)越來越難和基于開源技術(shù)的產(chǎn)品競(jìng)爭(zhēng)。
Spark 和 Flink 都是通用的開源大規(guī)模處理引擎，目標(biāo)是在一個(gè)系統(tǒng)中支持所有的數(shù)據(jù)處理以帶來效能的提升。兩者都有相對(duì)比較成熟的生態(tài)系統(tǒng)。是下一代大數(shù)據(jù)引擎最有力的競(jìng)爭(zhēng)者。Spark 的生態(tài)總體更完善一些，在機(jī)器學(xué)習(xí)的集成和易用性上暫時(shí)領(lǐng)先。Flink 在流計(jì)算上有明顯優(yōu)勢(shì)，核心架構(gòu)和模型也更透徹和靈活一些。在易用性方面兩者也都還有一些地方有較大的改進(jìn)空間。接下來誰能盡快補(bǔ)上短板發(fā)揮強(qiáng)項(xiàng)就有更多的機(jī)會(huì)。
聯(lián)系客服
