從 Flink Forward Asia 2021，看Flink未來開啟新篇章

律回春暉漸，萬象始更新，這句詩用來形容2021年的大數(shù)據(jù)領域再合適不過，而Flink在2021年也開啟了新的篇章。

2022年1月8-9號，F(xiàn)link Forward Asia（FFA）線上峰會成功舉行。Flink Forward Asia 是由 Apache 官方授權，Apache Flink中文社區(qū)主持舉辦的會議。目前，F(xiàn)link Forward Asia 已成為國內(nèi)最大的 Apache 頂級項目會議之一，是 Flink 開發(fā)者和使用者的年度盛會。在線上峰會的同時，F(xiàn)FA還舉辦了首屆以實時計算為主題的Flink Hackathon，共有267支參賽隊伍，最終27支隊伍入圍參與線下決賽。未來Flink Hackathon也會常態(tài)化舉辦，集思廣益。

FFA大會從社區(qū)發(fā)展，業(yè)界影響力以及生態(tài)技術演進這三方面總結了Flink在過去一年的發(fā)展。社區(qū)方面，根據(jù)Apache軟件基金會2021財年報告公布的各項核心指標，F(xiàn)link已連續(xù)三年位列Apache社區(qū)最活躍的項目之一。而作為社區(qū)的最小原子，F(xiàn)link的社區(qū)代碼開發(fā)者（Contributor）已超過1400名，年增長率超過20%。其中尤其值得一提的是Flink中文社區(qū)的蓬勃發(fā)展：Flink的官方公眾號訂閱數(shù)超過5萬人，全年推送超過140篇和Flink技術，生態(tài)以及行業(yè)實踐相關的最新資訊。最近，F(xiàn)link社區(qū)開通了Flink官方視頻號，希望通過更加豐富新穎的形式從更多緯度讓大家對Flink有更全面的了解。此外，F(xiàn)link社區(qū)重構和改版了去年開通的Flink官方學習網(wǎng)站Flink Learning[1]，希望通過這個學習網(wǎng)站，匯總沉淀和Flink相關的學習資料，場景案例以及活動信息，使Flink Learning真正成為大家學習研究探索Flink的好幫手。

業(yè)界影響力方面，F(xiàn)link已成為業(yè)界實時計算的事實標準。越來越多的公司不僅使用Flink，也積極參與Flink的發(fā)展與建設，共同完善Flink。目前，F(xiàn)link的代碼開發(fā)者來自全球超過100+公司。去年舉辦的4場的線下meet up，阿里巴巴、字節(jié)跳動，攜程和360都提供了大力支持。而今年FFA大會有來自互聯(lián)網(wǎng)，金融，能源，制造業(yè)，電信等各個行業(yè)的40+知名公司共83個主題演講。從生態(tài)技術演進來看，F(xiàn)link在云原生，高可用性，流批一體和AI四個主打方向上都取得了不錯的成績。特別值得一提的是Flink新推出了流批一體的進階版，流式數(shù)倉（Streaming Warehouse）這個概念，實現(xiàn)流批實時分析一體化，真正意義上完成流批一體計算和流批一體存儲的融合，讓整個數(shù)倉的數(shù)據(jù)流動起來。流式數(shù)倉將是Flink未來最重要的方向之一，在Flink社區(qū)也會同步推廣。

本文將對FFA Keynote議題作一些簡單的歸納總結，感興趣的小伙伴們可以在FFA官網(wǎng)[2]找到相關主題視頻觀看直播回放。 

一  主會場議題

