優(yōu)化器的作用是優(yōu)化查詢語句的執(zhí)行效率，它通過評估不同的執(zhí)行計劃并選擇最優(yōu)的執(zhí)行計劃來實(shí)現(xiàn)這一目標(biāo)。

CBO: 一種基于成本的優(yōu)化器，它通過評估不同查詢執(zhí)行計劃的成本來選擇最優(yōu)的執(zhí)行計劃。CBO會根據(jù)數(shù)據(jù)庫系統(tǒng)定義的統(tǒng)計信息以及其他因素，對不同的執(zhí)行計劃進(jìn)行評估，并選擇成本最低的執(zhí)行計劃。CBO的目標(biāo)是找到一個最優(yōu)的執(zhí)行計劃，使得查詢的執(zhí)行成本最低。

RBO: 一種基于規(guī)則的優(yōu)化器，它通過應(yīng)用一系列的優(yōu)化規(guī)則來選擇最優(yōu)的執(zhí)行計劃。RBO會根據(jù)預(yù)定義的規(guī)則對查詢進(jìn)行優(yōu)化，這些規(guī)則基于數(shù)據(jù)庫系統(tǒng)的特定邏輯和語義。RBO的優(yōu)點(diǎn)是實(shí)現(xiàn)簡單，適用于特定的查詢模式和數(shù)據(jù)分布。然而，RBO可能無法找到最優(yōu)的執(zhí)行計劃，特別是對于復(fù)雜的查詢和大規(guī)模的數(shù)據(jù)集。

Doris主要整合了Google Mesa（數(shù)據(jù)模型），Apache Impala（MPP查詢引擎)和Apache ORCFile (存儲格式，編碼和壓縮) 的技術(shù)。 Doris的查詢優(yōu)化器則是基于Impala改造實(shí)現(xiàn)的。Doris官方提供的 Nereids優(yōu)化器 文檔。

優(yōu)化器組件

查詢優(yōu)化器由多個部分組成，分別是: 詞法語法解析、語義解析、query改寫、生成執(zhí)行計劃。最后這步根據(jù)算法實(shí)現(xiàn)與業(yè)務(wù)場景的不同會有些許差異。

詞法語法解析

這個步驟，其實(shí)是做兩件事情，首先是解析SQL文本，提取關(guān)鍵字出來，比如(select、from等); 然后分析SQL文本是否滿足SQL語法，最終生成一個AST樹。其結(jié)構(gòu)如下:

對于不同類型的SQL，其語法樹的根節(jié)點(diǎn)類型也是不一樣的。一般是InsertStmt、UpdateStmt、DeleteStmt、SelectStmt等。而這些概念其實(shí)是impala中的，Doris的SQL查詢引擎是參考自impala。在其源碼中有這么一段注釋:

Impala是用于處理存儲在Hadoop集群中的大量數(shù)據(jù)的MPP（大規(guī)模并行處理）sql查詢引擎。 它是一個用C ++和Java編寫的開源軟件。 與其他Hadoop的SQL引擎相比，它提供了高性能和低延遲。其相關(guān)信息及文檔可參考: impala中文手冊

語義解析

根據(jù)AST樹與元數(shù)據(jù)中的表、列信息等做一個語義校驗，比如，表、字段是否在元數(shù)據(jù)中存在。其步驟一般如下:

query改寫

對原始的sql文本做一定程度的改寫使得SQL更簡單，執(zhí)行效率更高；一般是條件表達(dá)式改寫、子查詢改寫等。

在Doris中，有一個接口 ExprRewriteRule 負(fù)責(zé)表達(dá)式的改寫規(guī)則，基于該接口與各種不同的規(guī)則有不同的實(shí)現(xiàn)，在 Analyzer類的內(nèi)部類 GlobalState 構(gòu)造函數(shù)中，注冊了諸多的規(guī)則到rules集合中，而該list會被傳遞到ExprRewriter類中被應(yīng)用。

StmtRewriter 類處理子查詢改寫邏輯，其中的方法會處理各種場景下的子查詢改寫，比如rewriteSelectStatement方法.

這一步驟的處理是基于詞法語法解析后生成的AST樹進(jìn)行的。

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;
    }
}

單機(jī)執(zhí)行計劃

這一過程會生成PlanNodeTree，一般用于處理Join Reorder場景下的join調(diào)優(yōu)與謂詞下推等下推優(yōu)化。

SingleNodePlanner類用于生成單擊執(zhí)行計劃，該類其實(shí)也是基于impala框架改寫適用于Doris的。在這個類中，除了謂詞下推與join reorder外，還有類似列裁剪之類的優(yōu)化，都在這個類中有處理。

分布式執(zhí)行計劃

DistributedPlanner類負(fù)責(zé)分布式執(zhí)行計劃的優(yōu)化，其中會處理Join場景下的分布式執(zhí)行，選擇最優(yōu)的Join執(zhí)行路徑；其次就是Agg聚合函數(shù)的分布式執(zhí)行邏輯，Agg會分兩步執(zhí)行，先會在local本地scan，然后再Agg Node上在做一次scan聚合；當(dāng)然還有一些算子需要做分布式邏輯執(zhí)行優(yōu)化. 都可以在這個類中找到。當(dāng)然這個類也是基于impala框架改寫的。

如下是AggNode的分布式執(zhí)行計劃優(yōu)化:

總結(jié)

Doris的很多設(shè)計，其實(shí)都是有據(jù)可依，參考借鑒已有的框架/論文，再依據(jù)實(shí)際的業(yè)務(wù)場景做改寫；這也正是我們要學(xué)習(xí)了解的東西，通過一個點(diǎn)，然后鋪開去了解學(xué)習(xí)相關(guān)的其他點(diǎn)，慢慢的串聯(lián)起來形成面。查詢優(yōu)化器結(jié)合如下博客再加上自己去閱讀一下代碼，對整個脈絡(luò)及機(jī)制就算是掌握了。

聊聊分布式 SQL 數(shù)據(jù)庫Doris(五) 這是之前寫的對查詢優(yōu)化器相關(guān)的一些知識普及.

查詢優(yōu)化器詳解 Doris團(tuán)隊針對查詢優(yōu)化器的視頻講解.

Doris SQL 原理解析 小米工程師寫的，更深入的剖析.文章來源地址http://www.zghlxwxcb.cn/news/detail-747528.html

到了這里，關(guān)于聊聊分布式 SQL 數(shù)據(jù)庫Doris(九)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！