Flink Forward Asia 2019 - 總結和展望（附PPT下載連結）

吐泡泡ooO發表於2019-12-09

11 月 28 - 30 日，北京迎來了入冬以來的第一場雪，2019 Flink Forward Asia（FFA）也在初雪的召喚下順利拉開帷幕。儘管天氣寒冷，FFA 實際到會人次超過 2000，同比去年增加近 100%。

Flink Forward 是由 Apache 官方授權舉辦的會議，每年在歐洲、北美洲、亞洲各舉辦一場。通過參會不僅可以瞭解到 Flink 社群的最新動態和發展計劃，還可以瞭解到業界圍繞 Flink 生態的生產實踐經驗，是 Flink 開發者和使用者的盛會。去年 12 月 Flink Forward 首次在中國舉辦，是規模最大、參與人數最多的 Flink Forward 大會。今年 Flink Forward China 正式升級為 Flink Forward Asia，吸引到更多的關注，並於 11 月 28 日在北京開幕。

除了參會人數的迅速增加，多元化也是今年 FFA 的一大閃光點。筆者根據大會綱要數了一下，大約有超過 25 家來自北美，歐洲和亞洲的公司，高校以及科研機構參與分享了超過 45 個議題。國內外一線大牌網際網路公司齊聚一堂，其樂融融。這也說明越來越多的業界公司更加看好 Flink，並且深度參與 Flink 的規劃與發展，這無論是對 Flink 的未來還是 Flink 社群的發展都有非常積極的意義。

經過幾年的發展，Flink 已經成為 Apache 最活躍的社群和在 Github 上訪問量前三的專案。Github 的星數（代表專案受歡迎程度）在 2019 一年之內翻了一番。Apache Flink 在中國本土也更加的普及，下圖列出了一些使用 Flink 作為實時計算解決方案的中國公司 logo。

筆者總體的參會感受： 引擎一體化和生態多元化是 Flink 一以貫之的發展策略。引擎一體化指的是 離線（batch），實時（streaming）和線上（application）應用在執行層面的一體化。生態多元化指的是對 AI 生態環境的搭建和對更多生態的支援，包括 Hive，Python，Kubernetes 等。

接下來，筆者將根據自己參加的議題聊一聊參會的體驗和一些自己的思考，希望能對感興趣的同學有所助益。

主會場議題

在主議題之前有兩個環節值得提一提。一是作為主場的阿里雲智慧請出阿里集團 CTO 兼阿里雲智慧總裁張建鋒作為開場嘉賓進一步強化阿里集團以資料智慧為驅動，All in Cloud 的決心以及開源的 Flink 在此過程中起到的關鍵性作用。下圖很好地提煉了他的演講。

二是由阿里雲天池平臺和 Intel 聯合舉辦的 Apache Flink 極客挑戰賽頒獎儀式。本次比賽吸引了全球超過 4000 名參賽者，經過四個月的四輪角逐最終產生共 10 個優勝隊伍。值得一提的是獲獎選手中有兩位女將，未來也期待能有更多的妹子參與進來，放一張照片瞻仰一下。

下面言歸正傳，聊一聊幾個主議題。

Stateful Function

照例，第一個主議題由 Flink 一哥 Stephan Ewen 執棒。作為對 Flink Forward 柏林站的延續，Stephan 繼續推廣他對 Flink 作為應用服務場景（Applications and Services）通用引擎的展望和規劃。簡而言之，他認為 Flink 除了能夠做到批流一體，Flink 框架對於事件驅動的線上應用也可以有效甚至更好的支援，如下圖所示：

我的理解是他所指的應用服務場景（Applications and Services）和傳統意義上的 OLTP 類似。雲上對此類問題的主流解決方案是現在很火的 FaaS (Function as a Service)，但通常會有以下四方面痛點：

Bottlenecked by state access & I/O
State Consistency Problem
Scalability of Database (storing the states)
Connections and Request rates

特別是在應用邏輯非常複雜的情況下，應用邏輯之間的組合呼叫會更加複雜，並且加劇上面四個痛點的複雜度。