在主議題之前，阿里巴巴集團副總裁，阿里巴巴開源技術委員會負責人，阿里云智能計算平臺負責人賈揚清老師作為開場嘉賓，分享了他對開源在云計算的大背景下的思考：開源，無論是從技術貢獻還是生態(tài)發(fā)展來看，已從最初的替代和補充逐步發(fā)展成為創(chuàng)新和引領的角色。阿里巴巴到目前為止已經(jīng)開源了2700多個項目，是國內(nèi)互聯(lián)網(wǎng)技術企業(yè)中的先鋒。而Flink作為阿里巴巴最具影響力的開源項目之一，無論是在技術先進性還是生態(tài)豐富性上都無可爭議。不僅如此，阿里巴巴在過去幾年中積極拓展Flink的適用場景，通過自身大規(guī)模業(yè)務打磨迭代開源技術，進而將這些技術回饋Flink社區(qū)，并攜手其他開源項目形成更全面的聯(lián)合解決方案，真正做到了開源開放，持續(xù)回饋，加速普及。

下面來重點聊一聊幾個主議題。

1  Flink Next –– Beyond Stream Processing

主議題照例由Apache Flink中文社區(qū)發(fā)起人，阿里巴巴開源大數(shù)據(jù)平臺負責人王峰（花名莫問）老師開啟，主要介紹 Flink 社區(qū)在 2021 年取得的成果以及未來的發(fā)展方向，包括云原生，F(xiàn)link容錯，流批一體和機器學習四個部分。

云原生 –– 部署架構演進

Flink部署的三種模式

說起開源大數(shù)據(jù)的發(fā)展，繞不開云原生，兩者相依相生相輔相成。作為開源大數(shù)據(jù)的引擎課代表Flink的部署模式是如何在云原生大背景下演進的是個很有趣的話題。Flink最早的部署模式是經(jīng)典的靜態(tài)（Static）Standalone模式，這里的靜態(tài)是指用戶必須根據(jù)業(yè)務估算預留資源，資源少了作業(yè)就跑不起來，所以大部分情況下需要按最大資源量來預留。顯而易見這種模式對于用戶來說既復雜資源利用率也不高。第二種模式我們稱為主動（Active）模式，這里的主動是指Flink會根據(jù)業(yè)務資源的使用情況主動的去向底層Kubernetes或者Yarn申請和釋放資源。這種模式需要Flink和底層Kubernetes或者Yarn深度集成，適用于需要對資源深度把控的用戶，對中小用戶來講太過復雜。這就引出了第三種模式我們稱為適應性（Adaptive/Reactive）模式。在這種模式下，F(xiàn)link可以像云上其他應用一樣根據(jù)所給的資源（增加或減少資源pod），通過改變自身拓撲結構來動態(tài)調(diào)整運行。從用戶的角度來看，他并不需要了解資源是如何分配的，所以第三種模式對于用戶的門檻相對較低。

還有一個值得思考的問題是云原生到底給Flink帶來了什么，除了彈性資源管理，數(shù)據(jù)多備份，自適應運維管理，標準化的工具和操作，筆者覺得更重要的是降低用戶的使用門檻，用更小的成本給用戶提供更簡單，穩(wěn)定和豐富的使用體驗。

Flink容錯 –– 穩(wěn)定快速的Checkpoint

和Checkpointing相關的討論幾乎貫穿了Flink的整個發(fā)展歷程，它是整個Flink容錯架構的核心。Flink會定期給所有的算子狀態(tài)做快照檢查點（Checkpoint），如果Flink作業(yè)失敗，作業(yè)會從上一個完整的Checkpoint恢復。在實際工作中，我們發(fā)現(xiàn)引擎這一層很大部分的Oncall的問題都跟做Checkpoint相關，所以如何能夠高頻穩(wěn)定的完成Checkpoint是提升Flink高可用性（容錯）的重點。造成做Checkpoint失?。ǔ瑫r）的主要原因來自兩方面：一是中間數(shù)據(jù)流動緩慢造成Checkpoint Barrier流動緩慢，二是算子狀態(tài)過大造成狀態(tài)數(shù)據(jù)上傳超時。Flink針對這兩個方面都有重點項目在跟進：Buffer Debloating和Generalized Log-Based Checkpoint。

