Presto查詢引擎簡單分析
Hive查詢流程分析
各個元件的作用
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
一旦這些輸出產生，將通過序列化器生成零時的的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