其他分享
首页 > 其他分享> > 字节跳动基于 ClickHouse 优化实践之“查询优化器”

字节跳动基于 ClickHouse 优化实践之“查询优化器”

作者:互联网

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

 

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

因此,我们决定将 ClickHouse 能力进行全方位加强,打造一款更强大的数据分析平台。本篇将详细介绍我们是如何构建ClickHouse的查询优化器。

 

查询优化器有多重要?

在传统的关系型数据库中,如Oracle、DB2、MySQL,查询优化器都是作为几个最重要的核心组件之一。可以说,没有查询优化器的数据库是不完整的。相对 OLTP 而言在OLAP领域中更是如此;对于分析类场景,查询更为复杂,计划好坏的差异更大。一个优秀的查询优化器可以防止用户写出不好的SQL导致执行速度慢,能够准确的选择出一条效率最高的执行路径,大幅度降低查询时间。相应的,一个不好的查询优化器,甚至会让查询变慢。

常见的优化器逻辑分为两类,一类叫“基于规则的优化(RBO)”,另一类称为“基于代价的优化(CBO)”,实际应用过程中应当两类兼顾才能取得最佳效果。

基于规则的优化

根据优化规则对关系表达式进行转换,这里的转换是说一个关系表达式经过优化规则后会变成另外一个关系表达式,同时原有表达式会被裁剪掉,经过一系列转换后生成最终的执行计划。RBO中包含了一套有着严格顺序的优化规则,同样一条SQL,无论读取的表中数据是怎么样的,最后生成的执行计划都是一样的。同时,在RBO中SQL写法的不同很有可能影响最终的执行计划,从而影响脚本性能。

基于代价的优化

根据优化规则对关系表达式进行转换,这里的转换是说一个关系表达式经过优化规则后会生成另外一个关系表达式,同时原有表达式也会保留,经过一系列转换后会生成多个执行计划,然后CBO会根据统计信息和代价模型(Cost Model)计算每个执行计划的Cost,从中挑选Cost最小的执行计划。

ByteHouse的查询优化器

目前主流的OLAP的引擎在查询优化器方面做的并不够好,尤其是ClickHouse。众所周知ClickHouse以快著称,但是它的快是采用了力大飞砖的方式,需要用户将数据预先生成大宽表,以避免过于复杂的多表查询从而获得高性能。而代价是,每次维度变化或新需求都需要大量操作,以及在必须使用多表关联进行分析的场景中显得十分无力。

作为一个企业级的OLAP数据库来说一个完善且强大的优化器是必不可少的,因此,ByteHouse从零开始自研的了查询优化器。

查询优化的完整流程

 

上图描述了整个查询的执行流程,从 SQL parse 到执行期间所有内容全部进行了重新实现(其中紫色模块),构建了一套完整的且规范的查询优化器。

主要功能模块

Analyzers

Analyzers 目录包括两部分功能:

QueryRewriter 针对 ANSI SQL 的改写主要有:

QueryRewriter 针对 Clickhouse SQL 的改写主要有:

QueryAnalyzer 查询语义进行分析和校验,将 AST 抽象成出结构化的数据结构,为下一步构建 plan 提供数据。在该模块中标准 SQL 和 Clickhouse SQL 进行了区分,一套代码同时兼容两种语义。

QueryPlan

在 Analyze 之后则是利用 Analyze 出的数据结构构建初始的查询计划。QueryPlan 是在社区的 QueryPlanStep 基础上改进而来,一方面增加了序列化/反序列化方法,为了计划下发执行基于 QueryPlan 并非 AST 或者 SQL 文本。另一方面是对社区中不合理的 Step 进行更改,让每个 Step 仅仅表达关系代数的语义而非很多执行相关的内容和参数,而这些执行相关的信息则是在每个执行的 server 上构建执行 pipeline 时才真正进行获得。

Optimizer

构建完执行计划后则是最为关键最后为核心的优化器模块。 PlanOptimizer 类是查询优化的入口类,首先会基于 PlanPattern 对 SQL的查询做一次粗粒度的分类,不同复杂度的查询使用不同的规则集合,提升效率。

优化器不管是 RBO 还是 CBO 本质上都是对查询做改写,只是改写的思路以及改写框架有不同的取舍。我们实现了三种改写框架,用于处理不同的场景:

查询优化器带来了什么

在性能方面,原生Clickhouse受限于缺少查询优化器,对于 TPC-DS测试集的99个SQL用例仅能正常运行很少一部分查询,即使通过手动改写 SQL 也仅能成功运行 80%的查询。在实现了完善的优化器之后可以直接运行全部 TPC-DS 原始 SQL,改进后的 Clickhouse 才这正可以算是可用的 OLAP 数据库。不仅仅是可以正常执行这些复杂查询,而且效率也得到了很大的提升,相对在没优化器的情况下手动改写的 SQL ,性能提升 6 倍以上。在内部的一些业务场景中性能也有近10倍的提升。

优化器的能力方面:

下面我们用TPC-DS标准测试集,来为大家展现一下添加优化器前后的差别:

在没有优化器时,仅能完成26个SQL的查询。而添加了优化器后,能够完整跑完TPC-DS的全部99个SQL,并且在此前能完成的查询中,性能也得到了极大的提升。

 

立即跳转火山引擎BytHouse官网了解详情!

 

标签:基于,字节,查询,改写,SQL,执行,优化,ClickHouse
来源: https://www.cnblogs.com/bytedata/p/16635953.html