query optimization for distributed database systems
calcite是開源的一套查詢引擎,很多開源專案都使用了該開源專案,特別是對其optimizer部分的使用,類似drill、hive、flink都使用calcite作為其優化引擎。
calcite實現了兩套planner,hepplanner和volcanoplanner,hepplanner主要是一種貪婪式的planner,而volcano則是一種啟發式的planner,下面介紹下hepplanner的原始碼實現。
hepplanner是一套greedy方式的planner,可以認為是所優即所得,即任何rule只要命中執行,就認為其產生的結果是更優。
例:calcite實現的projectfiltertransposerule,功能主要是將project與filter進行交換。
subtree1:
project($0, $1)
filter($0 > 1)
subtree2:
filter($0 > 1)
project($0, $1)
則hepplanner會將subtree2作為更優的plan。
heprelvertex是對關係代數表示式relnode進行了簡單封裝。hepplanner的所有節點都是heprelvertex,每個heprelvertex都指向了乙個真正的relnode節點。
如
project($0, $1)
tablescan($0,$1,$2)
則hepplanner會封裝成
heprelvertex#1->currentrel(project($0, $1))
heprelvertex#2->currentrel(tablescan($0,$1,$2))
所以從整體上看整個relnode樹都是由heprelvertex節點組成,只是其指向了乙個內部relnode 節點。
hepplanner在將所有relnode tree轉化為heprelvertex時,構建了乙個graph,將所有的relnode節點關係使用vertex表示。首先根據每個heprelvertex構建了從其本身出發到其指向的孩子節點的source->dest之間的關係。
即directedgraph
heprelvertex#1->currentrel(project($0, $1))
heprelvertex#2->currentrel(tablescan($0,$1,$2))
則存在map
heprelvertex#1
-> (heprelvertex#1
-> heprelvertex#2)
heprelvertex#2
-> () --空
所有的這些對映關係被當作整個plan tree的graph。
rules表示需要執行的優化規則。
hepplanner執行hepprogram演算法如下
for (hepinstruction instruction : currentprogram.instructions)
}
可以看到處理方式很簡單,就是順序執行每乙個hepinstruction,然後當遇到transformation發生的次數到達一定程度時,清理一些中間結果的relnode。
hepplanner在calcite中主要是用來提前剪枝,方便給volcanoplanner提供一種次優plan後,繼續優化,類似drill等都是這樣處理。
ps:後續會繼續更新volcanoplanner的原始碼實現
spring原始碼分析 spring原始碼分析
1.spring 執行原理 spring 啟動時讀取應用程式提供的 bean 配置資訊,並在 spring 容器中生成乙份相應的 bean 配置登錄檔,然後根據這張登錄檔例項化 bean,裝配好 bean 之間的依賴關係,為上 層應用提供準備就緒的執行環境。二 spring 原始碼分析 1.1spr...
思科VPP原始碼分析(dpo機制原始碼分析)
vpp的dpo機制跟路由緊密結合在一起。路由表查詢 ip4 lookup 的最後結果是乙個load balance t結構。該結構可以看做是乙個hash表,裡面包含了很多dpo,指向為下一步處理動作。每個dpo都是新增路由時的乙個path的結果。dpo標準型別有 dpo drop,dpo ip nu...
redux原始碼分析(三) 原始碼部分
下面是每個部分的一些解讀 createstore apicreatestore reducer,initialstate enhancer 曾經非常好奇這個函式的第二個引數到底是initialstate還是enhancer,因為見過兩種寫法都有的,以為是版本問題。看了原始碼才發現,都可以的。如果你不...