天翼云數(shù)據(jù)湖場目錄面臨的業(yè)務(wù)場景組件選型面臨的挑戰(zhàn)湖倉一體的解決方案未來規(guī)劃當前業(yè)務(wù)現(xiàn)狀0102030405數(shù)據(jù)應(yīng)用很廣，涵蓋實時推薦、日志檢索、

BI報表、計費統(tǒng)計，在線應(yīng)用等。組件眾多(10+)計算：Hive、spark、Flink、Trino...存儲：Rdb、HBase、ClickHouse、Hdfs...業(yè)務(wù)野蠻生長各部門都存在壁壘。趨勢愈演愈烈，對國產(chǎn)軟硬件需求也越來越高。集團內(nèi)省公司比較多、各單位較獨立，公司之間甚至公司業(yè)務(wù)場景比較復雜，比如1M的大SQL，多表

Join,視圖套視圖等。國產(chǎn)化業(yè)務(wù)痛點與訴求易用高效統(tǒng)一安全國產(chǎn)化痛點訴求需要一套集開發(fā)、管理、治理于體一，高效、安全、湖倉統(tǒng)一的數(shù)據(jù)體系。01

數(shù)據(jù)體系煙囪林立、數(shù)據(jù)孤島，不僅存儲成本高、利用價值低。02數(shù)據(jù)查詢效率低，對開發(fā)和運營影響比較大。03

組件眾多、業(yè)務(wù)場景復雜導致使用門檻高。04

國產(chǎn)化進程不高，需要加快比例從10%提高到35%+目錄面臨的業(yè)務(wù)場景組件選型面臨的挑戰(zhàn)湖倉一體的解決方案與架構(gòu)未來規(guī)劃組件選型12Iceberg3CDC01以功能、性能和易用性為始，以業(yè)務(wù)需求為終。02社區(qū)活躍度和開放性。兩大目錄面臨的業(yè)務(wù)場景組件選型面臨的挑戰(zhàn)湖倉一體的解決方案與架構(gòu)未來規(guī)劃面臨的挑戰(zhàn)（一）挑戰(zhàn)一：數(shù)據(jù)安全和國產(chǎn)化要求高業(yè)務(wù)對機器國產(chǎn)化比例要求較高（35%+），這大大提高了D落地的復雜性。業(yè)務(wù)場景因企業(yè)性質(zhì)對組件和數(shù)據(jù)的安全性要求較高。思考：國產(chǎn)化比較核心的問題是軟硬件的兼容性和對引擎的性能影響。兼容性：我們需要對D內(nèi)核在不同芯片中的兼容性進行全面測試與評估。

性能：先進行一輪摸底，然后聯(lián)合芯片提供方結(jié)合硬件和系統(tǒng)的特性進行針對性優(yōu)化（如BitShuffle、壓縮算法、CRC32等）。面臨的挑戰(zhàn)（一）：解決方案與收益效果：百分比1007550250安全性性能優(yōu)化前優(yōu)化后不同SQL的前后耗時對比整體措施：首先搭建一套涵蓋ctyunos(x86)，kunpeng(arm)，海光(x86)等不同架構(gòu)下的自動化CICD流程，用于提高構(gòu)建、發(fā)布的效率。對D在不同架構(gòu)下從兼容性和性能兩個方面進行全面測試和評估，然后進行針對性的優(yōu)化。梳理D的弱密碼和接口的鑒權(quán)的現(xiàn)狀，然后和安全團隊對其進行安全評估，最后根據(jù)改進意見進行安全加固。面臨的挑戰(zhàn)（二）挑戰(zhàn)二：業(yè)務(wù)存在大量離線和實時數(shù)據(jù)的共享共享的數(shù)據(jù)來自不同的數(shù)據(jù)源和不同的集群。數(shù)據(jù)是動態(tài)變化的，面臨隨時更新的可能性。業(yè)務(wù)涉及較多跨庫/跨集群的JOIN、UNION等復雜操作。思考：數(shù)據(jù)共享最直接有效的方案就是采用存算分離的架構(gòu)把數(shù)據(jù)按統(tǒng)一的格式存儲到對象存儲上，但當時Doris存算分離版本（3.0）還未發(fā)布。數(shù)據(jù)同步方案探索：把共享的數(shù)據(jù)同步到有需要的集群中去，于是我們對D的CCR從原理和性能上都進行了深度剖析。性能：Doris的CCR在全量場景是同步表的Snshot，增量場景則表 的Binlog，因此性能上是比較高效的。資源：D的CCR在資源控制和限速上主要依賴的是主同步集群自身的資源管控機制，是一種被動的管控策略，由使用者和數(shù)據(jù)量決定。面臨的挑戰(zhàn)（二）：解決方案與收益整體措施：業(yè)務(wù)層基于D或spark構(gòu)建業(yè)務(wù)的數(shù)據(jù)模型(ODS、DWD、ADS)可以把數(shù)據(jù)存儲到Iceberg中。D多集群在查詢和分析過程中的結(jié)果，按需物化到

