Jeff Bean 談 Flink 與流式處理的 5 大新發現
公眾號/AI前線
作者|Jeff Bean
譯者|無明
編輯|Debra
AI 前線導讀:
在大資料領域工作了近 8 年後,今年秋天,作為 data Artisans 的技術佈道師,我在 Apache Flink 社群變得越來越活躍。在十月份舉行的灣區 Flink 座談會上,我從技術從業者的角度討論了我對 Flink 的看法。雖然我是一名 Flink 新手,但我已經在大資料領域工作了很長時間。正如我在座談會上所說的,我對人們這個領域的關注、投入和好奇心感到震驚。回想起來,這符合我對 Apache Flink 和 Apache Flink 社群的總體印象。下面我想介紹有關 Apache Flink 的 5 個早期印象,以及為什麼企業應該在他們的流式處理架構中儘早嘗試 Flink。
更多幹貨內容請關注微信公眾號“AI 前線”(ID:ai-front)
流式處理一直是大資料專案的必經之路。
我在 2010 年進入大資料領域,當時最先進的是分散式檔案系統,MapReduce、Hive、Pig、Flume 和 HBase。然而,低延遲資料處理長期以來一直是一個巨大的挑戰。例如,在我進入該領域工作的頭幾個月,一位客戶問我如何在 Hive 中對一個不斷增長的表基於五分鐘滾動視窗產生最新的聚合。這是一個非常困難的查詢,客戶和我都沒有想出來該怎麼做。MapReduce、Hive、Pig 和後來的 Spark 使用越來越小的批處理操作來處理大量不同資料,獲得接近低延遲的結果。一些框架如 Flume 和後來的 Kafka 讓資料攝取、封裝和傳輸變得更容易。其他查詢系統(如 HBase、Cassandra、Presto 和 Impala)可以近似實時地對新近攝取的資料進行互動式訪問。但是,所有這些專案都忽略了客戶和業務使用者真正的需求:將資料表示為流,並基於流進行復雜有狀態的分析。客戶和終端使用者通過各種有趣且昂貴的方式與延遲做鬥爭。
Apache Flink 在 2018 年的增長非常驚人。
最近 Qubole 的一份調查報告顯示,Apache Flink 是 2018 年大資料和 Hadoop 生態系統中發展最快的引擎,與 2017 年的類似調查相比,採用量增長了 125%。這種採用率的提升給人造成了一種很強烈的印象,Datanami 網站的兩篇與 Flink 不相關的文章中都提到了它。其中一篇感嘆大資料生態系統變得日益複雜,涉及的專案呈爆發式的增長,以及在應用場景中採用了錯誤技術所涉及的風險,但又不遺餘力地說明了 Flink 在採用方面的驚人增長。另一篇有關 Cloudera Mike Olson 的文章討論了這個領域從“動物園動物爭吵”到解決企業問題的演變,但它仍然給 Flink 的採用量增長點了一個贊。有時候,動物園裡最好的動物不一定是你所期望的那個。
值得注意的是,雖然 data Artisans 支援 Flink,銷售 Flink 相關的產品,並聘請了很多原始作者和提交者,但現今 Flink 的大部分採用都發生在 data Artisans 公司之外,比如 Netflix、阿里巴巴、Uber 和 Lyft,等等。
Flink 的分層抽象非常具有表現力,讓你能夠自然地概念化你的資料。
在使用 Hadoop 專案(如 MapReduce)多年之後,將流、狀態、時間和快照的構造作為事件處理的構建塊而不是鍵、值和執行階段這些不完整的概念,這令人耳目一新。我的印象是 Flink 在介面以及這些介面如何與底層平臺的功能相關聯方面是最具表現力的。例如,SQL 介面支援滾動視窗和複雜事件處理。如下圖的滾動時間視窗示例所示——幾年前我們還很那做到這些——但現在卻可以使用簡單的 SQL 來表示。圖中還顯示了流式 API 和 processFunction 抽象級別的相似表現力。
我們看到了包裝最佳實踐的出現。
供應商可以為活躍的開源專案帶來價值的一個地方是在精心構建的產品中包裝專業知識和最佳實踐。採用率較高的開源專案在選擇性和可配置性方面變得更加廣泛,因為它們執行在特定的生產環境中。
data Artisans 根據他們自己的經驗以及 Flink 使用者社群已經建立起的最佳實踐包裝了一些觀點。例如,在部署方面,Apache Flink 支援 YARN、Mesos、Kubernetes 和獨立部署。同樣,Flink 的終端使用者傾向於執行基於 Flink 的應用程式而不是 Flink 作業,這是 Flink 中可用的最高執行抽象。data Artisans 為 Flink 引入了應用程式的概念,可在 Kubernetes 上部署 Flink,包裝了一個非常有用又可擴充套件的一叢集一作業對應一個應用程式的最佳實踐。這些簡單的決策和包裝的最佳實踐有助於更早從 Flink 的採用中獲得價值,從而讓使用者無需一次又一次地解決同類問題。因為包裝了最佳實踐,data Artisans Platform Application Manager 不僅適用於生產部署:它也適用於開始應用 Flink。
在其他專案做不到的地方,Flink 卻取得了成功。
Flink 的流式處理有很多很好的生產應用場景。你可以從阿里巴巴、Netflix、Lyft、Uber、DriveTribe 等公司那裡瞭解更多有關它們通過採用 Flink 來滿足它們的業務對流式處理的需求。我注意到,在在採用 Flink 之前,總是先嚐試一下其他的專案。
阿里巴巴在參考另一個專案的微批處理正規化時,“第一種方法是使用批處理作為起點,然後嘗試在批處理之上進行流式處理。但是,這可能無法滿足他們對延遲的嚴格要求,因為模擬流的微批處理需要一些固定的開銷——所以當你嘗試減少延遲時,開銷的比例會增加。
在 Flink Forward 演講中,來自 Netflix 的 Shriya Arora 說道:“從歷史上看,我們已經通過批量的方式連線了大量資料集。然而,我們會問自己,資料是否是實時生成的,為什麼不能在下游進行實時處理?”
同樣,在討論他們基於 Flink 的平臺 AthenaX 時,Uber 寫道,他們在採用 Flink 之前嘗試了 Apache Storm 和 Apache Samza,“然而,這些解決方案還不夠理想。使用者要麼被迫實現、管理和監控他們自己的流式分析應用程式,要麼只能為預先定義的一組問題獲取答案。”
在我看來,乍一看,微批次處理、lambda 架構、輔助流式處理技術和替代流式處理專案等架構似乎都可以……直到有人從痛苦的經歷中發現,低延遲處理和複雜分析無法通過廉價、可擴充套件和容錯的方式來實現。
因此,我的建議是不要讓自己在一開始就被困在錯誤的技術採用的痛苦中,而是儘早嘗試使用 Flink 來解決你的流式處理問題。從 Flink 的採用模式來看,很多人走了彎路。
英文原文:
ofollow,noindex" target="_blank">Years in Big Data. Months with Apache Flink. 5 Early Observations With Stream Processing