優化器框架

Flume的優化器框架承擔兩個任務：

1. 把邏輯執行計劃轉換為物理執行計劃,
2. 針對不同的backend對執行流程進行優化.

一般來說，每個backend都有一個對應的planner作為專用的優化器.

工作流程

Planner的工作流程分為三個步驟:

1. 把邏輯執行計劃翻譯成flume任務的中間表示層Plan
2. 在Plan上對執行流程進行優化, 包括通用優化和與backend有關的專用優化
3. 把優化結束的Plan翻譯成物理執行計劃

從這里可以看出, planner與Logical-Plan和Runtime中的算子執行框架具有緊密的聯系.

執行計劃的中間表示

Plan是介于邏輯執行計劃和物理執行計劃之間的一種表示, 這種中間表示是一棵樹, 樹的非葉子節點由Unit組成, 代表一個Executor, 葉子節點由LeafUnit組成, 代表Executor上的一個數據集.
所有的葉子節點之間還有一些邊表示數據集之間的依賴關系, 因此Plan的描述其實是Tree + DAG.
節點之間的父子關系在Plan中稱為Control, 葉子節點之間的數據依賴在Plan中稱為Dependency, Plan提供了以下接口來修改節點之間的關系:

void AddControl(Unit* father, Unit* child);
void RemoveControl(Unit* father, Unit* child);
void ReplaceControl(Unit* father, Unit* child, Unit* unit);
void AddDependency(Unit* source, Unit* target, const std::string& tag);
void RemoveDependency(Unit* source, Unit* target);
void ReplaceDependency(Unit* source, Unit* target, Unit* unit);

Unit/LeafUnit

Unit/LeafUnit中記錄了如下信息:

• id, 僅在LeafUnit中有效, 唯一標識用戶算子/數據集的輸出
• type, Executor的類型, 例如DEFAULT, LOGICAL, LOCAL_SHUFFLE, EXTERNAL
• scope_level, 和Executor中的scope_level含義相同
• father, 父節點
• childs, 子節點, 包括Unit和LeafUnit
• nodes, 以當前節點為根的子樹中的所有LeafUnit（當前節點所有的孩子節點, 包含自身）
• inputs,當前節點所有直接輸入的邊 ，從非nodes節點到nodes節點的所有Dependency
• outputs,當前節點所有直接輸出的邊， 從nodes節點到非nodes節點的所有Dependency
• users, 由outputs的所有目標節點組成的集合(當前節點所有直接下游節點)
• needs, 由inputs的所有源節點組成的集合(當前節點所有直接上游節點)
• upstreams, 當前節點所有上游節點集合, 每個upstream和當前節點之間都存在一條Dependency鏈
• downstreams, 當前節點所有下游節點集合, 當前節點和每個downstream之間都存在一條Dependency鏈

優化器可以通過Unit/LeafUnit提供的接口讀取以上信息

Plan

除了修改節點關系的接口, Plan還提供了以下方法:
explict Plan(const PbLogicalPlan& message);
根據邏輯執行計劃初始化Unit/LeafUnit, 并維護節點上a的信息
Unit* Root();
獲取根節點, 結合Unit中的childs信息, 可以實現對Executor-Tree的遍歷
Unit* NewUnit();
創建一個新的Unit節點, 返回的節點沒有父節點, 也不屬于任何Dependency
void GetAllUnits(std::vector<Unit> result);
獲取所有Unit/LeafUnit的集合
void GetTopologicalOrder(std::list<Unit> result);
以拓撲順序獲取所有LeafUnit的集合

優化框架

Flume-Runtime的優化框架由Pass和Dispatcher組成.

Pass

所有的優化都被認為是對Plan的一種變換, 即一個優化算法的輸入是一個Plan, 輸出也是一個Plan. 這種變換被抽象為Pass:

class Pass {
public:
    virtual ~Pass() {}
// return true if plan is modified
    virtual bool Run(Plan* plan) = 0;
};

從代碼層次看，planner的執行過程是通過邏輯執行計劃創建Plan, 創建多個Pass對Plan進行修改, 最后生成物理執行計劃.

Dispatcher

通常來說, Pass對Plan進行的變換需要按照一定的順序對Unit/LeafUnit進行遍歷, 這種遍歷模型就是Dispatcher.

class Dispatcher {
public:
   virtual ~Dispatcher() {}
// return true if plan is modified
   virtual bool Run(Plan* plan) = 0;
};

Dispatcher的接口和Pass是一樣的, 兩者的區別在于含義不同, Pass代表一個完整的優化過程, 經過一個Pass的處理, Plan必須處于一個合理的狀態, 而一個Pass可能包括多個Dispatcher, 每個Dispatcher也可能執行多次.

RuleDispatcher

RuleDispatcher是一個單節點遍歷模型, 它把對Plan的處理拆分成對每一個節點的處理, 對每一個節點的處理則被抽象為對這個節點使用若干Rule, 這個類定義如下:

