下:比拼生態和將來,Spark和Flink哪家強?

前文對 Spark 和 Flink 的引擎作了對比。對用戶來講引擎並非考慮數據產品的惟一方面。開發和運維相關的工具和環境,技術支持,社區等等,對能不能在引擎上面作出東西來都很重要。這些構成了一個產品的生態。能夠說引擎決定了功能和性能的極限,而生態能讓這些能力真正發揮出做用。html

概 況

Spark 是最活躍的 Apache 項目之一。從 2014 年左右開始獲得普遍關注。Spark 的開源社區一度達到上千的活躍貢獻者。最主要推進者是 Databricks,由最初的 Spark 創造者們成立的公司。今年 6 月的 Spark+AI 峯會參加人數超過 4000。 Spark 由於在引擎方面比 MapReduce 全面佔優,通過幾年發展和 Hadoop 生態結合較好,已經被普遍視爲 Hadoop MapReduce 引擎的取代者。apache

Flink 也是 Apache 頂級項目,創始者們成立了 Data Artisans。社區規模還沒法和 Spark 相比。不過在業界,特別是流處理方面,有不錯的口碑。在大規模流處理方面走在最前沿,也是需求最強的幾個美國公司,包括 Netflix、 LinkedIn、Uber、Lyft 等,除 LinkedIn 有本身的 Samza 外,都已經採用 Flink 做爲流處理引擎或者有了較大投入。安全

阿里集團在 Flink 社區也有較大影響力。最近 Flink 1.3 到 1.5 裏都有幾個重磅功能是阿里和 Data Artisans 合做或者獨立開發的。阿里還有多是世界上最大的流計算集羣,也是在 Flink 的基礎上開發的。網絡

Unified Analytic platform

最近的 Spark+AI 峯會上, Databricks 主打的主題是統一分析平臺(Unified Analytics Platform)。三大新發布:Databricks delta、Databricks Runtime for ML和 ML flow,都是圍繞這一主題。隨着近年來機器學習(包括深度學習)在數據處理中佔比愈來愈高,能夠說 Databricks 又一次把握住了時代的脈搏。架構

統一分析平臺迴應了 Spark 的初衷。通過幾年的探索,對初始問題,即用戶能夠在一個系統裏解決絕大部分大數據的需求,有了一個比較明確具體的解決方案。app

不過有意思的是能夠看出 Databricks 在 AI 方面策略的轉變。在深度學習流行前,Spark 自帶的 MLLib 功能上應該是夠用的,可是多是因爲兼容性緣由並無取得預期中的普遍採用。框架

對深度學習的新寵 TensorFlow,Spark 曾經推出過 TensorFrames 和 Spark 引擎作了一些集成。結果應該不是很成功,可能尚未 Yahoo 從外面搭建的 TensorFlowOnSpark 影響力大。運維

從此次來看,Spark 轉向了集成的策略。Databricks Runtime for ML 實際上就是預裝了各個機器學習框架,而後支持在 Spark 任務裏啓動一個好比 TensorFlow 本身的集羣。Spark 引擎方面作的主要改進就是 gang scheduling,即支持一次申請多個 executor 以便 TensorFlow 集羣能正常啓動。機器學習

MLFlow 更是和 Spark 引擎無關。做爲一個工做流工具,MLFlow 的目標是幫助數據科學家提升工做效率。主要功能是以項目爲單位記錄和管理所作的機器學習試驗,並支持分享。設計要點是可重複試驗,以及對各類工具的靈活易用的支持。看起來 Spark 暫時在做爲 AI 引擎方面可能沒什麼大動做了。ide

Flink 的目標其實和 Spark 很類似。包含 AI 的統一平臺也是 Flink 的發展方向。Flink 從技術上也是能夠支持較好的機器學習集成和整條鏈路的,並且有一些大規模線上學習的使用實例。不過看起來在現階段 Flink 這方面的平臺化尚未 Spark 成熟。值得一提的是 Flink 因爲流處理引擎的優點,在線上學習方面可能能支持得更好一些。

數據使用者

產品和生態歸根結底是要解決大數據使用者的問題,從數據中產生價值。瞭解數據的使用者和他們的需求能夠幫助咱們在在討論生態的各方面時有一個比較清晰的脈絡。

數據相關的工做者大體能夠分爲如下角色。實際狀況中一個組織裏極可能幾個角色在人員上是重合的。各個角色也沒有公認的定義和明確的界限。

  • 數據採集:在產品和系統中合適的地方產生或收集數據發送到數據平臺。

  • 平臺:提供數據導入,存儲,計算的環境和工具等等。

  • 數據工程師:使用數據平臺把原始數據加工成能夠供後續高效使用的數據集。把分析師和數據科學家建立的指標和模型等等生產化成爲高效可靠的的自動處理。

  • 數據分析師和數據科學家(關於這二者的異同有不少討論。感興趣的能夠自行搜索。www.jianshu.com/p/cfd94d9e4… 這裏的譯文能夠提供一個視角):爲數據賦予意義,發現內含的價值。 下文再不特別區分的地方統稱爲數據分析。

  • 產品經理,管理和決策層:根據以上產生的數據調整產品和組織行爲。

這些構成了一個完整的環。上面的順序是數據流動的方向,而需求的驅動是反過來的方向。

本文所說的 Spark 和 Flink 的生態主要是對應到數據平臺這一層。直接面向的用戶主要是數據工程師、數據分析師和數據科學家。好的生態可以大大簡化數據平臺和數據工程師的工做,並使得數據分析師和數據科學家更加自主化同時提升效率。

開發環境

API

