一、流計算 Oceanus 介紹

隨著大數(shù)據(jù)技術(shù)的發(fā)展，客戶對實時處理與分析需求日益增長，實時數(shù)據(jù)分析已成為驅(qū)動業(yè)務(wù)創(chuàng)新、提升競爭力的關(guān)鍵要素。傳統(tǒng)批處理方式存在時效性差、數(shù)據(jù)孤島、難以擴(kuò)展等問題，因此需要實時計算來彌補(bǔ)。

騰訊云流計算基于開源的 Apache Flink 搭建，作為騰訊云大數(shù)據(jù)產(chǎn)品中的實時鏈路，是企業(yè)級實時大數(shù)據(jù)平臺，具備一站式開發(fā)、5 秒無縫銜接、亞秒延遲、低成本、安全穩(wěn)定等特性。

二、騰訊云流式湖倉架構(gòu)

接下來進(jìn)入本次分享的核心部分，詳細(xì)介紹騰訊云流式湖倉解決方案。

首先來介紹基于 Iceberg 的湖倉一體化基礎(chǔ)方案，該方案以 Iceberg 為核心，其生態(tài)穩(wěn)定，能提供強(qiáng)大的表管理與數(shù)據(jù)組織能力，支持大規(guī)模數(shù)據(jù)集高效處理，即便海量數(shù)據(jù)場景也可穩(wěn)定運(yùn)行，且生態(tài)集成良好，與主流大數(shù)據(jù)計算引擎（如 Spark、Flink、Presto 等）無縫對接，在騰訊云內(nèi)部與 DLC、EMR 等大數(shù)據(jù)產(chǎn)品深度結(jié)合。

Iceberg 湖倉鏈路可以覆蓋從實時流處理到離線批處理的完整數(shù)據(jù)鏈路，在騰訊云內(nèi)部廣泛應(yīng)用于離線分析場景，因此騰訊云流式湖倉基于 Iceberg 設(shè)計。

回顧大數(shù)據(jù)鏈路發(fā)展，除離線鏈路外，許多客戶都有實時鏈路需求。傳統(tǒng)上，實時與離線業(yè)務(wù)客戶常用 Lambda 架構(gòu)搭建實時分析鏈路。在 Lambda 架構(gòu)中，離線與實時鏈路分離，離線鏈路數(shù)據(jù)存儲于 Iceberg 等離線存儲引擎，后用 Spark 進(jìn)行多層數(shù)據(jù)轉(zhuǎn)換。在時效需求不高時，在數(shù)據(jù)規(guī)模支持與成本方面有優(yōu)勢。但隨著實時場景增加，單一 Iceberg 方式難以滿足業(yè)務(wù)需求，客戶常采用 Flink 加 Kafka 方式構(gòu)建實時分層鏈路，數(shù)據(jù)最終寫入數(shù)據(jù)倉庫或主流數(shù)據(jù)庫（如 CK、Doris 等）。

此鏈路雖可實現(xiàn)秒級延遲，但存在諸多問題。

其一，靈活性低，Kafka 僅作數(shù)據(jù)管道，無法應(yīng)用于數(shù)據(jù)探索、分析場景，且不能保存較長歷史數(shù)據(jù)，限制用戶使用靈活性，導(dǎo)致數(shù)據(jù)處理問題排查困難。

其二，成本高，實時鏈路單獨(dú)存在，Kafka 與 Flink 對 state 維護(hù)及存儲計算資源需求大，導(dǎo)致成本較高。

其三，對 update 場景支持不足，Kafka 寫入非完整 change log 流時，后續(xù)接入 Fink 作業(yè)進(jìn)行流式處理困難，雖 Flink 提供 upset Kafka 解決，但依賴本地狀態(tài)存儲，成本較高。

此外，Lambda 架構(gòu)將離線與實時鏈路、存儲及計算引擎隔離，相同數(shù)據(jù)需多次重復(fù)存儲，實時與離線計算邏輯需單獨(dú)開發(fā)，維護(hù)、管理及業(yè)務(wù)變更成本高，因此需要新的架構(gòu)來統(tǒng)一實時與離線分析鏈路，降低成本。