class RuleDispatcher {
public:
    class Rule {
    public:
        virtual ~Rule() {}
        // return true if this Rule could Run(plan, unit)
        virtual bool Accept(const Plan* plan, const Unit* unit) = 0;
        // return true if plan is modified
        virtual bool Run(Plan* plan, Unit* unit) = 0;
    };
virtual ~RuleDispatcher();
    virtual bool Run(Plan* plan);
    virtual void AddRule(Rule* rule);
protected:
    virtual bool Dispatch(Plan* plan, Unit* unit);
};

RuleDispatcher的Run方法首先從plan中獲取所有Unit/LeafUnit節點, 然后對每一個節點執行Dispatch方法, 后者嘗試對這個節點應用所有注冊的Rule.
RuleDispatcher對Plan的遍歷是無序的, 目前擴展了兩類固定順序的RuleDispatcher:

* DepthFirstDispatcher: 按照Plan中的Control關系深度遍歷, 提供PRE_ORDER和POST_ORDER兩種模式
* TopologicalDispatcher: 按照LeafUnit的Dependency關系進行拓撲遍歷, 提供順序和逆序兩種模式

優化算法

優化算法繼承Pass接口, 目前支持的優化包括獨立算子合并, 分桶合并, Partial-Processor前置.

獨立算子合并

global scope中的每個獨立算子(Process, Union, Sink)默認會產生一輪獨立的分布式計算, 本算法將其中連續的獨立算子合并到同一輪.

image.png

分桶合并

當使用分桶進行shuffle時, DistributeByDefault表明數據可以按照任意方式分成N份, 這時數據會按照flume內置的一個算法來分桶, 但如果數據在前一輪計算中已經按照某種方式分成了N份, 那么flume就沒必要再進行一次分桶shuffle了, 本算法把這種情況下的分桶計算和前一輪計算合并.

image.png

Partial-Processor前置

partial屬性表明同一組數據可以分任意多次進行運算, 如果數據在shuffle之后進行partial運算, 本算法可以把這次運算提前到shuffle之前, 以減少shuffle的數據量.

image.png

其他

pass & analysis

• pass改變拓撲，不可被pass依賴
• analysis 不改變拓撲，可被pass依賴
• 當pass條件滿足時，才會執行，如果改變了拓撲返回true，否則返回flase。依次調用，如for循環， 當所有的pass都返回false時，結束調用。

class LogicalOptimizing : public AddTaskUnitPass {
public:
//當pass條件滿足時，才會執行，如果改變了拓撲返回true，否則返回flase。依次調用，如for循環， 當所有的pass都返回false時，結束調用。
    RELY_PASS(LoadLogicalPlanPass);
    RELY_PASS(SplitUnionUnitPass);
    RELY_PASS(PromotePartialProcessPass);
    RELY_PASS(PruneCachedPathPass);// pass改變拓撲，不可被pass依賴
    RELY_PASS(ScopeAnalysis);// analysis 不改變拓撲，可被pass依賴
    RELY_PASS(RemoveUnsinkedPass);
    RELY_PASS(RemoveUselessUnionPass);
    RELY_PASS(RemoveEmptyUnitPass);
    RELY_PASS(AddDistributeByDefaultPass);
private:
    // use AddTaskUnitPass::Run
    virtual bool Run(Plan* plan) {
        bool changed = AddTaskUnitPass::Run(plan);
        plan->Root()->set<OptimizingStage>(TOPOLOGICAL_OPTIMIZING);
        return changed;
    }
};
class TopologicalOptimizing : public Pass {
public:
    RELY_PASS(MergeTaskPass);//rely_pass 在調用本pass前調用，apply_pass在本pass完成后調用
    APPLY_PASS(SetDefaultConcurrencyPass);
private:
    virtual bool Run(Plan* plan) {
        plan->Root()->set<OptimizingStage>(RUNTIME_OPTIMIZING);
        return false;
    }
};
class RuntimeOptimizing : public Pass {
public:
    RELY_PASS(RemoveEmptyUnitPass);
    RELY_PASS(AddCommonExecutorPass);
    RELY_PASS(AddTransferExecutorPass);
private:
    virtual bool Run(Plan* plan) {
        plan->Root()->set<OptimizingStage>(TRANSLATION_OPTIMIZING);
        return false;
    }
};
class TranslationOptimizing : public Pass {
public:
    RELY_PASS(BuildCommonExecutorPass);
    RELY_PASS(BuildTransferExecutorPass);
    RELY_PASS(BuildTaskSessionPass);
    RELY_PASS(BuildVertexInfoPass);
    RELY_PASS(BuildPhysicalPlanPass);
    PRESERVE_BY_DEFAULT();
private:
    virtual bool Run(Plan* plan) {
        // for draw plan
        return true;
    }
};