前言

當涉及到企業分析場景時，所使用的數據通常源自多樣的業務數據，這些數據系統大多采用以行為主的存儲結構，比如支付交易記錄、用戶購買行為、傳感器報警等。在數倉及分析領域，海量數據則主要采按列的方式儲存。因此，將數據從行級轉換成列級存儲是建立企業數倉的基礎能力。

傳統方式是采用Extract-Transform-Load (ETL)來將業務數據轉換為適合數倉的數據模型，然而，這依賴于獨立于數倉外的ETL系統，因而維護成本較高。但隨著云計算時代的到來，云數據倉庫具備更強擴展性和計算能力，也要求改變傳統的ELT流程。

火山引擎ByteHouse是一款基于開源ClickHouse推出的云原生數據倉庫，為用戶提供極速分析體驗，能夠支撐實時數據分析和海量數據離線分析，同時還具備便捷的彈性擴縮容能力，極致分析性能和豐富的企業級特性。憑借其強大的計算能力，可以全面支持Extract-Load-Transform (ELT)的能力，從而使用戶免于維護多套異構系統。

具體而言，用戶可以將數據導入后，通過自定義的SQL語句，在ByteHouse內部進行數據轉換，而無需依賴獨立的ETL系統及資源。這樣，用戶只需要采用統一的SQL方式來完成數據轉換操作。

在本文中，我們將重點介紹ByteHouse遇到的挑戰，以及如何通過3大能力建設實現完備的ELT能力。

痛點以及挑戰

我們先從一個簡單的SSB(start-schema-benchmark)場景出發， 其中包含：

• 1個事實表: lineorder
• 4個維度表：customer, part, supplier, dwdate

圖片

ssb.png

在SSB的查詢分析中，我們發現大部分的查詢都涉及到事實表和維表的join，因此可以通過Transform的步驟，將事實表“打平”。打平所用到的SQL如下:

insert into ssb_flat 
select * from
lineorder l
join customer c on l.lo_custkey = c.c_custkey
join part p on l.lo_partkey = p.p_partkey
join supplier s on l.lo_suppkey = s.s_suppkey
where l.lo_orderdate = <bizdate>

之后的查詢分析可以通過對ssb_flat 的單表掃描來規避很多join操作，其性能能有顯著提升。這個“打平”的過程，就是“Transform”的一種。實際生產場景中的“Transform”的case會更多也更復雜。但是通過以上這個“打平”的過程，我們可以分析出這類操作在數據庫上的普遍性痛點。

變換操作跟普通查詢相比，有幾個大的區別:

1. 變換操作執行時間久， 整體重試成本高
2. 變換操作沒有返回值，我們只關心他成功或者失敗
3. 變化操作讀寫量大，占用資源

具體來說：

• 首先對于ByteHouse來講，其擅長的臨時查詢時間都在秒級，查詢中間出故障一般都直接返回錯誤，交由上游重試。而在ETL場景下，一個任務如果執行了50分鐘，由于某些原因故障了，重試相當于前50分鐘的資源都被浪費了，顯然不能被接受。
• 其次，由于ETL沒有返回結果，客戶端需要保持一個idle的長鏈接，很有可能由于配置原因超時，同時大量的并發任務也會吃掉正常的鏈接資源。
• 最后，由于ETL任務讀寫量大，多個任務并發的時候，需要考慮到資源的分配，以達到性能和隔離的平衡。

針對這三個痛點，ByteHouse 針對性的設計了三個功能，即長任務管理、異步提交和查詢隊列。

功能一：長任務管理

通常情況下，我們可以用settings max_execution_time 來控制一個查詢的超時時間，ByteHouse提供了事務支持來保障讀寫操作的原子性。

但是并這不足以覆蓋ETL任務的需求。在長時間的任務執行中，更容易遇到系統性故障，如節點OOM等。在這種情況下，由客戶端重試并不是個優雅的方案。