基于此，內(nèi)部調(diào)研了社區(qū)原生 Iceberg Upsert 表方案，發(fā)現(xiàn)其存在一些問題。如 Iceberg 通過 upsert 表寫入數(shù)據(jù)時，產(chǎn)生的數(shù)據(jù)是無序的，數(shù)據(jù)管理面臨挑戰(zhàn)?；?EQ DELETE 的數(shù)據(jù)合并機(jī)制，在 update 場景下會產(chǎn)生非常大的合并開銷，無法滿足高數(shù)據(jù)量與擴(kuò)展性需求。且無法支持點(diǎn)查與部分列更新功能，不能滿足維表 join 和性能優(yōu)化的需求。同時，該鏈路缺乏生成 binlog 的能力，無法適應(yīng)流式寫入與流讀場景，限制了其在實時鏈路中的有效性。

針對這些問題，我們設(shè)計了全新的流式湖倉架構(gòu)。該架構(gòu)引入了 LSM Tree來組織數(shù)據(jù)，解決數(shù)據(jù)無序問題。先排序再寫入，確保高效的數(shù)據(jù)管理。Compaction 過程中生成邏輯日志文件，并引入了額外的元數(shù)據(jù)描述 LSM Tree 結(jié)構(gòu)與日志文件關(guān)系。

該方案的優(yōu)勢包括，可生成完整 binlog，增強(qiáng)對實時數(shù)據(jù)流支持；LSM Tree 自身的合并特性，可以減少數(shù)據(jù)合并開銷，提升系統(tǒng)性能；支持部分列更新與點(diǎn)查功能，為后續(xù) state 優(yōu)化與增量計算方案提供了基礎(chǔ)。

基于 Iceberg 生態(tài)的流式湖倉解決方案，采用了 LSM Tree 進(jìn)行存儲管理，支持高效逐行更新場景，數(shù)據(jù)寫入時通過增強(qiáng)數(shù)據(jù)合并優(yōu)化效率，支持單行數(shù)據(jù)部分列更新，使用戶能夠精準(zhǔn)管理數(shù)據(jù)變更，應(yīng)對復(fù)雜業(yè)務(wù)需求。流式湖倉可在數(shù)據(jù)處理過程中生成完整的 change log 記錄，為下游（如 Flink）提供支持，使增量處理與實時數(shù)據(jù)流管理成為可能。下游 Flink 作業(yè)可基于變更記錄生成下一層數(shù)據(jù)，實現(xiàn)流式數(shù)據(jù)的高效管理。整體方案增強(qiáng)了數(shù)據(jù)的實時性與靈活性，提供了一體化流式湖倉體驗。

從整體架構(gòu)看，流式湖倉方案基于開源 Iceberg 生態(tài)建設(shè)，天然支持 Iceberg 兼容能力。如上圖所示，藍(lán)框部分為普通 Iceberg 寫入，F(xiàn)link 寫入數(shù)據(jù)并生成快照時生成 Iceberg 元數(shù)據(jù)。

騰訊云流式湖倉寫入流程中，數(shù)據(jù)除先排序外，格式與原生 Iceberg 相同，生成原生元數(shù)據(jù)時，同時生成兩份元數(shù)據(jù)。一份是調(diào)用原生 Iceberg 包生成的兼容元數(shù)據(jù)，與開源 Iceberg 社區(qū)完全一致，支持 Iceberg 主要功能（如影視分區(qū)、schema 變更、partition 變更等）及所有版本系統(tǒng)高效支持；另一份是湖倉原生元數(shù)據(jù)，包含 LSM tree 結(jié)構(gòu)與邏輯日志文件等原生不支持信息，支持額外性能優(yōu)化與流讀場景。借助數(shù)據(jù)合并能力，生成的 Iceberg 表不含 EQ DELETE 記錄，可高效讀取。

