一、流計算 Oceanus 介紹

隨著大數據技術的發展，客戶對實時處理與分析需求日益增長，實時數據分析已成為驅動業務創新、提升競爭力的關鍵要素。傳統批處理方式存在時效性差、數據孤島、難以擴展等問題，因此需要實時計算來彌補。

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

二、騰訊云流式湖倉架構

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

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

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

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

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

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

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

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

此外，Lambda 架構將離線與實時鏈路、存儲及計算引擎隔離，相同數據需多次重復存儲，實時與離線計算邏輯需單獨開發，維護、管理及業務變更成本高，因此需要新的架構來統一實時與離線分析鏈路，降低成本。

基于此，內部調研了社區原生 Iceberg Upsert 表方案，發現其存在一些問題。如 Iceberg 通過 upsert 表寫入數據時，產生的數據是無序的，數據管理面臨挑戰。基于 EQ DELETE 的數據合并機制，在 update 場景下會產生非常大的合并開銷，無法滿足高數據量與擴展性需求。且無法支持點查與部分列更新功能，不能滿足維表 join 和性能優化的需求。同時，該鏈路缺乏生成 binlog 的能力，無法適應流式寫入與流讀場景，限制了其在實時鏈路中的有效性。

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

該方案的優勢包括，可生成完整 binlog，增強對實時數據流支持；LSM Tree 自身的合并特性，可以減少數據合并開銷，提升系統性能；支持部分列更新與點查功能，為后續 state 優化與增量計算方案提供了基礎。

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

從整體架構看，流式湖倉方案基于開源 Iceberg 生態建設，天然支持 Iceberg 兼容能力。如上圖所示，藍框部分為普通 Iceberg 寫入，Flink 寫入數據并生成快照時生成 Iceberg 元數據。

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

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

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

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

支持 pos deletion 合并與更新，優化數據更新性能，系統支持內置與自定義值合并函數，應對不同業務需求，并實現了部分列更新與點查能力，豐富數據鏈路處理能力，滿足復雜場景需求。

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

在 CDC 優化方面，CDC 入湖是流式湖倉架構關鍵部分。流式湖倉架構中，客戶先將業務數據同步至騰訊云流式湖倉，CDC 是常用實時數據抽取方法，可及時捕捉原系統數據變化并傳輸至目標系統，保證數據實時性與一致性。在 CDC 過程中，提供整庫同步能力，便于客戶遷移數據庫數據至流式湖倉，系統支持自動表結構變更，簡化了數據同步管理操作，用戶可輕松應對數據庫 schema 調整。

具體實現中，CDC 采用高效 at-least-once 數據同步模式，即便網絡波動或系統故障，也能確保數據至少傳輸一次，避免丟失，通過目標端 upsert 功能保證端到端一致性，即數據傳輸中重復時，目標端可通過 upsert 操作更新已有數據，避免冗余與不一致。

在存量數據同步階段，進行了顯著優化，通過改進同步機制，經內部性能測試，實現了與開源相比 10 倍以上性能提升，體現在數據傳輸速度與系統資源占用上，同步大規模數據時可顯著減少系統延遲與資源占用。

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

騰訊云流式湖倉的主要優勢包括：

其一，統一存儲，可簡化離線與實時兩套鏈路架構，打破傳統 Lambda 架構數據存儲壁壘，避免業務數據重復存儲與不同引擎計算邏輯重復開發，通過統一數據存儲與計算引擎可簡化系統運維管理，降低運維成本。

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

其三，數據訪問靈活，基于開源 Iceberg 架構，與 Iceberg 生態完全兼容，支持無縫遷移現有 Iceberg 作業，支持 Spark SQL、Trainer、Presto 等多種查詢引擎，可滿足不同客戶查詢需求。

其四，性能優化，對大表數據提交流程進行了優化，提高了寫入速度，采用高效分區策略，可減少存儲空間，提高查詢性能。

其五，成本低，通過實現存儲與計算引擎統一，可避免數據冗余，降低企業成本。

三、騰訊云流式湖倉實踐

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

以游戲行業為例，可實時采集玩家行為數據，反饋給開發團隊，從而快速調整游戲內容、優化用戶體驗，通過實時湖倉增量處理數據，了解玩家偏好，推出個性化活動與推薦，增強用戶粘性。

出行行業中，提供實時數據分析能力，監控交通流量與用戶實時出行需求，動態調整車輛分配與路線規劃，減少等待時間，提升服務質量，通過整合歷史與實時數據預測需求高峰，優化調度資源配置，提升運營效率。

教育行業可在直播場景下跟蹤學生學習進度，基于數據提供個性化教學建議。

電商行業通過流式湖倉幫助商家分析用戶畫像，實時監測行為數據，調整推薦算法與營銷策略，快速適應市場變化，優化促銷活動。

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

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

針對車企與出行行業的車聯網場景，需要分析運行過程中的車機信號，這些信號由車輛傳感器上報，可能分批次上傳，涉及大量數據更新操作。

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

客戶痛點為儲存成本高，同一數據在 HBase 與 Hive 中重復存儲，受系統儲存性能限制，成本較高；另外，時效性不夠，基于 Hive 的離線分析在車輛運行出現問題需快速了解分析結果時，延時較高。

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

四、騰訊云流式湖倉發展規劃

最后簡單分享一下后續發展規劃。

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

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

五、Q&A

Q1：數據存儲問題：車聯網場景中，熱數據和冷數據是如何存儲的？

A1：目前均統一存儲在 Iceberg 中。

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

A2：具體時間暫無法給出，但在車聯網客戶使用場景下，相比之前鏈路，延遲性能更優。

Q3：并發度及解決方案：車聯網或其他場景的并發度如何？如何解決高并發場景問題？

A3：高并發場景下，我們對提交部分進行了優化。傳統 Iceberg 用單節點生成 snapshot，我們采用兩階段提交流程。多個 bucket 提交時，先并行完成 bucket 元數據文件更新與歷史文件合并，生成 bucket 級元數據文件，再由全局 global committer 完成快照生成。此設計在 bucket 數量較多時可提高寫入性能，避免并發高導致的 OM 情況。

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

A4：目前產品處于內測與標桿客戶落地階段，性能數據暫不方便提供。后續產品上線后，將基于市面上所有湖格式在基礎場景上進行全面性能對比，屆時可關注。

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

A5：可以。最初在公有云產品上線，已通過客戶落地，后續計劃將場景下沉到私有化部署中，可實現完整 1:1 對應。

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

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