presto 架構

1. 一個Coordinator節點

1. 一個Discovery Server節點

1. 多個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 Cli提交一個查詢語句後，Cli使用HTTP協議與Coordinator通訊，Coordinator收到查詢請求後呼叫SqlParser解析SQL語句得到Statement物件，並將Statement封裝成一個QueryStarter物件放入執行緒池中等待執行，如下圖:示例SQL如下

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

資料模型

1. catalog 對應某一類資料來源，例如hive的資料，或mysql的資料

2. schema 對應mysql中的資料庫

3. table 對應mysql中的表

   
   

presto的儲存單元包括：

1. Page： 多行資料的集合，包含多個列的資料，內部僅提供邏輯行，實際以列式儲存。

1. Block：一列資料，根據不同型別的資料，通常採取不同的編碼方式，瞭解這些編碼方式，有助於自己的儲存系統對接presto。

不同型別的block：

1. array型別block，應用於固定寬度的型別，例如int，long，double。block由兩部分組成

   • boolean valueIsNull[]表示每一行是否有值。
   • T values[] 每一行的具體值。

1. 可變寬度的block，應用於string類資料，由三部分資訊組成

   • Slice ： 所有行的資料拼接起來的字串。
   • int offsets[] :每一行資料的起始便宜位置。每一行的長度等於下一行的起始便宜減去當前行的起始便宜。
   • boolean valueIsNull[] 表示某一行是否有值。如果有某一行無值，那麼這一行的便宜量等於上一行的偏移量。

1. 固定寬度的string型別的block，所有行的資料拼接成一長串Slice，每一行的長度固定。

1. 字典block：對於某些列，distinct值較少，適合使用字典儲存。主要有兩部分組成：

   • 字典，可以是任意一種型別的block(甚至可以巢狀一個字典block)，block中的每一行按照順序排序編號。
   • int ids[] 表示每一行資料對應的value在字典中的編號。在查詢時，首先找到某一行的id，然後到字典中獲取真實的值。

推薦閱讀：

https://developer.aliyun.com/article/686001