支持用戶基于 Iceberg 原生客戶端數(shù)據(jù)寫入能力，實現(xiàn)無縫集成與多數(shù)據(jù)源接入。其原理為客戶通過原生客戶端寫入數(shù)據(jù)后，先在兼容元數(shù)據(jù)版本中生成新快照記錄，系統(tǒng)定時任務(wù)或下次數(shù)據(jù)提交時，通過沖突檢測識別新提交快照中的新增數(shù)據(jù)文件，提取并重新排序插入 LSM tree 的 L0 層，在兼容與流式湖倉元數(shù)據(jù)中重復(fù)提交，分別生成完整 snapshot 實現(xiàn)數(shù)據(jù)的正式提交。

基于 LSM Tree 的流式湖倉在寫入過程中進(jìn)行數(shù)據(jù)合并操作，確保數(shù)據(jù)準(zhǔn)確有序及一致性，為后續(xù)數(shù)據(jù)讀取提供性能保障。整體采用 universal compaction 策略平衡讀寫放大，保證全局有序并減少文件數(shù)量。

數(shù)據(jù)從 L0 層首次合并至 L0 層以上時，系統(tǒng)查詢現(xiàn)有文件中相同組件前值，與新寫入值合并生成 binlog，更新現(xiàn)有 pos deletion 記錄。為提升合并性能，引入了索引定位數(shù)據(jù)位置，并且在本地增加了熱點(diǎn)文件緩存，以提升索引與合并性能。

支持 pos deletion 合并與更新，優(yōu)化數(shù)據(jù)更新性能，系統(tǒng)支持內(nèi)置與自定義值合并函數(shù)，應(yīng)對不同業(yè)務(wù)需求，并實現(xiàn)了部分列更新與點(diǎn)查能力，豐富數(shù)據(jù)鏈路處理能力，滿足復(fù)雜場景需求。

除數(shù)據(jù)合并外，流式湖倉在數(shù)據(jù)并發(fā)提交方面也有實現(xiàn)。數(shù)據(jù)文件寫入后，流式湖倉通過提交生成眾多源數(shù)據(jù)文件，在提交部分進(jìn)行了并發(fā)提交優(yōu)化，以提升性能。對比傳統(tǒng) Iceberg 單一節(jié)點(diǎn)完成 snapshot 生成，流式湖倉采用兩階段提交流程。多 bucket 需要提交時，commit 算子并行完成所分配 bucket 源數(shù)據(jù)文件更新與歷史文件合并操作，生成 bucket 級別的元數(shù)據(jù)文件后，由全局 global committer 算子完成快照生成。此設(shè)計在 bucket 較多時可顯著提高數(shù)據(jù)提交性能，避免數(shù)據(jù)提交過程中的 OM 情況，保證高效數(shù)據(jù)處理。同時支持多流寫入同一表，多個數(shù)據(jù)流可同時寫入，結(jié)合部分列更新能力，實現(xiàn)類似多流 join 的效果。多流寫入同一表時，每個流寫入并提交，需保證寫入快照可序列化，采用基于 sequence number 的沖突檢測與提交重試機(jī)制。每次提交時，若發(fā)現(xiàn)更新快照，對應(yīng)流需合并之前提交文件變化與最終快照并重新提交，確保數(shù)據(jù)一致性。此提交創(chuàng)新提高流式湖倉高并發(fā)場景性能，為用戶提供靈活高效的數(shù)據(jù)管理體驗。在該場景下，一般采用多流單流 compaction 方式實現(xiàn)數(shù)據(jù)合并，避免多流 compaction 沖突，優(yōu)化數(shù)據(jù)合并與整理過程，保證數(shù)據(jù)高效存儲與快速訪問。

在 CDC 優(yōu)化方面，CDC 入湖是流式湖倉架構(gòu)關(guān)鍵部分。流式湖倉架構(gòu)中，客戶先將業(yè)務(wù)數(shù)據(jù)同步至騰訊云流式湖倉，CDC 是常用實時數(shù)據(jù)抽取方法，可及時捕捉原系統(tǒng)數(shù)據(jù)變化并傳輸至目標(biāo)系統(tǒng)，保證數(shù)據(jù)實時性與一致性。在 CDC 過程中，提供整庫同步能力，便于客戶遷移數(shù)據(jù)庫數(shù)據(jù)至流式湖倉，系統(tǒng)支持自動表結(jié)構(gòu)變更，簡化了數(shù)據(jù)同步管理操作，用戶可輕松應(yīng)對數(shù)據(jù)庫 schema 調(diào)整。

