更多技術交流、求職機會，歡迎關注位元組跳動資料平臺微信公眾號，回覆【1】進入官方交流群

隨著資料的應用場景越來越豐富，企業對資料價值反饋到業務中的時效性要求也越來越高，很早就有人提出過一個概念：

資料的價值在於資料的線上化。實時計算起源於對資料加工時效性的嚴苛需求：資料的業務價值隨著時間的流逝會迅速降低，因此在資料產生後必須儘快對其進行計算和處理，從而最大效率實現資料價值轉化，對實時數倉的建設需求自然而然的誕生了。而建設好實時數倉需要解決如下幾個問題：

一、穩定性：實時數倉對資料的實時處理必須是可靠的、穩定的；

二、高效資料整合：流式資料的整合必須方便高效，要求能進行高並行、巨量資料量的寫入；

三、極致效能要求：實時數倉不能僅限於簡單查詢，需要支援複雜計算能力，且計算結果可秒級返回；

四、靈活查詢：需要具備自助分析的能力，為業務分析提供靈活的、自助式的彙總和明細查詢服務；

五、彈性擴縮：需要具備良好的擴充套件性， 必須架構統一具備擴充套件性，可為 IT 建設提供靈活性。

 

針對以上問題，火山引擎不斷在業務中摸索，總結了基於 ByteHouse 建設實時數倉的經驗。

選擇 ByteHouse 構建實時數倉的原因

ByteHouse 是火山引擎在 ClickHouse 的基礎上自研並大規模實踐的一款高效能、高可用企業級分析性資料庫，支援使用者互動式分析 PB 級別資料。其自研的表引擎，靈活支援各類資料分析和保證實時資料高效落盤，實現了熱資料按生命周自動冷存，緩解儲存空間壓力；同時引擎內建了圖形化運維介面，可輕鬆對叢集服務狀態進行運維；整體架構採用多主對等架構設計，架構安全可靠穩定，可確保單點無故障瓶頸。

ByteHouse 的架構簡潔，採用了全面向量化引擎，並配備全新設計的優化器，查詢速度有數量級提升（尤其是多表關聯查詢）。

使用者使用 ByteHouse 可以靈活構建包括大寬表、星型模型、雪花模型在內的各類模型。

ByteHouse 可以滿足企業級使用者的多種分析需求，包括 OLAP 多維分析、客製化報表、實時資料分析和 Ad-hoc 資料分析等各種應用場景。

ByteHouse 優勢一：實時資料高吞吐的接入能力

面對業務巨量資料量的產生，需要高效可靠實時資料的接入能力，為此我們自研了 Kafka 資料來源接入表引擎 HaKafka ，該表引擎可高效的將 Kafka 的資料接入 ByteHouse ，具有有如下特性：

1. 資料接入高吞吐性，支援了多線消費 Kafka topic 對應 Partition 的資料，滿足巨量資料量實時資料接入的需求。

2. 資料接入高可靠性，通過 Zookeeper 來實現主備消費節點管理，比如，當線上出現某個節點出現故障或無法提供服務時，可以通過 Zookeeper 心跳感知機制自動切換到另一個節點提供服務，以此來保障業務的穩定性。

3. 資料接入原子性，引擎自行管理 Kafka offset ，將 offset 和 parts 進行繫結在一起，來實現單批次消費寫入的原子性，當中途消費寫入失敗，會自動將繫結的 parts 復原，從而實現資料消費的穩定性。

 

具體流程原理如下圖所示

ByteHouse 優勢二：基於主鍵高頻資料更新能力

隨著實時資料分析場景的發展，對實時資料更新的分析需求也越來越多，比如在如下的業務場景就需要實時更新資料能力：

• 第一類是業務需要對它的交易類資料進行實時分析，需要把資料流同步到 ByteHouse 這類 OLAP 資料庫中。大家知道，業務資料諸如訂單資料天生是存在更新的，所以需要 OLAP 資料庫去支援實時更新。

• 第二個場景和第一類比較類似，業務希望把 TP 資料庫的表實時同步到 ByteHouse，然後藉助 ByteHouse 強大的分析能力進行實時分析，這就需要支援實時的更新和刪除。

• 最後一類場景的資料雖然不存在更新，但需要去重。大家知道在開發實時資料的時候，很難保證資料流裡沒有重複資料，因此通常需要儲存系統支援資料的冪等寫入。

 

基於以上業務場景的需求，我們自研了基於主鍵更新資料的表引擎 HaUniqueMergeTree，該表引擎即滿足高效查詢效能要求，又支援基於主鍵更新資料的表引擎，有如下特性：

1. 通過定義 Unique Key 唯一鍵，來提供資料實時更新的語意，唯一鍵的選擇支援多欄位和表示式的模式；

2. 支援分割區級別資料唯一和表級別資料唯一兩種模式；

