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

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

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

背景和挑戰(zhàn)

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

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

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

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

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

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

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

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

解決方案和收益

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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