一文帶你瞭解 Flink Forward 柏林站全部重點內容

前言

2019.10.7~9號，隨著70週年國慶活動的順利閉幕，Flink Forward 也照例在他們的發源地柏林舉辦了第五屆大會。雖然還沒有拿到具體的資料，不過從培訓門票已經在會前銷售一空的這樣的現象來看，Flink Forward 大會還是繼續保持了一個良好的勢頭。本屆大會不管是從參會人數上，提交的議題，以及參加的公司數量來看都繼續創了一個新高。當然，這要去掉去年 Flink Forward 北京站的資料 ;-)。阿里巴巴這次共派出了包括筆者在內的3名講師，總共參加了4場分享和2個問答環節。在這裡，我會根據自己參與的議題給大家做一下這次會議整體的一個介紹和個人在這次參會過程裡面的感受和思考，希望對感興趣的同學有所幫助。

Keynote

先說說這兩天的 Keynote。第一天的開場 Keynote 還是繼續由社群一哥 Stephan Ewen 來給出。他先總結了一下 Flink 專案目前的一些狀態，包括：

• Flink 在8月份的 Github star 數超過了1萬
• 在所有 Apache 專案中，Flink 排在郵件列表活躍度的 Top 3，並且這個數字在接下來很有可能還會變小
• 8月份釋出的 1.9.0 版本是 Flink 目前為止釋出的功能最多，修改量最大的一個版本

這張圖片很好的概括了 Flink 在過去大半年所側重的工作：

對於 Flink 未來的一個可能的方向，Stephan 繼續表達了他對 Application 這種偏線上服務的場景的興趣。他先是將我們平時所說的批處理和流計算總結為 Data Processing，同時將訊息驅動和資料庫之類的應用總結為 Applications，而 Stream Processing 就是連線這兩種看起來截然不同的場景的橋樑。我在一開始聽到這個的時候也有點一頭霧水，不明就裡的感覺，經過這幾天對這個問題的思考，有了一些自己的理解，我將在文末展開進行解釋。提到 Application，就不得不提現在很流行的 FaaS（Function as a Service）。在這個領域，Stephan 覺得大家都忽視了 State 在這裡面的重要性。比如一個典型的 Application 場景，一般都會具備以下這些特點：

• 整個 Application 會有一個或者多個入口，計算邏輯由訊息來驅動
• 具體的業務邏輯被拆分成粒度較小的幾個單元，每個邏輯單元使用一個 Function 來執行具體的邏輯
• Function 之間會互相呼叫，一般來說我們也會將這些呼叫設計為非同步的模式
• 每個 Function 的計算邏輯可能會需要一些狀態，比如可以使用資料庫作為狀態的儲存
• 在完整的計算邏輯完成之後，我們會透過一個統一的出口返回處理的狀態

在這個場景裡，我們看到了至少三點需求：

• 計算邏輯由訊息驅動
• 計算邏輯和互相呼叫的關係必須可以比較靈活的進行組織
• 計算邏輯需要狀態的支援，並且在某些情況下，需要保證 exactly once 的處理語義

這裡面屬第三點最難做。大家可以想象一下，假如現在我們的 Application 要處理類似電商場景下單這樣的過程，同時我們依賴資料庫作為這個應用的狀態儲存。我們有一個專門的庫存管理邏輯和一個下單邏輯。在一個完整的購買邏輯裡，我們需要先呼叫庫存管理模組，檢查下該商品是否有庫存，然後將該商品的庫存從資料庫裡減去1。這一步成功之後，我們的服務再繼續呼叫下單邏輯，在資料庫裡面生成一個新的訂單。在一切都正常的時候，這樣的邏輯還是比較簡單的，但一旦有錯誤出現就會相當麻煩。比如我們已經將庫存減掉，但是在生成訂單的過程中發生了錯誤，這樣我們還得想辦法讓庫存進行回滾。一旦類似的業務邏輯單元變多之後，你的應用程式碼將變得異常複雜。這個問題就是典型的 end-to-end exactly once，我們希望一個錯綜複雜的計算流程，要麼全部一起成功，要麼全部失敗，就當它完全沒發生過一樣。

