近期，ByteHouse與某數(shù)字娛樂公司達(dá)成合作，雙方聚焦高性能離/在線一體化數(shù)倉展開合作。隨著自身領(lǐng)域迅速發(fā)展的同時，該數(shù)字娛樂公司需要更穩(wěn)定、易用的數(shù)據(jù)基礎(chǔ)服務(wù)，但該方面遇到多種挑戰(zhàn)，如數(shù)據(jù)融合與整合、實(shí)時數(shù)據(jù)分析、可擴(kuò)展性和靈活性、多源數(shù)據(jù)入倉以及復(fù)雜的離線加工任務(wù)等。

作為一款云原生數(shù)據(jù)倉庫，ByteHouse基于ClickHouse技術(shù)路線進(jìn)行優(yōu)化和升級，不僅擁有極致的分析性能、良好的擴(kuò)展能力，而且有豐富的能力支撐ELT作業(yè)，支持fault tolerance、任務(wù)拆分等。

2023年該數(shù)字娛樂公司就引入 ByteHouse 構(gòu)建實(shí)時數(shù)倉服務(wù)，2024年又將離線數(shù)倉遷移至 ByteHouse 上，至此完成了統(tǒng)一的離線/實(shí)時一體化數(shù)倉建設(shè)。通過數(shù)倉一體化升級，大幅提高數(shù)據(jù)分析的實(shí)時性 （天級->分鐘級） ，保證了大數(shù)據(jù)量級下數(shù)據(jù)處理的穩(wěn)定性。

背景和挑戰(zhàn)

數(shù)據(jù)流向圖

如上圖所示，在一體化數(shù)倉改造前，該數(shù)字娛樂公司 的業(yè)務(wù)數(shù)據(jù)庫在 Oracle 和 TiDB 上，使用 Flink 通過 CDC 方案將數(shù)據(jù)同步到數(shù)據(jù)倉庫。導(dǎo)入后會經(jīng)過一系列的離線加工任務(wù)，生成供業(yè)務(wù)讀取的表，最終以報表、看板等形式展示到前端。

原架構(gòu)中離線加工任務(wù)是由 Hive 和 Spark SQL 完成的，只有最終加工得到的數(shù)據(jù)才會存儲在 ByteHouse 中，由 ByteHouse 提供實(shí)時查詢能力。該方案有以下弊端：

1. 架構(gòu)復(fù)雜。用戶需要維護(hù)多套引擎，無論是底層架構(gòu)、運(yùn)維方式、SQL語法還是參數(shù)調(diào)優(yōu)，多套引擎都截然不同。這造成了額外的維護(hù)成本。
2. 數(shù)據(jù)冗余。 從 Hive/Spark SQL 到 ByteHouse 的數(shù)據(jù)同步鏈路需要額外開發(fā)，且數(shù)據(jù)是冗余存儲了多份。無論從計(jì)算，還是存儲方面，都造成了浪費(fèi)。
3. 效率瓶頸。當(dāng)前資源下，該架構(gòu)已經(jīng)達(dá)到了每日多源數(shù)據(jù)融合的瓶頸，很難超過日增10億這個量級。制約了公司業(yè)務(wù)的發(fā)展。

在這種情況下，客戶選擇使用 ByteHouse 構(gòu)建一體化數(shù)倉，無論是 Adhoc 的報表查詢、還是復(fù)雜的離線加工任務(wù)，都在一個系統(tǒng)中完成，減少運(yùn)維、計(jì)算、存儲方面的成本。

技術(shù)挑戰(zhàn)

該數(shù)字娛樂公司 的離線加工場景對 ByteHouse 的能力提出了更高的要求，具體表現(xiàn)在：

• 數(shù)據(jù)量大。 數(shù)據(jù)增量每天10億級別，最大的表10TiB+，數(shù)據(jù)量1000億+。
• 加工鏈路長。 一共200+表，多層加工，任務(wù)依賴比較復(fù)雜，重試成本高。日常加工任務(wù)4-5千個，高峰時每天超過1萬。
• 查詢復(fù)雜。 查詢通常涉及大數(shù)據(jù)量 aggregate、多表 join，容易擠壓資源，造成 OOM、超時等報錯。

解決方案和收益

提升任務(wù)并行度，保障業(yè)務(wù)平穩(wěn)運(yùn)行

傳統(tǒng)架構(gòu)中，之所以要分別建設(shè)離線數(shù)倉和實(shí)時數(shù)倉，是因?yàn)槌Ｒ姷?OLAP 產(chǎn)品不擅長處理大量的復(fù)雜查詢，很容易把內(nèi)容打滿任務(wù)中斷，甚至造成宕機(jī)。

