更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群
相信大家都对大名鼎鼎的 ClickHouse 有一定的了解了，它强大的数据分析性能让人印象深刻。但在字节大量生产使用中，发现了 ClickHouse 依然存在了一定的限制。例如：
- 缺少完整的 upsert 和 delete 操作
- 多表关联查询能力弱
- 集群规模较大时可用性下降（对字节尤其如此）
- 没有资源隔离能力
本篇将详细介绍我们是如何为 ClickHouse 增强资源隔离能力的。
广告业务遇到的资源管控问题
ClickHouse 的资源管控能力不够完善，在 insert、select 并发高的场景下会导致执行失败，影响用户体验。这是因为社区版 ClickHouse 目前仅提供依据不同用户的最大内存控制，在超过阈值时会杀死执行的 query。
在字节的广告业务中，需要区分不同查询的优先级；对查询性能抖动的容忍度较低；同时也需要支持 adhoc 能力；查询类型广泛、资源占用可能会较多。
ClickHouse 提供的粗粒度并发控制不能满足需求；
-
无法灵活控制并发，导致查询迅速占满集群资源，部分后来的高优查询持续 pending，导致报错。
-
无法给特定业务预留 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 调度器，我们可以很容易的得到以下结论：
-
当所有资源组都有查询在执行时，每个资源组可以使用的 CPU 比例为
cpu_shares / sum(cpu_shares) -
当只有一个资源组有查询在执行时，该资源组可以使用的 CPU 比例为
100%
因此每个资源组可以使用的 CPU 资源比例范围就是 [cpu_shares/sum(cpu_shares), 100%],通过这个功能我们也就实现了两个预期效果：
- 保证了每个资源可以使用的 CPU 资源下限
- 保证了在任何 workload 情况下服务器 CPU 资源的总体利用率
Resource Group 带来的效果提升
Resource Group 能够显著的提升查询体验，为优先业务的查询提供保障，并且减小查询返回时间的方差。与此同时，也能够为集群稳定性带来提升，不会因为 OOM 杀死执行中的查询，以及防止一个服务出现故障而拖垮整个集群。
ByteHouse 的 Resource Group 主要有以下优点：
- 能够在 CPU、内存、并发控制等全方位的提供资源隔离的能力
- 可以限制低优先级查询带来的影响
- 降低写入语句可能带来的不良影响
在上文提到的广告业务中，使用 ByteHouse 替换 ClickHouse 后，查询时间明显缩短，体验明显改善。
应用前：
应用后：
可以看到上线前用户每天的查询平均耗时在 2.3s 到 14.1s 之间抖动，十分剧烈，用户的使用体验很差。上线后每天的查询平均耗时则在 0.4s 到 1.7s 之之间抖动，较好的保证了该优先业务的查询资源，并且显著缩短的平均查询返回时间。
ByteHouse 已经全面对外服务，并且提供各种版本以满足不同类型用户的需求。在 ByteHouse 官网上提交试用信息即可免费试用！欢迎大家试用。
点击跳转ByteHouse官方网站了解详情