為了解決這樣的問題，結合 Flink 目前的一些積累，Stephan 推出了一個全新的專案： statefun.io，即 Stateful Functions。透過結合 Stateful Stream Processing 和 FaaS，來提供一種全新的編寫 Stateful Application 的方式。

具體的實現邏輯，我就不再過多介紹，大家可以自行到官網進行檢視和學習。

Cloudera

Stephan 給的第一個 Keynote 還是比較的偏技術化，這也符合他的個人風格。在之後的包括第二天的所有 Keynote，基本上都是知名的大公司來給 Flink 站臺了。先從 Cloudera 說起，他們表示現在已經收到了越來越多的客戶點名要 Flink 的情況，因此就”順應民意“在他們的資料平臺里加入了 Flink 的支援。能在這種商業開源軟體提供商中佔據一席之地，基本也算是標誌在 Flink 已經進入了一個比較成熟的階段。另外，Cloudera 是玩開源的老大哥級別人物了，當然不會只是簡單的提供 Flink 軟體這麼簡單。他們在會上宣佈了他們已經組建了一支由兩名 Flink PMC 帶隊的工程團隊，並且打算後續在 Flink 社群也投入更多的資源，這無疑是給 Flink 社群的繁榮又注入了一股新鮮又強大的力量。

AWS

AWS 在第二天登場，由他們主管 EMR、Athena、DocumentDB以及區塊鏈的老大 Rahul 給出。他先是回顧了一下流計算相關的產品在 AWS 的發展歷程：

從圖中可以看出，他們早在2016年 Flink 嶄露頭角的時候就已經將 Flink 加入到了他們的 EMR 當中。相比 Cloudera 的後知後覺，AWS 在這方面果然就老江湖了許多。令人印象深刻的是，AWS 這幾年圍繞流計算產品的發展，一直有一個清晰的主線，那就是針對不同體量的客戶推出更加適合他們的產品和解決方案。他們很好的總結了不同體量的客戶對產品的需求的不同（相信這不僅僅只是針對流計算，針對其他的產品也是異曲同工）：

比如他們發現了大量的客戶有時候使用流計算框架只是簡單的解決一個資料轉存的問題，比如簡單的把資料從 Kinesis Data Stream（這個其實是他們的一個訊息佇列服務，光看名字容易有點誤導）轉存到 S3 上，或者把資料發到 Redshift 或者 Elasticsearch。針對這種場景，他們就開發了專門的 Kinesis Data Firehose 產品，讓使用者不需要寫程式碼就能夠完成這樣的工作。另外，一些具備一些開發能力的客戶，會寫一些程式碼或者 SQL 來對資料進行處理和分析。針對這種場景，他們提供了 Kinesis Data Analytics 服務。

另外讓人印象深刻的一點是，AWS 的各個產品之間的協同做的非常好（我在後來還參加了一個 AWS Kinesis 產品的演示分享，其中涉及到不少產品之間的協調和打通，讓人印象深刻）。每個產品專注解決一部分的問題，產品和產品之間在功能上不能說完全沒有重疊的地方，但基本上還是非常剋制。演講中分享的每個真實的使用者場景，基本都涉及了3-5個以上的產品互相的協同。對客戶需求的精準把握，以及產品的協同站位精確解決使用者問題，這兩點非常值得我們去學習。

扯的有點遠了，回到 Flink 上來。Rahul 最後總結了一下 Flink 是他們目前看到的會去訊息佇列裡消費資料的產品中增長最快的系統，但從絕對體量上來看還是偏小。這也基本符合 Flink 目前的一個狀態，熱度高，增長也很快，但是絕對體量還偏小，不過這也預示著想象的空間還比較大。

Google

Google 在 AWS 之後出場，由 Reven 和 Sergei 帶來（前者也是《Streaming Systems》一書的作者之一，終於見到真人了）。這個 Talk 整體上來講和 Flink 沒有太大的關係，分享的是 Google 這些年在流計算相關係統的研發過程中得到的經驗。和 AWS 相比，兩家公司的特色也是相當鮮明。AWS 分享的都是對客戶需求和產品的總結，而 Google 說的基本上都是純技術上的經驗收穫。聽了之後也確實收穫良多，不過由於篇幅問題就不在這具體展開了。人家也已經準備好一段總結讓我們可以打包帶走：