Buffer Debloating是在不影響吞吐和延遲的前提下縮減上下游需要緩存的數(shù)據(jù)到剛好算子不空轉(zhuǎn)，目前Buffer Debloating默認上游會動態(tài)緩存下游1秒鐘能處理的數(shù)據(jù)（這個時間是可以配置的）。Buffer Debloating在Flink-1.14版本已經(jīng)發(fā)布。Generalized Log-Based Checkpoint是一種基于log打點的方式來做Checkpoint的方法，類似傳統(tǒng)DB的write ahead log，好處是能快速，高頻且穩(wěn)定的做Checkpoint，代價是需要額外多寫/存一份log。我們知道Flink做Checkpoint由同步和異步兩個過程組成，同步的過程通常很快，主要的耗時在異步上傳狀態(tài)文件這個過程中。Generalized Log-Based Checkpoint的原理就是將Checkpointing這個過程和耗時的異步上傳文件這個過程剝離開，也同時和底層狀態(tài)存儲的物化過程解耦。Generalized Log-Based Checkpoint預計會在Flink-1.15版本發(fā)布。

分論壇核心技術專場talk“Flink新一代流計算和容錯（Flink Fault Tolerance 2.0）”對這個部分有更為詳細的闡述，感興趣的同學可以找來看看。

流批一體 –– 架構演進和落地

流批一體是近些年Flink一直在力推的創(chuàng)新性理念，從最早提出這個理念到當前被廣泛接受，莫問老師分享了流批一體在Flink的系統(tǒng)架構各個層面演進的過程及其落地場景，如下圖所示。

1）架構演進

API層面，去年流批統(tǒng)一的SQL/Table API（Declarative API）首次在阿里巴巴雙十一最核心的天貓營銷活動分析大屏場景中落地[3]，今年更近一步，完成了Imperative API的整合，形成流批統(tǒng)一的DataStream API，而陳舊的DataSet API將逐步被淘汰。架構層面，同一個作業(yè)可以同時處理有限數(shù)據(jù)集和無限數(shù)據(jù)集；并且connector框架可以同時對接流式存儲和批式存儲，做到一套代碼可以處理兩套數(shù)據(jù)源。運行層面，一套調(diào)度框架可以同時適用于流和批的作業(yè)；流批shuffle是pluggable的，復用一套shuffle接口。阿里巴巴實時計算團隊在今年開源了存算分離的Remote Shuffle Service[4]，放在Flink開源項目的Flink-extended這個子項目組里面。Flink-extended[5]里面包含很多其他Flink生態(tài)項目，有興趣的同學可以去看一看。

繼去年在天貓雙十一核心大屏業(yè)務上線后，流批一體今年逐步在阿里巴巴更多核心業(yè)務上推廣。除了阿里巴巴，有越來越多的公司認可流批一體這個理念。今年FFA有個專門的流批一體分論壇，由字節(jié)跳動，美團，京東以及小米等公司分享流批一體在其業(yè)務中的實踐。此外在核心技術專場中有專門針對流批一體架構演進的專場talk“面向流批一體的 Flink Runtime 新進展”，對這個話題感興趣的同學可以了解一下。對新版connector框架原理感興趣的同學可以參考核心技術專場中的“Flink Connector社區(qū)新動向與Hybrid Source原理實踐”。

2）場景落地

莫問老師指出，流批一體這一技術理念落地需要具體的場景支撐來體現(xiàn)其真正價值，基于此，他分享了流批一體最為典型的兩個應用場景。

場景1  Flink CDC：全增量一體化數(shù)據(jù)集成

在傳統(tǒng)的數(shù)據(jù)集成中，離線和實時數(shù)據(jù)集成是兩套不同的技術棧，需要全量和增量定時合并，時效性也比較差。Flink的流批一體能力結合Flink CDC的能力可以實現(xiàn)一體化數(shù)據(jù)集成：先全量的同步完歷史數(shù)據(jù)后自動接到斷點，實時的續(xù)傳增量數(shù)據(jù)，實現(xiàn)一站式數(shù)據(jù)同步（讀取數(shù)據(jù)庫全量數(shù)據(jù)后自動切換，通過binlog增量同步）。這里的自動切換的實現(xiàn)基于新版流批一體Source框架。

