隨著數據的應用場景越來越豐富，企業對數據價值反饋到業務中的時效性要求也越來越高，很早就有人提出過一個概念：數據的價值在于數據的在線化。實時計算起源于對數據加工時效性的嚴苛需求：數據的業務價值隨著時間的流逝會迅速降低，因此在數據產生后必須盡快對其進行計算和處理，從而最大效率實現數據價值轉化，對實時數倉的建設需求自然而然的誕生了。而建設好實時數倉需要解決如下幾個問題：

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

二、高效數據集成：流式數據的集成必須方便高效，要求能進行高并發、大數據量的寫入；

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

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

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

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

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

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

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

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

ByteHouse 可以滿足企業級用戶的多種分析需求，包括 OLAP 多維分析、定制報表、實時數據分析和 Ad-hoc 數據分析等各種應用場景。

ByteHouse 優勢一：實時數據高吞吐的接入能力

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

數據接入高吞吐性，支持了多線消費 Kafka topic 對應 Partition 的數據，滿足大數據量實時數據接入的需求。

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

數據接入原子性，引擎自行管理 Kafka offset ，將 offset 和 parts 進行綁定在一起，來實現單批次消費寫入的原子性，當中途消費寫入失敗，會自動將綁定的 parts 撤銷，從而實現數據消費的穩定性。

具體流程原理如下圖所示

ByteHouse 優勢二：基于主鍵高頻數據更新能力

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

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

? 第二個場景和第一類比較類似，業務希望把TP數據庫的表實時同步到 ByteHouse，然后借助 ByteHouse 強大的分析能力進行實時分析，這就需要支持實時的更新和刪除。

? 最后一類場景的數據雖然不存在更新，但需要去重。大家知道在開發實時數據的時候，很難保證數據流里沒有重復數據，因此通常需要存儲系統支持數據的冪等寫入。

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

通過定義 Unique Key 唯一鍵，來提供數據實時更新的語義，唯一鍵的選擇支持多字段和表達式的模式；

支持分區級別數據唯一和表級別數據唯一兩種模式；

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

具體流程原理如下圖所示

具體的原理細節可查閱之前發布的文章 干貨 | ClickHouse增強計劃之“Upsert”

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

在構建實時數據分析的場景中，我們常在數據加工的過程中，將多張表通過一些關聯字段打平成一張寬表，通過一張表對外提供分析能力，即大寬表模型。其實大寬表依然有它的局限性，一是，生成每一張大寬表都需要數據開發人員不小的工作量，而且生成過程也需要一定的時間；二是，生成寬表會產生大量的數據冗余。針對寬表模型的局限性，我們從0到1自研實現了查詢優化器，非常好的支持復雜查詢的需求，有如下特性：

兼容兩種 SQL 語法，支持 ANSI SQL 和原生 CLICKHOUSE SQL ;

支持基于RBO優化能力，即支持：列裁剪、分區裁剪、表達式簡化、子查詢解關聯、謂詞下推、冗余算子消除、Outer-JOIN 轉 INNER-JOIN、算子下推存儲、分布式算子拆分等常見的啟發式優化能力；

支持基于 CBO 優化能力，基于 Cascade 搜索框架，實現了高效的 Join 枚舉算法，以及基于 Histogram 的代價估算，對 10 表全連接級別規模的 Join Reorder 問題，能夠全量枚舉并尋求最優解，同時針對大于10表規模的 Join Reorder 支持啟發式枚舉并尋求最優解。CBO 支持基于規則擴展搜索空間，除了常見的 Join Reorder 問題以外，還支持 Outer-Join/Join Reorder，Magic Set Placement 等相關優化能力；

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

高階優化能力，實現了 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 已經在火山引擎上全面對外服務，并且提供各種版本以滿足不同類型用戶的需求。

審核編輯 ：李倩