主議程

由於分身乏術，在主議程中我只挑選了一些個人比較感興趣或者是不怎麼了解的領域進行觀摩和學習。但為了整篇報告的完整性，我還是儘量的簡單介紹一下其他我沒有參與但是還算熟悉的議題。後續主辦方也會將所有的影片和 PPT 上傳到網上供大家進行檢視。接下來我就把議題按照個人理解分成幾個不同的類別，分別拋磚引玉一下。大家如果對其中的某些議題的細節特別感興趣的，可以再去仔細檢視影片和 PPT。

平臺化實踐

基於 Flink 構建資料平臺可以算得上最熱門的一個議題方向了。這幾年阿里巴巴實時計算團隊一直不遺餘力的向社群推廣基於 SQL 構建資料處理平臺的經驗，目前看起來大家也基本上認同了這個方向，也紛紛的開始上了生產。不過根據具體的場景，作業量的規模等特點，也有一些公司會選擇使用更加底層和更加靈活的 DataStream API 來構建資料平臺，或者兩者都提供。這也符合我們一開始的判斷，SQL 能解決大多數問題，但不是全部。在一些靈活的場景下，DataStream 能更方便和高效的解決使用者的問題。

議題1：《Writing a interactive SQL engine and interface for executing SQL against running streams using Flink》

這個分享來自美國的一家名叫 eventador 的創業公司，也是本次大會的贊助商之一。整個分享大部分還是他們產品架構和功能的介紹，基本上和我們以及其他公司的平臺架構類似。比較有意思的是，他們也發現了在平臺化的實踐過程中，使用者是同時需要 SQL 這種高階 API 以及更加靈活和偏底層點的 DataStream API，並且這兩者的比例是8：2開。

還有一個比較有意思的功能是，他們在 SQL 上提供了 JavaScript 的 UDF 支援，並且在他們的使用者之間非常受歡迎。在 SQL 上，持續的降低使用門檻確實是一個比較靠譜的路子，和我們想提供 Python UDF 支援也是基於同樣的出發點。

議題2：《Building a Self-Service Streaming Platform at Pinterest》

Pinterest 算是 Flink 社群的新面孔，這次是他們第一次在 Flink 的大會上分享他們的經驗。他們主要的應用場景主要是圍繞廣告來展開，使用 Flink 來給廣告主們實時反饋廣告的效果。這也算的上是 Flink 相當經典的一個使用場景了。至於為什麼這麼晚才用 Flink，他們上來就進行了說明。他們花了比較大的功夫去對比 Spark Streaming，Flink 以及 Kafka Stream 這3個引擎，權衡再三之後才選擇了 Flink，也算是比較謹慎和心細了。同時他們的老的業務基本上都是使用 Spark 跑批處理作業，在切換成流之後，也是需要拿出點實實在在的成績才有可能在公司內大規模推廣。

接著，他們也分享了兩個在平臺化實踐過程中填的坑。第一個是日誌的檢視，尤其是當所有的作業跑在 YARN 上的時候，當作業結束後怎麼檢視作業執行時的日誌是一個比較頭疼的問題。第二個是 Backfilling，在新的作業上線或者作業邏輯需要變更的時候，他們希望先追一部分存在 S3 上的歷史資料，然後在基本追完的時候切換到 Kafka 這樣的訊息佇列上繼續進行處理。這個 Backfilling 是 Flink 流批一體最經典的場景，而且看起來確實是個很普遍的剛需。如果沒記錯的話，這次大會就有 3 個議題提到了這方面的問題，以及他們的解法。解法各有千秋，不過如果 Flink 在引擎上能夠直接內建支援了這樣的場景的話，相信體驗會好不少（這也恰恰是 Flink 接下去一個比較重要的方向之一）。

其他議題推薦

