优化器的作用是优化查询语句的执行效率，它通过评估不同的执行计划并选择最优的执行计划来实现这一目标。
CBO: 一种基于成本的优化器，它通过评估不同查询执行计划的成本来选择最优的执行计划。CBO会根据数据库系统定义的统计信息以及其他因素，对不同的执行计划进行评估，并选择成本最低的执行计划。CBO的目标是找到一个最优的执行计划，使得查询的执行成本最低。
RBO: 一种基于规则的优化器，它通过应用一系列的优化规则来选择最优的执行计划。RBO会根据预定义的规则对查询进行优化，这些规则基于数据库系统的特定逻辑和语义。RBO的优点是实现简单，适用于特定的查询模式和数据分布。然而，RBO可能无法找到最优的执行计划，特别是对于复杂的查询和大规模的数据集。
Doris主要整合了Google Mesa（数据模型），Apache Impala（MPP查询引擎)和Apache ORCFile (存储格式，编码和压缩) 的技术。 Doris的查询优化器则是基于Impala改造实现的。Doris官方提供的 Nereids优化器 文档。
优化器组件
查询优化器由多个部分组成，分别是: 词法语法解析、语义解析、query改写、生成执行计划。最后这步根据算法实现与业务场景的不同会有些许差异。
词法语法解析
这个步骤，其实是做两件事情，首先是解析SQL文本，提取关键字出来，比如(select、from等); 然后分析SQL文本是否满足SQL语法，最终生成一个AST树。其结构如下:
对于不同类型的SQL，其语法树的根节点类型也是不一样的。一般是InsertStmt、UpdateStmt、DeleteStmt、SelectStmt等。而这些概念其实是impala中的，Doris的SQL查询引擎是参考自impala。在其源码中有这么一段注释:
Impala是用于处理存储在Hadoop集群中的大量数据的MPP（大规模并行处理）sql查询引擎。 它是一个用C 和Java编写的开源软件。 与其他Hadoop的SQL引擎相比，它提供了高性能和低延迟。其相关信息及文档可参考: impala中文手册
语义解析
根据AST树与元数据中的表、列信息等做一个语义校验，比如，表、字段是否在元数据中存在。其步骤一般如下:
query改写
对原始的sql文本做一定程度的改写使得SQL更简单，执行效率更高；一般是条件表达式改写、子查询改写等。
在Doris中，有一个接口 ExprRewriteRule 负责表达式的改写规则，基于该接口与各种不同的规则有不同的实现，在 Analyzer类的内部类 GlobalState 构造函数中，注册了诸多的规则到rules集合中，而该list会被传递到ExprRewriter类中被应用。
StmtRewriter 类处理子查询改写逻辑，其中的方法会处理各种场景下的子查询改写，比如rewriteSelectStatement方法.
这一步骤的处理是基于词法语法解析后生成的AST树进行的。
代码语言：javascript复制public class GlobalState(Env env, ConnectContext context) {
this.env = env;
this.context = context;
List<ExprRewriteRule> rules = Lists.newArrayList();
// BetweenPredicates must be rewritten to be executable. Other non-essential
// expr rewrites can be disabled via a query option. When rewrites are enabled
// BetweenPredicates should be rewritten first to help trigger other rules.
rules.add(BetweenToCompoundRule.INSTANCE);
// Binary predicates must be rewritten to a canonical form for both predicate
// pushdown and Parquet row group pruning based on min/max statistics.
rules.add(NormalizeBinaryPredicatesRule.INSTANCE);
// Put it after NormalizeBinaryPredicatesRule, make sure slotRef is on the left and Literal is on the right.
rules.add(RewriteBinaryPredicatesRule.INSTANCE);
rules.add(RewriteImplicitCastRule.INSTANCE);
rules.add(RoundLiteralInBinaryPredicatesRule.INSTANCE);
rules.add(FoldConstantsRule.INSTANCE);
rules.add(EraseRedundantCastExpr.INSTANCE);
rules.add(RewriteFromUnixTimeRule.INSTANCE);
rules.add(CompoundPredicateWriteRule.INSTANCE);
rules.add(RewriteDateLiteralRule.INSTANCE);
rules.add(RewriteEncryptKeyRule.INSTANCE);
rules.add(RewriteInPredicateRule.INSTANCE);
rules.add(RewriteAliasFunctionRule.INSTANCE);
rules.add(RewriteIsNullIsNotNullRule.INSTANCE);
rules.add(MatchPredicateRule.INSTANCE);
rules.add(EliminateUnnecessaryFunctions.INSTANCE);
List<ExprRewriteRule> onceRules = Lists.newArrayList();
onceRules.add(ExtractCommonFactorsRule.INSTANCE);
onceRules.add(InferFiltersRule.INSTANCE);
exprRewriter = new ExprRewriter(rules, onceRules);
// init mv rewriter
List<ExprRewriteRule> mvRewriteRules = Lists.newArrayList();
mvRewriteRules.add(new ExprToSlotRefRule());
mvRewriteRules.add(ToBitmapToSlotRefRule.INSTANCE);
mvRewriteRules.add(CountDistinctToBitmapOrHLLRule.INSTANCE);
mvRewriteRules.add(CountDistinctToBitmap.INSTANCE);
mvRewriteRules.add(NDVToHll.INSTANCE);
mvRewriteRules.add(HLLHashToSlotRefRule.INSTANCE);
mvExprRewriter = new ExprRewriter(mvRewriteRules);
// context maybe null. eg, for StreamLoadPlanner.
// and autoBroadcastJoinThreshold is only used for Query's DistributedPlanner.
// so it is ok to not set autoBroadcastJoinThreshold if context is null
if (context != null) {
// compute max exec mem could be used for broadcast join
long perNodeMemLimit = context.getSessionVariable().getMaxExecMemByte();
double autoBroadcastJoinThresholdPercentage = context.getSessionVariable().autoBroadcastJoinThreshold;
if (autoBroadcastJoinThresholdPercentage > 1) {
autoBroadcastJoinThresholdPercentage = 1.0;
} else if (autoBroadcastJoinThresholdPercentage <= 0) {
autoBroadcastJoinThresholdPercentage = -1.0;
}
autoBroadcastJoinThreshold = (long) (perNodeMemLimit * autoBroadcastJoinThresholdPercentage);
} else {
// autoBroadcastJoinThreshold is a "final" field, must set an initial value for it
autoBroadcastJoinThreshold = 0;
}
}单机执行计划
这一过程会生成PlanNodeTree，一般用于处理Join Reorder场景下的join调优与谓词下推等下推优化。
SingleNodePlanner类用于生成单击执行计划，该类其实也是基于impala框架改写适用于Doris的。在这个类中，除了谓词下推与join reorder外，还有类似列裁剪之类的优化，都在这个类中有处理。
分布式执行计划
DistributedPlanner类负责分布式执行计划的优化，其中会处理Join场景下的分布式执行，选择最优的Join执行路径；其次就是Agg聚合函数的分布式执行逻辑，Agg会分两步执行，先会在local本地scan，然后再Agg Node上在做一次scan聚合；当然还有一些算子需要做分布式逻辑执行优化. 都可以在这个类中找到。当然这个类也是基于impala框架改写的。
如下是AggNode的分布式执行计划优化:
总结
Doris的很多设计，其实都是有据可依，参考借鉴已有的框架/论文，再依据实际的业务场景做改写；这也正是我们要学习了解的东西，通过一个点，然后铺开去了解学习相关的其他点，慢慢的串联起来形成面。查询优化器结合如下博客再加上自己去阅读一下代码，对整个脉络及机制就算是掌握了。
聊聊分布式 SQL 数据库Doris(五) 这是之前写的对查询优化器相关的一些知识普及.
查询优化器详解 Doris团队针对查询优化器的视频讲解.
Doris SQL 原理解析 小米工程师写的，更深入的剖析.
