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

? 缺少完整的upsert和delete操作

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

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

? 沒有資源隔離能力

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

實(shí)時(shí)人群圈選場(chǎng)景遇到的難題

在電商業(yè)務(wù)中，人群圈選是非常常見的一個(gè)場(chǎng)景。字節(jié)原有的離線圈選的方案是以T+1的方式更新數(shù)據(jù)，而不是實(shí)時(shí)更新，這很影響業(yè)務(wù)側(cè)的體驗(yàn)?，F(xiàn)在希望能夠基于實(shí)時(shí)標(biāo)簽，在數(shù)據(jù)管理平臺(tái)中構(gòu)建實(shí)時(shí)人群圈選的能力。整體數(shù)據(jù)鏈路如下：

為了保證實(shí)時(shí)數(shù)據(jù)和離線數(shù)據(jù)同時(shí)提供服務(wù)，在標(biāo)簽接入完畢后，在ClickHouse中完成寬表加工任務(wù)。但是原生ClickHouse只支持追加寫的能力，只有ReplacingMergeTree這種方案。但是選用ReplacingMergeTree引擎的限制比較多，不能滿足業(yè)務(wù)的需求，主要體現(xiàn)在：

? 性能下降嚴(yán)重，ReplacingMergeTree采用的是寫優(yōu)先的設(shè)計(jì)邏輯，這導(dǎo)致讀性能損失嚴(yán)重。表現(xiàn)是在進(jìn)行查詢時(shí)性能較ClickHouse其他引擎的性能下降嚴(yán)重，涉及ReplacingMergeTree的查詢響應(yīng)時(shí)間過慢。

? ReplacingMergeTree引擎只支持?jǐn)?shù)據(jù)的更新，并不支持?jǐn)?shù)據(jù)的刪除。只能通過CollaspingMergeTree來實(shí)現(xiàn)數(shù)據(jù)清除，通過不同的表引擎分別提供更新刪除能力會(huì)讓系統(tǒng)復(fù)雜度進(jìn)一步提升。

? ReplacingMergeTree中的去重是 Merge 觸發(fā)的，在剛導(dǎo)入的數(shù)據(jù)時(shí)是不去重的，過一段時(shí)間后才會(huì)在分區(qū)內(nèi)去重。

ByteHouse的解決方案：UniqueMergeTree

在這種情況下，字節(jié)在ByteHouse（火山引擎上基于ClickHouse能力增強(qiáng)的版本）中開發(fā)了一種支持實(shí)時(shí)更新刪除的表引擎：UniqueMergeTree。UniqueMergeTree與以往的表引擎有什么差別呢？下面介紹兩種支持實(shí)時(shí)更新的常見技術(shù)方案：

原生ClickHouse選擇的技術(shù)方案

原生ClickHouse的更新表引擎ReplacingMergeTree使用Merge on Read的實(shí)現(xiàn)邏輯，整個(gè)思想比較類似LSMTree。對(duì)于寫入，數(shù)據(jù)先根據(jù)key排序，然后生成對(duì)應(yīng)的列存文件。每個(gè)Batch寫入的文件對(duì)應(yīng)一個(gè)版本號(hào)，版本號(hào)能用來表示數(shù)據(jù)的寫入順序。

同一批次的數(shù)據(jù)不包含重復(fù)key，但不同批次的數(shù)據(jù)包含重復(fù)key，這就需要在讀的時(shí)候去做合并，對(duì)key相同的數(shù)據(jù)返回去最新版本的值，所以叫merge on read方案。原生ClickHouse ReplacingMergeTree用的就是這種方案。

大家可以看到，它的寫路徑是非常簡(jiǎn)單的，是一個(gè)很典型的寫優(yōu)化方案。它的問題是讀性能比較差，有幾方面的原因。首先，key-based merge通常是單線程的，比較難并行。其次merge過程需要非常多的內(nèi)存比較和內(nèi)存拷貝。最后這種方案對(duì)謂詞下推也會(huì)有一些限制。大家用過ReplacingMergeTree的話，應(yīng)該對(duì)讀性能問題深有體會(huì)。

這個(gè)方案也有一些變種，比如說可以維護(hù)一些index來加速merge過程，不用每次merge都去做key的比較。

面向讀優(yōu)化的新方案

UniqueMergeTree使用的技術(shù)方案Mark-Delete + Insert方案剛好反過來，是一個(gè)讀優(yōu)化方案。在這個(gè)方案中，更新是通過先刪除再插入的方式實(shí)現(xiàn)的。

Ref “Enhancements to SQLServer Column Stores”

下面以SQLServer的Column Stores為例介紹下這個(gè)方案。圖中，每個(gè)RowGroup對(duì)應(yīng)一個(gè)不可變的列存文件，并用Bitmap來記錄每個(gè)RowGroup中被標(biāo)記刪除的行號(hào)，即DeleteBitmap。處理更新的時(shí)候，先查找key所屬的RowGroup以及它在RowGroup中行號(hào)，更新RowGroup的DeleteBitmap，最后將更新后的數(shù)據(jù)寫入Delta Store。查詢的時(shí)候，不同RowGroup的掃描可以完全并行，只需要基于行號(hào)過濾掉屬于DeleteBitmap的數(shù)據(jù)即可。