Flink CDC目前已可以支持大部分主流數(shù)據(jù)庫包括MySQL、Postgres、Oracle、MongoDB、MariaDB，其他的如TiDB，DB2，SQL Server也在積極開發(fā)中。對Flink CDC如何能夠?qū)崿F(xiàn)一站式數(shù)據(jù)集成感興趣的同學可以參考分論壇實時數(shù)據(jù)湖專場中的talk“Flink CDC 如何簡化實時數(shù)據(jù)入湖入倉”。

場景2  Streaming Warehouse：流式數(shù)倉

前面提到，今年的一大亮點是莫問老師提出的流式數(shù)倉（Streaming Warehouse）這個概念，這個概念提出的大背景是為了解決實時離線數(shù)倉一體化的問題。

實時離線數(shù)倉一體化這個問題目前比較常用的解決方案是用實時和離線兩條鏈路來實現(xiàn)：1）實時流處理鏈路（Flink + Kafka）對數(shù)據(jù)進行分層ODS，DWD，DWS，并實時寫入在線服務層，提供在線服務（實時OLAP）；2）同時會有一條離線鏈路定期對實時數(shù)據(jù)進行補充和歷史修正。這里除了常見的流批不統(tǒng)一帶來的開發(fā)效率，維護成本，流批口徑不統(tǒng)一等問題以外，其實還有一個更隱蔽同時也更難解決的問題：為了保證實時性，實時鏈路中的ODS，DWD，DWS這些分層數(shù)據(jù)是存在消息隊列（比如Kafka）中的，但是消息隊列中的數(shù)據(jù)是沒辦法有效進行實時分析的，如果引入其他的OLAP系統(tǒng)會增加系統(tǒng)復雜度同時也不能保證數(shù)據(jù)一致性。

為了解決消息隊列無法有效率的進行實時分析的問題，F(xiàn)link引入了Dynamic Table動態(tài)表來存放實時鏈路產(chǎn)生的分層數(shù)據(jù)，如上圖所示。這樣一來，F(xiàn)link可以通過Flink SQL的流批一體能力實時的串聯(lián)起整個分層數(shù)倉；通過Flink SQL對Dynamic Table的OLAP查詢提供實時分析的能力。我們可以把這個理解成流批一體的進階版本流批實時分析一體化，也就是莫問老師這里提出的流式數(shù)倉（StreamHouse = Streaming + Warehouse）這個概念，真正做到在一套方法論的大框架下實現(xiàn)一套API，一套計算，一套中間存儲的全鏈路一體化。

Dynamic Table（動態(tài)表）不同于一般意義上的Source和Sink，是Flink的內(nèi)置表。之所以稱為動態(tài)表是因為此表具有流表二象性。流表二象性通過列存LSM Tree和Log兩種不同的存儲形式來支持，分別對應于Flink SQL的批（全量分析）和流（增量處理）兩種模式。Dynamic Table通過Flink自身的Checkpointing一致性語義機制保證流表二象性在兩種存儲形式下的一致性語義。這里需要特別注意的是，流表二象存儲的數(shù)據(jù)一致性問題是混拼系統(tǒng)（引入其他OLAP和消息隊列）無法輕易規(guī)避和解決的問題（因為中間涉及多系統(tǒng)間的一致性讀寫同步），這也是Flink Dynamic Table區(qū)別于其他類似系統(tǒng)的核心競爭力之一。如果大家對動態(tài)表的實現(xiàn)感興趣的話可以看一看流批一體分論壇中“基于Flink Dynamic Table構建流批一體數(shù)倉”這個talk，里面有對Dynamic Table更詳細的介紹。

