ClickHouse增强计划之“资源隔离”

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

• 缺少完整的upsert和delete操作
• 多表关联查询能力弱
• 集群规模较大时可用性下降（对字节尤其如此）
• 没有资源隔离能力

因此，我们决定将ClickHouse能力进行全方位加强，打造一款更强大的数据分析平台。后面我们将从五个方面来和大家分享，本篇将详细介绍我们是如何为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之之间抖动，较好的保证了该优先业务的查询资源，并且显著缩短的平均查询返回时间。

这是本次ClickHouse增强计划系列文章的最后一篇啦，除了这五篇文章提到的能力，ByteHouse还有有一个与ClickHouse使用不同执行引擎的版本，能够实现全面的存算分离，是真正的云原生数据仓库！后续我们也将为大家带来专题介绍。

审核编辑 ：李倩