同時你會發現上面的這些問題都和 State 的儲存（storage），讀寫（access）以及一致性（consistency）相關，而 Flink 的 Stream Processing 框架可以很好的解決這些和狀態相關的問題。所以 Stateful Function 在 Flink 現有的框架上擴充了對 Function Composition 和 Virtual Instance（輕量級的 Function 資源管理）的支援，以達到對應用服務場景（Application）的通用支援。

目前所有 Stateful Function 程式碼均已開源，在獲得社群認可後也會 merge 回 Apache Flink，有興趣的同學可以去官網自己實踐一下： https://statefun.io/ 。在分議題 Apache Flink 核心技術中也有一場專門講 Stateful Function 的實現，使用和 demo，小夥伴們也可以去感受一下，題目叫“Stateful Functions: Unlocking the next wave of applications with Stream Processing”。

看到這裡可能還是會覺得不太直觀，我結合自己的理解再多說兩句，我們可以從兩個維度理解 Stateful Function：

Stateful Function 到底要解決什麼問題
為什麼 Stateful Function 比現有的解決方案更好

設想如下的場景，我們使用 Lyft 打共享車。在乘客發起叫車請求以後，Lyft 首先會根據乘客的定位，空閒司機的狀態，目的地，交通狀況和個人喜好給乘客推薦不同型別車輛的定價。在乘客選擇定價以後，Lyft 會根據乘客的喜好（比如有些司機被乘客拉了黑名單），司機的喜好（乘客也有可能被司機拉了黑名單），司機和乘客的相對位置以及交通狀況進行匹配，匹配完成後訂單開始。在這個例子中，我們會發現：

有很多 Function Composition：乘客的喜好的計算，司機的喜好計算，司機和乘客相對位置計算，交通狀況計算，以及最終匹配計算。
狀態的一致性的重要：在匹配的過程中如果發生錯誤，在保持狀態一致性的情況下回滾非常重要。我們不希望一個乘客匹配給兩個司機，也不希望一個司機匹配給兩個乘客，更不希望乘客或者司機因為一致性問題無法得到匹配。

Stateful Function 在 Flink 開源 Runtime 的基礎上很好的解決了 Function Composition 和 State Consistency 的問題。

下面討論一下第二個維度：為什麼 Stateful Function 比現有的解決方案更好。我的理解是 Stateful Function 提供了更清晰的 abstraction。Stateful Function 把訊息傳輸、狀態管理從 Function 中隔離出來，使得使用者只需要關注 Function 計算邏輯本身，而不需要關注 Function 的排程，組合等問題，這也使得 Stateful Function 框架能有更多的自由度為 Function 排程組合等問題做優化。當然這只是我個人的理解，拋磚引玉。

Flink Heading Towards a Unified Engine

第二場由阿里巴巴實時計算負責人王峰（阿里花名：莫問）接棒，主要總結了 2019 年 Apache Flink 在一體化引擎發展方面的成果和未來的方向。他認為未來 Flink 的發展趨勢是一體化：包括 離線（batch），實時（streaming）和線上（application）一體化。在此基礎上，也需要把擁抱 AI 和雲原生納入到一體化中。後面的內容就是圍繞這三方面來展開的。

對於批流融合，通過 1.9 和 1.10 兩個版本的釋出，Flink 在 SQL 和 Table API 的層面以及 Flink runtime 層面對批流模式已經做到統一。對於 Flink SQL，在 1.10 這個版本里面，已經可以實現完整的 DDL 功能，相容 Hive 生態系統並且支援 Python UDF。

總體得到的訊息是：

Flink SQL 在批模式下經過多方驗證已經達到 生產可用的狀態。
Flink SQL 可以在 Hive 生態上直接執行，沒有遷移成本。
Flink SQL 可以做到批流在 SQL 優化，運算元層以及分散式執行層的一體化。

另外這部分印象比較深刻的一點是：跑 TPC-DS benchmark，Flink 1.10 比 Hive-3.0 快 7 倍：

在 AI 部分，2019 Flink 重點主要在優化和鋪墊 AI 的基礎設施部分：

