一文帶你瞭解 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 的速度和穩定性也都提出了更高的要求。在年末，咱們會在北京舉辦新一屆的 Flink Forward Asia 大會，屆時各大互聯網公司都會來分享他們使用 Flink 的經驗，同時還能夠學習到社區的最新動向，歡迎你們參加。

最後難免落個俗套，目標是遠大的，征途是艱辛的，但願能有更多的牛人加入咱們，加入 Flink 社區，你們一塊兒來攻克這個世界性的難題，達成」讓天下沒有難跑的計算「這個目標。

阿里雲雙11領億元補貼，拼手氣抽iPhone 11 Pro、衛衣等好禮，點此參與：http://t.cn/Ai1hLLJT

---

本文做者：巴蜀真人

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。