相信大家都對大名鼎鼎的ClickHouse有一定的了解了，它強(qiáng)大的數(shù)據(jù)分析性能讓人印象深刻。但在字節(jié)大量生產(chǎn)使用中，發(fā)現(xiàn)了ClickHouse依然存在了一定的限制。例如：

? 缺少完整的upsert和delete操作

? 多表關(guān)聯(lián)查詢能力弱

? 集群規(guī)模較大時(shí)可用性下降（對字節(jié)尤其如此）

? 沒有資源隔離能力

因此，我們決定將ClickHouse能力進(jìn)行全方位加強(qiáng)，打造一款更強(qiáng)大的數(shù)據(jù)分析平臺。后面我們將從五個(gè)方面來和大家分享，此前為大家介紹了字節(jié)是如何為ClickHouse補(bǔ)全更新刪除能力的，本篇將詳細(xì)介紹我們是如何加強(qiáng)ClickHouse多表關(guān)聯(lián)查詢能力。

大寬表的局限

數(shù)據(jù)分析的發(fā)展歷程，可以看作是不斷追求分析效率和分析靈活的過程。分析效率是非常重要的，但是并不是需要無限提升的。1秒返回結(jié)果和1分鐘返回結(jié)果的體驗(yàn)是天壤之別，但是0.1秒返回結(jié)果和1秒返回結(jié)果的差距就沒那么大了。因此，在滿足了一定時(shí)效的情況下，分析的靈活性就顯得額外重要了。

起初，數(shù)據(jù)分析都采用了固定報(bào)表的形式，格式更新頻率低，依賴定制化的開發(fā)，查詢邏輯是寫死的。對于業(yè)務(wù)和數(shù)據(jù)需求相對穩(wěn)定、不會頻繁變化的場景來說固定報(bào)表確實(shí)就足夠了，但是以如今的視角來看，完全固定的查詢邏輯不能充分發(fā)揮數(shù)據(jù)的價(jià)值，只有通過靈活的數(shù)據(jù)分析，才能幫助業(yè)務(wù)人員化被動為主動，探索各數(shù)據(jù)間的相關(guān)關(guān)系，快速找到問題背后的原因，極大地提升工作效率。。

后面，基于預(yù)計(jì)算思想的cube建模方案被提出。通過將數(shù)據(jù)ETL加工后存儲在cube中，保證領(lǐng)導(dǎo)和業(yè)務(wù)人員能夠快速得到分析結(jié)果基礎(chǔ)上，獲得了一定的分析靈活性。不過由于維度固定，以及數(shù)據(jù)聚合后基本無法查詢明細(xì)數(shù)據(jù)，依然無法滿足Adhoc這類即席查詢的場景需求。

近些年，以ClickHouse為代表的具備強(qiáng)大單表性能的查詢引擎，帶來了大寬表分析的風(fēng)潮。所謂的大寬表，就是在數(shù)據(jù)加工的過程中，將多張表通過一些關(guān)聯(lián)字段打平成一張寬表，通過一張表對外提供分析能力?；贑lickHouse單表性能支撐的大寬表模式，既能提升分析時(shí)效性又能提高數(shù)據(jù)查詢和分析操作的靈活性，是目前非常流行的一種模式。

然而大寬表依然有它的局限性，具體有：

? 生成每一張大寬表都需要數(shù)據(jù)開發(fā)人員不小的工作量，而且生成過程也需要一定的時(shí)間

? 生成寬表會產(chǎn)生大量的數(shù)據(jù)冗余

剛才有提到，數(shù)據(jù)分析的發(fā)展歷程可以看作是不斷追求分析效率和分析靈活的過程，那么大寬表的下一個(gè)階段呢？如果ClickHouse的多表關(guān)聯(lián)查詢能力足夠強(qiáng)，是不是連“將數(shù)據(jù)打平成寬表”這個(gè)步驟也可以省略，只需要維護(hù)好對外服務(wù)的接口，任何業(yè)務(wù)人員的需求都現(xiàn)場直接關(guān)聯(lián)查詢就可以了呢？

ByteHouse是如何強(qiáng)化多表關(guān)聯(lián)查詢能力的？

ClickHouse 的執(zhí)行模式相對比較簡單，其基本查詢模式分為 2 個(gè)階段：

ByteHouse 進(jìn)行多表關(guān)聯(lián)的復(fù)雜查詢時(shí)，采用分 Stage 的方式，替換目前 ClickHouse的2階段執(zhí)行方式。將一個(gè)復(fù)雜的 Query 按照數(shù)據(jù)交換情況切分成多個(gè) Stage，Stage 和 Stage 之間通過 exchange 完成數(shù)據(jù)的交換，單個(gè) Stage 內(nèi)不存在數(shù)據(jù)交換。Stage 間的數(shù)據(jù)交換主要有以下三種形式：

? 按照單（多）個(gè) key 進(jìn)行 Shuffle

? 由 1 個(gè)或者多個(gè)節(jié)點(diǎn)匯聚到一個(gè)節(jié)點(diǎn) (我們稱為 gather)

? 同一份數(shù)據(jù)復(fù)制到多個(gè)節(jié)點(diǎn)(也稱為 broadcast 或者說廣播)

單個(gè) Stage 執(zhí)行會繼續(xù)復(fù)用 ClickHouse 的底層的執(zhí)行方式。

按照不同的功能切分不同的模塊，設(shè)計(jì)目標(biāo)如下：

各個(gè)模塊約定好接口，盡量減少彼此的依賴和耦合。一旦某個(gè)模塊有變動不會影響別的模塊，例如 Stage 生成邏輯的調(diào)整不影響調(diào)度的邏輯。

模塊采用插件的架構(gòu)，允許模塊根據(jù)配置靈活支持不同的策略。

