Presto架構及原理
Presto 是 非死book 推出的一個基于Java開發的大數據分布式 SQL 查詢引擎，可對從數 G 到數 P 的大數據進行交互式的查詢，查詢的速度達到商業數據倉庫的級別，據稱該引擎的性能是 Hive 的 10 倍以上。Presto 可以查詢包括 Hive、Cassandra 甚至是一些商業的數據存儲產品，單個 Presto 查詢可合并來自多個數據源的數據進行統一分析。Presto 的目標是在可期望的響應時間內返回查詢結果，非死book 在內部多個數據存儲中使用 Presto 交互式查詢，包括 300PB 的數據倉庫，超過 1000 個 非死book 員工每天在使用 Presto 運行超過 3 萬個查詢，每天掃描超過 1PB 的數據。
目錄：
-
presto架構
-
presto低延遲原理
-
presto存儲插件
-
presto執行過程
-
presto引擎對比
Presto架構
-
Presto查詢引擎是一個 Master-Slave 的架構，由下面三部分組成:
-
一個Coordinator節點
-
一個Discovery Server節點
-
多個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屬性整個執行過程的流程圖如下：
-
PlanDistribution：表示一個查詢階段的分發方式，上圖中的4個SubPlan共有3種不同的PlanDistribution方式
-
Source ：表示這個SubPlan是數據源，Source類型的任務會按照數據源大小確定分配多少個節點進行執行
-
Fixed： 表示這個SubPlan會分配固定的節點數進行執行（Config配置中的query.initial-hash-partitions參數配置，默認是8）
-
None： 表示這個SubPlan只分配到一個節點進行執行
-
-
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
presto引擎對比
-
與hive、SparkSQL對比結果圖
來自：http://www.cnblogs.com/tgzhu/p/6033373.html