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 在 Flink Forward Asia 的 cool 照作為全篇的收尾，大家一起感受一下。
原文釋出時間：2019-12-5
作者 ：梅源（Yuan Mei）
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。