3. 支援多副本高可靠部署，實測資料去重寫入吞吐達每秒 10 萬行以上（10w+/s），很好的解決了社群版 ReplacingMergreTree 不能高效更新資料的痛點。

 

具體流程原理如下圖所示

具體的原理細節可查閱之前釋出的文章 乾貨 | ClickHouse增強計劃之「Upsert」

ByteHouse 優勢三：多表 Join 查詢能力

在構建實時資料分析的場景中，我們常在資料加工的過程中，將多張表通過一些關聯欄位打平成一張寬表，通過一張表對外提供分析能力，即大寬表模型。其實大寬表依然有它的侷限性，一是，生成每一張大寬表都需要資料開發人員不小的工作量，而且生成過程也需要一定的時間；二是，生成寬表會產生大量的資料冗餘。

 

針對寬表模型的侷限性，我們從 0 到 1 自研實現了查詢優化器，非常好的支援複雜查詢的需求，有如下特性：

1. 相容兩種 SQL 語法，支援 ANSI SQL 和原生 CLICKHOUSE SQL ;

2. 支援基於 RBO 優化能力，即支援：列裁剪、分割區裁剪、表示式簡化、子查詢解關聯、謂詞下推、冗餘運算元消除、Outer-JOIN 轉 INNER-JOIN、運算元下推儲存、分散式運算元拆分等常見的啟發式優化能力；

3. 支援基於 CBO 優化能力，基於 Cascade 搜尋方塊架，實現了高效的 Join 列舉演演算法，以及基於 Histogram 的代價估算，對 10 表全連線級別規模的 Join Reorder 問題，能夠全量列舉並尋求最優解，同時針對大於 10 表規模的 Join Reorder 支援啟發式列舉並尋求最優解。CBO 支援基於規則擴充套件搜尋空間，除了常見的 Join Reorder 問題以外，還支援 Outer-Join/Join Reorder，Magic Set Placement 等相關優化能力；

4. 分散式計劃優化，面向分散式 MPP 資料庫，生成分散式查詢計劃，並且和 CBO 結合在一起。相對業界主流實現：分為兩個階段，首先尋求最優的單機版計劃，然後將其分散式化。我們的方案則是將這兩個階段融合在一起，在整個 CBO 尋求最優解的過程中，會結合分散式計劃的訴求，從代價的角度選擇最優的分散式計劃。對於 Join/Aggregate 的還支援 Partition 屬性展開。

5. 高階優化能力，實現了 Dynamic Filter pushdown、單表物化檢視改寫、基於代價的 CTE （公共表示式共用）。

具體的原理細節可查閱之前釋出的文章 乾貨 | ClickHouse增強計劃之「查詢優化器」

實時數倉建設方案

藉助 Flink 出色流批一體的能力，ByteHouse 極致的查詢效能，為使用者構建實時數倉，滿足業務實時分析需求。

Flink 作為流式資料處理引擎，使用 Flink SQL 為整個實時數倉資料提供資料轉化與清洗；

Kafka 作為流式資料臨時儲存層，同時為 Flink SQL 資料轉化與清洗提供緩衝作用，提高資料穩定性；

ByteHouse 作為流式資料持久化儲存層，使用 ByteHouse HaKafka 、HaUniqueMergeTree 表引擎可將 Kafka 臨時資料高效穩定接入儲存到 ByteHouse ，為後端應用提供極速統一的資料市集查詢服務。具體的資料鏈路如下圖所示

實時數倉各邏輯層功能職責如下：

ODS 層（Operational Data Store）

把生產系統的資料匯入訊息佇列，原則上不做任何清洗操作，欄位資訊跟資料來源保持一致。目的是為了對資料來源做收斂管理，資料排查上也好做溯源回查。

DWD 層（Data Warehouse Detail）

DWD 層採用維度建模理論，針對業務內容梳理業務實體的維表資訊和事實表資訊，設計 DWD 明細寬表模型，根據設計好的邏輯模型對 ODS 層的資料進行資料淨化，重定義和整合，整合主要包含多流 join 和維度擴充兩部分內容， 建設能表達該業務主題下具體業務過程的多維明細寬表流。每一份 DWD 表從業務梳理->模型設計->資料流圖->任務開發連結->資料校驗結果->資料落地資訊->常用使用場景歸納。

DWS 層（Data Warehouse Summary）

該層級主要在 DWD 層明細資料的基礎上針對業務實體跨業務主題域建設彙總指標，根據統計場景，設計彙總指標模型。

APP 層（Application）

作為對接具體應用的數倉層級，由 ByteHouse 提供統一的資料服務，是基於 DWD 和 DWS 層對外提供一些客製化化實時流。

 

點選跳轉 ByteHouse雲原生資料倉儲 瞭解更多