Iceberg存儲中。 數(shù)據(jù)應(yīng)用層通過Spark或D的Catalog來使用共享數(shù)據(jù)。共享存儲方案的探索：綜合上面結(jié)論和成本上考慮數(shù)據(jù)同步方案不是最優(yōu)的解，于是探索用存儲共享的方案來實現(xiàn)：經(jīng)過多方面對比和湖倉一體的方面考慮，我們最后決定使用Iceberg作為共享數(shù)據(jù)的存儲介質(zhì)。成果：成功解決某省公司跨集群大查詢的需求，為業(yè)務(wù)割接邁進了一大步面臨的挑戰(zhàn)（三）挑戰(zhàn)三：D如何高效地把數(shù)據(jù)輸出到Iceberg思考：D當時版本還不支持Iceberg的回寫能力（即將上線），但是有HDFS的導出功能，于是我們對D的功能進行了深度的分析，結(jié)論如下：如果采用D的數(shù)據(jù)導出H

D

F

S的能力會存在如下問題：數(shù)據(jù)鏈路相對稍長，資源消耗較高，性能損耗過大。無法內(nèi)部創(chuàng)建庫表，元信息需要借助外部系統(tǒng)獲取。數(shù)據(jù)文件的Commit和導出任務(wù)的事務(wù)脫離很難保證數(shù)據(jù)一致性。面臨的挑戰(zhàn)（三）：重難點分析海量數(shù)據(jù)如何高效的輸出Iceberg本身僅僅是一種開放的表格式標準，它的數(shù)據(jù)是存儲到HDFS或是S3上，為了高效輸出數(shù)據(jù)我們需要考慮并發(fā)寫多個文件。數(shù)據(jù)在拷貝過程中不僅會消耗CPU和IO資源，同時也會給穩(wěn)定性帶來挑戰(zhàn)，因此數(shù)據(jù)流是路徑越短越有利。綜上我們在D中考慮直接在BE端并發(fā)地按Iceberg的格式把數(shù)據(jù)外部存儲系統(tǒng)中?；谏厦娴目紤]，我們需要完善D的數(shù)據(jù)湖能力，研發(fā)D直寫Iceberg的數(shù)據(jù)鏈路面臨的挑戰(zhàn)（三）：解決方案如何保障數(shù)據(jù)的一致性的事務(wù)協(xié)調(diào)，共同保障數(shù)據(jù)的一致性。當前通過并發(fā)的寫多個文件，因此需要一個Coorte來

Merge多個并發(fā)的Commit信息并構(gòu)建Iceberg的Manifest。綜上:Doris的數(shù)據(jù)一致性保障就是在BE端并行寫完數(shù)據(jù)之后，把各個BE寫文件的情況和需要提交的信息Report到FE端，由FE統(tǒng)一進行Manifest的提交，如果其中部分數(shù)據(jù)寫失敗了當前批次數(shù)據(jù)全部不提交，最后清理掉臟文件即可。面臨的挑戰(zhàn)（三）：解決方案如何解決小文件問題因為D是通過BE并行寫多個文件，那么如果并行度過大會生產(chǎn)很多小文件給存儲系統(tǒng)帶來很大負擔，并行度過小性能又較

差，如何才能在保障性能的前提下減少小文件數(shù)？引入了LocalShuffle

的概念。也即是在BE的scan算子和

sink之間加一個數(shù)據(jù)路由算子，用于對數(shù)據(jù)重新shuffle把相同分區(qū)的數(shù)據(jù)路由到同一個instance的同一個thread上，保證每一個BE節(jié)點對同一分區(qū)的數(shù)據(jù)只寫一個文件。這樣寫一批次數(shù)據(jù)，Iceberg側(cè)同一個分區(qū)的文件數(shù)能控制在[1,N]之間（N是

SinkOperator并行度），不僅能保證并行寫文件的性能優(yōu)勢還能減少小文件的數(shù)量。Iceberg側(cè)則采用Amoro

定期進一步去合并小文件的，最大程度去減少Iceberg的文件數(shù)量。面臨的挑戰(zhàn)（三）：解決方案與收益成果：成功解決了省公司跨集群Join/union的性能問題，為業(yè)務(wù)割接鋪平了道路；功能已貢獻給社區(qū)，代碼成功合入Master分支。整體措施：在FE對SQL進行解析并生產(chǎn)相對應(yīng)的執(zhí)行計劃BE端并行讀取D內(nèi)部的或是Catalog外部的數(shù)據(jù)。BE端通過Partitioner算子對數(shù)據(jù)重新路由之后傳送到Sink算子的不同線程中。Sink并行寫多個文件，并把寫文件的情況匯報到FE端去。FE端收集并Merge所有并行Task的Commit信息，然后構(gòu)建

