簡介：本文將對FFA Keynote議題作一些簡單的歸納總結，感興趣的小夥伴們可以在FFA官網[2]找到相關主題視頻觀看直播回放。
作者 | 梅源（Yuan Mei）
來源 | 阿里技術公衆號
律回春暉漸，萬象始更新，這句詩用來形容2021年的大數據領域再合適不過，而Flink在2021年也開啓了新的篇章。
2022年1月8-9號，Flink Forward Asia（FFA）線上峯會成功舉行。Flink Forward Asia 是由 Apache 官方授權，Apache Flink中文社區主持舉辦的會議。目前，Flink Forward Asia 已成爲國內最大的 Apache 頂級項目會議之一，是 Flink 開發者和使用者的年度盛會。在線上峯會的同時，FFA還舉辦了首屆以實時計算爲主題的Flink Hackathon，共有267支參賽隊伍，最終27支隊伍入圍參與線下決賽。未來Flink Hackathon也會常態化舉辦，集思廣益。
本文將對FFA Keynote議題作一些簡單的歸納總結，感興趣的小夥伴們可以在FFA官網[2]找到相關主題視頻觀看直播回放。
一 主會場議題
下面來重點聊一聊幾個主議題。
1 Flink Next –– Beyond Stream Processing
主議題照例由Apache Flink中文社區發起人，阿里巴巴開源大數據平臺負責人王峯（花名莫問）老師開啓，主要介紹 Flink 社區在 2021 年取得的成果以及未來的發展方向，包括雲原生，Flink容錯，流批一體和機器學習四個部分。
雲原生 –– 部署架構演進
說起開源大數據的發展，繞不開雲原生，兩者相依相生相輔相成。作爲開源大數據的引擎課代表Flink的部署模式是如何在雲原生大背景下演進的是個很有趣的話題。Flink最早的部署模式是經典的靜態（Static）Standalone模式，這裏的靜態是指用戶必須根據業務估算預留資源，資源少了作業就跑不起來，所以大部分情況下需要按最大資源量來預留。顯而易見這種模式對於用戶來說既複雜資源利用率也不高。第二種模式我們稱爲主動（Active）模式，這裏的主動是指Flink會根據業務資源的使用情況主動的去向底層Kubernetes或者Yarn申請和釋放資源。這種模式需要Flink和底層Kubernetes或者Yarn深度集成，適用於需要對資源深度把控的用戶，對中小用戶來講太過複雜。這就引出了第三種模式我們稱爲適應性（Adaptive/Reactive）模式。在這種模式下，Flink可以像雲上其他應用一樣根據所給的資源（增加或減少資源pod），通過改變自身拓撲結構來動態調整運行。從用戶的角度來看，他並不需要了解資源是如何分配的，所以第三種模式對於用戶的門檻相對較低。
還有一個值得思考的問題是雲原生到底給Flink帶來了什麼，除了彈性資源管理，數據多備份，自適應運維管理，標準化的工具和操作，筆者覺得更重要的是降低用戶的使用門檻，用更小的成本給用戶提供更簡單，穩定和豐富的使用體驗。
Flink容錯 –– 穩定快速的Checkpoint
Buffer Debloating是在不影響吞吐和延遲的前提下縮減上下游需要緩存的數據到剛好算子不空轉，目前Buffer Debloating默認上游會動態緩存下游1秒鐘能處理的數據（這個時間是可以配置的）。Buffer Debloating在Flink-1.14版本已經發布。Generalized Log-Based Checkpoint是一種基於log打點的方式來做Checkpoint的方法，類似傳統DB的write ahead log，好處是能快速，高頻且穩定的做Checkpoint，代價是需要額外多寫/存一份log。我們知道Flink做Checkpoint由同步和異步兩個過程組成，同步的過程通常很快，主要的耗時在異步上傳狀態文件這個過程中。Generalized Log-Based Checkpoint的原理就是將Checkpointing這個過程和耗時的異步上傳文件這個過程剝離開，也同時和底層狀態存儲的物化過程解耦。Generalized Log-Based Checkpoint預計會在Flink-1.15版本發佈。
分論壇核心技術專場talk“Flink新一代流計算和容錯（Flink Fault Tolerance 2.0）”對這個部分有更爲詳細的闡述，感興趣的同學可以找來看看。
流批一體 –– 架構演進和落地
流批一體是近些年Flink一直在力推的創新性理念，從最早提出這個理念到當前被廣泛接受，莫問老師分享了流批一體在Flink的系統架構各個層面演進的過程及其落地場景，如下圖所示。
API層面，去年流批統一的SQL/Table API（Declarative API）首次在阿里巴巴雙十一最核心的天貓營銷活動分析大屏場景中落地[3]，今年更近一步，完成了Imperative API的整合，形成流批統一的DataStream API，而陳舊的DataSet API將逐步被淘汰。架構層面，同一個作業可以同時處理有限數據集和無限數據集；並且connector框架可以同時對接流式存儲和批式存儲，做到一套代碼可以處理兩套數據源。運行層面，一套調度框架可以同時適用於流和批的作業；流批shuffle是pluggable的，複用一套shuffle接口。阿里巴巴實時計算團隊在今年開源了存算分離的Remote Shuffle Service[4]，放在Flink開源項目的Flink-extended這個子項目組裏面。Flink-extended[5]裏面包含很多其他Flink生態項目，有興趣的同學可以去看一看。
繼去年在天貓雙十一核心大屏業務上線後，流批一體今年逐步在阿里巴巴更多核心業務上推廣。除了阿里巴巴，有越來越多的公司認可流批一體這個理念。今年FFA有個專門的流批一體分論壇，由字節跳動，美團，京東以及小米等公司分享流批一體在其業務中的實踐。此外在覈心技術專場中有專門針對流批一體架構演進的專場talk“面向流批一體的 Flink Runtime 新進展”，對這個話題感興趣的同學可以瞭解一下。對新版connector框架原理感興趣的同學可以參考核心技術專場中的“Flink Connector社區新動向與Hybrid Source原理實踐”。
2）場景落地
莫問老師指出，流批一體這一技術理念落地需要具體的場景支撐來體現其真正價值，基於此，他分享了流批一體最爲典型的兩個應用場景。
場景1 Flink CDC：全增量一體化數據集成
Flink CDC目前已可以支持大部分主流數據庫包括MySQL、Postgres、Oracle、MongoDB、MariaDB，其他的如TiDB，DB2，SQL Server也在積極開發中。對Flink CDC如何能夠實現一站式數據集成感興趣的同學可以參考分論壇實時數據湖專場中的talk“Flink CDC 如何簡化實時數據入湖入倉”。
場景2 Streaming Warehouse：流式數倉
前面提到，今年的一大亮點是莫問老師提出的流式數倉（Streaming Warehouse）這個概念，這個概念提出的大背景是爲了解決實時離線數倉一體化的問題。
實時離線數倉一體化這個問題目前比較常用的解決方案是用實時和離線兩條鏈路來實現：1）實時流處理鏈路（Flink + Kafka）對數據進行分層ODS，DWD，DWS，並實時寫入在線服務層，提供在線服務（實時OLAP）；2）同時會有一條離線鏈路定期對實時數據進行補充和歷史修正。這裏除了常見的流批不統一帶來的開發效率，維護成本，流批口徑不統一等問題以外，其實還有一個更隱蔽同時也更難解決的問題：爲了保證實時性，實時鏈路中的ODS，DWD，DWS這些分層數據是存在消息隊列（比如Kafka）中的，但是消息隊列中的數據是沒辦法有效進行實時分析的，如果引入其他的OLAP系統會增加系統複雜度同時也不能保證數據一致性。
Dynamic Table（動態表）不同於一般意義上的Source和Sink，是Flink的內置表。之所以稱爲動態表是因爲此表具有流表二象性。流表二象性通過列存LSM Tree和Log兩種不同的存儲形式來支持，分別對應於Flink SQL的批（全量分析）和流（增量處理）兩種模式。Dynamic Table通過Flink自身的Checkpointing一致性語義機制保證流表二象性在兩種存儲形式下的一致性語義。這裏需要特別注意的是，流表二象存儲的數據一致性問題是混拼系統（引入其他OLAP和消息隊列）無法輕易規避和解決的問題（因爲中間涉及多系統間的一致性讀寫同步），這也是Flink Dynamic Table區別於其他類似系統的核心競爭力之一。如果大家對動態表的實現感興趣的話可以看一看流批一體分論壇中“基於Flink Dynamic Table構建流批一體數倉”這個talk，裏面有對Dynamic Table更詳細的介紹。
這個部分的最後有一個流式數倉的demo，用上述一體化的方法論展示了流作業在實時OLAP分析發現業務邏輯有錯後，如何批式做訂正並實時支持OLAP查詢更正的一個流批實時分析一體化的典型場景，還是很受啓發的，大家可以看一看。想對流式數倉有更詳細瞭解的同學可以參考莫問老師關於流式數倉的專訪[6]。
機器學習 –– Apache Flink ML 2.0 全新架構
Flink ML 2.0目前已經由阿里巴巴實時計算團隊和機器學習團隊共同完成，貢獻給Flink社區，成爲Flink的一個子項目Flink-ML[7]。值得一提的是除了阿里巴巴，現在還有很多其他公司也在共同建設Flink ML的生態，比如360貢獻了Clink[8]。核心技術專場中“爲實時機器學習設計的算法接口與迭代引擎”這個talk詳細介紹了Flink ML 2.0的架構演進，此外今年FFA還有一個機器學習專場，感興趣的同學可以看一看。
PyFlink方面，Flink對AI的主流開發語言Python的支持更加完備：PyFlink在功能上完全追平了Table API 和Data Stream API的能力，在性能上創新性的通過JNI調用C，再在C裏面調用Python解析器的方法消除了Python UDF和Java跨進程通信，使得Python UDF性能接近Java UDF，兼顧開發和運行的效率。分論壇核心技術專場“基於 FFI 的 PyFlink 下一代 Python 運行時介紹”有對這部分更詳細的解釋。
二 實時計算在字節跳動的發展與展望
主議題第二場由字節跳動計算基礎架構負責人師銳老師帶來。字節跳動的產品業務場景主要都是以實時信息流推薦爲主，因此以Flink爲支撐的實時計算廣泛應用在字節跳動的各個產品中。字節跳動旗下全線產品總MAU目前已超過19億，由於其業務特性，其數據量（EB級別，1EB = 2^60 Bytes）和實時推薦的請求量（百萬QPS）都是巨大的。我們可以看到在師銳老師分享的字節跳動引擎資源使用的對比圖中，Flink和Spark基本持平，這在一般的公司是不太常見的，從這個方面也可以看出字節跳動整個業務線對以Flink爲基礎的流計算的依賴。
字節跳動從2017年開始調研並逐步使用Flink流式計算，到2019年初，所有流式作業已完成從JStorm到Flink的遷移。2019年開始，隨着Flink SQL和Flink批式計算的成熟，Flink Batch也在字節跳動數據同步等場景相繼落地，現在每天大約有10w+ Flink Batch作業運行。師銳老師特別提到，從去年開始，流批一體也逐步在字節跳動公司內部推廣應用，感興趣的小夥伴可以參考流批一體分論壇專場中的talk“流批一體在字節跳動特徵平臺的實踐”。目前字節跳動全球Flink流式作業達到4w個，其中SQL作業佔30%，使用的CPU核數超過400萬核，晚高峯Flink作業處理消息的QPS達到90億，Checkpoint高峯流量吞吐達到600GB/s，還是很驚人的！
在字節跳動的分享中，基於存算分離架構的流批一體消息隊列BMQ值得提一提（BMQ目前承接了字節90%的消息隊列流量）。在BMQ之前，字節使用Kafka作爲消息隊列，集羣升級擴縮容需要大量拷貝數據，所以完成一個集羣的升級差不多需要一週的時間。爲了解決這個問題，字節團隊基於存算分離的架構重新設計實現了消息隊列，BMQ。在BMQ的架構之下，數據存放在分佈式文件系統HDFS中，Meta存放在K-V存儲中。由於BMQ的計算層Proxy無狀態所以非常容易做擴縮容，遷移時間可在分鐘級完成。另一方面，BMQ可以同時提供Stream API和Batch API，所以可以同時支持流和批的消費，實現存儲層的流批一體。有些小夥伴可能有疑問，這和上面提到的動態表（Dynamic Table）一樣嗎？筆者覺得還是很不一樣的，因爲要解決的問題不一樣：動態表要解決流批實時分析一體化的問題，所以它的流批存儲格式是完全不一樣的（爲了分別加速流處理和批查詢）；而BMQ所有數據只寫一份在HDFS上，主要還是爲支持高效的大規模消息傳輸和讀寫服務的。
師銳老師提到他們下一步計劃是推進Flink OLAP的落地。他指出，Flink擁有豐富的connector生態可以實現跨數據源查詢，Flink OLAP能力在字節內部測試過可以媲美Presto，甚至在有些情況下更優，現在有關Flink OLAP的改進和優化也在積極推進Flink社區中。本次FFA字節跳動有7個分會場talk，從核心技術提升到行業實踐涵蓋了方方面面，對Flink在字節跳動內部如何演進使用感興趣的同學可以去看看。
三 工商銀行實時大數據平臺建設歷程及展望
主議題第三場由中國工商銀行大數據平臺負責人袁一老師帶來，他從金融行業的視角分享了有關工行實時大數據平臺建設的歷程和思路。
聰明的小夥伴們可能已經發現了，上面這條複雜數據鏈路和Flink流式數倉（Streaming Warehouse）場景幾乎一摸一樣。但是通過Flink的流式數倉，我們可以把工行的這條中間貫穿很多系統和組件的鏈路簡化成Flink單鏈路，通過Flink的動態表（Dynamic Table）提供的流批實時分析一體化的能力來完成實時入湖，實時數據服務和實時分析！
另一個比較有趣的點是金融行業的數據中臺在設計的時候會特別考慮數據私密和安全的問題。他們採用的方法有以下幾種：1）採用全生命週期的數據監控審計，用於數據訪問的審計和追溯；2）在數據發生移動的時候給數據本身加水印可以方便溯源；3）通過SQL實現自然人級別的動態數據訪問權限控制；4）通過專家規則和Machine Learning來自動識別海量數據中的敏感數據。這些思想和方法在數據安全，數據私密越來越受重視的今天很有借鑑意義。袁一老師還詳細分享了很多和金融行業相關的業務場景，相信會對業務場景感興趣的同學有所啓發。
四 Deconstructing Stream Storage
主議題的最後一場由Pravega中國社區創始人，戴爾科技集團OSA軟件開發總監滕昱老師壓軸：解構流存儲。
Pravega是提供流批統一能力的開源分佈式流存儲，有如下特點：1）相同鍵值下可以保證數據有序；2）可以根據數據流量動態擴縮存儲單元；3）支持事務性寫入；4）支持Checkpointing和一致性讀寫；5）分層存儲設計。所有的這些特性都封裝在Stream抽象的設計理念之下，也給流式計算屏蔽了很多流存儲端的複雜性。在這次分享中，滕昱老師着重介紹了Pravega的分層存儲架構（Tiered Storage）：其底層是一個基於分佈式文件/對象存儲的持久性主存儲，中間是基於內存的全局Cache層，最上層是分佈式Log抽象層。滕昱老師還同時分享了Pravega的分層存儲架構與Kafka和Pulsar這兩個消息系統在架構上的區別以及對性能的影響，感興趣的同學可以去詳細瞭解一下。
一是Pravega針對現在比較火熱的物聯網邊緣計算的定製優化。比如Pravega針對多客戶端的兩階段數據聚合，在Writer進行第一階段聚合，在Segment Store進行第二階段聚合，極大的提高了吞吐量。這種數據聚合優化非常適用於有大量客戶端但每個客戶端產生的數據量比較小的情況，而這就是物聯網的典型特點。
二是Pravega和Flink聯動的端到端的auto-scaling。彈性擴縮容是雲原生大背景下非常重要的問題，前面提到Pravega的一大特點就是可以自動擴縮容，調整Segment數目，而這個數目可以很好的作爲Flink Reactive Scaling的指標，兩者相結合後可以做到從計算到存儲端到端的auto-scaling，目前這項工作已在兩邊社區合作規劃中。滕昱老師的分享中還有一個Demo展示了Pravega和Flink聯動scaling的效果。
滕昱老師表示未來存儲和計算，流和表的界限逐漸模糊，Pravega流批一體的存儲設計也暗合了Flink未來很重要的一個發展方向。Pravega社區會積極與包括Flink在內的數據湖倉相關的開源社區通力合作，構建解決方案。今年Pravega和Flink社區共同發佈了白皮書，未來也期望和Flink社區有更多合作，將Flink計算推向數據的產生端，通過Pravega能實現數據從端到雲的流動。
五 圓桌會議
今年FFA主會場新增加了一個環節圓桌會議（分北京和上海兩場），邀請了業界來自阿里巴巴，字節跳動，美團，快手，小米，工商銀行，戴爾科技集團和小紅書在內的多位大數據專家負責人，共同探討Flink以及實時計算的未來。各位大佬友好真誠並且很接地氣討論了很多大家都比較關心的問題，由於篇幅關係，這裏僅列出了討論的部分相關話題，大家可以找視頻感受一下：
- 如何看待Flink在實時計算方面已趨於成熟這個話題，目前大家都用實時計算做什麼？
- 實時計算的未來是怎樣的（技術和業務層面）？基於此，Flink需要探索哪些新的領域，解決哪些關鍵問題？
- 有人認爲實時計算的門檻和代價比較高，相對偏小衆；也有很多人認爲實時計算是未來的方向，大數據和 AI 都會向實時化方向演進；大家怎麼看這個問題？
- Flink在整個開源大數據生態中應該如何定位，如何保持差異化？
- 如何看待公司內部技術實踐，技術創新與開源社區之間的關係，大家使用和回饋社區的策略又是什麼？
- 使用和貢獻開源項目有哪些優勢？公司內部在做Flink哪方面的探索？過程中又遇到過哪些挑戰？
- Flink在內部使用的未來規劃，以及接下來有哪些打算貢獻社區的創新技術？
- 如何看待 Flink 與生態項目之間的（合作、競爭）關係？
- 什麼樣的開源社區是對大家有幫助的開源社區？同時又是一個可持續發展的社區？
六 總結和感想
過去的2021年是大數據領域的風口年，對於Apache Flink，實時計算的領跑者，能否抓住這個風口也是很關鍵的一年。在Flink SQL趨於成熟，流批一體在業內逐步被接受落地的當口，我們需要思考未來Flink何去何從，這也是我們正在做的事情。在此基礎上，Flink推出了流批一體的進階版，流式數倉（Streaming Warehouse）這個概念，希望能實現流批實時分析一體化，真正意義上完成流批一體計算和流批一體存儲的融合，做到在一套方法論的大框架下實現一套API，一套計算，一套中間存儲的全鏈路一體化。流式數倉將是Flink未來最重要的方向，道阻且長，行則將至，行而不輟，未來可期！
[1] Flink官方學習網站Flink Learning（
[2]
[3]40億條/秒！Flink流批一體在阿里雙11首次落地的背後
[4]Remote Shuffle Service（
[5]Flink-extended（
[6] Apache Flink不止於計算，數倉架構或興起新一輪變革（
[7]Flink-ML（
[8]Clink（
本文爲阿里雲原創內容，未經允許不得轉載。