這個(gè)方案平衡了寫和讀的性能。一方面寫入時(shí)需要去定位key的具體位置，另一方面需要處理write-write沖突問題。

這個(gè)方案也有一些變種。比如說寫入時(shí)先不去查找更新key的位置，而是先將這些key記錄到一個(gè)buffer中，使用后臺(tái)任務(wù)將這些key轉(zhuǎn)成DeleteBitmap。然后在查詢的時(shí)候通過merge on read的方式處理buffer中的增量key。

Upsert和Delete使用示例

首先我們建了一張UniqueMergeTree的表，表引擎的參數(shù)和ReplacingMergeTree是一樣的，不同點(diǎn)是可以通過UNIQUE KEY關(guān)鍵詞來指定這張表的唯一鍵，它可以是多個(gè)字段，可以包含表達(dá)式等等。

下面對(duì)這張表做寫入操作就會(huì)用到upsert的語義，比如說第6行寫了四條數(shù)據(jù)，但只包含1和2兩個(gè)key，所以對(duì)于第7行的select，每個(gè)key只會(huì)返回最高版本的數(shù)據(jù)。對(duì)于第11行的寫入，key 2是一個(gè)已經(jīng)存在的key，所以會(huì)把key 2對(duì)應(yīng)的name更新成B3; key 3是新key，所以直接插入。最后對(duì)于行刪除操作，我們?cè)黾恿艘粋€(gè)delete flag的虛擬列，用戶可以通過這個(gè)虛擬列標(biāo)記Batch中哪些是要?jiǎng)h除，哪些是要upsert。

UniqueMergeTree表引擎的亮點(diǎn)

? 對(duì)于Unique表的寫入，我們會(huì)采用upsert的語義，即如果寫入的是新key，那就直接插入數(shù)據(jù)；如果寫入的key已經(jīng)存在，那就更新對(duì)應(yīng)的數(shù)據(jù)。

? UniqueMergeTree表引擎既支持行更新的模式，也支持部分列更新的模式，用戶可以根據(jù)業(yè)務(wù)要求開啟或關(guān)閉。

? ByteHouse也支持指定Unique Key的value來刪除數(shù)據(jù)，滿足實(shí)時(shí)行刪除的需求。支持指定一個(gè)版本字段來解決回溯場(chǎng)景可能出現(xiàn)的低版本數(shù)據(jù)覆蓋高版本數(shù)據(jù)的問題。

? 最后ByteHouse也支持?jǐn)?shù)據(jù)在多副本的同步，避免整體系統(tǒng)存在單點(diǎn)故障。

在性能方面，我們對(duì)UniqueMergeTree的寫入和查詢性能做了性能測(cè)試，結(jié)果如下圖（箭頭前是ReplacingMergeTree的消耗時(shí)間，箭頭后是UniqueMergeTree的消耗時(shí)間）。

可以看到，與ReplacingMergeTree相比，UniqueMergeTree的寫入性能雖然略有下降，但在查詢性能上取得了數(shù)量級(jí)的提升。我們進(jìn)一步對(duì)比了UniqueMergeTree和普通MergeTree的查詢性能，發(fā)現(xiàn)兩者是非常接近的。

增強(qiáng)后的實(shí)施人群圈選

經(jīng)過UniqueMergeTree的加持，在原有架構(gòu)不變的情況下，完美的滿足了實(shí)時(shí)人群圈選場(chǎng)景的要求。

1、通過Unique Key配置唯一鍵，提供upsert更新寫語義，查詢自動(dòng)返回每個(gè)唯一鍵的最新值

2、性能：?jiǎn)蝧hard寫入吞吐可以達(dá)到10k+行/s；查詢性能與原生CH表幾乎相同

3、支持根據(jù)Unique Key實(shí)時(shí)刪除數(shù)據(jù)

此外，ByteHouse還通過UniqueMergeTree支持了一些其他特性：

1、唯一鍵支持多字段和表達(dá)式

2、支持分區(qū)級(jí)別唯一和表級(jí)別唯一兩種模式

3、支持自定義版本字段，寫入低版本數(shù)據(jù)時(shí)自動(dòng)忽略

4、支持多副本部署，通過主備異步復(fù)制保障數(shù)據(jù)可靠性

不僅在實(shí)時(shí)人群圈選場(chǎng)景，ByteHouse提供的upsert能力已經(jīng)服務(wù)于字節(jié)內(nèi)部眾多應(yīng)用，線上應(yīng)用的表數(shù)量有數(shù)千張，受到實(shí)時(shí)類應(yīng)用的廣泛歡迎。

除Upsert能力外，ByteHouse在為原生ClickHouse的企業(yè)級(jí)能力進(jìn)行了全方位的增強(qiáng)。下一期，我們將介紹ClickHouse增強(qiáng)計(jì)劃之“多表關(guān)聯(lián)查詢”，大家有興趣一定不要錯(cuò)過。

審核編輯 ：李倩