性能提升5倍！火山引擎如何为 ClickHouse 实现资源隔离？

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

• 缺少完整的 Upsert 和 Delete 操作

• 多表关联查询能力弱

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

• 没有资源隔离能力

因此，我们决定将 ClickHouse 能力进行全方位加强，打造一款更强大的数据分析平台。后面我们将从五个方面来和大家分享，本篇将详细介绍我们是如何为 ClickHouse 增强资源隔离能力的。

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

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

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

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

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

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

02 ByteHouse 的解决方案：Resource Group

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

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

1. 并发控制

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

2. 内存控制

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

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

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

3. CPU控制

ByteHouse 使用 CGroups 提供的 CPU Controller 实现资源组的 CPU 控制。CPU Controller通过使用 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%]，通过这个功能我们也就实现了两个预期效果：

（3）保证了每个资源可以使用的 CPU 资源下限

（4）保证了在任何 Workload 情况下服务器 CPU 资源的总体利用率

4. Resource Group 带来的效果提升

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

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

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

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

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

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

应用前：

应用后：

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