在ByteHouse中，一個SQL查詢會被轉化為一系列的算子。我們希望提升算子的容錯能力以更好的應對長時間查詢下的系統故障。目前的版本中，ByteHouse已經針對聚合，排序，關聯等算子提供了disk spill功能。具體來說，當某個算子無法獲得足夠的內存時，我們允許這個算子將一部分數據緩存在磁盤上，以此在資源緊張的情況下仍能夠完成工作。

例如在排序算子中，我們引入了external merge sort的能力，并通過max_bytes_before_external_sort來控制外部排序能力。在下圖左邊是未開啟spill的排序查詢計劃，右邊是開啟spill的計劃。

組 1.png

可以看到在開啟external sort之后，ByteHouse引入了BufferingToFileTransform，MergingSortedTransform兩個算子。同樣的，ByteHouse里的聚合，關聯算子都做了類似的優化例如grace hash join等。

接下來ByteHouse也打算針對exchange操作，進一步提升shuffle操作的容錯性。

功能二：異步提交能力

面對大量長耗時的ETL任務時，傳統的同步執行的方式需要客戶端等待服務端返回。這樣很容易出現客戶端超時，進而影響后續任務執行的問題。

同時，在這種場景中，用戶并不關心單個任務或請求的相應時間，只期望任務能在特定時間內完成，并對可靠性等要求較高。因此ByteHouse提供了異步提交的任務的能力。

ByteHouse用戶現在可以通過 setting enable_async_execution 來提交一個異步任務。ByteHouse在收到這類任務之后，會返回一個異步任務ID， 例如 ff46fccf-d872-4c68-bdb2-c8c18fc178f5。之后客戶端可以選擇間歇性輪訓來獲得任務的最終狀態。

ByteHouse 提供了 show async status 'ff46fccf-d872-4c68-bdb2-c8c18fc178f5' 的指令來獲得狀態。同時ByteHouse也提供了 kill query 'ff46fccf-d872-4c68-bdb2-c8c18fc178f5'的指令來取消某些異步的查詢。

功能三：查詢隊列

離線加工面對大量請求時，當系統超載，需要一定的排隊機制使query請求掛起，等待集群釋放資源后再進行調度。ByteHouse為此提供了查詢隊列能力。

ByteHouse可以允許用戶從三個維度度來定義一個隊列，即: 隊列大小，總CPU占用率，和總內存占用率。

在ByteHouse中，Resource Manager 組件可以用來監聽各個隊列中的查詢指標，得到隊列的資源使用率。當用戶向一個隊列提交查詢時，如果隊列還未達到上限，ByteHouse會將這個查詢入隊，否則拒絕掉這個查詢。

此后，ByteHouse會時刻檢查隊列的資源利用率，當空閑資源高過某個閥值時，Bytehouse會將等待中的查詢出隊。當某個處于等待期的查詢被取消時，ByteHouse也會將其移出隊列。利用查詢隊列，用戶在編排ETL任務時不用擔心底層資源過載，因此可以更加自由。

之后ByteHouse也在計劃增加優先級隊列功能。屆時，用戶可以為ETL任務和即時查詢創建不同隊列優先級，這樣ELT任務和即時查詢可以跑在同一個計算組中而不會顯著的相互影響。

總結

以上介紹了ByteHouse 在支持ETL能力中的一些技術細節。其中長任務，異步提交已經隊列功能已經在preview版本中上線。接下來，ByteHouse也會繼續擴展ETL能力，包括支持更多的ETL相關的轉換函數、長任務容錯、優先級隊列等。

除了ELT能力之外，火山引擎ByteHouse基于獨家自研的高可用引擎及查詢優化器，可以為企業提供快速、穩定、安全的查詢服務和數據寫入性能。在云原生架構下，火山引擎ByteHouse提供了極致擴展的統一數據分析平臺，具有出色的彈性伸縮和可擴展性，確保資源可以靈活地水平擴展；同時，ByteHouse支持多級資源隔離，為用戶資源提供更安心的安全保障。火山引擎ByteHouse還從業務角度出發提供了完整的運維監控和排障能力，幫助企業實現業務云上托管，降低運維成本。