• 《Stream SQL with Flink @ Yelp》：Yelp 已經算是 Flink 的老牌玩家了，在這個分享裡他們總結了他們目前的流計算場景，以及他們的平臺的做法。我因為時間衝突的原因沒有聽到這個分享，不過從其他渠道得到的反饋看起來他們應該是屬於玩的比較溜的。推薦大家在影片和 PPT 上線後觀摩學習一下。
• 《Flink for Everyone: Self-Service Data Analytics with StreamPipes》：一般來說，平臺化建設都是公司內部專案，很少進行開源。這個叫做 FZI 的非盈利機構跳出來當了一把雷鋒，提供了一套完全開源的平臺化工程實現： streampipes。自帶一整套托拉拽的作業構建流程，而且看起來介面也相當的不錯，有需要的同學可以參考一下。
• 《Dynamically Generated Flink Jobs at Scale》：這是高盛分享的基於 Flink 的平臺實踐，支援一天執行 12 萬的作業。在銀行和金融業的 IT 同學們可以參考下。

篇幅有限，還有其他相關的議題就不一一列出了。總體來說，基於 Flink 構建資料平臺已經是一個相當成熟的實踐，各行各業都有成功的案例進行參考。還沒有上車的同學們，你們還在等什麼？

應用場景類

除了上面的平臺化實踐，使用 Flink 解決某些應用場景的具體問題也是這次分享中一個比較熱門的方向。這些使用者往往自己編寫少量作業，來解決他們的實際問題。或者就乾脆是平臺的使用方，來分享如何使用平臺來解決更貼近終端使用者的問題。這也是 Flink 能夠真正創造實際業務價值的地方，本想多聽幾個，可無奈老是時間衝突。

議題1：《Making Sense of Streaming Sensor Data: How Uber Detects On-trip Car Crashes》

這是 Uber 分享的一個腦洞比較大的應用場景，他們使用 Flink 來實時判斷乘客是不是發生了車禍。和 Pinterest 一樣，在這個業務場景下，Uber 也是為了時效性而從 Spark 遷移到了 Flink。他們介紹了他們如何依賴兩項最重要的資料（GPS資訊和手機加速資訊），再套用機器學習模型，來實時的判斷乘客是否發生了車禍。

後續也提到了他們希望共享這個業務上收集的資料，以及在這個資料的基礎上生成的一些特徵，在其他的團隊進行推廣（怎麼感覺方向又要轉到平臺化了-_-!）

其他議題推薦

• 《Airbus makes more of the sky with Flink》：空客公司介紹了他們如何使用 Azure、Flink 來進行飛行資料的分析，旨在提供更好的飛行體驗。
• 《Intelligent Log Analysis and Real-time Anomaly Detection @ Salesforce》：Salesforce 介紹了他們使用 Flink 結合機器學習模型來解決實時日誌分析，並且實時探測一些異常情況比如關鍵服務效能下降等。
• 《Large Scale Real Time Ad Invalid Traffic Detection with Flink》：Criteo 這家法國的廣告公司介紹了廣告場景下進行實時的異常流量探測。
• 《Enabling Machine Learning with Apache Flink》：Lyft 分享了他們如何基於 Flink 構建了機器學習的平臺來解決多種多樣的業務問題。

簡單總結一下，在偏應用場景的方向上，已經越來越多的看到了 Flink 和機器學習結合使用的案例。基本上，一些稍微複雜點的問題很難透過規則邏輯，或者 SQL 來進行簡單的判定。這種情況下，機器學習就能夠派上比較大的用場。目前看來，大家還是更多的先使用其他引擎訓練好模型，然後讓 Flink 載入模型之後進行預測操作。但是過程中也會碰到類似兩個引擎對樣本的處理邏輯不同等問題而影響最終的效果。這也算是 Flink 今後的一個機會，如果 Flink 在更加偏向批處理的模型訓練上能提供比較好的支援，那麼使用者完全可以使用同一個引擎來進行諸如用本拼接，模型訓練以及實時預測這一整套流程。整個的開發體驗包括實際上線效果相信都會有較大的提升，讓我們拭目以待 Flink 在這方面的動作。

生產實踐

這部分主要是生產實踐的經驗分享，很不好意思的是，相關的議題我一個都沒有參與。我根據議題的簡介簡單做個介紹，感興趣的同學可以自行檢視相關資料。

