Presto查詢引擎簡單分析

Hive查詢流程分析

cdn.xitu.io/2019/6/24/16b8778e2a2c1915?imageView2/0/w/1280/h/960/format/webp/ignore-error/1">

各個組件的作用

UI(user interface)(用戶接口)：提交數據操作的窗口
Driver(引擎)：負責接收數據操作，實現了會話句柄，并提供基于JDBC / ODBC的execute和fetch API
Metastore(元數據)：Hive元數據，存儲所有表信息以及相關的HDFS文件存儲目錄，一般采用MySQL或者derby存儲
Compiler(編譯器)：解析查詢的SQL，生成階段性的執行計劃（包含MapReduce、元數據操作）
Execution Engine(執行引擎)：執行compiler生成的執行計劃。該執行計劃是一個階段的DAG

查詢流程

Step 1：UI調用的Driver的execute接口

Step 2：Driver為查詢創建會話句柄，并將查詢發送給compiler以生成執行計劃，

Step 3，4：compiler從metastore獲取相關的元數據

Step 5：檢查元數據，基于查詢謂詞調整分區，解析SQL，生成執行計劃

Step 6，6.1，6.2，6.3：由compiler生成的執行計劃是階段的DAG，每個階段都會涉及到Map/Reduce job，元數據的操作或者HDFS文件的操作。
在Map/Reduce階段，執行計劃包含Map操作樹(操作樹在Mappers上執行)和reduce操作樹(Reduce 操作樹在 Reducers上執行)，
Execution Engine 將各個階段提交個適當的組件執行。
Step 7, 8 and 9：在每個任務(mapper / reducer)中，表或者中間輸出相關的反序列化器從HDFS讀取行，并通過相關的操作樹進行傳遞。
一旦這些輸出產生，將通過序列化器生成零時的的HDFS文件(這個只發生在只有Map沒有reduce的情況)，生成的HDFS零時文件用于執行計劃后續的Map/Reduce階段。
對于DML操作，臨時文件最終移動到表的位置。該方案確保不出現臟數據讀取(文件重命名是HDFS中的原子操作)，
對于查詢，臨時文件的內容由Execution Engine直接從HDFS讀取，作為從Driver Fetch API的一部分

Presto查詢流程分析

在Map/Reduce階段 執?計劃包含Map操作樹 操作樹在Mappers上執? 和reduce

各個組件的作用

Client(客戶端)：提交數據操作的窗口

Discovery Server(服務發現者)：存儲可用的Server列表
Coordinator(協調者): 接收數據操作，解析SQL語句，生成查詢計劃，分發任務至Worker機
Connector Plugin(連接插件)：連接Storagr，提供元數據，支持Hive、Kafka、MySQL、MonogoDB、Redis、JMX等數據源，可自定義
Worker(執行者)：執行查詢計劃

查詢流程

1、Client使用HTTP協議發送一個query請求
2、通過Discovery Server發現可用的Server
3、Coordinator構建查詢計劃（通過Anltr3解析為AST（抽象語法樹），然后通過Connector獲取原始數據的Metadata信息，生成分發計劃和執行計劃）
4、Coordinator向workers發送任務
5、Worker通過Connector插件讀取數據
6、Worker在內存里執行任務（Worker是純內存型計算引擎）
7、Worker將數據返回給Coordinator，匯總之后再響應客戶端

Presto與Hive對比

區別：
MapReduce每個操作都需要寫磁盤，每個stage需要等待前一個stage全部完成才開始執行， ?
而Presto將SQL轉換為stage，每個stage又由多個tasks執行，每個tasks又將分為多個split。 ?
所有的task是并行的方式執行，stage之間數據是以pipeline形式流式的執行， ?
數據之間的傳輸也是通過網絡以Memory-to-Memory的形式進行，沒有磁盤io操作。 ?
這也是Presto性能比Hive快5-10倍的決定性原因

Presto缺點

1、沒有容錯能力，當一個query分發到多個Worker去執行時，當有一個Worker因為各種原因查詢失敗，Master感知到之后，整個query也會失敗

2、內存限制，由于Presto是純內存計算，所以當內存不夠時，Presto并不會將結果dump到磁盤上，所以查詢也就失敗了(據說最新版本的Presto已經支持寫盤操作)

3、并行查詢，因為所有的task都是并行執行，如果其中一臺Worker因為各種原因查詢很慢，那么整個query就會變得很慢

4、并發限制，因為全內存操作+內存限制，能同時處理的數據量有限，因而導致并發能力不足

Mob項目的應用
http://gitlab.code.mob.com/mobdata-plat/dbcloud-api