相信大家都对大名鼎鼎的ClickHouse有一定的了解了,它强大的数据分析性能让人印象深刻。但在字节大量生产使用中,发现了ClickHouse依然存在了一定的限制。例如:
- 缺少完整的upsert和delete操作
- 多表关联查询能力弱
- 集群规模较大时可用性下降(对字节尤其如此)
- 没有资源隔离能力
因此,我们决定将ClickHouse能力进行全方位加强,打造一款更强大的数据分析平台。后面我们将从五个方面来和大家分享,本篇将详细介绍我们是如何为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之之间抖动,较好的保证了该优先业务的查询资源,并且显著缩短的平均查询返回时间。
这是本次ClickHouse增强计划系列文章的最后一篇啦,除了这五篇文章提到的能力,ByteHouse还有有一个与ClickHouse使用不同执行引擎的版本,能够实现全面的存算分离,是真正的云原生数据仓库!后续我们也将为大家带来专题介绍。
审核编辑 :李倩
-
内存
+关注
关注
8文章
2965浏览量
73804 -
资源
+关注
关注
0文章
59浏览量
17763 -
数据分析
+关注
关注
2文章
1410浏览量
33982
原文标题:火山引擎:ClickHouse增强计划之“资源隔离”
文章出处:【微信号:芋道源码,微信公众号:芋道源码】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论