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