根據(jù)數(shù)據(jù)的規(guī)模和分布，ByteHouse支持了多種關(guān)聯(lián)查詢的實(shí)現(xiàn)，目前已經(jīng)支持的有：

Shuffle Join，最通用的 Join

Broadcast Join，針對大表 Join 小表的場景，通過把右表廣播到左表的所有 worker 節(jié)點(diǎn)來減少左表的傳輸

Colocate Join，針對左右表按照 Join key 保持相通分布的場景，減少左右表數(shù)據(jù)傳輸

Join 算子通常是 OLAP 引擎中最耗時(shí)的算子。如果想優(yōu)化 Join 算子，可以有兩種思路，一方面可以提升 Join 算子的性能，例如更好的 Hash Table 實(shí)現(xiàn)和 Hash 算法，以及更好的并行。另一方面可以盡可能減少參與 Join 計(jì)算的數(shù)據(jù)。

Runtime Filter 在一些場景特別是事實(shí)表 join 維度表的星型模型場景下會有比較大的效果。因?yàn)檫@種情況下通常事實(shí)表規(guī)模比較大，而大部分過濾條件都在維度表上，事實(shí)表可能要全量 join 維度表。Runtime Filter 的作用是通過在 Join 的 probe 端（就是左表）提前過濾掉那些不會命中 Join 的輸入數(shù)據(jù)來大幅減少 Join 中的數(shù)據(jù)傳輸和計(jì)算，從而減少整體的執(zhí)行時(shí)間。以下圖為例，

改善后的效果

以SSB 100G測試集為例，不把數(shù)據(jù)打成大寬表的情況下，分別使用 ClickHouse 22.2.3.1版本和ByteHouse 2.0.1版本，在相同硬件環(huán)境下進(jìn)行測試。（無數(shù)據(jù)表示無法返回結(jié)果或超過60s）

可以看到大多數(shù)測試中，ClickHouse都會發(fā)生報(bào)錯無法返回結(jié)果的情況，而ByteHouse能夠穩(wěn)定的在1s內(nèi)跑出結(jié)果。

只看SSB的多表測試有些抽象，下面從兩個(gè)具體的case來看一下優(yōu)化后的效果:。

Case1：Hash Join 右表為大表

經(jīng)過優(yōu)化后，query 執(zhí)行時(shí)間從17.210s降低至1.749s。

lineorder 是一張大表，通過 shuffle 可以將大表數(shù)據(jù)按照 join key shuffle 到每個(gè) worker 節(jié)點(diǎn)，減少了右表構(gòu)建的壓力。

SELECT
sum(LO_REVENUE)-sum(LO_SUPPLYCOST)ASprofit
FROM
customer
INNERJOIN
(
SELECT
LO_REVENUE,
LO_SUPPLYCOST,
LO_CUSTKEY
from
lineorder
WHEREtoYear(LO_ORDERDATE)=1997andtoMonth(LO_ORDERDATE)=1
)aslineorder
ONLO_CUSTKEY=C_CUSTKEY
WHEREC_REGION='AMERICA'

Case 2：5張表 Join（未開啟runtime filter）

經(jīng)優(yōu)化后，query 執(zhí)行時(shí)間從8.583s降低至4.464s。

所有的右表可同時(shí)開始數(shù)據(jù)讀取和構(gòu)建。為了和現(xiàn)有模式做對比，ByteHouse這里并沒有開啟 runtime filter，開啟 runtime filter 后效果會更快。

SELECT
D_YEAR,
S_CITY,
P_BRAND,
sum(LO_REVENUE)-sum(LO_SUPPLYCOST)ASprofit
FROMssb1000.lineorder
INNERJOIN
(
SELECTC_CUSTKEY
FROMssb1000.customer
WHEREC_REGION='AMERICA'
)AScustomerONLO_CUSTKEY=C_CUSTKEY
INNERJOIN
(
SELECT
D_DATEKEY,
D_YEAR
FROMdate
WHERE(D_YEAR=1997)OR(D_YEAR=1998)
)ASdatesONLO_ORDERDATE=toDate(D_DATEKEY)
INNERJOIN
(
SELECT
S_SUPPKEY,
S_CITY
FROMssb1000.supplier
WHERES_NATION='UNITEDSTATES'
)ASsupplierONLO_SUPPKEY=S_SUPPKEY
INNERJOIN
(
SELECT
P_PARTKEY,
P_BRAND
FROMssb1000.part
WHEREP_CATEGORY='MFGR#14'
)ASpartONLO_PARTKEY=P_PARTKEY
GROUPBY
D_YEAR,
S_CITY,
P_BRAND
ORDERBY
D_YEARASC,
S_CITYASC,
P_BRANDASC
SETTINGSenable_distributed_stages=1,exchange_source_pipeline_threads=32

經(jīng)過多表關(guān)聯(lián)查詢能力的增強(qiáng)，ByteHouse能夠更加全面的支撐各類業(yè)務(wù)，用戶可以根據(jù)場景選擇是否將數(shù)據(jù)打成大寬表，均能獲得非常良好的分析體驗(yàn)。

之所以ByteHouse在多表關(guān)聯(lián)場景表現(xiàn)如此出色，其中一大原因就是因?yàn)樽止?jié)自研了查詢優(yōu)化器，彌補(bǔ)了社區(qū)ClickHouse的一大不足。查詢優(yōu)化器都能帶來哪些體驗(yàn)上的優(yōu)化？字節(jié)是如何實(shí)現(xiàn)查詢優(yōu)化器的？我們會在下一期為大家詳細(xì)介紹。

ByteHouse已經(jīng)全面對外服務(wù)，并且提供各種版本以滿足不同類型用戶的需求。在ByteHouse官網(wǎng)上提交試用信息即可免費(fèi)試用！