• 《Apache Flink Worst Practices》：大家可能都聽過不少 Best Practices，這個分享反其道而行之，專門介紹各種使用 Flink 的最差姿勢，基本上算是分享各種踩坑或者踩雷的地方，讓聽眾能夠避開。
• 《How to configure your streaming jobs like a pro》：Cloudera 基於這些年他們在數百個流計算作業上總結下來的調參經驗。針對不同型別的作業，哪些引數比較關鍵。
• 《Running Flink in production: The good, the bad and the in-between》：Lyft 分享的他們運維 Flink 的經驗，有哪些 Flink 做的比較好的地方，也包括哪些 Flink 現在做的不夠好的地方。讓大家對運維 Flink 生產作業有更全面的認知。
• 《Introspection of the Flink in production》：Criteo 分享的教大家如何觀測 Flink 作業是否正常的經驗，以及當作業出問題時，如何最快的定位 root cause。
• 《Kubernetes + Operator + PaaSTA = Flink @ Yelp》：當大部分人還是基於 Yarn 來執行 Flink的時候，Yelp 這個深度玩家已然走到了大家前面。這也是我在這次大會中看到的唯一使用 Flink + K8S 上線的組合。

雖然一個議題也沒聽，但是也從別的議題中零零星星的聽到一些大家關於 Flink 生產的話題，其中比較突出的是 Flink 和 Kubernetes 的結合問題。K8S 的火熱，讓大家都有種不蹭一下熱度就落伍了的想法。不少公司都有朝著這個方向進行嘗試和探索的意願。其中就屬 Yelp 走的最快，已經拿這套架構上線了。個人覺得 Flink 和 K8S 的結合還是相當靠譜的，可以解鎖更多 Application 和線上服務相關的姿勢。當然，阿里巴巴實時計算團隊在這方面也沒有落伍，我們也已經和阿里雲 K8S 合作了相當長一段時間，最近也推出了基於 K8S 容器化的全新一代實時計算產品 ververica platform。

研究型專案

前面的議題基本都是一些工程化的實踐，這次大會還有不少研究型的專案吸引了我的興趣。生態的繁榮發展，除了有各大公司的實踐之外，偏理論化的研究型專案也不可缺少。聽說這次大會收到了不少研究型的議題，但由於議題數量有限，只從裡面挑選了一部分。

議題1：《Self-managed and automatically reconfigurable stream processing》

這是蘇黎世聯邦理工學院的一名博士後帶來的自動配置流計算作業的一個研究型專案。他們的研究方向主要集中在如何讓流計算作業能夠自治，不需要人為干預而能夠自動的調整到最佳的狀態。這和 Google 在 keynote 裡的分享不謀而合，都是希望系統本身具備足夠強的動態調整能力。這個分享主要有兩部分內容，第一部分是提出了一種新的效能瓶頸分析理論。一般來說，當我們想要最佳化一個流計算作業的吞吐和延遲時，我們往往採用比較傳統的觀測 CPU 熱點的方式，找到作業中最耗 CPU 的部分然後進行最佳化。但往往我們忽略了一個事實是，影響系統 latency 或者吞吐往往還有各種等待的操作，比如運算元在等待資料進行處理等。如果我們單獨最佳化 cpu 熱點，最佳化完之後可能只會讓系統其它地方等待的時間變長，並不能真正帶來延遲的下降和吞吐的上升。所以他們先提出了一種”關鍵路徑“的理論，在判斷效能瓶頸時是以鏈路為單元進行判斷和測量。只有真正的降低整條關鍵路徑的耗時，才能有有效的降低作業的延遲。

第二個部分是介紹了一種新的作業自動擴縮容機制，並且和微軟的 Dhalion 進行了對比。這個做法的特色在於，其他類似的系統總是對一個運算元單獨做決策，而他們會更多的把多個運算元進行同時考慮。在擴縮容的時候讓多個運算元同時操作，減少收斂所需要的動作次數。