具體實現(xiàn)中，CDC 采用高效 at-least-once 數(shù)據(jù)同步模式，即便網(wǎng)絡(luò)波動或系統(tǒng)故障，也能確保數(shù)據(jù)至少傳輸一次，避免丟失，通過目標(biāo)端 upsert 功能保證端到端一致性，即數(shù)據(jù)傳輸中重復(fù)時，目標(biāo)端可通過 upsert 操作更新已有數(shù)據(jù)，避免冗余與不一致。

在存量數(shù)據(jù)同步階段，進(jìn)行了顯著優(yōu)化，通過改進(jìn)同步機(jī)制，經(jīng)內(nèi)部性能測試，實現(xiàn)了與開源相比 10 倍以上性能提升，體現(xiàn)在數(shù)據(jù)傳輸速度與系統(tǒng)資源占用上，同步大規(guī)模數(shù)據(jù)時可顯著減少系統(tǒng)延遲與資源占用。

總體而言，CDC 場景優(yōu)化提升了數(shù)據(jù)同步效率與一致性，可為企業(yè)提供可靠的實時數(shù)據(jù)同步解決方案，從而更好地應(yīng)對大規(guī)模數(shù)據(jù)管理與分析需求。

騰訊云流式湖倉的主要優(yōu)勢包括：

其一，統(tǒng)一存儲，可簡化離線與實時兩套鏈路架構(gòu)，打破傳統(tǒng) Lambda 架構(gòu)數(shù)據(jù)存儲壁壘，避免業(yè)務(wù)數(shù)據(jù)重復(fù)存儲與不同引擎計算邏輯重復(fù)開發(fā)，通過統(tǒng)一數(shù)據(jù)存儲與計算引擎可簡化系統(tǒng)運(yùn)維管理，降低運(yùn)維成本。

其二，具有較強(qiáng)的實時處理能力，可生成完整 changelog，使流處理引擎（如 Flink）可對數(shù)據(jù)進(jìn)行增量處理，保證實時數(shù)據(jù)實時性，基于 RSM Tree 引擎支持高效組件更新與部分列更新，以滿足業(yè)務(wù)快速響應(yīng)需求。

其三，數(shù)據(jù)訪問靈活，基于開源 Iceberg 架構(gòu)，與 Iceberg 生態(tài)完全兼容，支持無縫遷移現(xiàn)有 Iceberg 作業(yè)，支持 Spark SQL、Trainer、Presto 等多種查詢引擎，可滿足不同客戶查詢需求。

其四，性能優(yōu)化，對大表數(shù)據(jù)提交流程進(jìn)行了優(yōu)化，提高了寫入速度，采用高效分區(qū)策略，可減少存儲空間，提高查詢性能。

其五，成本低，通過實現(xiàn)存儲與計算引擎統(tǒng)一，可避免數(shù)據(jù)冗余，降低企業(yè)成本。

三、騰訊云流式湖倉實踐

騰訊流式湖倉方案廣泛應(yīng)用于多個行業(yè)與場景，如游戲、出行、教育、電商等。

以游戲行業(yè)為例，可實時采集玩家行為數(shù)據(jù)，反饋給開發(fā)團(tuán)隊，從而快速調(diào)整游戲內(nèi)容、優(yōu)化用戶體驗，通過實時湖倉增量處理數(shù)據(jù)，了解玩家偏好，推出個性化活動與推薦，增強(qiáng)用戶粘性。

出行行業(yè)中，提供實時數(shù)據(jù)分析能力，監(jiān)控交通流量與用戶實時出行需求，動態(tài)調(diào)整車輛分配與路線規(guī)劃，減少等待時間，提升服務(wù)質(zhì)量，通過整合歷史與實時數(shù)據(jù)預(yù)測需求高峰，優(yōu)化調(diào)度資源配置，提升運(yùn)營效率。

教育行業(yè)可在直播場景下跟蹤學(xué)生學(xué)習(xí)進(jìn)度，基于數(shù)據(jù)提供個性化教學(xué)建議。

