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

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

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

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

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

一  主會場議題

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

下面來重點(diǎn)聊一聊幾個主議題。

1  Flink Next –– Beyond Stream Processing

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

云原生 –– 部署架構(gòu)演進(jìn)

Flink部署的三種模式

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

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

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

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

Buffer Debloating是在不影響吞吐和延遲的前提下縮減上下游需要緩存的數(shù)據(jù)到剛好算子不空轉(zhuǎn)，目前Buffer Debloating默認(rèn)上游會動態(tài)緩存下游1秒鐘能處理的數(shù)據(jù)（這個時間是可以配置的）。Buffer Debloating在Flink-1.14版本已經(jīng)發(fā)布。Generalized Log-Based Checkpoint是一種基于log打點(diǎn)的方式來做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預(yù)計會在Flink-1.15版本發(fā)布。

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

流批一體 –– 架構(gòu)演進(jìn)和落地

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

1）架構(gòu)演進(jìn)

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

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

2）場景落地

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

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

在傳統(tǒng)的數(shù)據(jù)集成中，離線和實(shí)時數(shù)據(jù)集成是兩套不同的技術(shù)棧，需要全量和增量定時合并，時效性也比較差。Flink的流批一體能力結(jié)合Flink CDC的能力可以實(shí)現(xiàn)一體化數(shù)據(jù)集成：先全量的同步完歷史數(shù)據(jù)后自動接到斷點(diǎn)，實(shí)時的續(xù)傳增量數(shù)據(jù)，實(shí)現(xiàn)一站式數(shù)據(jù)同步（讀取數(shù)據(jù)庫全量數(shù)據(jù)后自動切換，通過binlog增量同步）。這里的自動切換的實(shí)現(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ù)集成感興趣的同學(xué)可以參考分論壇實(shí)時數(shù)據(jù)湖專場中的talk“Flink CDC 如何簡化實(shí)時數(shù)據(jù)入湖入倉”。

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

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

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

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

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

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

機(jī)器學(xué)習(xí) –– Apache Flink ML 2.0 全新架構(gòu)

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

 

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

 

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跨進(jìn)程通信，使得Python UDF性能接近Java UDF，兼顧開發(fā)和運(yùn)行的效率。分論壇核心技術(shù)專場“基于 FFI 的 PyFlink 下一代 Python 運(yùn)行時介紹”有對這部分更詳細(xì)的解釋。

 

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

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

字節(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è)運(yùn)行。師銳老師特別提到，從去年開始，流批一體也逐步在字節(jié)跳動公司內(nèi)部推廣應(yīng)用，感興趣的小伙伴可以參考流批一體分論壇專場中的talk“流批一體在字節(jié)跳動特征平臺的實(shí)踐”。目前字節(jié)跳動全球Flink流式作業(yè)達(dá)到4w個，其中SQL作業(yè)占30%，使用的CPU核數(shù)超過400萬核，晚高峰Flink作業(yè)處理消息的QPS達(dá)到90億，Checkpoint高峰流量吞吐達(dá)到600GB/s，還是很驚人的！

 

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

 

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

 

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

 

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

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

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

 

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

 

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

 

四  Deconstructing Stream Storage

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

 

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

在Pravega的分享中有幾個比較有趣的點(diǎn)：

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

 

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

 

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

 

五  圓桌會議

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

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

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

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

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

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

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

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

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

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

 

六  總結(jié)和感想

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

[1] Flink官方學(xué)習(xí)網(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ù)倉架構(gòu)或興起新一輪變革（https://c.tb.cn/F3.0OfNLU）

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

[8]Clink（https://github.com/flink-extended/clink）