優化器的作用是優化查詢語句的執行效率，它通過評估不同的執行計劃并選擇最優的執行計劃來實現這一目標。

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樹進行的。

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 原理解析 小米工程師寫的，更深入的剖析.

總結

以上是生活随笔為你收集整理的聊聊分布式 SQL 数据库Doris(九)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。