Presto架構及原理

原文鏈接：https://blog.csdn.net/dxl342/article/details/78127384

Presto 是 Facebook 推出的一個基於Java開發的大數據分佈式 SQL 查詢引擎，可對從數 G 到數 P 的大數據進行交互式的查詢，查詢的速度達到商業數據倉庫的級別，據稱該引擎的性能是 Hive 的 10 倍以上。Presto 可以查詢包括 Hive、Cassandra 甚至是一些商業的數據存儲產品，單個 Presto 查詢可合併來自多個數據源的數據進行統一分析。Presto 的目標是在可期望的響應時間內返回查詢結果，Facebook 在內部多個數據存儲中使用 Presto 交互式查詢，包括 300PB 的數據倉庫，超過 1000 個 Facebook 員工每天在使用 Presto 運行超過 3 萬個查詢，每天掃描超過 1PB 的數據。

目錄：

presto架構
presto低延遲原理
presto存儲插件
presto執行過程
presto引擎對比

Presto架構

Presto查詢引擎是一個Master-Slave的架構，由下面三部分組成:
1. 一個Coordinator節點
2. 一個Discovery Server節點
3. 多個Worker節點
Coordinator: 負責解析SQL語句，生成執行計劃，分發執行任務給Worker節點執行
Discovery Server: 通常內嵌於Coordinator節點中
Worker節點: 負責實際執行查詢任務,負責與HDFS交互讀取數據
Worker節點啓動後向Discovery Server服務註冊，Coordinator從Discovery Server獲得可以正常工作的Worker節點。如果配置了Hive Connector，需要配置一個Hive MetaStore服務爲Presto提供Hive元信息
更形象架構圖如下：

Presto低延遲原理

完全基於內存的並行計算
流水線式計算作業
本地化計算
動態編譯執行計劃
GC控制

Presto存儲插件

Presto設計了一個簡單的數據存儲的抽象層，來滿足在不同數據存儲系統之上都可以使用SQL進行查詢。
存儲插件（連接器,connector）只需要提供實現以下操作的接口，包括對元數據（metadata）的提取，獲得數據存儲的位置，獲取數據本身的操作等。
除了我們主要使用的Hive/HDFS後臺系統之外，我們也開發了一些連接其他系統的Presto 連接器，包括HBase，Scribe和定製開發的系統
插件結構圖如下：

presto執行過程

執行過程示意圖：
提交查詢：用戶使用Presto Cli提交一個查詢語句後，Cli使用HTTP協議與Coordinator通信，Coordinator收到查詢請求後調用SqlParser解析SQL語句得到Statement對象，並將Statement封裝成一個QueryStarter對象放入線程池中等待執行，如下圖:示例SQL如下

select c1.rank, count(*) from dim.city c1 join dim.city c2 on c1.id = c2.id where c1.id > 10 group by c1.rank limit 10;

邏輯執行過程示意圖如下：
上圖邏輯執行計劃圖中的虛線就是Presto對邏輯執行計劃的切分點，邏輯計劃Plan生成的SubPlan分爲四個部分，每一個SubPlan都會提交到一個或者多個Worker節點上執行
SubPlan有幾個重要的屬性planDistribution、outputPartitioning、partitionBy屬性整個執行過程的流程圖如下：
1. PlanDistribution：表示一個查詢階段的分發方式，上圖中的4個SubPlan共有3種不同的PlanDistribution方式
  - Source：表示這個SubPlan是數據源，Source類型的任務會按照數據源大小確定分配多少個節點進行執行
  - Fixed：表示這個SubPlan會分配固定的節點數進行執行（Config配置中的query.initial-hash-partitions參數配置，默認是8）
  - None：表示這個SubPlan只分配到一個節點進行執行
2. OutputPartitioning：表示這個SubPlan的輸出是否按照partitionBy的key值對數據進行Shuffle（洗牌），只有兩個值HASH和NONE
在上圖的執行計劃中，SubPlan1和SubPlan0 PlanDistribution=Source，這兩個SubPlan都是提供數據源的節點，SubPlan1所有節點的讀取數據都會發向SubPlan0的每一個節點；SubPlan2分配8個節點執行最終的聚合操作；SubPlan3只負責輸出最後計算完成的數據，如下圖：
SubPlan1和SubPlan0 作爲Source節點，它們讀取HDFS文件數據的方式就是調用的HDFS InputSplit API，然後每個InputSplit分配一個Worker節點去執行，每個Worker節點分配的InputSplit數目上限是參數可配置的，Config中的query.max-pending-splits-per-node參數配置，默認是100
SubPlan1的每個節點讀取一個Split的數據並過濾後將數據分發給每個SubPlan0節點進行Join操作和Partial Aggr操作
SubPlan0的每個節點計算完成後按GroupBy Key的Hash值將數據分發到不同的SubPlan2節點
所有SubPlan2節點計算完成後將數據分發到SubPlan3節點
SubPlan3節點計算完成後通知Coordinator結束查詢，並將數據發送給Coordinator