Flink 1.9 釋出一套標準化的 Machine Learning Pipeline API (這個 pipeline 的概念最早在 Scikit-learn 中提出，在其他生態中也有廣泛的採納)。AI 的開發人員可以使用這套 API（Transformer，Estimator，Model）來實現機器學習演算法。
更好的支援 Python 生態。Flink 1.10 在 Table API 中可以支援 Python UDF，複用了 Beam 的 Python 框架來進行 Java 和 Python 程式之間的通訊。
Alink 開源釋出。Alink 是基於 Flink 的機器學習演算法庫， 最大的亮點是對流式和線上學習的支援。以下為開源地址，感興趣的同學可以研究一下。

https://github.com/alibaba/alink

在 AI 部分還有一個很值得期待的專案是 Flink AI 明年的一個重點投入方向：AI Flow。AI Flow 為 AI 鏈路定製了一套完整的解決方案：包括從 data acquisition，preprocessing，到 model training & validation & serving 以及 inference 的一整套鏈路。這個方案是針對解決現在 AI 鏈路裡面資料預處理複雜，離線訓練和線上預測脫鉤等問題定製的，讓我們拭目以待。

此外還有一個重要的方向是 Flink 對雲原生生態的支援，具體來說就是與 Kubernetes 生態的深度融合。Kubernetes 環境可以在 multi-user 的場景下提供更好的隔離，對 Flink 在生產的穩定性方面會有所提升。Kubernetes 廣泛應用在各種線上業務上，Flink 與 Kubernetes 的深度融合可以在更大範圍內統一管理運維資源。Kubernetes 生態本身發展很快，可以給 Flink 在生產中提供更好的運維能力。後面 Lyft 和其他企業在分享中也提到希望 Flink 對 Kubernetes 可以原生地支援，也有以上這些方面的考慮。Flink 在 1.10 版本釋出後可以原生地執行在 Kubernetes 之上。

阿里巴巴通過 1.9 和 1.10 兩個版本歷經 1 年左右將 Blink 中比較通用的部分悉數回饋給 Apache Flink 社群，回饋總程式碼數超過一百萬行。阿里內部的 Blink 核心也逐步會由 Flink 核心替換，並且推出基於 Flink 核心的企業版 Ververica Platform，明年 1 月會正式商用。

另外這部分演講中的兩個 demo 讓我眼前一亮。一個是基於 Flink + Hive + Zeppelin 的 Flink SQL demo，看完以後可以深刻感受到“可以在 Hive 生態上直接執行，沒有遷移成本“，以及“一套 SQL，批流一體執行”的真正含義。還有一個是 Alink ML 基於 Jupyter 的 demo，看完以後我發現現在機器學習模型訓練和使用可以如此簡單，感興趣的同學可以找來看看。

Storage Reimagined for a Streaming World

第三個議題是由戴爾科技集團帶來的流式儲存議題: Pravega。

他們的主要觀點是隨著流式計算在大企業使用者中越來越廣泛的應用，流式計算對儲存也產生了新的需求：流式儲存。需求來自兩個方面：一是大型企業使用者希望計算框架流程化繁為簡，從而提出對流式計算儲存一體化的需求；二是批流的計算一體化本身也對儲存提出批流一體化需求。

在後面的分會場議題開源大資料生態中，Pravega 還有一場更偏技術的分享，包括整體的設計架構，如何保證 exactly once 語義，Stream Segment 如何更方便的提供 scaling up/down 等等，感興趣的同學也可以看看，題目叫“Delivering stream data reliably with Pravega”。

這個議題本身也很有趣。不可避免的，我們會想到流式儲存和通常意義上的訊息佇列系統（例如 Kafka）之間有什麼區別，畢竟 infinite retention 的訊息佇列系統也可以被看成是一個 stream storage。另一個比較有趣的問題是一體化的抽象應該在哪個層面上來做，以及如何做。換言之，讀寫是否應該和儲存分離，只提供統一的API？因為筆者對 storage 這塊兒細節不是特別瞭解，這裡就不班門弄斧了，感興趣的小夥伴我們可以私下討論。分議題中還有一場關於 Pulsar 的，也相關，題目叫“基於 Pulsar 和 Flink 進行批流一體的彈性資料處理”。

基於 Apache Flink 的大規模準實時資料分析平臺