從 API 上來看,Spark 和 Flink 提供的功能領域大體至關。固然具體看各個方向支持的程度會有差別。整體來看 Spark 的 API 通過幾輪迭代,在易用性,特別是機器學習的集成方面,更強一些。Flink 在流計算方面更成熟一些。

API Spark Flink
底層 API RDD Process Function
核心 API DataFrame / Dataset / Structured Streaming DataStream / Dataset / Table API
SQL
機器學習
MLLib
FlinkML
圖計算
GraphX
Gelly
其它 CEP

支持的語言也大體至關。Spark 發展的時間長一些仍是有優點,特別是數據分析經常使用的 Python 和 R。

支持語言 Spark Flink
Java
Scala
Python
Beta
R
第三方
SQL

Connectors

有了 API,再有數據就能夠開工了。Spark 和 Flink 都能對接大部分比較經常使用的系統。若是暫時尚未支持的,也都能比較好地支持本身寫一個 connector。

databricks.com/spark/about

www.slideshare.net/chobeat/dat…

集成開發工具

這方面數據工程師和數據分析的需求有一些不一樣。

數據分析的工做性質比較偏探索性,更強調交互性和分享。Notebook 能比較好地知足這些需求,是比較理想的開發工具,用來作演示效果也至關不錯。比較流行的 Notebook 有 Apache Zeppelin,Jupyter 等。Databricks 更是本身開發了 Databricks Notebook 並將之做爲服務的主要入口。Zeppelin 支持 Spark 和 Flink,Jupyter 還只支持 Spark。

數據工程師的工做更傾向於把比較肯定的數據處理生產化,能快速把代碼寫出來是一方面。另外還有項目管理,版本管理,測試,配置,調試,部署,監控等等工做,需求和傳統的集成開發工具比較類似。 還常常出現須要複用已有的業務邏輯代碼庫的狀況。Notebook 對其中一些需求並不能很好地知足。比較理想的開發工具多是相似 IntelliJ 加上 Spark/Flink 插件,再加上一些插件能直接提交任務到集羣並進行調試,並對接 Apache Oozie 之類的工做流管理等等。在開源社區尚未見到能把這些集成到一塊兒的。在商業產品中卻是見過一些比較接近的。Spark 和 Flink 在這方面差很少。

運行環境

部署模式 / 集羣管理 / 開源閉源

應用開發完後要提交到運行環境。Spark 和 Flink 都支持各類主流的部署環境,在這方面都算作得比較好的。

部署環境 Spark Flink
獨立程序
獨立集羣
Yarn
Mesos
Kubernetes

企業級平臺

既然 Spark 和 Flink 都支持各類部署方式,那一個企業是否可使用開源代碼快速搭建一個支持 Spark 或者 Flink 的平臺呢?

這個要看想要達到什麼效果了。最簡單的模式多是給每一個任務起一個獨佔集羣,或着給小團隊一個獨立集羣。這個確實能夠很快作到,可是用戶多了之後,統一運維的成本可能過高,須要用戶參與運維。還有一個缺點是資源分配固定,而負載會有變化,致使資源利用率上不去。比較理想的是多租戶的共享大集羣,能夠提升運維效率的同時最大限度地提升資源利用率。而這就須要一系列的工做,好比不一樣的做業提交方式,數據安全與隔離等等。對一些企業來講,可能利用託管服務(包括雲服務)是一種值得考慮的開始方式。

社 區

Spark 社區在規模和活躍程度上都是領先的,畢竟多了幾年發展時間。並且做爲一個德國公司,Data Artisans 想在美國擴大影響力要更難一些。不過 Flink 社區也有一批穩定的支持者,達到了可持續發展的規模。

在中國狀況可能會不同一些。比起美國公司,中國公司作事情速度更快,更願意嘗試新技術。中國的一些創新場景也對實時性有更高的需求。這些都對 Flink 更友好一些。

近期 Flink 的中國社區有一系列動做,是瞭解 Flink 的好機會。

Spark 的中文文檔在 www.apachecn.org/bigdata/spa…

Flink 的中文社區在 flink-china.org/。

另外,今年年末 Flink 中文社區也會在北京舉辦 Flink Forward China 大會,感興趣的朋友能夠關注。

將來發展趨勢

近兩年一個明顯的趨勢就是機器學習在數據處理中的比重增加。Spark 和 Flink 都能支持在一個系統中作機器學習和其它數據處理。誰能作得更好就能掌握先機。

另外一個可能沒有那麼明顯的趨勢是,隨着 IOT 的增加以及計算資源和網絡的持續發展,實時處理需求會愈來愈多。如今其實真正對低延遲有很高追求的業務並無那麼多,因此每一次流計算新技術的出現都能看到那幾家公司的身影。隨着新應用場景的出現和競爭環境的發展,實時處理可能會變得愈來愈重要。Flink 如今在這方面是領先的,若是發揮得好能夠成爲核心優點。

還有一點值得一提的是,由於用戶不想鎖定供應商,擔憂持續的支持等緣由,是否開源已經成爲用戶選擇數據產品的一個重要考量。閉源產品若是沒有決定性優點會愈來愈難和基於開源技術的產品競爭。

總 結

Spark 和 Flink 都是通用的開源大規模處理引擎,目標是在一個系統中支持全部的數據處理以帶來效能的提高。二者都有相對比較成熟的生態系統。是下一代大數據引擎最有力的競爭者。Spark 的生態整體更完善一些,在機器學習的集成和易用性上暫時領先。Flink 在流計算上有明顯優點,核心架構和模型也更透徹和靈活一些。在易用性方面二者也都還有一些地方有較大的改進空間。接下來誰能儘快補上短板發揮強項就有更多的機會。

更多資訊請訪問 Apache Flink 中文社區網站

相關文章
相關標籤/搜索