流計算任務的自治化也是我個人非常感興趣的一個方向，也看到不少研究型的專案和論文在闡述這方面的工作，但暫時還未見到工業界對比有比較深入的分享（AWS 的 kinesis 服務具備動態擴縮容能力，但由於缺乏細節介紹不確定是否足夠通用以及是否能夠應對比較複雜的場景）。阿里巴巴實時計算團隊早在一年前就啟動了類似的專案，在這方向上進行了嘗試和探索。面對內部大量的業務場景和需求，加上目前各種前沿的研究，相信不遠的將來可以有所突破。

其他議題推薦

• 《Moving on from RocksDB to something FASTER》：這也是蘇黎世聯邦理工帶來的關於狀態儲存相關的研究，尋找比 RocksDB 更快的解決方案。在 Statebackend 上，阿里巴巴實時計算團隊也有所佈局，我們正在探索一種完全基於 Java 的儲存引擎。
• 《Scotty: Efficient Window Aggregation with General Stream Slicing》：介紹了一種使用切片來提升視窗聚合效能的方法。

深度技術剖析

這個部分主要介紹的都是 Flink 在過去1-2個版本內做的一些大的 feature 和重構。由於本人就是 Flink 的開發者，對這些工作都比較熟悉，因此就沒有選擇去聽這些分享。借用 Stephan 在 Keynote 中的兩張圖，基本做了比較好的概括。

有同學對其中個別的技術點感興趣的話，基本都能夠找到對應的議題，在這裡我就不展開一一介紹了。

總結和感想

這幾年隨著阿里巴巴持續對 Flink 的大力投資，Flink 的成熟度和活躍度均有了質的飛躍。社群生態也越發的繁榮，包括 cloudera 和 AWS 都已經開始積極的擁抱 Flink，也得到了不錯的成果。各大公司的議題也從早年的抱著嚐鮮的態度嘗試 Flink，轉變成了來分享使用 Flink 大規模上線後的一些成果和經驗教訓。在此基礎之上，逐漸了形成了基於 Flink 的平臺化實踐、結合機器學習進行具體業務的問題解決和一些比較新穎的探索研究型專案等方向，讓整個生態的發展更加的完整和壯實。不僅如此，Flink 也在積極的探索一些新的熱門方向，比如和 K8S 的結合，和線上服務場景的結合等等，體現了這個生態的強大生命力。

不過歸根結底，Flink 到底還是一個大資料計算引擎，其宗旨還是希望去解決大資料計算這個問題。在文章的一開頭，我也提到了在看到 Flink 進軍 Application 和 FaaS 的方向時，一個疑問一直在我的心頭縈繞：Flink 到底是怎麼樣的一個計算引擎，它究竟是要解決什麼樣的問題？如果沒有一個很清晰的主線和長遠認識，在引擎的發展過程中很容易就會走偏，最終導致失敗。

大部分人可能還停留在 Flink 是一個成熟的實時計算引擎的認知，但 Flink 從誕生的第一天起就想著要解決批處理的問題。即便現在 Flink 已經逐漸填補了批處理這個坑，但又朝著 Application 這樣的線上服務場景發起了探索。乍一看，Flink 好像什麼問題都想解，什麼方向都想插一腳，真的是這樣嗎？

帶著這樣的疑問參加完了整個大會，又額外思考了幾天，我開始有了一些新的認識和見解。想要回答 Flink 到底是怎麼樣的一個計算引擎，它究竟想解決什麼樣的問題這個疑問，我們得從資料本身開始看起。畢竟，一個計算引擎所要處理的物件，就是資料本身。

第一個問題是，我們需要處理的資料都是從哪裡來的？對大部分公司和企業來說，資料可能來自各種手機APP，IoT裝置，線上服務的日誌，使用者的查詢等等。雖然資料的來源和種類各不相同，但有一個特點可能是大部分情況下都具備的： 資料總是實時的不斷產生。

我們可以使用流（Stream）或者日誌（Log）這樣的概念來模擬抽象所需要處理的資料，這也是現在一種比較流行的抽象方式，Jay Kreps 大神早年就在不遺餘力的推廣這樣的方式，感興趣的同學可以讀一下這篇博文：
《The Log: What every software engineer should know about real-time data's unifying abstraction》。

