律回春暉漸，永珍始更新，這句詩用來形容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大會從社群發展，業界影響力以及生態技術演進這三方面總結了Flink在過去一年的發展。社群方面，根據Apache軟體基金會2021財年報告公佈的各項核心指標，Flink已連續三年位列Apache社群最活躍的專案之一。而作為社群的最小原子，Flink的社群程式碼開發者（Contributor）已超過1400名，年增長率超過20%。其中尤其值得一提的是Flink中文社群的蓬勃發展：Flink的官方公眾號訂閱數超過5萬人，全年推送超過140篇和Flink技術，生態以及行業實踐相關的最新資訊。最近，Flink社群開通了Flink官方影片號，希望透過更加豐富新穎的形式從更多緯度讓大家對Flink有更全面的瞭解。此外，Flink社群重構和改版了去年開通的Flink官方學習網站Flink Learning[1]，希望透過這個學習網站，彙總沉澱和Flink相關的學習資料，場景案例以及活動資訊，使Flink Learning真正成為大家學習研究探索Flink的好幫手。
業界影響力方面，Flink已成為業界即時計算的事實標準。越來越多的公司不僅使用Flink，也積極參與Flink的發展與建設，共同完善Flink。目前，Flink的程式碼開發者來自全球超過100+公司。去年舉辦的4場的線下meet up，阿里巴巴、字節跳動，攜程和360都提供了大力支援。而今年FFA大會有來自網際網路，金融，能源，製造業，電信等各個行業的40+知名公司共83個主題演講。從生態技術演進來看，Flink在雲原生，高可用性，流批一體和AI四個主打方向上都取得了不錯的成績。特別值得一提的是Flink新推出了流批一體的進階版，流式數倉（Streaming Warehouse）這個概念，實現流批即時分析一體化，真正意義上完成流批一體計算和流批一體儲存的融合，讓整個數倉的資料流動起來。流式數倉將是Flink未來最重要的方向之一，在Flink社群也會同步推廣。
本文將對FFA Keynote議題作一些簡單的歸納總結，感興趣的小夥伴們可以在FFA官網[2]找到相關主題影片觀看直播回放。
一 主會場議題
在主議題之前，阿里巴巴集團副總裁，阿里巴巴開源技術委員會負責人，阿里雲智慧計算平臺負責人賈揚清老師作為開場嘉賓，分享了他對開源在雲計算的大背景下的思考：開源，無論是從技術貢獻還是生態發展來看，已從最初的替代和補充逐步發展成為創新和引領的角色。阿里巴巴到目前為止已經開源了2700多個專案，是國內網際網路技術企業中的先鋒。而Flink作為阿里巴巴最具影響力的開源專案之一，無論是在技術先進性還是生態豐富性上都無可爭議。不僅如此，阿里巴巴在過去幾年中積極拓展Flink的適用場景，透過自身大規模業務打磨迭代開源技術，進而將這些技術回饋Flink社群，並攜手其他開源專案形成更全面的聯合解決方案，真正做到了開源開放，持續回饋，加速普及。
下面來重點聊一聊幾個主議題。
1 Flink Next –– Beyond Stream Processing
主議題照例由Apache Flink中文社群發起人，阿里巴巴開源大資料平臺負責人王峰（花名莫問）老師開啟，主要介紹 Flink 社群在 2021 年取得的成果以及未來的發展方向，包括雲原生，Flink容錯，流批一體和機器學習四個部分。
雲原生 –– 部署架構演進
Flink部署的三種模式
說起開源大資料的發展，繞不開雲原生，兩者相依相生相輔相成。作為開源大資料的引擎課代表Flink的部署模式是如何在雲原生大背景下演進的是個很有趣的話題。Flink最早的部署模式是經典的靜態（Static）Standalone模式，這裡的靜態是指使用者必須根據業務估算預留資源，資源少了作業就跑不起來，所以大部分情況下需要按最大資源量來預留。顯而易見這種模式對於使用者來說既複雜資源利用率也不高。第二種模式我們稱為主動（Active）模式，這裡的主動是指Flink會根據業務資源的使用情況主動的去向底層Kubernetes或者Yarn申請和釋放資源。這種模式需要Flink和底層Kubernetes或者Yarn深度整合，適用於需要對資源深度把控的使用者，對中小使用者來講太過複雜。這就引出了第三種模式我們稱為適應性（Adaptive/Reactive）模式。在這種模式下，Flink可以像雲上其他應用一樣根據所給的資源（增加或減少資源pod），透過改變自身拓撲結構來動態調整執行。從使用者的角度來看，他並不需要了解資源是如何分配的，所以第三種模式對於使用者的門檻相對較低。
還有一個值得思考的問題是雲原生到底給Flink帶來了什麼，除了彈性資源管理，資料多備份，自適應運維管理，標準化的工具和操作，筆者覺得更重要的是降低使用者的使用門檻，用更小的成本給使用者提供更簡單，穩定和豐富的使用體驗。
Flink容錯 –– 穩定快速的Checkpoint
和Checkpointing相關的討論幾乎貫穿了Flink的整個發展歷程，它是整個Flink容錯架構的核心。Flink會定期給所有的運算元狀態做快照檢查點（Checkpoint），如果Flink作業失敗，作業會從上一個完整的Checkpoint恢復。在實際工作中，我們發現引擎這一層很大部分的Oncall的問題都跟做Checkpoint相關，所以如何能夠高頻穩定的完成Checkpoint是提升Flink高可用性（容錯）的重點。造成做Checkpoint失敗（超時）的主要原因來自兩方面：一是中間資料流動緩慢造成Checkpoint Barrier流動緩慢，二是運算元狀態過大造成狀態資料上傳超時。Flink針對這兩個方面都有重點專案在跟進：Buffer Debloating和Generalized Log-Based 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的系統架構各個層面演進的過程及其落地場景，如下圖所示。
1）架構演進
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的流批一體能力結合Flink CDC的能力可以實現一體化資料整合：先全量的同步完歷史資料後自動接到斷點，即時的續傳增量資料，實現一站式資料同步（讀取資料庫全量資料後自動切換，透過binlog增量同步）。這裡的自動切換的實現基於新版流批一體Source框架。
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系統會增加系統複雜度同時也不能保證資料一致性。
為了解決訊息佇列無法有效率的進行即時分析的問題，Flink引入了Dynamic Table動態表來存放即時鏈路產生的分層資料，如上圖所示。這樣一來，Flink可以透過Flink SQL的流批一體能力即時的串聯起整個分層數倉；透過Flink SQL對Dynamic Table的OLAP查詢提供即時分析的能力。我們可以把這個理解成流批一體的進階版本流批即時分析一體化，也就是莫問老師這裡提出的流式數倉（StreamHouse = Streaming + Warehouse）這個概念，真正做到在一套方法論的大框架下實現一套API，一套計算，一套中間儲存的全鏈路一體化。
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 全新架構
機器學習作為Apache Flink的另一大重要場景，在今年Flink流批一體API和架構進一步完善的基礎上，基於流批一體DataStream API完成重構，全面升級到Flink ML 2.0。Flink ML最大的特點是即時離線一體化，以及與之相配套的即時離線一體化管理排程（Flink AI Flow）和執行。在Flink ML 2.0中有幾個新的亮點是值得看一看的：1）Flink基於DataStream在引擎部分原生的支援全新的迭代計算框架，支援更靈活的分散式同步和非同步迭代；2）釋出了一套新版Flink ML pipeline API，遵循機器學習使用者更熟悉Scikit-Learn風格（Transformer，Estimator，Model）；3）支援一體化的深度學習整合，Flink ML Estimator可以將Pytorch和Tensorflow拉起；4）流批一體能力使得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，還是很驚人的！
Flink在字節跳動發展圖
在字節跳動的分享中，基於存算分離架構的流批一體訊息佇列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在字節跳動內部如何演進使用感興趣的同學可以去看看。
三 工商銀行即時大資料平臺建設歷程及展望
主議題第三場由中國工商銀行大資料平臺負責人袁一老師帶來，他從金融行業的視角分享了有關工行即時大資料平臺建設的歷程和思路。
首先我們來看一張描述工行資料流向的示意圖，如上圖所示。應用產生的資料會寫入到MySQL或Oracle等關係型資料庫，之後將資料庫產生的日誌複製到Kafka訊息佇列中作為即時處理平臺的資料來源。即時處理平臺有三個資料出口，一是透過Flink即時ETL可以實現即時資料入湖；二是將Flink的結果輸出到HBase或者ES等聯機資料庫中提供面向應用的資料中臺服務，三是透過Presto或CK等分析型引擎，提供面向分析師的BI分析能力。工行內部的高時效業務場景，基本上都可以包含在這條鏈路體系之中。
聰明的小夥伴們可能已經發現了，上面這條複雜資料鏈路和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針對現在比較火熱的物聯網邊緣計算的定製最佳化。比如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（https://flink-learning.org.cn/）
[2] https://flink-forward.org.cn/
[4]Remote Shuffle Service（https://github.com/flink-extended/flink-remote-shuffle）
[5]Flink-extended（https://github.com/flink-extended/）
[6] Apache Flink不止於計算，數倉架構或興起新一輪變革（https://c.tb.cn/F3.0OfNLU）
[7]Flink-ML（https://github.com/apache/flink-ml）