Iceberg的Manifest并提交。面臨的挑戰(zhàn)（四）任務(wù)繁重我們面臨的數(shù)據(jù)任務(wù)數(shù)量龐大(1w+)。原數(shù)據(jù)體系引擎不一致，導致遷移過程中難以準確評估和處理各種差異性。超大SQL單SQL大小高達1M+，系統(tǒng)的處理難度很高。SQL復雜且可讀性差當前業(yè)務(wù)SQL大部分由BI工具自動生成，不僅犧牲了可讀性而且復雜度高，給理解和遷移帶來了困難。海量數(shù)據(jù)與場景多樣化需遷移的數(shù)據(jù)量接近PB級。業(yè)務(wù)場景多，實時推薦、日志檢索、BI報表、計費統(tǒng)計，在線應(yīng)用等。挑戰(zhàn)四：海量數(shù)據(jù)遷移，時間緊、卡點多，遷移難點飆升面臨的挑戰(zhàn)（四）思考：如何評估和解決異構(gòu)引擎給業(yè)務(wù)帶來的影響和風險？在任務(wù)量龐大，SQL復雜性高，場景多的情況下，如何衡量異構(gòu)引擎對現(xiàn)存業(yè)務(wù)的影響范圍？通過窮舉的傳統(tǒng)思路顯然不可靠，工作量不僅繁雜而且很容易出現(xiàn)紕漏導致遷移故障，因此我們需要把業(yè)務(wù)真實跑起來(雙跑)，通過實際結(jié)果來評估功能和性能。

雙跑首先要解決問題是任務(wù)Clone和口徑問題，因此我們通過

SQLGlot封裝了一個自動化SQL轉(zhuǎn)換工具，用于任務(wù)的自動化克隆大大提高遷移的效率。因為庫表數(shù)和數(shù)據(jù)量都很大，那么存量Schema和數(shù)據(jù)遷移也是一個不可忽視的問題。最后經(jīng)過多方面的調(diào)研和考慮發(fā)現(xiàn)X2D

是一款集自動建表和數(shù)據(jù)遷移為一體的高性能工具，高度契合我們需

求。面臨的挑戰(zhàn)（四）：解決方案與收益整體措施：通過自動化手段構(gòu)建一對孿生集群利用業(yè)務(wù)雙跑來驗證引擎的功能和性能。通過自動化工具X2D對存量庫表和數(shù)據(jù)的遷移。居于SQLGlot封裝自動化的SQL轉(zhuǎn)換工具解決任務(wù)克隆的復雜性和效率。定期對兩個集群的schema、數(shù)據(jù)量、任務(wù)耗時進行比對和數(shù)據(jù)抽樣稽查。持續(xù)觀察1個月以上，然后根據(jù)運行情況評估兩個異構(gòu)集群的功能和性能。成果：已經(jīng)幫助用戶成功完成2套集群的遷移，1000+作業(yè)數(shù)，其他集群還在繼續(xù)跟進。目錄面臨的業(yè)務(wù)場景組件選型面臨的挑戰(zhàn)湖倉一體的解決方案未來規(guī)劃湖倉一體架構(gòu)推薦離線：實時：數(shù)據(jù)源

=》

數(shù)據(jù)管道

=》

Spark

=》

Iceberg

=》

數(shù)據(jù)應(yīng)用(Spark查詢)=》

Flink(CDC)

=》

D

=》

數(shù)據(jù)應(yīng)用(D即席查詢)=》

Iceberg(結(jié)果物化/數(shù)據(jù)共享)

=》

數(shù)據(jù)應(yīng)用_x0008_數(shù)據(jù)源

=》

數(shù)據(jù)管道（D/Spark）湖倉一體解決方案

采用湖倉一體架構(gòu)統(tǒng)一各省公司的數(shù)據(jù)體系，打通數(shù)據(jù)孤島建設(shè)集入湖、開發(fā)、管理、治理于一體數(shù)據(jù)平臺。通過FlinkCDC(實時)+Spark(離線)作為數(shù)據(jù)集成工具，統(tǒng)一入湖的數(shù)據(jù)鏈路。使用Doris統(tǒng)一數(shù)據(jù)加工層，實現(xiàn)輕量化的數(shù)據(jù)分析和ETL。通過Doris/Spark來加速數(shù)據(jù)查詢的效率。使用Iceberg作為數(shù)據(jù)湖流批一體的存儲層。安全上對D進行加固，并通過Ranger統(tǒng)一離線和實時的數(shù)據(jù)權(quán)限。

國產(chǎn)化上通過CICD流程構(gòu)建多芯環(huán)境，全面測試和評估兼容性和性能，并結(jié)合硬件特性和系統(tǒng)指令有針對性進行優(yōu)化。接入監(jiān)控和日志系統(tǒng)，通過指