一文帶你了解 Flink Forward 柏林站全部重點內(nèi)容
前言
2019.10.7~9號，隨著70周年國慶活動的順利閉幕，F(xiàn)link Forward 也照例在他們的發(fā)源地柏林舉辦了第五屆大會。雖然還沒有拿到具體的數(shù)據(jù)，不過從培訓(xùn)門票已經(jīng)在會前銷售一空的這樣的現(xiàn)象來看，F(xiàn)link Forward 大會還是繼續(xù)保持了一個良好的勢頭。本屆大會不管是從參會人數(shù)上，提交的議題，以及參加的公司數(shù)量來看都繼續(xù)創(chuàng)了一個新高。當(dāng)然，這要去掉去年 Flink Forward 北京站的數(shù)據(jù) ;-)。阿里巴巴這次共派出了包括筆者在內(nèi)的3名講師，總共參加了4場分享和2個問答環(huán)節(jié)。在這里，我會根據(jù)自己參與的議題給大家做一下這次會議整體的一個介紹和個人在這次參會過程里面的感受和思考，希望對感興趣的同學(xué)有所幫助。
Keynote
先說說這兩天的 Keynote。第一天的開場 Keynote 還是繼續(xù)由社區(qū)一哥 Stephan Ewen 來給出。他先總結(jié)了一下 Flink 項目目前的一些狀態(tài)，包括：
-
Flink 在8月份的 Github star 數(shù)超過了1萬
-
在所有 Apache 項目中，F(xiàn)link 排在郵件列表活躍度的 Top 3，并且這個數(shù)字在接下來很有可能還會變小
-
8月份發(fā)布的 1.9.0 版本是 Flink 目前為止發(fā)布的功能最多，修改量最大的一個版本
這張圖片很好的概括了 Flink 在過去大半年所側(cè)重的工作：
對于 Flink 未來的一個可能的方向，Stephan 繼續(xù)表達了他對 Application 這種偏在線服務(wù)的場景的興趣。他先是將我們平時所說的批處理和流計算總結(jié)為 Data Processing，同時將消息驅(qū)動和數(shù)據(jù)庫之類的應(yīng)用總結(jié)為 Applications，而 Stream Processing 就是連接這兩種看起來截然不同的場景的橋梁。我在一開始聽到這個的時候也有點一頭霧水，不明就里的感覺，經(jīng)過這幾天對這個問題的思考，有了一些自己的理解，我將在文末展開進行解釋。提到 Application，就不得不提現(xiàn)在很流行的 FaaS（Function as a Service）。在這個領(lǐng)域，Stephan 覺得大家都忽視了 State 在這里面的重要性。比如一個典型的 Application 場景，一般都會具備以下這些特點：
-
整個 Application 會有一個或者多個入口，計算邏輯由消息來驅(qū)動
-
具體的業(yè)務(wù)邏輯被拆分成粒度較小的幾個單元，每個邏輯單元使用一個 Function 來執(zhí)行具體的邏輯
-
Function 之間會互相調(diào)用，一般來說我們也會將這些調(diào)用設(shè)計為異步的模式
-
每個 Function 的計算邏輯可能會需要一些狀態(tài)，比如可以使用數(shù)據(jù)庫作為狀態(tài)的存儲
-
在完整的計算邏輯完成之后，我們會通過一個統(tǒng)一的出口返回處理的狀態(tài)
這里面屬第三點最難做。大家可以想象一下，假如現(xiàn)在我們的 Application 要處理類似電商場景下單這樣的過程，同時我們依賴數(shù)據(jù)庫作為這個應(yīng)用的狀態(tài)存儲。我們有一個專門的庫存管理邏輯和一個下單邏輯。在一個完整的購買邏輯里，我們需要先調(diào)用庫存管理模塊，檢查下該商品是否有庫存，然后將該商品的庫存從數(shù)據(jù)庫里減去1。這一步成功之后，我們的服務(wù)再繼續(xù)調(diào)用下單邏輯，在數(shù)據(jù)庫里面生成一個新的訂單。在一切都正常的時候，這樣的邏輯還是比較簡單的，但一旦有錯誤出現(xiàn)就會相當(dāng)麻煩。比如我們已經(jīng)將庫存減掉，但是在生成訂單的過程中發(fā)生了錯誤，這樣我們還得想辦法讓庫存進行回滾。一旦類似的業(yè)務(wù)邏輯單元變多之后，你的應(yīng)用代碼將變得異常復(fù)雜。這個問題就是典型的 end-to-end exactly once，我們希望一個錯綜復(fù)雜的計算流程，要么全部一起成功，要么全部失敗，就當(dāng)它完全沒發(fā)生過一樣。
為了解決這樣的問題，結(jié)合 Flink 目前的一些積累，Stephan 推出了一個全新的項目：
statefun.io，即 Stateful Functions。通過結(jié)合 Stateful Stream Processing 和 FaaS，來提供一種全新的編寫 Stateful Application 的方式。
具體的實現(xiàn)邏輯，我就不再過多介紹，大家可以自行到官網(wǎng)進行查看和學(xué)習(xí)。
Cloudera
Stephan 給的第一個 Keynote 還是比較的偏技術(shù)化，這也符合他的個人風(fēng)格。在之后的包括第二天的所有 Keynote，基本上都是知名的大公司來給 Flink 站臺了。先從 Cloudera 說起，他們表示現(xiàn)在已經(jīng)收到了越來越多的客戶點名要 Flink 的情況，因此就”順應(yīng)民意“在他們的數(shù)據(jù)平臺里加入了 Flink 的支持。能在這種商業(yè)開源軟件提供商中占據(jù)一席之地，基本也算是標志在 Flink 已經(jīng)進入了一個比較成熟的階段。另外，Cloudera 是玩開源的老大哥級別人物了，當(dāng)然不會只是簡單的提供 Flink 軟件這么簡單。他們在會上宣布了他們已經(jīng)組建了一支由兩名 Flink PMC 帶隊的工程團隊，并且打算后續(xù)在 Flink 社區(qū)也投入更多的資源，這無疑是給 Flink 社區(qū)的繁榮又注入了一股新鮮又強大的力量。
AWS
AWS 在第二天登場，由他們主管 EMR、Athena、DocumentDB以及區(qū)塊鏈的老大 Rahul 給出。他先是回顧了一下流計算相關(guān)的產(chǎn)品在 AWS 的發(fā)展歷程：
從圖中可以看出，他們早在2016年 Flink 嶄露頭角的時候就已經(jīng)將 Flink 加入到了他們的 EMR 當(dāng)中。相比 Cloudera 的后知后覺，AWS 在這方面果然就老江湖了許多。令人印象深刻的是，AWS 這幾年圍繞流計算產(chǎn)品的發(fā)展，一直有一個清晰的主線，那就是針對不同體量的客戶推出更加適合他們的產(chǎn)品和解決方案。他們很好的總結(jié)了不同體量的客戶對產(chǎn)品的需求的不同（相信這不僅僅只是針對流計算，針對其他的產(chǎn)品也是異曲同工）：
比如他們發(fā)現(xiàn)了大量的客戶有時候使用流計算框架只是簡單的解決一個數(shù)據(jù)轉(zhuǎn)存的問題，比如簡單的把數(shù)據(jù)從 Kinesis Data Stream（這個其實是他們的一個消息隊列服務(wù)，光看名字容易有點誤導(dǎo)）轉(zhuǎn)存到 S3 上，或者把數(shù)據(jù)發(fā)到 Redshift 或者 Elasticsearch。針對這種場景，他們就開發(fā)了專門的 Kinesis Data Firehose 產(chǎn)品，讓用戶不需要寫代碼就能夠完成這樣的工作。另外，一些具備一些開發(fā)能力的客戶，會寫一些代碼或者 SQL 來對數(shù)據(jù)進行處理和分析。針對這種場景，他們提供了 Kinesis Data Analytics 服務(wù)。
另外讓人印象深刻的一點是，AWS 的各個產(chǎn)品之間的協(xié)同做的非常好（我在后來還參加了一個 AWS Kinesis 產(chǎn)品的演示分享，其中涉及到不少產(chǎn)品之間的協(xié)調(diào)和打通，讓人印象深刻）。每個產(chǎn)品專注解決一部分的問題，產(chǎn)品和產(chǎn)品之間在功能上不能說完全沒有重疊的地方，但基本上還是非?？酥?。演講中分享的每個真實的用戶場景，基本都涉及了3-5個以上的產(chǎn)品互相的協(xié)同。對客戶需求的精準把握，以及產(chǎn)品的協(xié)同站位精確解決用戶問題，這兩點非常值得我們?nèi)W(xué)習(xí)。
扯的有點遠了，回到 Flink 上來。Rahul 最后總結(jié)了一下 Flink 是他們目前看到的會去消息隊列里消費數(shù)據(jù)的產(chǎn)品中增長最快的系統(tǒng)，但從絕對體量上來看還是偏小。這也基本符合 Flink 目前的一個狀態(tài)，熱度高，增長也很快，但是絕對體量還偏小，不過這也預(yù)示著想象的空間還比較大。
Google
Google 在 AWS 之后出場，由 Reven 和 Sergei 帶來（前者也是《Streaming Systems》一書的作者之一，終于見到真人了）。這個 Talk 整體上來講和 Flink 沒有太大的關(guān)系，分享的是 Google 這些年在流計算相關(guān)系統(tǒng)的研發(fā)過程中得到的經(jīng)驗。和 AWS 相比，兩家公司的特色也是相當(dāng)鮮明。AWS 分享的都是對客戶需求和產(chǎn)品的總結(jié)，而 Google 說的基本上都是純技術(shù)上的經(jīng)驗收獲。聽了之后也確實收獲良多，不過由于篇幅問題就不在這具體展開了。人家也已經(jīng)準備好一段總結(jié)讓我們可以打包帶走：
主議程
由于分身乏術(shù)，在主議程中我只挑選了一些個人比較感興趣或者是不怎么了解的領(lǐng)域進行觀摩和學(xué)習(xí)。但為了整篇報告的完整性，我還是盡量的簡單介紹一下其他我沒有參與但是還算熟悉的議題。后續(xù)主辦方也會將所有的視頻和 PPT 上傳到網(wǎng)上供大家進行查看。接下來我就把議題按照個人理解分成幾個不同的類別，分別拋磚引玉一下。大家如果對其中的某些議題的細節(jié)特別感興趣的，可以再去仔細查看視頻和 PPT。
平臺化實踐
基于 Flink 構(gòu)建數(shù)據(jù)平臺可以算得上最熱門的一個議題方向了。這幾年阿里巴巴實時計算團隊一直不遺余力的向社區(qū)推廣基于 SQL 構(gòu)建數(shù)據(jù)處理平臺的經(jīng)驗，目前看起來大家也基本上認同了這個方向，也紛紛的開始上了生產(chǎn)。不過根據(jù)具體的場景，作業(yè)量的規(guī)模等特點，也有一些公司會選擇使用更加底層和更加靈活的 DataStream API 來構(gòu)建數(shù)據(jù)平臺，或者兩者都提供。這也符合我們一開始的判斷，SQL 能解決大多數(shù)問題，但不是全部。在一些靈活的場景下，DataStream 能更方便和高效的解決用戶的問題。
議題1：《Writing a interactive SQL engine and interface for executing SQL against running streams using Flink》
這個分享來自美國的一家名叫 eventador 的創(chuàng)業(yè)公司，也是本次大會的贊助商之一。整個分享大部分還是他們產(chǎn)品架構(gòu)和功能的介紹，基本上和我們以及其他公司的平臺架構(gòu)類似。比較有意思的是，他們也發(fā)現(xiàn)了在平臺化的實踐過程中，用戶是同時需要 SQL 這種高階 API 以及更加靈活和偏底層點的 DataStream API，并且這兩者的比例是8：2開。
還有一個比較有意思的功能是，他們在 SQL 上提供了 JavaScript 的 UDF 支持，并且在他們的用戶之間非常受歡迎。在 SQL 上，持續(xù)的降低使用門檻確實是一個比較靠譜的路子，和我們想提供 Python UDF 支持也是基于同樣的出發(fā)點。
議題2：《Building a Self-Service Streaming Platform at Pinterest》
Pinterest 算是 Flink 社區(qū)的新面孔，這次是他們第一次在 Flink 的大會上分享他們的經(jīng)驗。他們主要的應(yīng)用場景主要是圍繞廣告來展開，使用 Flink 來給廣告主們實時反饋廣告的效果。這也算的上是 Flink 相當(dāng)經(jīng)典的一個使用場景了。至于為什么這么晚才用 Flink，他們上來就進行了說明。他們花了比較大的功夫去對比 Spark Streaming，F(xiàn)link 以及 Kafka Stream 這3個引擎，權(quán)衡再三之后才選擇了 Flink，也算是比較謹慎和心細了。同時他們的老的業(yè)務(wù)基本上都是使用 Spark 跑批處理作業(yè)，在切換成流之后，也是需要拿出點實實在在的成績才有可能在公司內(nèi)大規(guī)模推廣。
接著，他們也分享了兩個在平臺化實踐過程中填的坑。第一個是日志的查看，尤其是當(dāng)所有的作業(yè)跑在 YARN 上的時候，當(dāng)作業(yè)結(jié)束后怎么查看作業(yè)運行時的日志是一個比較頭疼的問題。第二個是 Backfilling，在新的作業(yè)上線或者作業(yè)邏輯需要變更的時候，他們希望先追一部分存在 S3 上的歷史數(shù)據(jù)，然后在基本追完的時候切換到 Kafka 這樣的消息隊列上繼續(xù)進行處理。這個 Backfilling 是 Flink 流批一體最經(jīng)典的場景，而且看起來確實是個很普遍的剛需。如果沒記錯的話，這次大會就有 3 個議題提到了這方面的問題，以及他們的解法。解法各有千秋，不過如果 Flink 在引擎上能夠直接內(nèi)置支持了這樣的場景的話，相信體驗會好不少（這也恰恰是 Flink 接下去一個比較重要的方向之一）。
其他議題推薦
-
《Stream SQL with Flink @ Yelp》：Yelp 已經(jīng)算是 Flink 的老牌玩家了，在這個分享里他們總結(jié)了他們目前的流計算場景，以及他們的平臺的做法。我因為時間沖突的原因沒有聽到這個分享，不過從其他渠道得到的反饋看起來他們應(yīng)該是屬于玩的比較溜的。推薦大家在視頻和 PPT 上線后觀摩學(xué)習(xí)一下。
-
《Flink for Everyone: Self-Service Data Analytics with StreamPipes》：一般來說，平臺化建設(shè)都是公司內(nèi)部項目，很少進行開源。這個叫做 FZI 的非盈利機構(gòu)跳出來當(dāng)了一把雷鋒，提供了一套完全開源的平臺化工程實現(xiàn)：
streampipes。自帶一整套托拉拽的作業(yè)構(gòu)建流程，而且看起來界面也相當(dāng)?shù)牟诲e，有需要的同學(xué)可以參考一下。
-
《Dynamically Generated Flink Jobs at Scale》：這是高盛分享的基于 Flink 的平臺實踐，支持一天運行 12 萬的作業(yè)。在銀行和金融業(yè)的 IT 同學(xué)們可以參考下。
篇幅有限，還有其他相關(guān)的議題就不一一列出了?？傮w來說，基于 Flink 構(gòu)建數(shù)據(jù)平臺已經(jīng)是一個相當(dāng)成熟的實踐，各行各業(yè)都有成功的案例進行參考。還沒有上車的同學(xué)們，你們還在等什么？
應(yīng)用場景類
除了上面的平臺化實踐，使用 Flink 解決某些應(yīng)用場景的具體問題也是這次分享中一個比較熱門的方向。這些用戶往往自己編寫少量作業(yè)，來解決他們的實際問題。或者就干脆是平臺的使用方，來分享如何使用平臺來解決更貼近終端用戶的問題。這也是 Flink 能夠真正創(chuàng)造實際業(yè)務(wù)價值的地方，本想多聽幾個，可無奈老是時間沖突。
議題1：《Making Sense of Streaming Sensor Data: How Uber Detects On-trip Car Crashes》
這是 Uber 分享的一個腦洞比較大的應(yīng)用場景，他們使用 Flink 來實時判斷乘客是不是發(fā)生了車禍。和 Pinterest 一樣，在這個業(yè)務(wù)場景下，Uber 也是為了時效性而從 Spark 遷移到了 Flink。他們介紹了他們?nèi)绾我蕾噧身椬钪匾臄?shù)據(jù)（GPS信息和手機加速信息），再套用機器學(xué)習(xí)模型，來實時的判斷乘客是否發(fā)生了車禍。
后續(xù)也提到了他們希望共享這個業(yè)務(wù)上收集的數(shù)據(jù)，以及在這個數(shù)據(jù)的基礎(chǔ)上生成的一些特征，在其他的團隊進行推廣（怎么感覺方向又要轉(zhuǎn)到平臺化了-_-!）
其他議題推薦
-
《Airbus makes more of the sky with Flink》：空客公司介紹了他們?nèi)绾问褂?Azure、Flink 來進行飛行數(shù)據(jù)的分析，旨在提供更好的飛行體驗。
-
《Intelligent Log Analysis and Real-time Anomaly Detection @ Salesforce》：Salesforce 介紹了他們使用 Flink 結(jié)合機器學(xué)習(xí)模型來解決實時日志分析，并且實時探測一些異常情況比如關(guān)鍵服務(wù)性能下降等。
-
《Large Scale Real Time Ad Invalid Traffic Detection with Flink》：Criteo 這家法國的廣告公司介紹了廣告場景下進行實時的異常流量探測。
-
《Enabling Machine Learning with Apache Flink》：Lyft 分享了他們?nèi)绾位?Flink 構(gòu)建了機器學(xué)習(xí)的平臺來解決多種多樣的業(yè)務(wù)問題。
簡單總結(jié)一下，在偏應(yīng)用場景的方向上，已經(jīng)越來越多的看到了 Flink 和機器學(xué)習(xí)結(jié)合使用的案例。基本上，一些稍微復(fù)雜點的問題很難通過規(guī)則邏輯，或者 SQL 來進行簡單的判定。這種情況下，機器學(xué)習(xí)就能夠派上比較大的用場。目前看來，大家還是更多的先使用其他引擎訓(xùn)練好模型，然后讓 Flink 加載模型之后進行預(yù)測操作。但是過程中也會碰到類似兩個引擎對樣本的處理邏輯不同等問題而影響最終的效果。這也算是 Flink 今后的一個機會，如果 Flink 在更加偏向批處理的模型訓(xùn)練上能提供比較好的支持，那么用戶完全可以使用同一個引擎來進行諸如用本拼接，模型訓(xùn)練以及實時預(yù)測這一整套流程。整個的開發(fā)體驗包括實際上線效果相信都會有較大的提升，讓我們拭目以待 Flink 在這方面的動作。
生產(chǎn)實踐
這部分主要是生產(chǎn)實踐的經(jīng)驗分享，很不好意思的是，相關(guān)的議題我一個都沒有參與。我根據(jù)議題的簡介簡單做個介紹，感興趣的同學(xué)可以自行查看相關(guān)資料。
-
《Apache Flink Worst Practices》：大家可能都聽過不少 Best Practices，這個分享反其道而行之，專門介紹各種使用 Flink 的最差姿勢，基本上算是分享各種踩坑或者踩雷的地方，讓聽眾能夠避開。
-
《How to configure your streaming jobs like a pro》：Cloudera 基于這些年他們在數(shù)百個流計算作業(yè)上總結(jié)下來的調(diào)參經(jīng)驗。針對不同類型的作業(yè)，哪些參數(shù)比較關(guān)鍵。
-
《Running Flink in production: The good, the bad and the in-between》：Lyft 分享的他們運維 Flink 的經(jīng)驗，有哪些 Flink 做的比較好的地方，也包括哪些 Flink 現(xiàn)在做的不夠好的地方。讓大家對運維 Flink 生產(chǎn)作業(yè)有更全面的認知。
-
《Introspection of the Flink in production》：Criteo 分享的教大家如何觀測 Flink 作業(yè)是否正常的經(jīng)驗，以及當(dāng)作業(yè)出問題時，如何最快的定位 root cause。
-
《Kubernetes + Operator + PaaSTA = Flink @ Yelp》：當(dāng)大部分人還是基于 Yarn 來運行 Flink的時候，Yelp 這個深度玩家已然走到了大家前面。這也是我在這次大會中看到的唯一使用 Flink + K8S 上線的組合。
雖然一個議題也沒聽，但是也從別的議題中零零星星的聽到一些大家關(guān)于 Flink 生產(chǎn)的話題，其中比較突出的是 Flink 和 Kubernetes 的結(jié)合問題。K8S 的火熱，讓大家都有種不蹭一下熱度就落伍了的想法。不少公司都有朝著這個方向進行嘗試和探索的意愿。其中就屬 Yelp 走的最快，已經(jīng)拿這套架構(gòu)上線了。個人覺得 Flink 和 K8S 的結(jié)合還是相當(dāng)靠譜的，可以解鎖更多 Application 和在線服務(wù)相關(guān)的姿勢。當(dāng)然，阿里巴巴實時計算團隊在這方面也沒有落伍，我們也已經(jīng)和阿里云 K8S 合作了相當(dāng)長一段時間，最近也推出了基于 K8S 容器化的全新一代實時計算產(chǎn)品 ververica platform。
研究型項目
前面的議題基本都是一些工程化的實踐，這次大會還有不少研究型的項目吸引了我的興趣。生態(tài)的繁榮發(fā)展，除了有各大公司的實踐之外，偏理論化的研究型項目也不可缺少。聽說這次大會收到了不少研究型的議題，但由于議題數(shù)量有限，只從里面挑選了一部分。
議題1：《Self-managed and automatically reconfigurable stream processing》
這是蘇黎世聯(lián)邦理工學(xué)院的一名博士后帶來的自動配置流計算作業(yè)的一個研究型項目。他們的研究方向主要集中在如何讓流計算作業(yè)能夠自治，不需要人為干預(yù)而能夠自動的調(diào)整到最佳的狀態(tài)。這和 Google 在 keynote 里的分享不謀而合，都是希望系統(tǒng)本身具備足夠強的動態(tài)調(diào)整能力。這個分享主要有兩部分內(nèi)容，第一部分是提出了一種新的性能瓶頸分析理論。一般來說，當(dāng)我們想要優(yōu)化一個流計算作業(yè)的吞吐和延遲時，我們往往采用比較傳統(tǒng)的觀測 CPU 熱點的方式，找到作業(yè)中最耗 CPU 的部分然后進行優(yōu)化。但往往我們忽略了一個事實是，影響系統(tǒng) latency 或者吞吐往往還有各種等待的操作，比如算子在等待數(shù)據(jù)進行處理等。如果我們單獨優(yōu)化 cpu 熱點，優(yōu)化完之后可能只會讓系統(tǒng)其它地方等待的時間變長，并不能真正帶來延遲的下降和吞吐的上升。所以他們先提出了一種”關(guān)鍵路徑“的理論，在判斷性能瓶頸時是以鏈路為單元進行判斷和測量。只有真正的降低整條關(guān)鍵路徑的耗時，才能有有效的降低作業(yè)的延遲。
第二個部分是介紹了一種新的作業(yè)自動擴縮容機制，并且和微軟的 Dhalion 進行了對比。這個做法的特色在于，其他類似的系統(tǒng)總是對一個算子單獨做決策，而他們會更多的把多個算子進行同時考慮。在擴縮容的時候讓多個算子同時操作，減少收斂所需要的動作次數(shù)。
流計算任務(wù)的自治化也是我個人非常感興趣的一個方向，也看到不少研究型的項目和論文在闡述這方面的工作，但暫時還未見到工業(yè)界對比有比較深入的分享（AWS 的 kinesis 服務(wù)具備動態(tài)擴縮容能力，但由于缺乏細節(jié)介紹不確定是否足夠通用以及是否能夠應(yīng)對比較復(fù)雜的場景）。阿里巴巴實時計算團隊早在一年前就啟動了類似的項目，在這方向上進行了嘗試和探索。面對內(nèi)部大量的業(yè)務(wù)場景和需求，加上目前各種前沿的研究，相信不遠的將來可以有所突破。
其他議題推薦
-
《Moving on from RocksDB to something FASTER》：這也是蘇黎世聯(lián)邦理工帶來的關(guān)于狀態(tài)存儲相關(guān)的研究，尋找比 RocksDB 更快的解決方案。在 Statebackend 上，阿里巴巴實時計算團隊也有所布局，我們正在探索一種完全基于 Java 的存儲引擎。
-
《Scotty: Efficient Window Aggregation with General Stream Slicing》：介紹了一種使用切片來提升窗口聚合性能的方法。
深度技術(shù)剖析
這個部分主要介紹的都是 Flink 在過去1-2個版本內(nèi)做的一些大的 feature 和重構(gòu)。由于本人就是 Flink 的開發(fā)者，對這些工作都比較熟悉，因此就沒有選擇去聽這些分享。借用 Stephan 在 Keynote 中的兩張圖，基本做了比較好的概括。
有同學(xué)對其中個別的技術(shù)點感興趣的話，基本都能夠找到對應(yīng)的議題，在這里我就不展開一一介紹了。
總結(jié)和感想
這幾年隨著阿里巴巴持續(xù)對 Flink 的大力投資，F(xiàn)link 的成熟度和活躍度均有了質(zhì)的飛躍。社區(qū)生態(tài)也越發(fā)的繁榮，包括 cloudera 和 AWS 都已經(jīng)開始積極的擁抱 Flink，也得到了不錯的成果。各大公司的議題也從早年的抱著嘗鮮的態(tài)度嘗試 Flink，轉(zhuǎn)變成了來分享使用 Flink 大規(guī)模上線后的一些成果和經(jīng)驗教訓(xùn)。在此基礎(chǔ)之上，逐漸了形成了基于 Flink 的平臺化實踐、結(jié)合機器學(xué)習(xí)進行具體業(yè)務(wù)的問題解決和一些比較新穎的探索研究型項目等方向，讓整個生態(tài)的發(fā)展更加的完整和壯實。不僅如此，F(xiàn)link 也在積極的探索一些新的熱門方向，比如和 K8S 的結(jié)合，和在線服務(wù)場景的結(jié)合等等，體現(xiàn)了這個生態(tài)的強大生命力。
不過歸根結(jié)底，F(xiàn)link 到底還是一個大數(shù)據(jù)計算引擎，其宗旨還是希望去解決大數(shù)據(jù)計算這個問題。在文章的一開頭，我也提到了在看到 Flink 進軍 Application 和 FaaS 的方向時，一個疑問一直在我的心頭縈繞：Flink 到底是怎么樣的一個計算引擎，它究竟是要解決什么樣的問題？如果沒有一個很清晰的主線和長遠認識，在引擎的發(fā)展過程中很容易就會走偏，最終導(dǎo)致失敗。
大部分人可能還停留在 Flink 是一個成熟的實時計算引擎的認知，但 Flink 從誕生的第一天起就想著要解決批處理的問題。即便現(xiàn)在 Flink 已經(jīng)逐漸填補了批處理這個坑，但又朝著 Application 這樣的在線服務(wù)場景發(fā)起了探索。乍一看，F(xiàn)link 好像什么問題都想解，什么方向都想插一腳，真的是這樣嗎？
帶著這樣的疑問參加完了整個大會，又額外思考了幾天，我開始有了一些新的認識和見解。想要回答 Flink 到底是怎么樣的一個計算引擎，它究竟想解決什么樣的問題這個疑問，我們得從數(shù)據(jù)本身開始看起。畢竟，一個計算引擎所要處理的對象，就是數(shù)據(jù)本身。
第一個問題是，我們需要處理的數(shù)據(jù)都是從哪里來的？對大部分公司和企業(yè)來說，數(shù)據(jù)可能來自各種手機APP，IoT設(shè)備，在線服務(wù)的日志，用戶的查詢等等。雖然數(shù)據(jù)的來源和種類各不相同，但有一個特點可能是大部分情況下都具備的：
數(shù)據(jù)總是實時的不斷產(chǎn)生。
我們可以使用流（Stream）或者日志（Log）這樣的概念來模擬抽象所需要處理的數(shù)據(jù)，這也是現(xiàn)在一種比較流行的抽象方式，Jay Kreps 大神早年就在不遺余力的推廣這樣的方式，感興趣的同學(xué)可以讀一下這篇博文：
《The Log: What every software engineer should know about real-time data's unifying abstraction》。
在這里先解答一下常見的幾個疑惑，因為這個看起來和大家平時接觸到的數(shù)據(jù)比較不一樣。常見的問題會有：
-
我平時的接觸的數(shù)據(jù)都存在Database里，看起來這個不一樣啊？Database 可以理解成為將這些 Stream 物化后的產(chǎn)物，一般是為了后續(xù)的頻繁訪問可以更快。而且大部分 Database 系統(tǒng)的實現(xiàn)里，其實也是用的 Log 來存儲所有的增刪改行為。
-
我平時接觸的數(shù)據(jù)都放在數(shù)倉里，按照天做了分區(qū)。這種情況可以再往數(shù)據(jù)的源頭想一下，數(shù)據(jù)剛產(chǎn)生的時候不會直接到你的數(shù)倉，一般也是需要經(jīng)過一個 ETL 過程。一般的數(shù)倉可以理解成將過去的一段段有限流，轉(zhuǎn)存成了更高效的格式。
當(dāng)我們使用這樣的方式來抽象數(shù)據(jù)之后，我們就可以考慮我們會在這樣的數(shù)據(jù)上做什么樣類型的計算了。先從有限流開始：
-
對過去的一部分數(shù)據(jù)做一下簡單的清洗和處理，這基本上就是大部分經(jīng)典的批處理 ETL 作業(yè)
-
對過去的一部分數(shù)據(jù)做一些稍微復(fù)雜點的關(guān)聯(lián)和分析，這算是比 ETL 稍微復(fù)雜點的批處理作業(yè)
-
對過去的一部分數(shù)據(jù)進行深度的挖掘從而產(chǎn)生更深的洞察，這是機器學(xué)習(xí)訓(xùn)練模型的場景
對于無限流來說，我們需要時刻消費最新產(chǎn)生的數(shù)據(jù)，那么可能產(chǎn)生的計算類型會有：
-
和批處理類似的 ETL 和分析型的數(shù)據(jù)處理場景，只不過計算發(fā)生在最新實時產(chǎn)生的數(shù)據(jù)上
-
對于最新產(chǎn)生的數(shù)據(jù)進行特征分析和挖掘，這是機器學(xué)習(xí)實時訓(xùn)練模型的場景
-
將最新產(chǎn)生的數(shù)據(jù)樣本化，然后套用機器學(xué)習(xí)模型進行判定，這是典型的實時預(yù)測場景
-
根據(jù)最新產(chǎn)生的數(shù)據(jù)，觸發(fā)一系列后臺業(yè)務(wù)邏輯，這就是典型的 Application 或者在線服務(wù)場景
特別值得注意的是，有限流的計算和無限流的計算并不是完全獨立存在的，有時候我們的計算需要在兩者之間進行切換，比如這些場景：
-
先將所有的歷史數(shù)據(jù)進行處理，然后開始實時消費最新產(chǎn)生的數(shù)據(jù)。比如說統(tǒng)計的場景，當(dāng)統(tǒng)計口徑變化之后，我們希望先把所有歷史數(shù)據(jù)重新統(tǒng)計一遍，然后再接上最新的數(shù)據(jù)進行實時統(tǒng)計。
-
我們先根據(jù)歷史數(shù)據(jù)進行樣本生成然后訓(xùn)練模型，然后再消費最新的數(shù)據(jù)，將其轉(zhuǎn)化為樣本后開始做實時的預(yù)測和判定。這也是機器學(xué)習(xí)中很典型的做法，關(guān)鍵點在于需要保證訓(xùn)練模型時的樣本邏輯和實時判定時的樣本邏輯需要保持一致。
另外，我們也可以嘗試從計算的延遲的角度對這些繁多的計算模式進行大致的分類：
列舉了這么多例子和場景之后，大家應(yīng)該也差不多能領(lǐng)悟到其中的道理了。當(dāng)我們基于 Stream 來抽象所有的數(shù)據(jù)之后，在數(shù)據(jù)之上引發(fā)的計算模式是相當(dāng)?shù)亩鄻踊?。正?Stephan 一開始在 keynote 中提到的，傳統(tǒng)的 Data Processing 和消息驅(qū)動的 Application 場景，都不足以覆蓋所有的計算模型。所有計算模型的本質(zhì)是 Stream Processing，只不過有時候我們需要去處理有限的數(shù)據(jù)，有時候我們又需要去處理最新的實時數(shù)據(jù)。Flink 的愿景就是成為一個通用的 Stream Processing 引擎，并覆蓋基于這個范式的所有可能的比較具體的計算場景。這樣一來當(dāng)用戶有不同的計算需求時，不需要選擇多個不同的系統(tǒng)（比如經(jīng)典的 lambda 架構(gòu)，我們需要選擇一個專門的批處理引擎和專門的流計算引擎）。同時當(dāng)我們需要在不同的計算模式間進行切換的時候（比如先處理歷史數(shù)據(jù)再接上實時數(shù)據(jù)），使用相同的計算引擎也有利于我們保證行為的統(tǒng)一。
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