主議題的最後一場是 Flink 實踐，是由 Lyft 帶來的大規模準實時資料分析平臺的分享。這裡所說的準實時，指端到端資料延遲不超過 5 分鐘，在 Lyft 內部主要用於資料互動式查詢，下圖是 Lyft 準實時平臺架構圖。

Flink 在整個架構中是用來做流資料注入的，Flink 向 AWS S3 以 Parquet 的格式持久化資料，並以這些原始資料為基礎，進行多級 non-blocking 的 ETL 加工（壓縮去重），建立實時數倉，用於互動式資料查詢。

在這個分享中印象深刻的幾點：

Flink 的高效性。據 Lyft 的大佬們講，這個新的平臺相較於先前基於 Kinesis Client 的 ingestion 相比較，僅資料注入部分的叢集就縮減了 10%，所以他們對 Flink 的高效性是非常認可的。
Lyft 也提到，他們花了蠻多精力基於 Flink 的 StreamingFileSink 來解決 Flink 和 ETL 之間 watermark 的同步問題。其實我很希望他們能分享一下為何壓縮去重（ETL）部分不也用 Flink 來做。如果是技術上的問題可以幫助 Flink 更好的完善自己。
Lyft 提到 Flink 的重啟和部署會對 SLO 造成延遲影響，subtask 停滯會造成整個 pipeline 的停滯以及期望 Flink 能夠有一套在 Kubernetes 環境下執行的方案。其實這裡提到的幾點也在其他的幾場企業實踐分享中被提到，這些也是當前 Flink 亟待解決的幾大痛點。社群對這幾點都有規劃，分議題中有一場“Pluggable Shuffle Service and Unaligned Checkpoints”有針對 Flink 重啟和停滯的討論；“Optimize Apache Flink on Kubernetes with YuniKorn Scheduler”討論了一些和 Kubernetes 應用相關的問題。

除了 Lyft，在分會場中也有很多企業參與分享了自己使用和深度參與 Flink 開發的經驗和教訓。Flink 不僅在國內公司中深受歡迎，很多北美歐洲的公司比如 Netflix，Uber 和 Yelp 也越來越多的使用和開發 Flink，感興趣的同學可以關注一下分會場議題中的“企業實踐”和“實時數倉”專場。

分會場議題

分會場議題主要圍繞著上面四個主議題展開，分為五個專場：

Apache Flink 核心技術：主要針對 Flink 1.9 和 1.10 中比較核心的技術更新
人工智慧：除了主議題已經包括的，Flink+TensorFlow 的實踐分享也很有趣
企業實踐：位元組跳動，快手，滴滴，網易，愛奇藝，Bilibili，360 等分享的實踐經驗
實時數倉：Netflix，美團，小米等分享的基於 Flink 的數倉平臺
開源大資料生態：和 Flink 生態相關的內容，主要包括 Zeppelin，Kubernetes，Hive 等等

由於篇幅關係，這裡就不作展開了，貼個清單連結，方便大家查閱，所有PPT資料也會連結在文末。

總結和感想

三天的 FFA，感觸頗深。Flink 創始人之一 Ververica CEO Kostas Tzoumas 感慨說，五年前當他們 5 個初創剛剛開始 Flink 這個專案的時候無法想象今天 Flink 能有如此大的生態和如此廣的應用。雖然我無法深切體會到他的感受，但是當前 Flink 社群的繁榮和 Flink 的應用廣度是有目共睹的，但更重要的問題是：未來我們如何延續這種繁榮。Flink 在經歷了高效能流式引擎，批流一體兩代發展後，我們確實需要思考一下未來的 Flink 是什麼樣的。

在這屆 FFA 中一直強調一體化和多元化的概念，也就是開篇講的 引擎一體化和生態多元化，具象化來說有三點：Stateful Function，擁抱AI，雲原生。再到下一個層面也給 Flink 引擎本身提出更多的要求，這是挑戰當然也是機遇。古語云瑞雪兆豐年， FFA 在北京的初雪中圓滿落下帷幕，也讓我們共同努力，把握好機遇一起迎接挑戰，共創美好的 Flink 2020。最後，分享一張一哥 Stephan 在 FFA 的 cool 照作為全篇的收尾，大家一起感受一下。