這個部分的最后有一個流式數(shù)倉的demo，用上述一體化的方法論展示了流作業(yè)在實時OLAP分析發(fā)現(xiàn)業(yè)務邏輯有錯后，如何批式做訂正并實時支持OLAP查詢更正的一個流批實時分析一體化的典型場景，還是很受啟發(fā)的，大家可以看一看。想對流式數(shù)倉有更詳細了解的同學可以參考莫問老師關于流式數(shù)倉的專訪[6]。

機器學習 –– Apache Flink ML 2.0 全新架構

機器學習作為Apache Flink的另一大重要場景，在今年Flink流批一體API和架構進一步完善的基礎上，基于流批一體DataStream API完成重構，全面升級到Flink ML 2.0。Flink ML最大的特點是實時離線一體化，以及與之相配套的實時離線一體化管理調(diào)度（Flink AI Flow）和執(zhí)行。在Flink ML 2.0中有幾個新的亮點是值得看一看的：1）Flink基于DataStream在引擎部分原生的支持全新的迭代計算框架，支持更靈活的分布式同步和異步迭代；2）發(fā)布了一套新版Flink ML pipeline API，遵循機器學習用戶更熟悉Scikit-Learn風格（Transformer，Estimator，Model）；3）支持一體化的深度學習集成，F(xiàn)link ML Estimator可以將Pytorch和Tensorflow拉起；4）流批一體能力使得Flink ML 2.0可以同時對接流和批的數(shù)據(jù)集。

Flink ML 2.0目前已經(jīng)由阿里巴巴實時計算團隊和機器學習團隊共同完成，貢獻給Flink社區(qū)，成為Flink的一個子項目Flink-ML[7]。值得一提的是除了阿里巴巴，現(xiàn)在還有很多其他公司也在共同建設Flink ML的生態(tài)，比如360貢獻了Clink[8]。核心技術專場中“為實時機器學習設計的算法接口與迭代引擎”這個talk詳細介紹了Flink ML 2.0的架構演進，此外今年FFA還有一個機器學習專場，感興趣的同學可以看一看。

PyFlink方面，F(xiàn)link對AI的主流開發(fā)語言Python的支持更加完備：PyFlink在功能上完全追平了Table API 和Data Stream API的能力，在性能上創(chuàng)新性的通過JNI調(diào)用C，再在C里面調(diào)用Python解析器的方法消除了Python UDF和Java跨進程通信，使得Python UDF性能接近Java UDF，兼顧開發(fā)和運行的效率。分論壇核心技術專場“基于 FFI 的 PyFlink 下一代 Python 運行時介紹”有對這部分更詳細的解釋。

二  實時計算在字節(jié)跳動的發(fā)展與展望

主議題第二場由字節(jié)跳動計算基礎架構負責人師銳老師帶來。字節(jié)跳動的產(chǎn)品業(yè)務場景主要都是以實時信息流推薦為主，因此以Flink為支撐的實時計算廣泛應用在字節(jié)跳動的各個產(chǎn)品中。字節(jié)跳動旗下全線產(chǎn)品總MAU目前已超過19億，由于其業(yè)務特性，其數(shù)據(jù)量（EB級別，1EB = 2^60 Bytes）和實時推薦的請求量（百萬QPS）都是巨大的。我們可以看到在師銳老師分享的字節(jié)跳動引擎資源使用的對比圖中，F(xiàn)link和Spark基本持平，這在一般的公司是不太常見的，從這個方面也可以看出字節(jié)跳動整個業(yè)務線對以Flink為基礎的流計算的依賴。

字節(jié)跳動主要計算引擎資源對比圖

字節(jié)跳動從2017年開始調(diào)研并逐步使用Flink流式計算，到2019年初，所有流式作業(yè)已完成從JStorm到Flink的遷移。2019年開始，隨著Flink SQL和Flink批式計算的成熟，F(xiàn)link Batch也在字節(jié)跳動數(shù)據(jù)同步等場景相繼落地，現(xiàn)在每天大約有10w+ Flink Batch作業(yè)運行。師銳老師特別提到，從去年開始，流批一體也逐步在字節(jié)跳動公司內(nèi)部推廣應用，感興趣的小伙伴可以參考流批一體分論壇專場中的talk“流批一體在字節(jié)跳動特征平臺的實踐”。目前字節(jié)跳動全球Flink流式作業(yè)達到4w個，其中SQL作業(yè)占30%，使用的CPU核數(shù)超過400萬核，晚高峰Flink作業(yè)處理消息的QPS達到90億，Checkpoint高峰流量吞吐達到600GB/s，還是很驚人的！