在這裡先解答一下常見的幾個疑惑，因為這個看起來和大家平時接觸到的資料比較不一樣。常見的問題會有：

• 我平時的接觸的資料都存在Database裡，看起來這個不一樣啊？Database 可以理解成為將這些 Stream 物化後的產物，一般是為了後續的頻繁訪問可以更快。而且大部分 Database 系統的實現裡，其實也是用的 Log 來儲存所有的增刪改行為。
• 我平時接觸的資料都放在數倉裡，按照天做了分割槽。這種情況可以再往資料的源頭想一下，資料剛產生的時候不會直接到你的數倉，一般也是需要經過一個 ETL 過程。一般的數倉可以理解成將過去的一段段有限流，轉存成了更高效的格式。

當我們使用這樣的方式來抽象資料之後，我們就可以考慮我們會在這樣的資料上做什麼樣型別的計算了。先從有限流開始：

• 對過去的一部分資料做一下簡單的清洗和處理，這基本上就是大部分經典的批處理 ETL 作業
• 對過去的一部分資料做一些稍微複雜點的關聯和分析，這算是比 ETL 稍微複雜點的批處理作業
• 對過去的一部分資料進行深度的挖掘從而產生更深的洞察，這是機器學習訓練模型的場景

對於無限流來說，我們需要時刻消費最新產生的資料，那麼可能產生的計算型別會有：

• 和批處理類似的 ETL 和分析型的資料處理場景，只不過計算發生在最新實時產生的資料上
• 對於最新產生的資料進行特徵分析和挖掘，這是機器學習實時訓練模型的場景
• 將最新產生的資料樣本化，然後套用機器學習模型進行判定，這是典型的實時預測場景
• 根據最新產生的資料，觸發一系列後臺業務邏輯，這就是典型的 Application 或者線上服務場景

特別值得注意的是，有限流的計算和無限流的計算並不是完全獨立存在的，有時候我們的計算需要在兩者之間進行切換，比如這些場景：

• 先將所有的歷史資料進行處理，然後開始實時消費最新產生的資料。比如說統計的場景，當統計口徑變化之後，我們希望先把所有歷史資料重新統計一遍，然後再接上最新的資料進行實時統計。
• 我們先根據歷史資料進行樣本生成然後訓練模型，然後再消費最新的資料，將其轉化為樣本後開始做實時的預測和判定。這也是機器學習中很典型的做法，關鍵點在於需要保證訓練模型時的樣本邏輯和實時判定時的樣本邏輯需要保持一致。

另外，我們也可以嘗試從計算的延遲的角度對這些繁多的計算模式進行大致的分類：

列舉了這麼多例子和場景之後，大家應該也差不多能領悟到其中的道理了。當我們基於 Stream 來抽象所有的資料之後，在資料之上引發的計算模式是相當的多樣化的。正如 Stephan 一開始在 keynote 中提到的，傳統的 Data Processing 和訊息驅動的 Application 場景，都不足以覆蓋所有的計算模型。所有計算模型的本質是 Stream Processing，只不過有時候我們需要去處理有限的資料，有時候我們又需要去處理最新的實時資料。Flink 的願景就是成為一個通用的 Stream Processing 引擎，並覆蓋基於這個正規化的所有可能的比較具體的計算場景。這樣一來當使用者有不同的計算需求時，不需要選擇多個不同的系統（比如經典的 lambda 架構，我們需要選擇一個專門的批處理引擎和專門的流計算引擎）。同時當我們需要在不同的計算模式間進行切換的時候（比如先處理歷史資料再接上實時資料），使用相同的計算引擎也有利於我們保證行為的統一。

這個目標無疑是相當宏大的，社群也還在一步一步的向前邁進當中。在幾個月前釋出的1.9版本，Flink 已經將批處理這一大場景進行了完善和加強。後續還需要攻克基於批處理的機器學習訓練、實時模型預測等場景。同時對延遲和一致性有嚴格要求的線上應用場景，也對 Flink 的錯誤恢復速度，Checkpoint 的速度和穩定性也都提出了更高的要求。

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。