電商行業(yè)通過流式湖倉幫助商家分析用戶畫像，實時監(jiān)測行為數(shù)據(jù)，調(diào)整推薦算法與營銷策略，快速適應(yīng)市場變化，優(yōu)化促銷活動。

在基于騰訊流式湖倉的游戲行業(yè)實時直播買量數(shù)據(jù)分析場景中，用戶鏈路為通過 Flink 或 Spark 將業(yè)務(wù)數(shù)據(jù)導(dǎo)入騰訊流式湖倉并實時整合。如玩家在游戲直播中點(diǎn)擊、下載等互動行為數(shù)據(jù)與游戲分類等相關(guān)數(shù)據(jù)實時匯總，通過流式湖倉架構(gòu)實時收集并分析。用戶行為數(shù)據(jù)聚合到 ODS 層，小文件合并等治理操作可以保證查詢準(zhǔn)確性與高效性。流式湖倉的每一層可通過 Doris 關(guān)聯(lián)外表進(jìn)行 OLAP 分析，實現(xiàn)數(shù)據(jù)多次復(fù)用，也可通過 DRC、MR 中的 Spark、Presto 等引擎進(jìn)行離線業(yè)務(wù)報表計算。

通過該案例可以展現(xiàn)出騰訊云流式湖倉的諸多優(yōu)勢，如靈活的數(shù)據(jù)寫入與高效管理。直播中用戶互動數(shù)據(jù)以實時或批量方式同步，系統(tǒng)根據(jù)業(yè)務(wù)需求靈活處理不同更新頻率。批量數(shù)據(jù)寫入時，Iceberg 可自動完成小文件合并等優(yōu)化操作，確保系統(tǒng)性能不因小文件過多而下降。還可進(jìn)行實時聚合與多維分析，ODS 層聚合數(shù)據(jù)通過流式湖倉生成 changelog，經(jīng) Flink 進(jìn)一步處理，如游戲直播下載與點(diǎn)擊數(shù)據(jù)與用戶信息、游戲分類等維表關(guān)聯(lián)生成寬表，實現(xiàn)更深入實時分析，監(jiān)控用戶行為趨勢，優(yōu)化廣告投放策略與直播內(nèi)容，同時也可以通過部分列更新能力提高系統(tǒng)效率。此外，多層數(shù)據(jù)復(fù)用與靈活查詢，在流式湖倉架構(gòu)中的每一層可多種方式分析計算，全面復(fù)用鏈路數(shù)據(jù)，如分析直播中歷史行為數(shù)據(jù)，用 Spark 引擎離線處理并決策分析。最后，統(tǒng)一存儲簡化了大數(shù)據(jù)管理，實現(xiàn)了成本控制，游戲行業(yè)需實時響應(yīng)用戶行為與離線分析歷史數(shù)據(jù)，傳統(tǒng)架構(gòu)較為復(fù)雜，而流式湖倉實現(xiàn)了離線與實時鏈路統(tǒng)一，可避免重復(fù)存儲與復(fù)雜系統(tǒng)維護(hù)。

針對車企與出行行業(yè)的車聯(lián)網(wǎng)場景，需要分析運(yùn)行過程中的車機(jī)信號，這些信號由車輛傳感器上報，可能分批次上傳，涉及大量數(shù)據(jù)更新操作。

客戶早期使用傳統(tǒng)架構(gòu)，采用 HBase 加 Hive 鏈路，HBase 用于快速檢索，滿足車輛上報場景下對單輛車特定信號快捷分析需求，但保存數(shù)據(jù)有限，無法長期管理；Hive 用于離線分析，生成全面歷史性報告，但分析延遲高，只能達(dá)到小時級。

客戶痛點(diǎn)為儲存成本高，同一數(shù)據(jù)在 HBase 與 Hive 中重復(fù)存儲，受系統(tǒng)儲存性能限制，成本較高；另外，時效性不夠，基于 Hive 的離線分析在車輛運(yùn)行出現(xiàn)問題需快速了解分析結(jié)果時，延時較高。

