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

時間 2020-01-08

標籤 flink forward asia 總結展望 ppt 下載連接欄目 Microsoft Office 简体版

原文原文鏈接

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

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

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

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

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

接下來，筆者將根據本身參加的議題聊一聊參會的體驗和一些本身的思考，但願能對感興趣的同窗有所助益。框架

主會場議題

在主議題以前有兩個環節值得提一提。一是做爲主場的阿里雲智能請出阿里集團 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 照做爲全篇的收尾，你們一塊兒感覺一下。