ByteHouse 具備 BSP 模式，支持將查詢切分為不同的 stage，每個 stage 獨(dú)立運(yùn)行。在此基礎(chǔ)上，stage 內(nèi)的數(shù)據(jù)也可以進(jìn)行切分，并行化不再受節(jié)點(diǎn)數(shù)量限制，理論上可以無限擴(kuò)展，從而大幅度降低峰值內(nèi)存。

在實(shí)際應(yīng)用中，通過對關(guān)鍵的大表增加并行度，該數(shù)字娛樂公司 的離線任務(wù)整體內(nèi)存峰值降低了40% 左右。有效減少了內(nèi)存溢出的概率，保障任務(wù)平穩(wěn)運(yùn)行。

任務(wù)級重試，減少重試成本

離線加工任務(wù)的另外一個特點(diǎn)就是鏈路比較長，并且任務(wù)間有依賴關(guān)系。如下圖所示，

如上圖所示，task4 依賴 task1、task2 的完成。如果 task1 失敗發(fā)起重試，會顯示為整個鏈路執(zhí)行失敗。

ByteHouse 增加了任務(wù)級重試能力，在 ByteHouse 中只有運(yùn)行失敗的 task 需要重試。以10月15日到10月17日為例：

總數(shù)及發(fā)生重試的任務(wù)數(shù)以***脫敏展示

可以看到，任務(wù)的成功率在這三天內(nèi)分別提高了6.6%、4.4%和2.9%，整體成功率為100% 。除提高任務(wù)執(zhí)行的成功率外，還能顯著減少重試時間，體現(xiàn)為降低整體的離線任務(wù)執(zhí)行時間。

大批量并行寫入，穩(wěn)且快

該數(shù)字娛樂公司 的業(yè)務(wù)數(shù)據(jù)存在頻繁更新的特點(diǎn)，使用重疊窗口進(jìn)行批量 ETL 操作時，會帶來大量的數(shù)據(jù)更新。在這種場景下，ByteHouse 做了大量的優(yōu)化。

寫入優(yōu)化示意圖

經(jīng)過持續(xù)優(yōu)化，將最耗時的數(shù)據(jù)寫入部分單獨(dú)并行化，并且在寫入 part 文件時標(biāo)記是否需要進(jìn)行后續(xù)的 dedup 作業(yè)。在所有數(shù)據(jù)寫入完畢后，由 server 指定一個 worker 進(jìn)行 dedup 和最后的事務(wù)提交（如上圖最右）。

經(jīng)過優(yōu)化，在保持穩(wěn)定的前提下，用戶十億表的 insert 作業(yè)運(yùn)行時間從48分鐘降低到13分鐘，提速73% 。其他相對較小的表插入效率也提高了26%-44%左右。

簡化數(shù)據(jù)鏈路，提高健壯性

ByteHouse 在傳統(tǒng)的 MPP 鏈路基礎(chǔ)上增加了對復(fù)雜查詢的支持，這使得 join 等操作可以有效地得到執(zhí)行。

在數(shù)據(jù)交換方面，要求所有 stage 之間的依賴必須在查詢執(zhí)行之前以網(wǎng)絡(luò)連接的形式體現(xiàn)。離線加工場景下，這種方式有著天然的劣勢：

• stage 較多、并行度較大時，每一個 task 出現(xiàn)的抖動都會影響整體鏈路，疊加的抖動增加任務(wù)失敗的概率；
• task 同時拉起會進(jìn)一步對資源進(jìn)行擠占。

BSP 模式使用 barrier 將各個 stage 進(jìn)行隔離，每個 stage 獨(dú)立運(yùn)行，stage 之內(nèi)的 task 也相互獨(dú)立。即便機(jī)器環(huán)境發(fā)生變化，對查詢的影響被限定在 task 級別。且每個 task 運(yùn)行完畢后會及時釋放計(jì)算資源，對資源的使用更加充分。

在這個基礎(chǔ)上，BSP 的這種設(shè)計(jì)更利于重試的設(shè)計(jì)。任務(wù)失敗后，只需要重新拉起時讀取它所依賴的任務(wù)的 shuffle 數(shù)據(jù)即可，而無需考慮任務(wù)狀態(tài)。

總結(jié)

所有以上提到的這些優(yōu)化，均建立在ByteHouse提供極速分析性能的基礎(chǔ)上。

在實(shí)時數(shù)倉的能力上，通過疊加對離線數(shù)倉能力的支持，ByteHouse通過將查詢切分為獨(dú)立的階段、階段內(nèi)進(jìn)行并行度的拓展，對大查詢的內(nèi)存降低、任務(wù)的失敗降低、寫入效率和整體魯棒性來說，都有明顯的效果。

這在最終促成了該數(shù)字娛樂公司可以使用ByteHouse一個引擎同時完成數(shù)據(jù)加工和數(shù)據(jù)分析，減少了組件冗余，節(jié)省了人力成本，大大提高了數(shù)據(jù)實(shí)時性、優(yōu)化了運(yùn)營效率。