架構(gòu)
Presto查詢引擎是一個Master-Slave的架構(gòu)，由一個Coordinator節(jié)點漱办，一個Discovery Server節(jié)點这刷，多個Worker節(jié)點組成，
Discovery Server通常內(nèi)嵌于Coordinator節(jié)點中娩井。
Coordinator負(fù)責(zé)解析SQL語句暇屋，生成執(zhí)行計劃，分發(fā)執(zhí)行任務(wù)給Worker節(jié)點執(zhí)行洞辣。
Worker節(jié)點負(fù)責(zé)實際執(zhí)行查詢?nèi)蝿?wù)咐刨。
Worker節(jié)點啟動后向Discovery Server服務(wù)注冊，Coordinator從Discovery Server獲得可以正常工作的Worker節(jié)點屋彪。如果配置了Hive Connector所宰，需要配置一個Hive MetaStore服務(wù)為Presto提供Hive元信息，Worker節(jié)點與HDFS交互讀取數(shù)據(jù)畜挥。
- 主從架構(gòu)
- Coordinator
- Worker
- Discovery Server
執(zhí)行過程
提交查詢
用戶使用Presto Cli提交一個查詢語句后仔粥，Cli使用HTTP協(xié)議與Coordinator通信，Coordinator收到查詢請求后調(diào)用SqlParser解析SQL語句得到Statement對象蟹但，并將Statement封裝成一個QueryStarter對象放入線程池中等待執(zhí)行躯泰。
SQL編譯過程
邏輯執(zhí)行計劃
虛線就是Presto對邏輯執(zhí)行計劃的切分點
邏輯計劃Plan生成的SubPlan分為四個部分，每一個SubPlan都會提交到一個或者多個Worker節(jié)點上執(zhí)行
查詢執(zhí)行流程
1.Cli通過HTTP協(xié)議提交SQL查詢之后华糖，查詢請求封裝成一個SqlQueryExecution對象交給Coordinator的SqlQueryManager#queryExecutor線程池去執(zhí)行
2.每個SqlQueryExecution線程（圖中Q-X線程）啟動后對查詢請求的SQL進行語法解析和優(yōu)化并最終生成多個Stage的SqlStageExecution任務(wù)麦向，每個SqlStageExecution任務(wù)仍然交給同樣的線程池去執(zhí)行
3.每個SqlStageExecution線程（圖中S-X線程）啟動后每個Stage的任務(wù)按PlanDistribution屬性構(gòu)造一個或者多個RemoteTask通過HTTP協(xié)議分配給遠(yuǎn)端的Worker節(jié)點執(zhí)行
4.Worker節(jié)點接收到RemoteTask請求之后，啟動一個SqlTaskExecution線程（圖中T-X線程）將這個任務(wù)的每個Split包裝成一個PrioritizedSplitRunner任務(wù)（圖中SR-X）交給Worker節(jié)點的TaskExecutor#executor線程池去執(zhí)行
物理執(zhí)行計劃
SubPlan的幾個屬性
planDistribution 分發(fā)方式
3種不同的PlanDistribution方式：
Source表示這個SubPlan是數(shù)據(jù)源客叉，Source類型的任務(wù)會按照數(shù)據(jù)源大小確定分配多少個節(jié)點進行執(zhí)行诵竭；
Fixed表示這個SubPlan會分配固定的節(jié)點數(shù)進行執(zhí)行（Config配置中的query.initial-hash-partitions參數(shù)配置话告，默認(rèn)是8）；
None表示這個SubPlan只分配到一個節(jié)點進行執(zhí)行卵慰。
在下面的執(zhí)行計劃中沙郭，SubPlan1和SubPlan0 PlanDistribution=Source，這兩個SubPlan都是提供數(shù)據(jù)源的節(jié)點裳朋，SubPlan1所有節(jié)點的讀取數(shù)據(jù)都會發(fā)向SubPlan0的每一個節(jié)點病线；SubPlan2分配8個節(jié)點執(zhí)行最終的聚合操作；SubPlan3只負(fù)責(zé)輸出最后計算完成的數(shù)據(jù)鲤嫡。
outputPartitioning
OutputPartitioning屬性只有兩個值HASH和NONE，
表示這個SubPlan的輸出是否按照partitionBy的key值對數(shù)據(jù)進行Shuffle暖眼。在下面的執(zhí)行計劃中只有SubPlan0的OutputPartitioning=HASH，所以SubPlan2接收到的數(shù)據(jù)是按照rank字段Partition后的數(shù)據(jù)
partitionBy
低延時查詢核心技術(shù)
完全基于內(nèi)存的并行計算
上述查詢執(zhí)行流程赡突，均放在內(nèi)存線程中執(zhí)行
內(nèi)存中的數(shù)據(jù)模型
Presto中處理的最小數(shù)據(jù)單元是一個Page對象区赵，Page對象的數(shù)據(jù)結(jié)構(gòu)如下圖所示。
一個Page對象包含多個Block對象漱受，每個Block對象是一個字節(jié)數(shù)組昂羡，存儲一個字段的若干行摔踱。多個Block橫切的一行是真實的一行數(shù)據(jù)。一個Page最大1MB蛹批，最多16*1024行數(shù)據(jù)篮愉。
流水線計算
流水線模型
左側(cè)是任務(wù)的執(zhí)行流程圖
Worker節(jié)點將最細(xì)粒度的任務(wù)封裝成一個PrioritizedSplitRunner對象，放入pending split優(yōu)先級隊列中猪勇。每個
Worker節(jié)點啟動一定數(shù)目的線程進行計算泣刹，線程數(shù)task.shard.max-threads=availableProcessors() * 4助析，在config中配置。
每個空閑的線程從隊列中取出一個PrioritizedSplitRunner對象執(zhí)行貌笨，如果執(zhí)行完成一個周期襟沮，超過最大執(zhí)行時間1秒鐘昌腰，判斷任務(wù)是否執(zhí)行完成开伏，如果完成，從allSplits隊列中刪除固灵，如果沒有巫玻，則放回pendingSplits隊列中仍秤。
每個任務(wù)的執(zhí)行流程如下圖右側(cè)可很，依次遍歷所有Operator，嘗試從上一個Operator取一個Page對象我抠，如果取得的Page不為空，交給下一個Operator執(zhí)行瓣窄。
本地化計算
Presto在選擇Source任務(wù)計算節(jié)點的時候俺夕，對于每一個Split啥么，按下面的策略選擇一些minCandidates
優(yōu)先選擇與Split同一個Host的Worker節(jié)點
如果節(jié)點不夠優(yōu)先選擇與Split同一個Rack的Worker節(jié)點
如果節(jié)點還不夠隨機選擇其他Rack的節(jié)點
對于所有Candidate節(jié)點贰逾，選擇assignedSplits最少的節(jié)點。
動態(tài)編譯執(zhí)行計劃
小心使用內(nèi)存和數(shù)據(jù)結(jié)構(gòu)
類BlinkDB的近似查詢
引入了一些近似查詢函數(shù)approx_avg氯迂、approx_distinct、approx_percentile
GC控制
參考鏈接
更多文章參見 微信號: life_361
