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

? 缺少完整的upsert和delete操作

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

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

? 沒有資源隔離能力

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

實時人群圈選場景遇到的難題

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

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

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

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

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

ByteHouse的解決方案：UniqueMergeTree

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

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

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

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

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

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

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

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

Ref “Enhancements to SQLServer Column Stores”

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

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

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

Upsert和Delete使用示例

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

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

UniqueMergeTree表引擎的亮點

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

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

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

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

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

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

增強后的實施人群圈選

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

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

2、性能：單shard寫入吞吐可以達到10k+行/s；查詢性能與原生CH表幾乎相同

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

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

1、唯一鍵支持多字段和表達式

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

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

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

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

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

審核編輯 ：李倩