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

一、穩(wěn)定性：實時數(shù)倉對數(shù)據(jù)的實時處理必須是可靠的、穩(wěn)定的；

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

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

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

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

針對以上問題，火山引擎不斷在業(yè)務中摸索，總結了基于 ByteHouse 建設實時數(shù)倉的經(jīng)驗。

選擇ByteHouse構建實時數(shù)倉的原因

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

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

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

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

ByteHouse 優(yōu)勢一：實時數(shù)據(jù)高吞吐的接入能力

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

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

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

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

具體流程原理如下圖所示

ByteHouse 優(yōu)勢二：基于主鍵高頻數(shù)據(jù)更新能力

隨著實時數(shù)據(jù)分析場景的發(fā)展，對實時數(shù)據(jù)更新的分析需求也越來越多，比如在如下的業(yè)務場景就需要實時更新數(shù)據(jù)能力：

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

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

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

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

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

支持分區(qū)級別數(shù)據(jù)唯一和表級別數(shù)據(jù)唯一兩種模式；

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

具體流程原理如下圖所示

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

ByteHouse 優(yōu)勢三：多表 Join 查詢能力

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

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

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

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

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

高階優(yōu)化能力，實現(xiàn)了 Dynamic Filter pushdown、單表物化視圖改寫、基于代價的 CTE （公共表達式共享）。

具體的原理細節(jié)可查閱之前發(fā)布的文章 干貨 | ClickHouse增強計劃之“查詢優(yōu)化器”

實時數(shù)倉建設方案

借助Flink 出色流批一體的能力，ByteHouse極致的查詢性能，為用戶構建實時數(shù)倉，滿足業(yè)務實時分析需求。

Flink 作為流式數(shù)據(jù)處理引擎，使用Flink SQL為整個實時數(shù)倉數(shù)據(jù)提供數(shù)據(jù)轉化與清洗；

Kafka作為流式數(shù)據(jù)臨時存儲層，同時為Flink SQL 數(shù)據(jù)轉化與清洗提供緩沖作用，提高數(shù)據(jù)穩(wěn)定性；

ByteHouse 作為流式數(shù)據(jù)持久化存儲層，使用 ByteHouse HaKafka 、HaUniqueMergeTree 表引擎可將 Kafka 臨時數(shù)據(jù)高效穩(wěn)定接入儲存到 ByteHouse ，為后端應用提供極速統(tǒng)一的數(shù)據(jù)集市查詢服務。具體的數(shù)據(jù)鏈路如下圖所示

實時數(shù)倉各邏輯層功能職責如下：

ODS 層（Operational Data Store）

把生產(chǎn)系統(tǒng)的數(shù)據(jù)導入消息隊列，原則上不做任何清洗操作，字段信息跟數(shù)據(jù)源保持一致。目的是為了對數(shù)據(jù)源做收斂管理，數(shù)據(jù)排查上也好做溯源回查。

DWD 層（Data Warehouse Detail）

DWD 層采用維度建模理論，針對業(yè)務內(nèi)容梳理業(yè)務實體的維表信息和事實表信息，設計 DWD 明細寬表模型，根據(jù)設計好的邏輯模型對 ODS 層的數(shù)據(jù)進行數(shù)據(jù)清洗，重定義和整合，整合主要包含多流 join 和維度擴充兩部分內(nèi)容， 建設能表達該業(yè)務主題下具體業(yè)務過程的多維明細寬表流。每一份 DWD 表從業(yè)務梳理->模型設計->數(shù)據(jù)流圖->任務開發(fā)鏈接->數(shù)據(jù)校驗結果->數(shù)據(jù)落地信息->常用使用場景歸納。

DWS 層（Data Warehouse Summary）

該層級主要在 DWD 層明細數(shù)據(jù)的基礎上針對業(yè)務實體跨業(yè)務主題域建設匯總指標，根據(jù)統(tǒng)計場景，設計匯總指標模型。

APP 層（Application）

作為對接具體應用的數(shù)倉層級，由 ByteHouse 提供統(tǒng)一的數(shù)據(jù)服務，是基于 DWD 和 DWS 層對外提供一些定制化實時流。

ByteHouse 已經(jīng)在火山引擎上全面對外服務，并且提供各種版本以滿足不同類型用戶的需求。

審核編輯 ：李倩