Flink在字節(jié)跳動發(fā)展圖

在字節(jié)跳動的分享中，基于存算分離架構的流批一體消息隊列BMQ值得提一提（BMQ目前承接了字節(jié)90%的消息隊列流量）。在BMQ之前，字節(jié)使用Kafka作為消息隊列，集群升級擴縮容需要大量拷貝數(shù)據(jù)，所以完成一個集群的升級差不多需要一周的時間。為了解決這個問題，字節(jié)團隊基于存算分離的架構重新設計實現(xiàn)了消息隊列，BMQ。在BMQ的架構之下，數(shù)據(jù)存放在分布式文件系統(tǒng)HDFS中，Meta存放在K-V存儲中。由于BMQ的計算層Proxy無狀態(tài)所以非常容易做擴縮容，遷移時間可在分鐘級完成。另一方面，BMQ可以同時提供Stream API和Batch API，所以可以同時支持流和批的消費，實現(xiàn)存儲層的流批一體。有些小伙伴可能有疑問，這和上面提到的動態(tài)表（Dynamic Table）一樣嗎？筆者覺得還是很不一樣的，因為要解決的問題不一樣：動態(tài)表要解決流批實時分析一體化的問題，所以它的流批存儲格式是完全不一樣的（為了分別加速流處理和批查詢）；而BMQ所有數(shù)據(jù)只寫一份在HDFS上，主要還是為支持高效的大規(guī)模消息傳輸和讀寫服務的。

師銳老師提到他們下一步計劃是推進Flink OLAP的落地。他指出，F(xiàn)link擁有豐富的connector生態(tài)可以實現(xiàn)跨數(shù)據(jù)源查詢，F(xiàn)link OLAP能力在字節(jié)內(nèi)部測試過可以媲美Presto，甚至在有些情況下更優(yōu)，現(xiàn)在有關Flink OLAP的改進和優(yōu)化也在積極推進Flink社區(qū)中。本次FFA字節(jié)跳動有7個分會場talk，從核心技術提升到行業(yè)實踐涵蓋了方方面面，對Flink在字節(jié)跳動內(nèi)部如何演進使用感興趣的同學可以去看看。

三  工商銀行實時大數(shù)據(jù)平臺建設歷程及展望

主議題第三場由中國工商銀行大數(shù)據(jù)平臺負責人袁一老師帶來，他從金融行業(yè)的視角分享了有關工行實時大數(shù)據(jù)平臺建設的歷程和思路。

首先我們來看一張描述工行數(shù)據(jù)流向的示意圖，如上圖所示。應用產(chǎn)生的數(shù)據(jù)會寫入到MySQL或Oracle等關系型數(shù)據(jù)庫，之后將數(shù)據(jù)庫產(chǎn)生的日志復制到Kafka消息隊列中作為實時處理平臺的數(shù)據(jù)源。實時處理平臺有三個數(shù)據(jù)出口，一是通過Flink實時ETL可以實現(xiàn)實時數(shù)據(jù)入湖；二是將Flink的結果輸出到HBase或者ES等聯(lián)機數(shù)據(jù)庫中提供面向應用的數(shù)據(jù)中臺服務，三是通過Presto或CK等分析型引擎，提供面向分析師的BI分析能力。工行內(nèi)部的高時效業(yè)務場景，基本上都可以包含在這條鏈路體系之中。

