字节跳动基于 ClickHouse 优化实践之“资源隔离”

更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

相信大家都对大名鼎鼎的 ClickHouse 有一定的了解了，它强大的数据分析性能让人印象深刻。但在字节大量生产使用中，发现了 ClickHouse 依然存在了一定的限制。例如：

• 缺少完整的 upsert 和 delete 操作

• 多表关联查询能力弱

• 集群规模较大时可用性下降（对字节尤其如此）

• 没有资源隔离能力

本篇将详细介绍我们是如何为 ClickHouse 增强资源隔离能力的。

广告业务遇到的资源管控问题

ClickHouse 的资源管控能力不够完善，在 insert、select 并发高的场景下会导致执行失败，影响用户体验。这是因为社区版 ClickHouse 目前仅提供依据不同用户的最大内存控制，在超过阈值时会杀死执行的 query。

在字节的广告业务中，需要区分不同查询的优先级；对查询性能抖动的容忍度较低；同时也需要支持 adhoc 能力；查询类型广泛、资源占用可能会较多。

ClickHouse 提供的粗粒度并发控制不能满足需求；

1. 无法灵活控制并发，导致查询迅速占满集群资源，部分后来的高优查询持续 pending，导致报错。

2. 无法给特定业务预留 cpu 资源，出现大查询占满 cpu，而后来的查询执行时间大幅增加。

ByteHouse 的解决方案：Resource Group

在这种情况下，字节在 ByteHouse（字节基于 ClickHouse 能力增强的版本）中开发了资源管理的组件：Resource Group。

基本思路是将并发、内存、CPU 等资源拆分给不同的资源组，同时通过资源组的父子关系实现不同资源组共享部分资源的能力。当用户的查询提交给引擎，依照定义的规则选定相应的资源组，然后评估该资源组以及父资源组是否能够执行该查询，如是则直接执行，否则进入该资源组的等待队列，等待资源释放。

并发控制

max_concurrent_queries 配置项控制一个资源组能够同时运行的查询上限。当资源组并发达到上限，或者该资源组的父资源组并发达到上限，引擎会把查询放入该资源组的等待队列。当该资源组有一个查询结束，引擎会执行该资源组等待队列中最早的查询；如果此时该资源组等待队列为空，则会触发父资源组的资源释放，进一步触发该父资源组的其他子资源组的等待队列查询执行，实现并发 quota 在一个父资源组之间的共享。

内存控制

每一个资源组可以配置一个软性的内存上限，当资源组中的查询使用内存超过这个软性限制之后，新查询将会进入等待队列。和并发控制类似，内存也会判断父资源组的限制，并使用类似的逻辑实现内存在一个父资源组之间的共享。

由于目前还没有一个准确的查询占用内存预估的模型，当前采取的策略是预估+实际内存矫正的模式，当一个新查询进入时，引擎会按照预估内存评估是否可以执行，在开始执行之后则是利用查询现有的 memory_tracker 在下一轮判断之前矫正预估值。

此软性的内存限制不同于原生 ClickHouse 的硬性内存限制，并不会杀死已经在执行的查询，而是用于控制新查询的可执行判断，因此可以配合使用。

CPU 控制

ByteHouse 使用 cgroups 提供的 cpu controller 实现资源组的 CPU 控制。Cpu controler 通过使用 CFS 调度器将 CPU 资源按照相同的时间分片进行分配，以实现不同 group 按照预定义的 cpu shares 占用相应的 CPU 资源。

在 ByteHouse 内部，我们实现了一个新的线程池类，在该类中给查询分配线程资源时，会依据当前 Context 中记录的资源组信息分配关联到相应 cgroup 的线程。

由于采用的 CFS 调度器，我们可以很容易的得到以下结论：

1. 当所有资源组都有查询在执行时，每个资源组可以使用的 CPU 比例为 cpu_shares / sum(cpu_shares)
   

2. 当只有一个资源组有查询在执行时，该资源组可以使用的 CPU 比例为 100%
   

因此每个资源组可以使用的 CPU 资源比例范围就是 [cpu_shares/sum(cpu_shares), 100%],通过这个功能我们也就实现了两个预期效果：

1. 保证了每个资源可以使用的 CPU 资源下限

2. 保证了在任何 workload 情况下服务器 CPU 资源的总体利用率

Resource Group 带来的效果提升

Resource Group 能够显著的提升查询体验，为优先业务的查询提供保障，并且减小查询返回时间的方差。与此同时，也能够为集群稳定性带来提升，不会因为 OOM 杀死执行中的查询，以及防止一个服务出现故障而拖垮整个集群。

ByteHouse 的 Resource Group 主要有以下优点：

• 能够在 CPU、内存、并发控制等全方位的提供资源隔离的能力

• 可以限制低优先级查询带来的影响

• 降低写入语句可能带来的不良影响

在上文提到的广告业务中，使用 ByteHouse 替换 ClickHouse 后，查询时间明显缩短，体验明显改善。

应用前：

应用后：

可以看到上线前用户每天的查询平均耗时在 2.3s 到 14.1s 之间抖动，十分剧烈，用户的使用体验很差。上线后每天的查询平均耗时则在 0.4s 到 1.7s 之之间抖动，较好的保证了该优先业务的查询资源，并且显著缩短的平均查询返回时间。

ByteHouse 已经全面对外服务，并且提供各种版本以满足不同类型用户的需求。在 ByteHouse 官网上提交试用信息即可免费试用！欢迎大家试用。

点击跳转ByteHouse官方网站了解详情