共计 3249 个字符，预计需要花费 9 分钟才能阅读完成。
更多技术交换、求职机会、试用福利，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
置信大家都对赫赫有名的 ClickHouse 有肯定的理解，它弱小的数据分析性能让人印象粗浅。但在字节大量生产应用中，发现了 ClickHouse 仍然存在了肯定的限度。例如：
- 短少残缺的 upsert 和 delete
- 操作多表关联查问能力弱
- 集群规模较大时可用性降落（对字节尤其如此）
- 没有资源隔离能力
因而，咱们决定将 ClickHouse 能力进行全方位增强，打造一款更弱小的数据分析平台。本篇将具体介绍咱们是如何为 ClickHouse 补全更新删除能力的。
实时人群圈选场景遇到的难题
在电商业务中，人群圈选是十分常见的一个场景。字节原有的离线圈选的计划是以 T + 1 的形式更新数据，而不是实时更新，这很影响业务侧的体验。当初心愿可能基于实时标签，在数据管理平台中构建实时人群圈选的能力。整体数据链路如下：
为了保障实时数据和离线数据同时提供服务，在标签接入结束后，在 ClickHouse 中实现宽表加工工作。然而原生 ClickHouse 只反对追加写的能力，只有 ReplacingMergeTree 这种计划。然而选用 ReplacingMergeTree 引擎的限度比拟多，不能满足业务的需要，次要体现在：
- 性能降落重大，ReplacingMergeTree 采纳的是写优先的设计逻辑，这导致读性能损失重大。体现是在进行查问时性能较 ClickHouse 其余引擎的性能降落重大，波及 ReplacingMergeTree 的查问响应工夫过慢。
- ReplacingMergeTree 引擎只反对数据的更新，并不反对数据的删除。只能通过额定的定制解决来实现数据革除，但这样会进一步拖慢了查问的性能。
- ReplacingMergeTree 中的去重是 Merge 触发的，在刚导入的数据时是不去重的，过一段时间后才会在分区内去重。
解决方案：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 的企业级能力进行了全方位的加强。
立刻跳转火山引擎 BytHouse 官网理解详情！