引入騰訊云流式湖倉方案后，數(shù)據(jù)采用 Iceburg 統(tǒng)一存儲，既具備傳統(tǒng) HBase 按 key 查詢的能力，又可以滿足實時檢索需求，也可實現(xiàn)離線分析能力，從而降低數(shù)據(jù)儲存成本。流式湖倉還可實現(xiàn)實時增量計算，支持生成 binlog 能力，系統(tǒng)可以捕捉數(shù)據(jù)實時變更，將計算邏輯轉(zhuǎn)換為增量計算，數(shù)據(jù)上報時無需等待批量處理結(jié)束，即可實時計算更新分析結(jié)果，提高分析實時性，在緊急業(yè)務(wù)場景（如故障發(fā)生）下可分鐘級獲取分析結(jié)果，未來有望優(yōu)化至秒級。同時，系統(tǒng)管理優(yōu)化，統(tǒng)一存儲與計算。

四、騰訊云流式湖倉發(fā)展規(guī)劃

最后簡單分享一下后續(xù)發(fā)展規(guī)劃。

騰訊云流式湖倉基于 Iceberg 生態(tài)系統(tǒng)，除了 Iceberg 之外，市面上還有其它一些優(yōu)秀的湖格式。我們后續(xù)會考慮兼容 Paimon，通過 Paimon Adapter 寫入騰訊云流式湖倉中。同時會在稀疏數(shù)據(jù)場景、數(shù)據(jù)提交、合并檢索加速等方面提供額外的優(yōu)勢。

后續(xù)還將支持秒級延遲秒級可見，支持二級索引，并考慮為流式湖倉提供專有 API 與完善的生態(tài)。

五、Q&A

Q1：數(shù)據(jù)存儲問題：車聯(lián)網(wǎng)場景中，熱數(shù)據(jù)和冷數(shù)據(jù)是如何存儲的？

A1：目前均統(tǒng)一存儲在 Iceberg 中。

Q2：鏈路延遲評估：每個階段為保證準(zhǔn)確性，鏈路延遲大概是多少？

A2：具體時間暫無法給出，但在車聯(lián)網(wǎng)客戶使用場景下，相比之前鏈路，延遲性能更優(yōu)。

Q3：并發(fā)度及解決方案：車聯(lián)網(wǎng)或其他場景的并發(fā)度如何？如何解決高并發(fā)場景問題？

A3：高并發(fā)場景下，我們對提交部分進(jìn)行了優(yōu)化。傳統(tǒng) Iceberg 用單節(jié)點(diǎn)生成 snapshot，我們采用兩階段提交流程。多個 bucket 提交時，先并行完成 bucket 元數(shù)據(jù)文件更新與歷史文件合并，生成 bucket 級元數(shù)據(jù)文件，再由全局 global committer 完成快照生成。此設(shè)計在 bucket 數(shù)量較多時可提高寫入性能，避免并發(fā)高導(dǎo)致的 OM 情況。

Q4：計算性能對比：計算過程中，使用 Iceberg 與 Spark 本身計算在性能對比（查詢效率、內(nèi)存使用、CPU 使用等）方面的情況如何？

A4：目前產(chǎn)品處于內(nèi)測與標(biāo)桿客戶落地階段，性能數(shù)據(jù)暫不方便提供。后續(xù)產(chǎn)品上線后，將基于市面上所有湖格式在基礎(chǔ)場景上進(jìn)行全面性能對比，屆時可關(guān)注。

Q5：私有化部署能力：這套能力能否在私有化部署中獲得？

A5：可以。最初在公有云產(chǎn)品上線，已通過客戶落地，后續(xù)計劃將場景下沉到私有化部署中，可實現(xiàn)完整 1:1 對應(yīng)。

Q6：Iceberg 與 Paimon 相關(guān)問題：湖格式中，Iceberg 部分列更新特性及與 Paimon 的對比，以及流式湖倉對 Paimon 的支持計劃如何？

A6：最初選擇 Iceberg 后發(fā)現(xiàn)其部分問題，在現(xiàn)有架構(gòu)中已補(bǔ)齊列更新、檢查、流讀等能力。Paimon 推廣較多，客戶有使用需求，計劃在明年年初或今年年底兼容現(xiàn)有 Paimon 格式，并針對 Paimon 與 Iceberg 后續(xù)發(fā)展進(jìn)行功能更新。