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

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

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

背景和挑戰

數據流向圖

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

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

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

在這種情況下，客戶選擇使用 ByteHouse 構建一體化數倉，無論是 Adhoc 的報表查詢、還是復雜的離線加工任務，都在一個系統中完成，減少運維、計算、存儲方面的成本。

技術挑戰

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

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

解決方案和收益

提升任務并行度，保障業務平穩運行

傳統架構中，之所以要分別建設離線數倉和實時數倉，是因為常見的 OLAP 產品不擅長處理大量的復雜查詢，很容易把內容打滿任務中斷，甚至造成宕機。

ByteHouse 具備 BSP 模式，支持將查詢切分為不同的 stage，每個 stage 獨立運行。在此基礎上，stage 內的數據也可以進行切分，并行化不再受節點數量限制，理論上可以無限擴展，從而大幅度降低峰值內存。

在實際應用中，通過對關鍵的大表增加并行度，該數字娛樂公司 的離線任務整體內存峰值降低了40% 左右。有效減少了內存溢出的概率，保障任務平穩運行。

任務級重試，減少重試成本

離線加工任務的另外一個特點就是鏈路比較長，并且任務間有依賴關系。如下圖所示，

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

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

總數及發生重試的任務數以***脫敏展示

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

大批量并行寫入，穩且快

該數字娛樂公司 的業務數據存在頻繁更新的特點，使用重疊窗口進行批量 ETL 操作時，會帶來大量的數據更新。在這種場景下，ByteHouse 做了大量的優化。

寫入優化示意圖

經過持續優化，將最耗時的數據寫入部分單獨并行化，并且在寫入 part 文件時標記是否需要進行后續的 dedup 作業。在所有數據寫入完畢后，由 server 指定一個 worker 進行 dedup 和最后的事務提交（如上圖最右）。

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

簡化數據鏈路，提高健壯性

ByteHouse 在傳統的 MPP 鏈路基礎上增加了對復雜查詢的支持，這使得 join 等操作可以有效地得到執行。

在數據交換方面，要求所有 stage 之間的依賴必須在查詢執行之前以網絡連接的形式體現。離線加工場景下，這種方式有著天然的劣勢：

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

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

在這個基礎上，BSP 的這種設計更利于重試的設計。任務失敗后，只需要重新拉起時讀取它所依賴的任務的 shuffle 數據即可，而無需考慮任務狀態。

總結

所有以上提到的這些優化，均建立在ByteHouse提供極速分析性能的基礎上。

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

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