來源｜ByConity 開源社群
在數據驅動時代，高效的數據處理和分析能力已經成為企業競爭力的關鍵。在實際業務中，使用者會基於不同的產品分異位建即時數倉和離線數倉。其中，即時數倉強調數據能夠快速入庫，且在入庫的第一時間就可以進行分析，低時延的返回分析結果。而離線數倉強調復雜任務能夠穩定的執行完，需要更好的記憶體管理。
ByConity 是字節跳動開源的雲原生資料倉儲，可以滿足使用者的多種數據分析場景。2024 年 8 月，ByConity 增加了 bsp 模式：可以進行 task 級別的容錯；更細粒度的排程；基於資源感知的排程。希望透過 bsp 能力，把數據加工（T）的過程轉移到 ByConity 內部，能夠一站式完成數據接入、加工和分析。
為了讓更多的開發者深入了解並體驗 ByConity bsp 模式的能力，InfoQ 和 ByConity 社群聯合舉辦「ByConity 有獎眾測活動」，邀請廣大開發者參與 ByConity bsp 模式在離線數倉場景的實際測試，透過親身實踐來感受其帶來的高效與便捷。
0 1
ByConity 有獎眾測參與指南
> 活動時間
2024 年 12 月 2 日 - 2024 年 12 月 20 日
> 眾測要求
本次眾測活動共提供兩種測試型別，以滿足不同使用者的需求。
標準測試
測試環境與數據集：社群提供測試環境與測試集，使用者可以在提供好的環境中上手測試。
測試內容：使用小資源跑 TPC-DS 數據集，中間加上一些參數調整。
產出要求：產出對應測試文件並在 InfoQ 寫作社群 + 金塊開發者社群釋出。
進階測試
測吧試環境與數據集 ：使用者使用自有環境 & 自有數據集進行測試。
測試內容 ：100G 以上數據，需要執行 10 分鐘以上的查詢，包含一個以上的 join 或 group by。
產出要求 ：產出對應測試文件並在 InfoQ 寫作社群 + 金塊開發者社群釋出。
> 參與方 式
點選文章最下方「閱讀原文」或者掃碼海報報名二維碼參與，參與標準測試開發者需完成測試並產出測試文章並釋出，參與進階測試開發者需在自有場景成功完成測試，能夠勝任離線數倉的負載，並有對應測試文件產出並釋出。
參與者可添加小助手進答疑群
> 參與獎品
標準測試 ：
完成測試，填寫測試反饋，送社群 T 恤
釋出測試文章，送其他社群精美禮品
羅技（Logitech）藍芽鍵盤（黑色 / 銀色）
ByConity 一周年紀念版 t 恤
ByConity 雙肩包
抖音文創多功能三合一無線充電器
進階測試 ：社群周邊 + 進階測試激勵。
> ELT 任務對系統的要求
整體易擴充套件 ：匯入和轉換通常需要大量的資源，系統需要透過水平擴充套件的方式來滿足數據量的快速增長。
可靠性和容錯能力 ：大量的 job 能有序排程；出現 task 偶然失敗（OOM）、container 失敗時，能夠拉起重試；能處理一定的數據傾斜。
效率 & 效能 ：有效利用多核多機並行能力；數據快速匯入；記憶體使用有效（記憶體管理）；CPU 最佳化（向量化、codegen）。
生態 & 可觀測性 ：可對接多種工具；任務狀態感知；任務進度感知；失敗日誌查詢；有一定視覺化能力。
02
ByConity 對 ELT 能力的最佳化
> 提升任務並列度，保障業務平穩執行
傳統架構中，之所以要分別建設離線數倉和即時數倉，是因為常見的 OLAP 產品不擅長處理大量的復雜查詢，很容易把內容打滿任務中斷，甚至造成宕機。
ByConity 具備 BSP 模式，支持將查詢切分為不同的 stage，每個 stage 獨立執行。在此基礎上，stage 內的數據也可以進行切分，並列化不再受節點數量限制，理論上可以無限擴充套件，從而大振幅降低峰值記憶體。
> 任務級重試，減少重試成本
離線加工任務的另外一個特點就是鏈路比較長，並且任務間有依賴關系。如下圖所示，
如上圖所示，task4 依賴 task1、task2 的完成。如果 task1 失敗發起重試，會顯示為整個鏈路執行失敗。 ByConity 增加了任務級重試能力，在 ByConity 中只有執行失敗的 task 需要重試。
> 大批次並列寫入，穩且快
即時數倉存在頻繁更新的特點，使用重疊視窗進行批次 ETL 操作時，會帶來大量的數據更新。在這種場景下， ByConity 做了大量的最佳化。
（寫入最佳化示意圖）
經過持續最佳化，將最耗時的數據寫入部份單獨並列化，並且在寫入 part 檔時標記是否需要進行後續的 dedup 作業。在所有數據寫入完畢後，由 server 指定一個 worker 進行 dedup 和最後的事務送出（如上圖最右）。
> 簡化數據鏈路，提高健壯性
ByConity 在傳統的 MPP 鏈路基礎上增加了對復雜查詢的支持，這使得 join 等操作可以有效地得到執行。在數據交換方面，要求所有 stage 之間的依賴必須在查詢執行之前以網路連線的形式體現。離線加工場景下，這種方式有著天然的劣勢：
stage 較多、並列度較大時，每一個 task 出現的抖動都會影響整體鏈路，疊加的抖動增加任務失敗的機率；
task 同時拉起會進一步對資源進行擠占。
BSP 模式使用 barrier 將各個 stage 進行隔離，每個 stage 獨立執行，stage 之內的 task 也相互獨立。即便機器環境發生變化，對查詢的影響被限定在 task 級別。且每個 task 執行完畢後會及時釋放計算資源，對資源的使用更加充分。
在這個基礎上，BSP 的這種設計更利於重試的設計。任務失敗後，只需要重新拉起時讀取它所依賴的任務的 shuffle 數據即可，而無需考慮任務狀態。
期待開發者持續關註 ByConity，同 ByConity 一起開啟開啟資料倉儲的新篇章。
