一、流計(jì)算 Oceanus 介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、騰訊云流式湖倉(cāng)實(shí)踐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、Q&A

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

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

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

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

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

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

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

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

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

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

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

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