聰明的小伙伴們可能已經(jīng)發(fā)現(xiàn)了，上面這條復雜數(shù)據(jù)鏈路和Flink流式數(shù)倉（Streaming Warehouse）場景幾乎一摸一樣。但是通過Flink的流式數(shù)倉，我們可以把工行的這條中間貫穿很多系統(tǒng)和組件的鏈路簡化成Flink單鏈路，通過Flink的動態(tài)表（Dynamic Table）提供的流批實時分析一體化的能力來完成實時入湖，實時數(shù)據(jù)服務和實時分析！

另一個比較有趣的點是金融行業(yè)的數(shù)據(jù)中臺在設計的時候會特別考慮數(shù)據(jù)私密和安全的問題。他們采用的方法有以下幾種：1）采用全生命周期的數(shù)據(jù)監(jiān)控審計，用于數(shù)據(jù)訪問的審計和追溯；2）在數(shù)據(jù)發(fā)生移動的時候給數(shù)據(jù)本身加水印可以方便溯源；3）通過SQL實現(xiàn)自然人級別的動態(tài)數(shù)據(jù)訪問權限控制；4）通過專家規(guī)則和Machine Learning來自動識別海量數(shù)據(jù)中的敏感數(shù)據(jù)。這些思想和方法在數(shù)據(jù)安全，數(shù)據(jù)私密越來越受重視的今天很有借鑒意義。袁一老師還詳細分享了很多和金融行業(yè)相關的業(yè)務場景，相信會對業(yè)務場景感興趣的同學有所啟發(fā)。

四  Deconstructing Stream Storage

主議題的最后一場由Pravega中國社區(qū)創(chuàng)始人，戴爾科技集團OSA軟件開發(fā)總監(jiān)滕昱老師壓軸：解構流存儲。

Pravega是提供流批統(tǒng)一能力的開源分布式流存儲，有如下特點：1）相同鍵值下可以保證數(shù)據(jù)有序；2）可以根據(jù)數(shù)據(jù)流量動態(tài)擴縮存儲單元；3）支持事務性寫入；4）支持Checkpointing和一致性讀寫；5）分層存儲設計。所有的這些特性都封裝在Stream抽象的設計理念之下，也給流式計算屏蔽了很多流存儲端的復雜性。在這次分享中，滕昱老師著重介紹了Pravega的分層存儲架構（Tiered Storage）：其底層是一個基于分布式文件/對象存儲的持久性主存儲，中間是基于內(nèi)存的全局Cache層，最上層是分布式Log抽象層。滕昱老師還同時分享了Pravega的分層存儲架構與Kafka和Pulsar這兩個消息系統(tǒng)在架構上的區(qū)別以及對性能的影響，感興趣的同學可以去詳細了解一下。

在Pravega的分享中有幾個比較有趣的點：

一是Pravega針對現(xiàn)在比較火熱的物聯(lián)網(wǎng)邊緣計算的定制優(yōu)化。比如Pravega針對多客戶端的兩階段數(shù)據(jù)聚合，在Writer進行第一階段聚合，在Segment Store進行第二階段聚合，極大的提高了吞吐量。這種數(shù)據(jù)聚合優(yōu)化非常適用于有大量客戶端但每個客戶端產(chǎn)生的數(shù)據(jù)量比較小的情況，而這就是物聯(lián)網(wǎng)的典型特點。

二是Pravega和Flink聯(lián)動的端到端的auto-scaling。彈性擴縮容是云原生大背景下非常重要的問題，前面提到Pravega的一大特點就是可以自動擴縮容，調(diào)整Segment數(shù)目，而這個數(shù)目可以很好的作為Flink Reactive Scaling的指標，兩者相結合后可以做到從計算到存儲端到端的auto-scaling，目前這項工作已在兩邊社區(qū)合作規(guī)劃中。滕昱老師的分享中還有一個Demo展示了Pravega和Flink聯(lián)動scaling的效果。

