相信大家都對大名鼎鼎的ClickHouse有一定的了解了，它強大的數據分析性能讓人印象深刻。但在字節大量生產使用中，發現了ClickHouse依然存在了一定的局限。例如：

? 缺少完整的upsert和delete操作

? 多表關聯查詢能力弱

? 集群規模較大時可用性下降（對字節尤其如此）

? 沒有資源隔離能力

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

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

在電商業務中，人群圈選是非常常見的一個場景。字節原有的離線圈選的方案是以T+1的方式更新數據，而不是實時更新，這很影響業務側的體驗。現在希望能夠基于實時標簽，在數據管理平臺中構建實時人群圈選的能力。整體數據鏈路如下：

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

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

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

? ReplacingMergeTree中的去重是 Merge 觸發的，在剛導入的數據時是不去重的，過一段時間后才會在分區內去重。

ByteHouse的解決方案：UniqueMergeTree

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

原生ClickHouse選擇的技術方案

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

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

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

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

面向讀優化的新方案

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

Ref “Enhancements to SQLServer Column Stores”

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

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

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

Upsert和Delete使用示例

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

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

UniqueMergeTree表引擎的亮點

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

? UniqueMergeTree表引擎既支持行更新的模式，也支持部分列更新的模式，用戶可以根據業務要求開啟或關閉。

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

? 最后ByteHouse也支持數據在多副本的同步，避免整體系統存在單點故障。

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

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

增強后的實施人群圈選

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

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

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

3、支持根據Unique Key實時刪除數據

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

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

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

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

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

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

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

審核編輯 ：李倩