滕昱老師表示未來存儲和計算，流和表的界限逐漸模糊，Pravega流批一體的存儲設計也暗合了Flink未來很重要的一個發(fā)展方向。Pravega社區(qū)會積極與包括Flink在內(nèi)的數(shù)據(jù)湖倉相關的開源社區(qū)通力合作，構建解決方案。今年Pravega和Flink社區(qū)共同發(fā)布了白皮書，未來也期望和Flink社區(qū)有更多合作，將Flink計算推向數(shù)據(jù)的產(chǎn)生端，通過Pravega能實現(xiàn)數(shù)據(jù)從端到云的流動。

五  圓桌會議

今年FFA主會場新增加了一個環(huán)節(jié)圓桌會議（分北京和上海兩場），邀請了業(yè)界來自阿里巴巴，字節(jié)跳動，美團，快手，小米，工商銀行，戴爾科技集團和小紅書在內(nèi)的多位大數(shù)據(jù)專家負責人，共同探討Flink以及實時計算的未來。各位大佬友好真誠并且很接地氣討論了很多大家都比較關心的問題，由于篇幅關系，這里僅列出了討論的部分相關話題，大家可以找視頻感受一下：

- 如何看待Flink在實時計算方面已趨于成熟這個話題，目前大家都用實時計算做什么？

- 實時計算的未來是怎樣的（技術和業(yè)務層面）？基于此，F(xiàn)link需要探索哪些新的領域，解決哪些關鍵問題？

- 有人認為實時計算的門檻和代價比較高，相對偏小眾；也有很多人認為實時計算是未來的方向，大數(shù)據(jù)和 AI 都會向?qū)崟r化方向演進；大家怎么看這個問題？

- Flink在整個開源大數(shù)據(jù)生態(tài)中應該如何定位，如何保持差異化？

- 如何看待公司內(nèi)部技術實踐，技術創(chuàng)新與開源社區(qū)之間的關系，大家使用和回饋社區(qū)的策略又是什么？

- 使用和貢獻開源項目有哪些優(yōu)勢？公司內(nèi)部在做Flink哪方面的探索？過程中又遇到過哪些挑戰(zhàn)？

- Flink在內(nèi)部使用的未來規(guī)劃，以及接下來有哪些打算貢獻社區(qū)的創(chuàng)新技術？

- 如何看待 Flink 與生態(tài)項目之間的（合作、競爭）關系？

- 什么樣的開源社區(qū)是對大家有幫助的開源社區(qū)？同時又是一個可持續(xù)發(fā)展的社區(qū)？

六  總結和感想

過去的2021年是大數(shù)據(jù)領域的風口年，對于Apache Flink，實時計算的領跑者，能否抓住這個風口也是很關鍵的一年。在Flink SQL趨于成熟，流批一體在業(yè)內(nèi)逐步被接受落地的當口，我們需要思考未來Flink何去何從，這也是我們正在做的事情。在此基礎上，F(xiàn)link推出了流批一體的進階版，流式數(shù)倉（Streaming Warehouse）這個概念，希望能實現(xiàn)流批實時分析一體化，真正意義上完成流批一體計算和流批一體存儲的融合，做到在一套方法論的大框架下實現(xiàn)一套API，一套計算，一套中間存儲的全鏈路一體化。流式數(shù)倉將是Flink未來最重要的方向，道阻且長，行則將至，行而不輟，未來可期！

[1] Flink官方學習網(wǎng)站Flink Learning（https://flink-learning.org.cn/）

[2] https://flink-forward.org.cn/

[3]40億條/秒！Flink流批一體在阿里雙11首次落地的背后

[4]Remote Shuffle Service（https://github.com/flink-extended/flink-remote-shuffle）

[5]Flink-extended（https://github.com/flink-extended/）

[6] Apache Flink不止于計算，數(shù)倉架構或興起新一輪變革（https://c.tb.cn/F3.0OfNLU）

[7]Flink-ML（https://github.com/apache/flink-ml）

FFA 2021 直播回放 & 演講 PDF 獲取

   戳我，獲取 FFA 2021 峰會資料～