Presto架構及原理、安裝及部署

時間 2019-11-08

原文原文鏈接

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

目錄：java

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

Presto架構node

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低延遲原理mysql

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

Presto存儲插件linux

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

presto執行過程git

執行過程示意圖：
提交查詢：用戶使用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

presto引擎對比github

與hive、SparkSQL對比結果圖

1，Presto基本認識

1.1 定義
Presto是一個分佈式的查詢引擎，自己並不存儲數據，可是能夠接入多種數據源，而且支持跨數據源的級聯查詢。Presto是一個OLAP的工具，擅長對海量數據進行復雜的分析；可是對於OLTP場景，並非Presto所擅長，因此不要把Presto當作數據庫來使用。

和你們熟悉的Mysql相比：首先Mysql是一個數據庫，具備存儲和計算分析能力，而Presto只有計算分析能力；其次數據量方面，Mysql做爲傳統單點關係型數據庫不能知足當前大數據量的需求，因而有各類大數據的存儲和分析工具產生，Presto就是這樣一個能夠知足大數據量分析計算需求的一個工具。

1.2 數據源
Presto須要從其餘數據源獲取數據來進行運算分析，它能夠鏈接多種數據源，包括Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等

一條Presto查詢能夠將多個數據源的數據進行合併分析。
好比：select * from a join b where a.id=b.id;，其中表a能夠來自Hive，表b能夠來自Mysql。

1.3 優點
Presto是一個低延遲高併發的內存計算引擎，相比Hive，執行效率要高不少。

舉例：
SELECT id,
name,
source_type,
created_at
FROM dw_dwb.dwb_user_day
WHERE dt='2018-06-03'
AND created_at>’2018-05-20’;

上述SQL在Presto運行時間不到1秒鐘，在Hive裏要幾十秒鐘。

1.4數據模型
Presto使用Catalog、Schema和Table這3層結構來管理數據。

---- Catalog:就是數據源。Hive是數據源，Mysql也是數據源，Hive 和Mysql都是數據源類型，能夠鏈接多個Hive和多個Mysql，每一個鏈接都有一個名字。一個Catalog能夠包含多個Schema，你們能夠經過show catalogs 命令看到Presto鏈接的全部數據源。
---- Schema：至關於一個數據庫實例，一個Schema包含多張數據表。show schemas from 'catalog_name'可列出catalog_name下的全部schema。
---- Table：數據表，與通常意義上的數據庫表相同。show tables from 'catalog_name.schema_name'可查看'catalog_name.schema_name'下的全部表。

在Presto中定位一張表，通常是catalog爲根，例如：一張表的全稱爲 hive.test_data.test，標識 hive(catalog)下的 test_data(schema)中test表。
能夠簡理解爲：數據源的大類.數據庫.數據表。

2，Presto與Hive
Hive是一個基於HDFS(分佈式文件系統)的一個數據庫，具備存儲和分析計算能力，支持大數據量的存儲和查詢。Hive 做爲數據源，結合Presto分佈式查詢引擎，這樣大數據量的查詢計算速度就會快不少。

Presto支持標準SQL，這裏須要提醒你們的是，在使用Hive數據源的時候，若是表是分區表，必定要添加分區過濾，不加分區掃描全表是一個很暴力的操做，執行效率低下而且佔用大量集羣資源，你們儘可能避免這種寫法。

這裏提到Hive分區，我簡單介紹一下概念。Hive分區就是分目錄，把一個大的數據集根據業務須要分割成更細的數據集。

舉例：假如一個表的數據都放在/user/xiaoming/table/目錄下，若是想把數據按照天天的數據細分，則就變成/user/xiaoming/table/2018-06-01/，/user/xiaoming/table/2018-06-02/，……若是查詢某一天的數據，就能夠直接取某一天目錄下的數據，不須要掃描其餘天的數據，節省了時間和資源。

使用Presto:
3，Presto接入方式
Presto的接入方式有多種：presto-cli，pyhive，jdbc，http，golang，SQLAlchemy，PHP等，其中presto-cli是Presto官方提供的，下面以presto-cli爲例展開說明(自行下載)。

以鏈接hive數據源爲例，在電腦終端輸入：./presto-cli.jar --server presto.xxx-apps.com:9200 --catalog hive --user xxxx --source 'pf=adhoc;client=cli'就能夠進入presto終端界面。

先解釋下各參數的含義：

--server 是presto服務地址；
--catalog 是默認使用哪一個數據源，後面也能夠切換，若是想鏈接mysql數據源，使用mysql數據源名稱便可；
--user 是用戶名；
--source 是表明查詢來源，source設置格式爲key=value形式（英文分號分割）；例如我的從command line查詢應設置爲pf=adhoc;client=cli。

進入終端後:
查看數據源： show catalogs;
查看數據庫實例：show schemas;

Presto使用手冊：https://prestodb.io/docs/current/

問答：
1.使用場景？
－mysql跨數據庫查詢；－數倉的表數據查詢(數據分析) ...

2.爲何presto查詢速度比Hive快？
presto是常駐任務，接受請求當即執行，全內存並行計算；hive須要用yarn作資源調度，接受查詢須要先申請資源，啓動進程，而且中間結果會通過磁盤。golang

Presto簡介

不是什麼

雖然Presto能夠解析SQL，但它不是一個標準的數據庫。不是MySQL、PostgreSQL或者Oracle的代替品，也不能用來處理在線事務（OLTP）web

是什麼

Presto經過使用分佈式查詢，能夠快速高效的完成海量數據的查詢。做爲Hive和Pig的替代者，Presto不只能訪問HDFS，也能訪問不一樣的數據源，包括：RDBMS和其餘數據源（如Cassandra）。sql

架構

圖中各個組件的概念及做用會在下文講述。

Presto中SQL運行過程：MapReduce vs Presto

使用內存計算，減小與硬盤交互。

優勢

1.Presto與hive對比，都可以處理PB級別的海量數據分析，但Presto是基於內存運算，減小不必的硬盤IO，因此更快。
2.可以鏈接多個數據源，跨數據源連表查，如從hive查詢大量網站訪問記錄，而後從mysql中匹配出設備信息。
3.部署也比hive簡單，由於hive是基於HDFS的，須要先部署HDFS。

缺點

1.雖然可以處理PB級別的海量數據分析，但不是表明Presto把PB級別都放在內存中計算的。而是根據場景，如count，avg等聚合運算，是邊讀數據邊計算，再清內存，再讀數據再計算，這種耗的內存並不高。可是連表查，就可能產生大量的臨時數據，所以速度會變慢，反而hive此時會更擅長。
2.爲了達到實時查詢，可能會想到用它直連MySql來操做查詢，這效率並不會提高，瓶頸依然在MySql，此時還引入網絡瓶頸，因此會比本來直接操做數據庫要慢。

Presto概念

服務器類型（Server Types）

Presto有兩類服務器：coordinator和worker。

Coordinator

Coordinator服務器是用來解析語句，執行計劃分析和管理Presto的worker結點。Presto安裝必須有一個Coordinator和多個worker。若是用於開發環境和測試，則一個Presto實例能夠同時擔任這兩個角色。

Coordinator跟蹤每一個work的活動狀況並協調查詢語句的執行。 Coordinator爲每一個查詢創建模型，模型包含多個stage，每一個stage再轉爲task分發到不一樣的worker上執行。

Coordinator與Worker、client通訊是經過REST API。

Worker

Worker是負責執行任務和處理數據。Worker從connector獲取數據。Worker之間會交換中間數據。Coordinator是負責從Worker獲取結果並返回最終結果給client。

當Worker啓動時，會廣播本身去發現 Coordinator，並告知 Coordinator它是可用，隨時能夠接受task。

Worker與Coordinator、Worker通訊是經過REST API。

數據源

貫穿全文，你會看到一些術語：connector、catelog、schema和table。這些是Presto特定的數據源

Connector

Connector是適配器，用於Presto和數據源（如Hive、RDBMS）的鏈接。你能夠認爲相似JDBC那樣，但倒是Presto的SPI的實現，使用標準的API來與不一樣的數據源交互。
Presto有幾個內建Connector：JMX的Connector、System Connector（用於訪問內建的System table）、Hive的Connector、TPCH（用於TPC-H基準數據）。還有不少第三方的Connector，因此Presto能夠訪問不一樣數據源的數據。
每一個catalog都有一個特定的Connector。若是你使用catelog配置文件，你會發現每一個文件都必須包含connector.name屬性，用於指定catelog管理器（建立特定的Connector使用）。一個或多個catelog用一樣的connector是訪問一樣的數據庫。例如，你有兩個Hive集羣。你能夠在一個Presto集羣上配置兩個catelog，兩個catelog都是用Hive Connector，從而達到能夠查詢兩個Hive集羣。

Catelog

一個Catelog包含Schema和Connector。例如，你配置JMX的catelog，經過JXM Connector訪問JXM信息。當你執行一條SQL語句時，能夠同時運行在多個catelog。

Presto處理table時，是經過表的徹底限定（fully-qualified）名來找到catelog。例如，一個表的權限定名是hive.test_data.test，則test是表名，test_data是schema，hive是catelog。
Catelog的定義文件是在Presto的配置目錄中。

Schema

Schema是用於組織table。把catelog好schema結合在一塊兒來包含一組的表。當經過Presto訪問hive或Mysq時，一個schema會同時轉爲hive和mysql的同等概念。

Table

Table跟關係型的表定義同樣，但數據和表的映射是交給Connector。

執行查詢的模型（Query Execution Model）

語句（Statement）

Presto執行ANSI兼容的SQL語句。當Presto提起語句時，指的就是ANSI標準的SQL語句，包含着列名、表達式和謂詞。
之因此要把語句和查詢分開說，是由於Presto裏，語句知識簡單的文本SQL語句。而當語句執行時，Presto則會建立查詢和分佈式查詢計劃並在Worker上運行。

查詢（Query）

當Presto解析一個語句時，它將其轉換爲一個查詢，並建立一個分佈式查詢計劃（多個互信鏈接的stage，運行在Worker上）。若是想獲取Presto的查詢狀況，則獲取每一個組件（正在執行這語句的結點）的快照。
查詢和語句的區別是，語句是存SQL文本，而查詢是配置和實例化的組件。一個查詢包含：stage、task、split、connector、其餘組件和數據源。

Stage

當Presto執行查詢時，會將執行拆分爲有層次結構的stage。例如，從hive中的10億行數據中聚合數據，此時會建立一個用於聚合的根stage，用於聚合其餘stage的數據。
層次結構的stage相似一棵樹。每一個查詢都由一個根stage，用於聚合其餘stage的數據。stage是Coordinator的分佈式查詢計劃（distributed query plan）的模型，stage不是在worker上運行。

Task

因爲stage不是在worker上運行。stage又會被分爲多個task，在不一樣的work上執行。
Task是Presto結構裏是「work horse」。一個分佈式查詢計劃會被拆分爲多個stage，並再轉爲task，而後task就運行或處理split。Task有輸入和輸出，一個stage能夠分爲多個並行執行的task，一個task能夠分爲多個並行執行的driver。

Split

Task運行在split上。split是一個大數據集合中的一塊。分佈式查詢計劃最底層的stage是經過split從connector上獲取數據，分佈式查詢計劃中間層或頂層則是從它們下層的stage獲取數據。

Presto調度查詢，coordinator跟蹤每一個機器運行什麼任務，那些split正在被處理。

Driver

Task包含一個或多個並行的driver。Driver在數據上處理，並生成輸出，而後由Task聚合，最後傳送給stage的其餘task。一個driver是Operator的序列。driver是Presto最最低層的並行機制。一個driver有一個輸出和一個輸入。

Operator

Operator消費，傳送和生產數據。如一個Operator從connector中掃表獲取數據，而後生產數據給其餘Operator消費。一個過濾Operator消費數據，並應用謂詞，最後生產出子集數據。

Exchange

Exchange在Presto結點的不一樣stage之間傳送數據。Task生產和消費數據是經過Exchange客戶端。

參考：https://prestodb.io/docs/curr...

Presto的部署

安裝Presto

1.下載

wget https://repo1.maven.org/maven2/com/facebook/presto/presto-server/0.200/presto-server-0.200.tar.gz

2.解壓

tar -zxvf presto-server-0.200.tar.gz -C /usr/local/

/usr/local/presto-server-0.200則爲安裝目錄，另外Presto還須要數據目錄，數據目錄最好不要在安裝目錄裏面，方便後面Presto的版本升級。

配置Presto

在安裝目錄裏建立etc目錄。這目錄會有如下配置：

結點屬性（Node Properties）：每一個結點的環境配置
JVM配置（JVM Config）：Java虛擬機的命令行選項
配置屬性（Config Properties）：Persto server的配置
Catelog屬性（Catalog Properties）：配置Connector（數據源）

結點屬性（Node Properties）

結點屬性文件etc/node.properties，包含每一個結點的配置。一個結點是一個Presto實例。這文件通常是在Presto第一次安裝時建立的。如下是最小配置：

node.environment=production
node.id=ffffffff-ffff-ffff-ffff-ffffffffffff
node.data-dir=/var/presto/data

node.environment: 環境名字，Presto集羣中的結點的環境名字都必須是同樣的。
node.id: 惟一標識，每一個結點的標識都必須是爲一的。就算重啓或升級Presto都必須還保持原來的標識。
node.data-dir: 數據目錄，Presto用它來保存log和其餘數據。

JVM配置（JVM Config）

JVM配置文件etc/jvm.config，包含啓動Java虛擬機時的命令行選項。格式是每一行是一個命令行選項。此文件數據是由shell解析，因此選項中包含空格或特殊字符會被忽略。

如下是參考配置：

-server
-Xmx16G
-XX:+UseG1GC
-XX:G1HeapRegionSize=32M
-XX:+UseGCOverheadLimit
-XX:+ExplicitGCInvokesConcurrent
-XX:+HeapDumpOnOutOfMemoryError
-XX:+ExitOnOutOfMemoryError

由於OutOfMemoryError會致使JVM存在不一致狀態，因此用heap dump來debug，來找出進程爲何崩潰的緣由。

配置屬性（Config Properties）

配置屬性文件etc/config.properties，包含Presto server的配置。Presto server能夠同時爲coordinator和worker，但一個大集羣裏最好就是隻指定一臺機器爲coordinator。
如下是coordinator的最小配置：

coordinator=true
node-scheduler.include-coordinator=false
http-server.http.port=8080
query.max-memory=50GB
query.max-memory-per-node=1GB
discovery-server.enabled=true
discovery.uri=http://example.net:8080

如下是worker的最小配置：

coordinator=false
http-server.http.port=8080
query.max-memory=50GB
query.max-memory-per-node=1GB
discovery.uri=http://example.net:8080

若是適用於測試目的，須要將一臺機器同時配置爲coordinator和worker，則使用如下配置：

coordinator=true
node-scheduler.include-coordinator=true
http-server.http.port=8080
query.max-memory=5GB
query.max-memory-per-node=1GB
discovery-server.enabled=true
discovery.uri=http://example.net:8080

coordinator：是否運行該實例爲coordinator（接受client的查詢和管理查詢執行）。
node-scheduler.include-coordinator:coordinator是否也做爲work。對於大型集羣來講，在coordinator裏作worker的工做會影響查詢性能。
http-server.http.port:指定HTTP端口。Presto使用HTTP來與外部和內部進行交流。
query.max-memory: 查詢能用到的最大總內存
query.max-memory-per-node: 查詢能用到的最大單結點內存
discovery-server.enabled: Presto使用Discovery服務去找到集羣中的全部結點。每一個Presto實例在啓動時都會在Discovery服務裏註冊。這樣能夠簡化部署，不須要額外的服務，Presto的coordinator內置一個Discovery服務。也是使用HTTP端口。
discovery.uri: Discovery服務的URI。將example.net:8080替換爲coordinator的host和端口。這個URI不能以斜槓結尾，這個錯誤需特別注意，否則會報404錯誤。

另外還有如下屬性：
jmx.rmiregistry.port: 指定JMX RMI的註冊。JMX client能夠鏈接此端口
jmx.rmiserver.port: 指定JXM RMI的服務器。可經過JMX監聽。

詳情請查看Resource Groups

Catelog屬性（Catalog Properties）

Presto經過connector訪問數據。而connector是掛載（mount）在catelog中。connector支持catelog裏全部的schema和table。舉個例子，Hive connector映射每一個Hive數據庫到schema，所以Hive connector掛載在hive catelog（因此能夠把catelog理解爲目錄，掛載），並且Hive包含table clicks在數據庫web，因此這個table在Presto是hive.web.clicks。
Catalog的註冊是經過etc/catalog目錄下的catalog屬性文件。例如，建立etc/catalog/jmx.properties，將jmxconnector掛載在jmx catelog：

connector.name=jmx

查看Connectors查看更多信息。

運行Presto

啓動命令：

bin/launcher start

日誌在val/log目錄下：
launcher.log: 記錄服務初始化狀況和一些JVM的診斷。
server.log: Presto的主要日誌文件。會自動被壓縮。
http-request.log: 記錄HTTP請求。會自動被壓縮。

運行Presto命令行界面

1.下載 presto-cli-0.200-executable.jar,
2.修更名字 presto-cli-0.200-executable.jar爲 presto
3.修改執行權限chmod +x
4.運行

./presto --server localhost:8080 --catalog hive --schema default

1、Presto簡介

一、PRESTO是什麼？

Presto是一個開源的分佈式SQL查詢引擎，適用於交互式分析查詢，數據量支持GB到PB字節。

Presto的設計和編寫徹底是爲了解決像Facebook這樣規模的商業數據倉庫的交互式分析和處理速度的問題。

二、它能夠作什麼？

Presto支持在線數據查詢，包括Hive, Cassandra, 關係數據庫以及專有數據存儲。一條Presto查詢能夠將多個數據源的數據進行合併，能夠跨越整個組織進行分析。

Presto以分析師的需求做爲目標，他們指望響應時間小於1秒到幾分鐘。 Presto終結了數據分析的兩難選擇，要麼使用速度快的昂貴的商業方案，要麼使用消耗大量硬件的慢速的「免費」方案。

三、介紹

Presto是一個運行在多臺服務器上的分佈式系統。完整安裝包括一個coordinator和多個worker。由客戶端提交查詢，從Presto命令行CLI提交到coordinator。 coordinator進行解析，分析並執行查詢計劃，而後分發處理隊列到worker。

四、需求

Presto的基本需求

Linux or Mac OS X

Java 8, 64-bit

Python 2.4+

五、鏈接器

Presto支持插接式鏈接器提供的數據。各鏈接器的設計需求會有所不一樣。

HADOOP / HIVE

Presto支持從如下版本的Hadoop中讀取Hive數據：

Apache Hadoop 1.x

Apache Hadoop 2.x

Cloudera CDH 4

Cloudera CDH 5

支持如下文件類型：Text, SequenceFile, RCFile, ORC

此外，須要有遠程的Hive元數據。不支持本地或嵌入模式。 Presto不使用MapReduce，只須要HDFS。

2、Presto安裝部署

一、下載presto tar包：

https://repo1.maven.org/maven2/com/facebook/presto/presto-server/0.189/presto-server-0.189.tar.gz

二、將下載的presto tar包經過ftp工具上傳到linux服務器上，而後解壓安裝文件。

tar -zxvf presto-server-0.189.tar.gz -C /opt/cdh-5.3.6/

chown -R hadoop:hadoop /opt/cdh-5.3.6/presto-server-0.189/

三、配置presto

分別執行如下步驟：

在安裝目錄中建立一個etc目錄。在這個etc目錄中放入如下配置信息：

l 節點屬性：每一個節點的環境配置信息

l JVM 配置：JVM的命令行選項

l 配置屬性：Presto server的配置信息

l Catalog屬性：configuration forConnectors（數據源）的配置信息

1）Node Properties

節點屬性配置文件：etc/node.properties包含針對於每一個節點的特定的配置信息。一個節點就是在一臺機器上安裝的Presto實例。這份配置文件通常狀況下是在Presto第一次安裝的時候，由部署系統建立的。一個etc/node.properties配置文件至少包含以下配置信息：

node.environment=production

node.id=ffffffff-ffff-ffff-ffff-ffffffffffff

node.data-dir=/var/presto/data

針對上面的配置信息描述以下：

node.environment：集羣名稱。全部在同一個集羣中的Presto節點必須擁有相同的集羣名稱。

node.id：每一個Presto節點的惟一標示。每一個節點的node.id都必須是惟一的。在Presto進行重啓或者升級過程當中每一個節點的node.id必須保持不變。若是在一個節點上安裝多個Presto實例（例如：在同一臺機器上安裝多個Presto節點），那麼每一個Presto節點必須擁有惟一的node.id。

node.data-dir：數據存儲目錄的位置（操做系統上的路徑）。Presto將會把日期和數據存儲在這個目錄下。

2）JVM配置

JVM配置文件，etc/jvm.config，包含一系列在啓動JVM的時候須要使用的命令行選項。這份配置文件的格式是：一系列的選項，每行配置一個單獨的選項。因爲這些選項不在shell命令中使用。所以即便將每一個選項經過空格或者其餘的分隔符分開，java程序也不會將這些選項分開，而是做爲一個命令行選項處理。（就想下面例子中的OnOutOfMemoryError選項）。

一個典型的etc/jvm.config配置文件以下：

-server

-Xmx16G

-XX:+UseG1GC

-XX:G1HeapRegionSize=32M

-XX:+UseGCOverheadLimit

-XX:+ExplicitGCInvokesConcurrent

-XX:+HeapDumpOnOutOfMemoryError

-XX:+ExitOnOutOfMemoryError

因爲OutOfMemoryError將會致使JVM處於不一致狀態，因此遇到這種錯誤的時候咱們通常的處理措施就是將dump headp中的信息（用於debugging），而後強制終止進程。

Presto會將查詢編譯成字節碼文件，所以Presto會生成不少class，所以咱們咱們應該增大Perm區的大小（在Perm中主要存儲class）而且要容許Jvm class unloading。

3）Config Properties

Presto的配置文件：etc/config.properties包含了Presto server的全部配置信息。每一個Presto server既是一個coordinator也是一個worker。可是在大型集羣中，處於性能考慮，建議單獨用一臺機器做爲 coordinator。

一個coordinator的etc/config.properties應該至少包含如下信息：

coordinator=true

node-scheduler.include-coordinator=false

http-server.http.port=8080

query.max-memory=50GB

query.max-memory-per-node=1GB

discovery-server.enabled=true

discovery.uri=http://example.net:8080

如下是最基本的worker配置：

coordinator=false

http-server.http.port=8080

query.max-memory=50GB

query.max-memory-per-node=1GB

discovery.uri=http://example.net:8080

可是若是你用一臺機器進行測試，那麼這一臺機器將會即做爲coordinator，也做爲worker。配置文件將會以下所示：

coordinator=true

node-scheduler.include-coordinator=true

http-server.http.port=8080

query.max-memory=5GB

query.max-memory-per-node=1GB

discovery-server.enabled=true

discovery.uri=http://example.net:8080

對配置項解釋以下：

coordinator：指定是否運維Presto實例做爲一個coordinator(接收來自客戶端的查詢情切管理每一個查詢的執行過程)。

node-scheduler.include-coordinator：是否容許在coordinator服務中進行調度工做。對於大型的集羣，在一個節點上的Presto server即做爲coordinator又做爲worke將會下降查詢性能。由於若是一個服務器做爲worker使用，那麼大部分的資源都不會被worker佔用，那麼就不會有足夠的資源進行關鍵任務調度、管理和監控查詢執行。

http-server.http.port：指定HTTP server的端口。Presto 使用 HTTP進行內部和外部的全部通信。

task.max-memory=1GB：一個單獨的任務使用的最大內存 (一個查詢計劃的某個執行部分會在一個特定的節點上執行)。這個配置參數限制的GROUP BY語句中的Group的數目、JOIN關聯中的右關聯表的大小、ORDER BY語句中的行數和一個窗口函數中處理的行數。該參數應該根據併發查詢的數量和查詢的複雜度進行調整。若是該參數設置的過低，不少查詢將不能執行；可是若是設置的過高將會致使JVM把內存耗光。

discovery-server.enabled：Presto 經過Discovery 服務來找到集羣中全部的節點。爲了可以找到集羣中全部的節點，每個Presto實例都會在啓動的時候將本身註冊到discovery服務。Presto爲了簡化部署，而且也不想再增長一個新的服務進程，Presto coordinator 能夠運行一個內嵌在coordinator 裏面的Discovery 服務。這個內嵌的Discovery 服務和Presto共享HTTP server而且使用一樣的端口。

discovery.uri：Discovery server的URI。因爲啓用了Presto coordinator內嵌的Discovery 服務，所以這個uri就是Presto coordinator的uri。修改example.net:8080，根據你的實際環境設置該URI。注意：這個URI必定不能以「/「結尾。

4）日誌級別

日誌配置文件：etc/log.properties。在這個配置文件中容許你根據不一樣的日誌結構設置不一樣的日誌級別。每一個logger都有一個名字（一般是使用logger的類的全標示類名）. Loggers經過名字中的「.「來表示層級和集成關係。 (像java裏面的包). 以下面的log配置信息：

com.facebook.presto=INFO

This would set the minimum level to INFO for both com.facebook.presto.server and com.facebook.presto.hive. The default minimum level is INFO (thus the above example does not actually change anything). There are four levels: DEBUG, INFO, WARN and ERROR.

5）Catalog Properties

Presto經過connectors訪問數據。這些connectors掛載在catalogs上。 connector 能夠提供一個catalog中全部的schema和表。例如： Hive connector 將每一個hive的database都映射成爲一個schema，因此若是hive connector掛載到了名爲hive的catalog，而且在hive的web有一張名爲clicks的表，那麼在Presto中能夠經過hive.web.clicks來訪問這張表。

經過在etc/catalog目錄下建立catalog屬性文件來完成catalogs的註冊。例如：能夠先建立一個etc/catalog/jmx.properties文件，文件中的內容以下，完成在jmxcatalog上掛載一個jmxconnector：

connector.name=jmx

查看Connectors的詳細配置選項。

四、運行Presto

在安裝目錄的bin/launcher文件，就是啓動腳本。Presto可使用以下命令做爲一個後臺進程啓動：

bin/launcher start

另外，也能夠在前臺運行，日誌和相關輸出將會寫入stdout/stderr（可使用相似daemontools的工具捕捉這兩個數據流）：

bin/launcher run

運行bin/launcher–help，Presto將會列出支持的命令和命令行選項。另外能夠經過運行bin/launcher–verbose命令，來調試安裝是否正確。

啓動完以後，日誌將會寫在var/log目錄下，該目錄下有以下文件：

launcher.log：這個日誌文件由launcher建立，而且server的stdout和stderr都被重定向到了這個日誌文件中。這份日誌文件中只會有不多的信息，包括：

在server日誌系統初始化的時候產生的日誌和JVM產生的診斷和測試信息。

server.log：這個是Presto使用的主要日誌文件。通常狀況下，該文件中將會包括server初始化失敗時產生的相關信息。這份文件會被自動輪轉和壓縮。

http-request.log：這是HTTP請求的日誌文件，包括server收到的每一個HTTP請求信息，這份文件會被自動輪轉和壓縮。

3、部署presto client

一、下載：

https://repo1.maven.org/maven2/com/facebook/presto/presto-cli/0.189/presto-cli-0.189-executable.jar

上傳linux服務器上，重命名爲presto：

$mv presto-cli-0.189-executable.jar presto

$chmod a+x presto

執行如下命令：

$ ./presto --server localhost:8080 --catalog hive --schema default

4、proste鏈接hive

一、編輯hive-site.xml文件，增長如下內容：

<name>hive.server2.thrift.port</name>

</property>

<name>hive.server2.thrift.bind.host</name>

<value>chavin.king</value>

</property>

<name>hive.metastore.uris</name>

<value>thrift://chavin.king:9083</value>

</property>

二、啓動hiveserver2和hive元數據服務：

bin/hive --service hiveserver2 &

bin/hive --service matestore &

三、配置hive插件，etc/catalog目錄下建立hive.properties文件，輸入以下內容。

3.1）hive配置：

connector.name=hive-hadoop2 #這個鏈接器的選擇要根據自身集羣狀況結合插件包的名字來寫

hive.metastore.uri=thrift://chavin.king:9083 #修改成 hive-metastore 服務所在的主機名稱，這裏我是安裝在master節點

3.2）HDFS Configuration：

若是hive metastore的引用文件存放在一個存在聯邦的HDFS上，或者你是經過其餘非標準的客戶端來訪問HDFS集羣的，請添加如下配置信息來指向你的HDFS配置文件:

hive.config.resources=/etc/hadoop/conf/core-site.xml,/etc/hadoop/conf/hdfs-site.xml

大多數狀況下，Presto會在安裝過程當中自動完成HDFS客戶端的配置。若是確實須要特殊配置，只須要添加一些額外的配置文件，而且須要指定這些新加的配置文件。建議將配置文件中的配置屬性最小化。儘可能少添加一些配置屬性，由於過多的添加配置屬性會引發其餘問題。

3.3）Configuration Properties

Property Name	Description	Example
hive.metastore.uri	The URI of the Hive Metastore to connect to using the Thrift protocol. This property is required.	thrift://192.0.2.3:9083
hive.config.resources	An optional comma-separated list of HDFS configuration files. These files must exist on the machines running Presto. Only specify this if absolutely necessary to access HDFS.	/etc/hdfs-site.xml
hive.storage-format	The default file format used when creating new tables	RCBINARY
hive.force-local-scheduling	Force splits to be scheduled on the same node as the Hadoop DataNode process serving the split data. This is useful for installations where Presto is collocated with every DataNode.	true

四、presto鏈接hive schema，注意presto不能進行垮庫join操做，測試結果以下：

$ ./presto --server localhost:8080 --catalog hive --schema chavin

presto:chavin> select * from emp;

-------+--------+-----------+------+------------+--------+--------+--------

7369 | SMITH | CLERK | 7902 | 1980/12/17 | 800.0 | NULL | 20

7499 | ALLEN | SALESMAN | 7698 | 1981/2/20 | 1600.0 | 300.0 | 30

7521 | WARD | SALESMAN | 7698 | 1981/2/22 | 1250.0 | 500.0 | 30

7566 | JONES | MANAGER | 7839 | 1981/4/2 | 2975.0 | NULL | 20

7654 | MARTIN | SALESMAN | 7698 | 1981/9/28 | 1250.0 | 1400.0 | 30

7698 | BLAKE | MANAGER | 7839 | 1981/5/1 | 2850.0 | NULL | 30

7782 | CLARK | MANAGER | 7839 | 1981/6/9 | 2450.0 | NULL | 10

7788 | SCOTT | ANALYST | 7566 | 1987/4/19 | 3000.0 | NULL | 20

7839 | KING | PRESIDENT | NULL | 1981/11/17 | 5000.0 | NULL | 10

7844 | TURNER | SALESMAN | 7698 | 1981/9/8 | 1500.0 | 0.0 | 30

7876 | ADAMS | CLERK | 7788 | 1987/5/23 | 1100.0 | NULL | 20

7900 | JAMES | CLERK | 7698 | 1981/12/3 | 950.0 | NULL | 30

7902 | FORD | ANALYST | 7566 | 1981/12/3 | 3000.0 | NULL | 20

7934 | MILLER | CLERK | 7782 | 1982/1/23 | 1300.0 | NULL | 10

(14 rows)

Query 20170711_081802_00002_ydh8n, FINISHED, 1 node

Splits: 17 total, 17 done (100.00%)

0:05 [14 rows, 657B] [2 rows/s, 130B/s]

presto:chavin>

5、JDBC驅動

經過使用JDBC驅動，能夠訪問Presto。下載presto-jdbc-0.100.jar並將這個jar文件添加到你的java應用程序的classpath中，Presto支持的URL格式以下：

jdbc:presto://host:port

jdbc:presto://host:port/catalog

jdbc:presto://host:port/catalog/schema

例如，可使用下面的URL來鏈接運行在example.net服務器8080端口上的Presto的hive catalog中的sales schema：

jdbc:presto://example.net:8080/hive/sales

6、presto管理之隊列配置

排隊規則定義在一個Json文件中，用於控制可以提交給Presto的查詢的個數，以及每一個隊列中可以同時運行的查詢的個數。用config.properties中的query.queue-config-file來指定Json配置文件的名字。

排隊規則若是定義了多個隊列，查詢會按順序依次進入不一樣的隊列中。排隊規則將按照順序進行處理，而且使用第一個匹配上的規則。在如下的配置例子中，有5個隊列模板，在user.${USER}隊列中，${USER}表示着提交查詢的用戶名。一樣的${SOURCE}表示提交查詢的來源。

一樣有五條規則定義了哪一類查詢會進入哪個隊列中：

第一條規則將使bob成爲管理員，bob提交的查詢進入admin隊列。

第二條規則表示，全部使用了experimental_big_querysession參數而且來源包含pipeline的查詢將首先進入用戶的我的隊列中，而後進入pipeline隊列，最後進入big隊列中。當一個查詢進入一個新的隊列後，直到查詢結束纔會離開以前的隊列。

第三條規則同上一條相似，可是沒有experimental_big_query的要求，同時用global隊列替換了big隊列。

最後兩條規則跟以上兩條規則相似，可是沒有了pipeline來源的要求。

全部這些規則實現了這樣的策略，bob是一個管理員，而其餘用戶須要遵循如下的限制：

每一個用戶最多能同時運行5個查詢。

big查詢同時只能運行一個

最多能同時運行10個pipeline來源的查詢。

最多能同時運行100個非big查詢

{

"queues": {

"user.${USER}": {

"maxConcurrent": 5,

"maxQueued": 20

"pipeline": {

"maxConcurrent": 10,

"maxQueued": 100

"admin": {

"maxConcurrent": 100,

"maxQueued": 100

"global": {

"maxConcurrent": 100,

"maxQueued": 1000

"big": {

"maxConcurrent": 1,

"maxQueued": 10

}

"rules": [

{

"user": "bob",

"queues": ["admin"]

{

"session.experimental_big_query": "true",

"source": ".*pipeline.*",

"queues": [

"user.${USER}",

"pipeline",

"big"

]

{

"source": ".*pipeline.*",

"queues": [

"user.${USER}",

"pipeline",

"global"

]

{

"session.experimental_big_query": "true",

"queues": [

"user.${USER}",

"big"

]

{

"queues": [

"user.${USER}",

"global"

]

}

]

}

7、presto鏈接mysql數據庫

一、在etc/catalog目錄下建立文件mysql.properties，輸入以下內容，保存退出。

connector.name=mysql

connection-url=jdbc:mysql://example.net:3306

connection-user=root

connection-password=secret

二、presto客戶端鏈接mysql服務並執行查詢：

$ ./presto --server localhost:8080 --catalog mysql --schema chavin

presto:chavin> select * from mysql.chavin.emp;

-------+--------+-----------+------+------------+--------+--------+--------

7369 | SMITH | CLERK | 7902 | 1980-12-17 | 800.0 | NULL | 20

7499 | ALLEN | SALESMAN | 7698 | 1981-02-20 | 1600.0 | 300.0 | 30

7521 | WARD | SALESMAN | 7698 | 1981-02-22 | 1250.0 | 500.0 | 30

7566 | JONES | MANAGER | 7839 | 1981-04-02 | 2975.0 | NULL | 20

7654 | MARTIN | SALESMAN | 7698 | 1981-09-28 | 1250.0 | 1400.0 | 30

7698 | BLAKE | MANAGER | 7839 | 1981-05-01 | 2850.0 | NULL | 30

7782 | CLARK | MANAGER | 7839 | 1981-06-09 | 2450.0 | NULL | 10

7788 | SCOTT | ANALYST | 7566 | 1987-04-19 | 3000.0 | NULL | 20

7839 | KING | PRESIDENT | NULL | 1981-11-17 | 5000.0 | NULL | 10

7844 | TURNER | SALESMAN | 7698 | 1981-09-08 | 1500.0 | 0.0 | 30

7876 | ADAMS | CLERK | 7788 | 1987-05-23 | 1100.0 | NULL | 20

7900 | JAMES | CLERK | 7698 | 1981-12-03 | 950.0 | NULL | 30

7902 | FORD | ANALYST | 7566 | 1981-12-03 | 3000.0 | NULL | 20

7934 | MILLER | CLERK | 7782 | 1982-01-23 | 1300.0 | NULL | 10

(14 rows)

Query 20170711_085557_00002_hpvqh, FINISHED, 1 node

Splits: 17 total, 17 done (100.00%)

0:00 [14 rows, 0B] [28 rows/s, 0B/s]

8、presto鏈接postgresql

一、在etc/catalog目錄下建立文件postgresql.properties文件，添加以下內容：

connector.name=postgresql

connection-url=jdbc:postgresql://example.net:5432/database

connection-user=root

connection-password=secret

二、經過presto客戶端查詢postgresql數據庫：

$ ./presto --server localhost:8080 --catalog postgresql --schema postgres

附：

參考文檔：https://prestodb.io/docs/current/

presto是什麼

是Facebook開源的，徹底基於內存的並⾏計算，分佈式SQL交互式查詢引擎

是一種Massively parallel processing (MPP)架構，多個節點管道式執⾏

⽀持任意數據源（經過擴展式Connector組件），數據規模GB~PB級

使用的技術，如向量計算，動態編譯執⾏計劃，優化的ORC和Parquet Reader等

presto不太支持存儲過程，支持部分標準sql

presto的查詢速度比hive快5-10倍

上面講述了presto是什麼，查詢速度，如今來看看presto適合幹什麼

適合：PB級海量數據複雜分析，交互式SQL查詢，⽀持跨數據源查詢

不適合：多個大表的join操做，由於presto是基於內存的，多張大表在內存裏可能放不下

和hive的對比：

hive是一個數據倉庫，是一個交互式比較弱一點的查詢引擎，交互式沒有presto那麼強，並且只能訪問hdfs的數據

presto是一個交互式查詢引擎，能夠在很短的時間內返回查詢結果，秒級，分鐘級，能訪問不少數據源

hive在查詢100Gb級別的數據時，消耗時間已是分鐘級了

可是presto是取代不了hive的，由於p所有的數據都是在內存中，限制了在內存中的數據集大小，好比多個大表的join，這些大表是不能徹底放進內存的，實際應用中，對於在presto的查詢是有必定規定條件的，比好比說一個查詢在presto查詢超過30分鐘，那就kill掉吧，說明不適合在presto上使用，主要緣由是，查詢過大的話，會佔用整個集羣的資源，這會致使你後續的查詢是沒有資源進行查詢的，這跟presto的設計理念是衝突的，就像是你進行一個查詢，可是要等個5分鐘纔有資源繼續查詢，這是很不合理的，交互式就變得弱了不少

presto基本架構

在談presto架構以前，先回顧下hive的架構

hive：client將查詢請求發送到hive server，它會和metastor交互，獲取表的元信息，如表的位置結構等，以後hive server會進行語法解析，解析成語法樹，變成查詢計劃，進行優化後，將查詢計劃交給執行引擎，默認是MR，而後翻譯成MR

presto：presto是在它內部作hive相似的邏輯

接下來，深刻看下presto的內部架構

這裏面三個服務：

Coordinator是一箇中心的查詢角色，它主要的一個做用是接受查詢請求，將他們轉換成各類各樣的任務，將任務拆解後分發到多個worker去執行各類任務的節點

一、解析SQL語句

二、⽣成執⾏計劃

三、分發執⾏任務給Worker節點執⾏

Worker，是一個真正的計算的節點，執行任務的節點，它接收到task後，就會到對應的數據源裏面，去把數據提取出來，提取方式是經過各類各樣的connector：

一、負責實際執⾏查詢任務

Discovery service，是將coordinator和woker結合到一塊兒的服務：

一、Worker節點啓動後向Discovery Server服務註冊

二、Coordinator從Discovery Server得到Worker節點

coordinator和woker之間的關係是怎麼維護的呢？是經過Discovery Server，全部的worker都把本身註冊到Discovery Server上，Discovery Server是一個發現服務的service，Discovery Server發現服務以後，coordinator便知道在個人集羣中有多少個worker可以給我工做，而後我分配工做到worker時便有了根據

最後，presto是經過connector plugin獲取數據和元信息的，它不是⼀個數據存儲引擎，不須要有數據，presto爲其餘數據存儲系統提供了SQL能⼒，客戶端協議是HTTP+JSON

Presto支持的數據源和存儲格式

Hadoop/Hive connector與存儲格式：

HDFS，ORC，RCFILE，Parquet，SequenceFile，Text

開源數據存儲系統：

MySQL & PostgreSQL，Cassandra，Kafka，Redis

其餘：

MongoDB，ElasticSearch，HBase

Presto中SQL運行過程：總體流程

一、當咱們執行一條sql查詢，coordinator接收到這條sql語句之後，它會有一個sql的語法解析器去把sql語法解析變成一個抽象的語法樹AST，這抽象的語法書它裏面只是進行一些語法解析，若是你的sql語句裏面，好比說關鍵字你用的是int而不是Integer，就會在語法解析這裏給暴露出來

二、若是語法是符合sql語法規範，以後會通過一個邏輯查詢計劃器的組件，他的主要做用是，好比說你sql裏面出現的表，他會經過connector的方式去meta裏面把表的schema，列名，列的類型等，所有給找出來，將這些信息，跟語法樹給對應起來，以後會生成一個物理的語法樹節點，這個語法樹節點裏面，不只擁有了它的查詢關係，還擁有類型的關係，若是在這一步，數據庫表裏某一列的類型，跟你sql的類型不一致，就會在這裏報錯

三、若是經過，就會獲得一個邏輯的查詢計劃，而後這個邏輯查詢計劃，會被送到一個分佈式的邏輯查詢計劃器裏面，進行一個分佈式的解析，分佈式解析裏面，他就會去把對應的每個查詢計劃轉化爲task

四、在每個task裏面，他會把對應的位置信息所有給提取出來，交給執行的plan，由plan把對應的task發給對應的worker去執行，這就是整個的一個過程

這是一個通用的sql解析流程，像hive也是遵循相似這樣的流程，不同的地方是distribution planner和executor pan，這裏是各個引擎不同的地方，前面基本上都一致的

Presto中SQL運行過程：MapReduce vs Presto

task是放在每一個worker上該執行的，每一個task執行完以後，數據是存放在內存裏了，而不像mr要寫磁盤，而後當多個task之間要進行數據交換，好比shuffle的時候，直接從內存裏處理

Presto監控和配置：監控

Web UI

　　Query基本狀態的查詢

JMX HTTP API

　　GET /v1/jmx/mbean[/{objectName}]
　　　　• com.facebook.presto.execution:name=TaskManager
　　　　• com.facebook.presto.execution:name=QueryManager
　　　　• com.facebook.presto.execution:name=NodeScheduler
事件通知
　　Event Listener
　　　　• query start, query complete

Presto監控和配置：配置

執行計劃計劃（Coordinator）

node-scheduler.include-coordinator

　　• 是否讓coordinator運行task

query.initial-hash-partitions

　　• 每一個GROUP BY操做使⽤的hash bucket(=tasks)最大數目(default: 8)

node-scheduler.min-candidates

　　• 每一個stage併發運行過程當中可以使用的最大worker數目（default：10）

query.schedule-split-batch-size

　　• 每一個split數據量

任務執行（Worker）

query.max-memory (default: 20 GB)

　　• 一個查詢可使用的最大集羣內存

　　• 控制集羣資源使用，防止一個大查詢佔住集羣全部資源

　　• 使用resource_overcommit能夠突破限制

query.max-memory-per-node (default: 1 GB)

　　• 一個查詢在一個節點上可使用的最大內存

舉例

　　• Presto集羣配置： 120G * 40

　　• query.max-memory=1 TB

　　• query.max-memory-per-node=20 GB

query.max-run-time (default: 100 d)

　　• 一個查詢能夠運行的最大時間

　　• 防止用戶提交一個長時間查詢阻塞其餘查詢

task.max-worker-threads (default: Node CPUs * 4)

　　• 每一個worker同時運行的split個數

　　• 調大能夠增長吞吐率，可是會增長內存的消耗

隊列（Queue）

任務提交或者資源使用的一些配置，是經過隊列的配置來實現的

資源隔離，查詢能夠提交到相應隊列中

• 資源隔離，查詢能夠提交到相應隊列中
• 每一個隊列能夠配置ACL（權限）
• 每一個隊列能夠配置Quota
　　能夠併發運行查詢的數量
　　排隊的最大數量

大數據OLAP引擎對比

Presto：內存計算，mpp架構

Druid：時序，數據放內存，索引，預計算

Spark SQL：基於Spark Core，mpp架構

Kylin：Cube預計算　　

最後，一些零散的知識點

presto適合pb級的海量數據查詢分析，不是說把pb的數據放進內存，好比一張pb表，查詢count，vag這種有個特色，雖然數據不少，可是最終的查詢結果很小，這種就不會把數據都放到內存裏面，只是在運算的過程當中，拿出一些數據放內存，而後計算，在拋出，在拿，這種的內存佔用量是很小的，可是join這種，在運算的中間過程會產生大量的數據，或者說那種查詢的數據不大，可是生成的數據量很大，這種也是不合適用presto的，但不是說不能作，只是會佔用大量內存，消耗很長的時間，這種hive合適點

presto算是hive的一個補充，須要儘快得出結果的用presto，不然用hive

work是部署的時候就事先部署好的，work啓動100個，使用的work不必定100個，而是根據coordinator來決定拆分紅多少個task，而後分發到多少個work去

一個coordinator可能同時又多個用戶在請求query，而後共享work的去執行，這是一個共享的集羣

coordinator和discovery server能夠啓動在一個節點一個進程，也能夠放在不一樣的node上，可是如今公司大部分都是放在一個節點上，一個launcher start會同時把上述兩個啓動起來

對於presto的容錯，若是某個worker掛掉了，discovery server會發現並通知coordinator

可是對於一個query，是沒有容錯的，一旦一個work掛了，那麼整個qurey就是敗了

由於對於presto，他的查詢時間是很短的，與其查詢這裏作容錯能力，不如從新執行來的快來的簡單

對於coordinator和discovery server節點的單點故障，presto尚未開始處理這個問題貌似

Presto是一款由FaceBook開源的一個分佈式SQL-on—Hadoop分析引擎。Presto目前由開源社區和FaceBook內部工程師共同維護，並衍生出多個商業版本。

基本特性

Presto使用Java語言進行開發，具有易用、高性能、強擴展能力等特色，具體的：

徹底支持ANSI SQL。
支持豐富的數據源 Presto可接入豐富的數據來源，以下所示：
- 與Hive數倉互操做
- Cassandra
- Kafka
- MongoDB
- MySQL
- PostgreSQL
- SQL Server
- Redis
- Redshift
- 本地文件
支持高級數據結構：
- 支持數組和Map數據。
- 支持JSON數據。
- 支持GIS數據。
- 支持顏色數據。
功能擴展能力強 Presto提供了多種擴展機制，包括：
- 擴展數據鏈接器。
- 自定義數據類型。
- 自定義SQL函數。
用戶能夠根據自身業務特色擴展相應的模塊，實現高效的業務處理。
基於Pipeline處理模型數據在處理過程當中實時返回給用戶。
監控接口完善：
- 提供友好的WebUI，可視化的呈現查詢任務執行過程。
- 支持JMX協議。

應用場景

Presto是定位在數據倉庫和數據分析業務的分佈式SQL引擎，比較適合以下幾個應用場景：

ETL
Ad-Hoc查詢
海量結構化數據/半結構化數據分析
海量多維數據聚合/報表

特別須要注意的是，Presto是一個數倉類產品，其設計目標並非爲了替代MySQL、PostgreSQL等傳統的RDBMS數據庫，對事務對支持有限，不適合在線業務場景。

產品優點

EMR Presto產品除了開源Presto自己具備的優勢外，還具有以下優點：

即買即用分分鐘完成上百節點的Presto集羣搭建。
彈性擴容簡單操做便可完成集羣的擴容和縮容。
與EMR軟件棧完美結合，支持處理存儲在OSS的數據。
免運維 7*24一站式服務

本章將介紹Presto數據庫的基本使用方法和應用開發方法，使開發者可以快速的使用Presto數據庫進行應用開發。

系統組成

Presto的系統組成以下圖所示：

Presto是典型的M/S架構的系統，由一個Coordinator節點和多個Worker節點組成。Coordinator負責以下工做：

接收用戶查詢請求，解析並生成執行計劃，下發Worker節點執行。
監控Worker節點運行狀態，各個Worker節點與Coordinator節點保持心跳鏈接，彙報節點狀態。
維護MetaStore數據。

Worker節點負責執行下發到任務，經過鏈接器讀取外部存儲系統到數據，進行處理，並將處理結果發送給Coordinator節點。

基本概念

本節介紹Presto中到基本概念，以便更好到理解Presto到工做機制。

數據模型
數據模型即數據的組織形式。Presto使用 Catalog、Schema 和 Table 這3層結構來管理數據。
- Catalog
  
  一個 Catalog 能夠包含多個 Schema，物理上指向一個外部數據源，能夠經過 Connector 訪問改數據源。一次查詢能夠訪問一個或多個 Catalog。
- Schema
  
  至關於一個數據庫示例，一個 Schema 包含多張數據表。
- Table
  
  數據表，與通常意義上的數據庫表相同。
Catalog、Schema 和 Table 之間的關係以下圖所示：
Connector
Presto經過各類 Connector 來接入多種外部數據源。Presto提供了一套標準的SPI接口，用戶可使用這套接口，開發本身的 Connector，以便訪問自定義的數據源。

一個 Catalog 通常會綁定一種類型的 Connector（在 Catalog 的 Properties 文件中設置）。Presto內置了多種 Connector 實現。
查詢相關概念
本節主要介紹Presto查詢過程當中的相關概念，以便用戶可以更好的理解Presto查詢語句執行過程和性能調優方法。
- Statement
  
  即查詢語句，表示用戶經過JDBC或CLI輸入對SQL語句。
- Query
  
  表示一次查詢的執行過程，Presto接收到一個SQL Statement 後，在Coordinator中進行解析，生成執行計劃，下發到Worker中執行。一個 Query 邏輯上由 Stage，Task，Driver，Split，Operator 和 DataSource 幾個組件組成，以下所示：
- Stage
  
  Presto中的一個 Query 由多個 Stage 組成，Stage 是一個邏輯概念，表示查詢過程的一個階段，包含了一個或多個執行任務（Task）。Presto採用樹狀結構組織 Stage，該樹的Root節點爲 Single Stage，該Stage會匯聚其上游Stage輸出的數據，進行聚合運算，將結果直接發送給 Coordinator。該樹的葉子節點爲 Source Stage，該Stage從 Connector 獲取數據進行處理。
- Task
  
  Task 表示一個具體的執行任務，是Presto任務調度的最小單元，執行過程當中，Presto任務調度器會將這些Task調度到各個Worker上執行。一個Stage中的任務能夠並行執行。兩個Stage之間的任務經過 Exchange 模塊傳遞數據。Task也是一個邏輯概念，包含了任務的參數和內容，實際的任務執行工做由 Driver 完成。
- Driver
  
  Driver 負責執行具體的任務工做。一個 Task 能夠包含多個 Driver 實例，從而實現Task內部的並行處理。一個Driver 處理一個數據分片（Split）。一個 Driver 內部一組 Operator 組成，負責具體的數據操做，如轉換、過濾等。
- Operator
  
  Operator 是最小的執行單元，負責對數據分片（Split）中的每個 Page 進行處理，如加權、轉換等，概念上與算子相似。Page 是 Operator 處理的最小數據單元，是一個列式的數據結構。一個 Page 對象由多個 Block 組成，每一個 Block 表明一個字段的多行數據。一個Page最大爲1MB，最多包含16*1024行數據。
- Exchange
  
  兩個 Stage 之間經過 Exchange 模塊進行數據交換。實際的數據傳輸過程出如今兩個 Task 之間。一般，下游的 Task 會經過其上的 Exchange Client 模塊從其上游 Task 的 Output Buffer 中拉去數據。拉取的數據以 Split 爲單位傳遞給 Driver 進行處理。

命令行工具

經過SSH登入EMR集羣，執行下面對命令進入Presto控制檯：

試用

$ presto --server emr-header-1:9090 --catalog hive --schema default --user hadoop

高安全集羣使用以下命令形式：

試用

$ presto  --server https://emr-header-1:7778  \
          --enable-authentication \
          --krb5-config-path /etc/krb5.conf \
          --krb5-keytab-path  /etc/ecm/presto-conf/presto.keytab \
          --krb5-remote-service-name presto \
          --keystore-path /etc/ecm/presto-conf/keystore \
          --keystore-password 81ba14ce6084 \
          --catalog hive --schema default \
          --krb5-principal  presto/emr-header-1.cluster-XXXX@EMR.XXXX.COM

XXXX 爲集羣的 ecm id，爲一串數字，能夠經過 cat /etc/hosts 獲取。
81ba14ce6084 爲 /etc/ecm/presto-conf/keystore 的默認密碼，建議部署後替換爲本身的keystore.

接下來就可已在該控制檯下執行如下命令：

試用

presto:default> show schemas;
    Schema
--------------------
default
hive
information_schema
tpch_100gb_orc
tpch_10gb_orc
tpch_10tb_orc
tpch_1tb_orc
(7 rows)

執行 presto --help 命令能夠獲取控制檯的幫助，各個參數對解釋以下所示：

試用

--server <server>                       # 指定Coordinator的URI
--user <user>                           # 設置用戶名
--catalog <catalog>                     # 指定默認的Catalog
--schema <schema>                       # 指定默認的Schema
--execute <execute>                     # 執行一條語句，而後退出
-f <file>, --file <file>                # 執行一個SQL文件，而後退出
--debug                                 # 顯示調試信息
--client-request-timeout <timeout>      # 指定客戶端超時時間，默認爲2m
--enable-authentication                 # 使能客戶端認證
--keystore-password <keystore password> # KeyStore密碼
--keystore-path <keystore path>         # KeyStore路徑
--krb5-config-path <krb5 config path>   # Kerberos配置文件路徑（默認爲/etc/krb5.conf）
--krb5-credential-cache-path <path>     # Kerberos憑據緩存路徑
--krb5-keytab-path <krb5 keytab path>   # Kerberos Key table路徑
--krb5-principal <krb5 principal>       # 要使用的Kerberos principal
--krb5-remote-service-name <name>       # 遠程Kerberos節點名稱
--log-levels-file <log levels>          # 調試日誌配置文件路徑
--output-format <output-format>         # 批量導出的數據格式，默認爲 CSV
--session <session>                     # 指定回話屬性，格式以下 key=value
--socks-proxy <socks-proxy>             # 設置代理服務器
--source <source>                       # 設置查詢的Source
--version                               # 顯示版本信息
-h, --help                              # 顯示幫組信息

使用JDBC

Java應用可使用Presto提供的JDBC driver鏈接數據庫進，使用方式與通常RDBMS數據庫差異不大。

在Maven中引入能夠在pom文件中加入以下配置引入Presto JDBC driver：

試用

<dependency>
    <groupId>com.facebook.presto</groupId>
    <artifactId>presto-jdbc</artifactId>
    <version>0.187</version>
</dependency>

Driver類名
Presto JDBC driver類爲com.facebook.presto.jdbc.PrestoDriver。

鏈接字串可使用以下格式的鏈接字串：

試用

jdbc:presto://<COORDINATOR>:<PORT>/[CATALOG]/[SCHEMA]

例如：

試用

jdbc:presto://emr-header-1:9090               # 鏈接數據庫，使用默認的Catalog和Schema
jdbc:presto://emr-header-1:9090/hive          # 鏈接數據庫，使用Catalog(hive)和默認的Schema
jdbc:presto://emr-header-1:9090/hive/default  # 鏈接數據庫，使用Catalog(hive)和Schema(default)

鏈接參數

Presto JDBC driver支持不少參數，這些參數既能夠經過 Properties 對象傳入，也能夠經過URL參數傳入，這兩種方式是等價的。

經過 Properties 對象傳入示例：

試用

String url = "jdbc:presto://emr-header-1:9090/hive/default";
Properties properties = new Properties();
properties.setProperty("user", "hadoop");
Connection connection = DriverManager.getConnection(url, properties);
......

經過URL參數傳入示例：

試用

String url = "jdbc:presto://emr-header-1:9090/hive/default?user=hadoop";
Connection connection = DriverManager.getConnection(url);
......

下面對各個參數進行說明：

參數名稱	格式	參數說明
user	STRING	用戶名
password	STRING	密碼
socksProxy	\:\	SOCKS代理服務器地址，如localhost:1080
httpProxy	\:\	HTTP代理服務器地址，如localhost:8888
SSL	true\	是否使用HTTPS鏈接，默認爲 false
SSLTrustStorePath	STRING	Java TrustStore文件路徑
SSLTrustStorePassword	STRING	Java TrustStore密碼
KerberosRemoteServiceName	STRING	Kerberos服務名稱
KerberosPrincipal	STRING	Kerberos principal
KerberosUseCanonicalHostname	true\	是否使用規範化主機名，默認爲 false
KerberosConfigPath	STRING	Kerberos配置文件路徑
KerberosKeytabPath	STRING	Kerberos KeyTab文件路徑
KerberosCredentialCachePath	STRING	Kerberos credential緩存路徑

Java示例下面給出一個Java使用Presto JDBC driver的例子。

試用

.....
// 加載JDBC Driver類
try {
    Class.forName("com.facebook.presto.jdbc.PrestoDriver");
} catch(ClassNotFoundException e) {
    LOG.ERROR("Failed to load presto jdbc driver.", e);
    System.exit(-1);
}
Connection connection = null;
Statement statement = null;
try {
    String url = "jdbc:presto://emr-header-1:9090/hive/default";
    Properties properties = new Properties();
    properties.setProperty("user", "hadoop");
    // 建立鏈接對象
    connection = DriverManager.getConnection(url, properties);
    // 建立Statement對象
    statement = connection.createStatement();
    // 執行查詢
    ResultSet rs = statement.executeQuery("select * from t1");
    // 獲取結果
    int columnNum = rs.getMetaData().getColumnCount();
    int rowIndex = 0;
    while (rs.next()) {
        rowIndex++;
        for(int i = 1; i <= columnNum; i++) {
            System.out.println("Row " + rowIndex + ", Column " + i + ": " + rs.getInt(i));
        }
    }
} catch(SQLException e) {
    LOG.ERROR("Exception thrown.", e);
} finally {
  // 銷燬Statement對象
  if (statement != null) {
      try {
        statement.close();
    } catch(Throwable t) {
        // No-ops
    }
  }
  // 關閉鏈接
  if (connection != null) {
      try {
        connection.close();
    } catch(Throwable t) {
        // No-ops
    }
  }
}

其它參考：

快速入門
數據類型
經常使用函數和操做符
SQL語句

Presto是一個運行在多臺服務器上的分佈式系統。完整安裝包括一個coordinator（調度節點）和多個worker。由客戶端提交查詢，從Presto命令行CLI提交到coordinator。 coordinator進行解析，分析並執行查詢計劃，而後分發處理隊列到worker

目錄：

環境基本要求
集羣規劃
鏈接器
安裝步驟
config.properties
node.properties
jvm.config
log.properties
Catalog Properties
運行presto
測試驗證

環境基本要求

Linux or Mac OS X
Java 8, 64-bit
Python 2.4+

集羣規劃

hdp1 ( 192.169.1.89) : 調度節點
hdp2 (192.169.1.2) : worker節點
hdp3 (192.169.1.99) : worker節點

鏈接器

Presto支持從如下版本的Hadoop中讀取Hive數據：支持如下文件類型：Text, SequenceFile, RCFile, ORC
1. Apache Hadoop 1.x （hive-hadoop1）
2. Apache Hadoop 2.x （hive-hadoop2）
3. Cloudera CDH 4 （hive-cdh4）
4. Cloudera CDH 5 （hive-cdh5）
此外，須要有遠程的Hive元數據。不支持本地或嵌入模式。 Presto不使用MapReduce，只須要HDFS

安裝步驟

下載 presto-server-0.100, ( 下載地址：https://repo1.maven.org/maven2/com/facebook/presto/presto-server/0.100/presto-server-0.100.tar.gz）
將 presto-server-0.100.tar.gz 上傳至linux主機，解壓後的文件目錄結構以下（稱爲安裝目錄）：Presto須要一個用於存儲日誌、本地元數據等的數據目錄。建議在安裝目錄的外面建立一個數據目錄。這樣方便Presto進行升級，如：/presto/data
在安裝目錄中建立一個etc目錄，在這個etc目錄中放入如下配置文件：

1. config.properties ：Presto 服務配置
2. node.properties ：環境變量配置，每一個節點特定配置
3. jvm.config ：Java虛擬機的命令行選項
4. log.properties: 容許你根據不一樣的日誌結構設置不一樣的日誌級別
5. catalog目錄：每一個鏈接者配置（data sources）

config.properties

包含了Presto server的全部配置信息。每一個Presto server既是一個coordinator也是一個worker。可是在大型集羣中，處於性能考慮，建議單獨用一臺機器做爲 coordinator，一個coordinator的etc/config.properties應該至少包含如下信息：
```
coordinator=true
node-scheduler.include-coordinator=false
http-server.http.port=9000
task.max-memory=1GB
discovery-server.enabled=true
discovery.uri=http://192.169.1.89:9000
```

1. coordinator：指定是否運維Presto實例做爲一個coordinator(接收來自客戶端的查詢情切管理每一個查詢的執行過程)
2. node-scheduler.include-coordinator：是否容許在coordinator服務中進行調度工做, 對於大型的集羣，在一個節點上的Presto server即做爲coordinator又做爲worke將會下降查詢性能。由於若是一個服務器做爲worker使用，那麼大部分的資源都會被worker佔用，那麼就不會有足夠的資源進行關鍵任務調度、管理和監控查詢執行
3. http-server.http.port：指定HTTP server的端口。Presto 使用 HTTP進行內部和外部的全部通信
4. task.max-memory=1GB：一個單獨的任務使用的最大內存 (一個查詢計劃的某個執行部分會在一個特定的節點上執行)。這個配置參數限制的GROUP BY語句中的Group的數目、JOIN關聯中的右關聯表的大小、ORDER BY語句中的行數和一個窗口函數中處理的行數。該參數應該根據併發查詢的數量和查詢的複雜度進行調整。若是該參數設置的過低，不少查詢將不能執行；可是若是設置的過高將會致使JVM把內存耗光
5. discovery-server.enabled：Presto 經過Discovery 服務來找到集羣中全部的節點。爲了可以找到集羣中全部的節點，每個Presto實例都會在啓動的時候將本身註冊到discovery服務。Presto爲了簡化部署，而且也不想再增長一個新的服務進程，Presto coordinator 能夠運行一個內嵌在coordinator 裏面的Discovery 服務。這個內嵌的Discovery 服務和Presto共享HTTP server而且使用一樣的端口
6. discovery.uri：Discovery server的URI。因爲啓用了Presto coordinator內嵌的Discovery 服務，所以這個uri就是Presto coordinator的uri。注意：這個URI必定不能以「/「結尾

注意：上例中若是是worker的config.properties，配置應該以下：

coordinator=false
http-server.http.port=9000
query.max-memory=1GB
discovery.uri=http://192.169.1.89:9000

若是用一臺機器進行測試，那麼這一臺機器將會即做爲coordinator，也做爲worker。配置文件將會以下所示：

coordinator=true
node-scheduler.include-coordinator=true
http-server.http.port=9000
task.max-memory=1GB
discovery-server.enabled=true
discovery.uri=http://192.169.1.89:9000

node.properties

包含針對於每一個節點的特定的配置信息。一個節點就是在一臺機器上安裝的Presto實例，etc/node.properties配置文件至少包含以下配置信息
```
node.environment=test
node.id=ffffffff-ffff-ffff-ffff-ffffffffff01
node.data-dir=/presto/data
```

node.environment：集羣名稱, 全部在同一個集羣中的Presto節點必須擁有相同的集羣名稱
node.id：每一個Presto節點的惟一標示。每一個節點的node.id都必須是惟一的。在Presto進行重啓或者升級過程當中每一個節點的node.id必須保持不變。若是在一個節點上安裝多個Presto實例（例如：在同一臺機器上安裝多個Presto節點），那麼每一個Presto節點必須擁有惟一的node.id
node.data-dir：數據存儲目錄的位置（操做系統上的路徑）, Presto將會把日期和數據存儲在這個目錄下

jvm.config

包含一系列在啓動JVM的時候須要使用的命令行選項。這份配置文件的格式是：一系列的選項，每行配置一個單獨的選項。因爲這些選項不在shell命令中使用。所以即便將每一個選項經過空格或者其餘的分隔符分開，java程序也不會將這些選項分開，而是做爲一個命令行選項處理,信息以下：
```
-server
-Xmx16G
-XX:+UseConcMarkSweepGC
-XX:+ExplicitGCInvokesConcurrent
-XX:+CMSClassUnloadingEnabled
-XX:+AggressiveOpts
-XX:+HeapDumpOnOutOfMemoryError
-XX:OnOutOfMemoryError=kill -9 %p
-XX:ReservedCodeCacheSize=150M
```

log.properties

這個配置文件中容許你根據不一樣的日誌結構設置不一樣的日誌級別。每一個logger都有一個名字（一般是使用logger的類的全標示類名）. Loggers經過名字中的「.「來表示層級和集成關係，信息以下：
```
com.facebook.presto=DEBUG
```
配置日誌等級，相似於log4j。四個等級：DEBUG,INFO,WARN,ERROR

Catalog Properties

經過在etc/catalog目錄下建立catalog屬性文件來完成catalogs的註冊。例如：能夠先建立一個etc/catalog/jmx.properties文件，文件中的內容以下，完成在jmxcatalog上掛載一個jmxconnector
```
connector.name=jmx
```

在etc/catalog目錄下建立hive.properties，信息以下：

connector.name=hive-hadoop2
hive.metastore.uri=thrift://192.169.1.89:9083
hive.config.resources=/etc/hadoop/2.4.2.0-258/0/core-site.xml, /etc/hadoop/2.4.2.0-258/0/hdfs-site.xml
hive.allow-drop-table=true

運行presto

在安裝目錄的bin/launcher文件，就是啓動腳本。Presto可使用以下命令做爲一個後臺進程啓動：
```
bin/launcher start
```
也能夠在前臺運行, 可查看具體的日誌
```
bin/launcher run
```
中止服務進程命令
```
bin/laucher stop
```
查看進程： ps -aux|grep PrestoServer 或 jps

測試驗證

下載 presto-cli-0.100-executable.jar：Presto CLI爲用戶提供了一個用於查詢的可交互終端窗口。CLI是一個可執行 JAR文件, 這也就意味着你能夠像UNIX終端窗口同樣來使用CLI ，下載地址（https://repo1.maven.org/maven2/com/facebook/presto/presto-cli/0.100/presto-cli-0.100-executable.jar）
文件下載後，重名名爲 presto ，使用 chmod +x 命令設置可執行權限
```
chmod +x /presto/presto.jar
```
在hive中查一下hive default庫中的表，結果以下圖：
退出hive cli，進入presto cli
命令： ./presto.jar --server 192.168.1.89:9000 --catalog hive --schema default (若是要調度，可加 --debug, 紅色標識的項必須與 config.properties 配置文件中的uri 地址一致，配置的IP就用IP，機器名就用機器名)
命令： show tables; (查看 hive defult 庫中表結構），以下：
或者使用下面命令：
./presto.jar --server 192.168.1.89:9000 --catalog hive
show tables from default;
命令： select * from web_log; （查詢上面建立Hive表的結果）
命令： quit; 退出presto cli

分類: Presto

2.導出數據

presto能夠指定導出數據的格式,可是不能直接指定導出數據的文件地址,須要用Linux的命令支持。

下面是一個帶有header的csv數據導出。

bin/presto --execute "sql statement" --output-format CSV_HEADER > test1.csv

3.跨源join

查詢mysql和hive的數據,並作join。

這裏再也不寫出sql了。

注意:

須要指定catalog。
不一樣庫之間作join的時候須要主要字段類型,好比userid,在hive中多是String,在mysql多是int,這時候須要使用cast轉一下格式,而後再作等於的比較。

4.管理界面

默認的管理界面的端口是8080。看着很炫酷。

5.airpal

在airpal上提交query卻是也挺方便,可是有很多bug,目測更新的比較慢,跟不上presto的更新速度。用過就知道了…..

來源:
http://blog.csdn.net/zhaodedong/article/details/52132318

Presto調優

默認的Presto配置知足絕大部分的負載要求，下面的一些信息會幫助你解決Presto集羣環境中的一些特殊的性能問題。

配置文件

task.info-refresh-max-wait

控制過時task信息，使用在調度中。增長這個值可以減小coordinator 的CPU負載，可是可能致使split調度不是最優的。

task.max-worker-threads

設置workers處理splits時使用的線程數。若是Worker的CPU利用率低而且全部的線程都在使用，那麼增長這個值能夠提升吞吐量，可是會增長堆內存空間大小。活動線程的數量能夠經過

com.facebook.presto.execution.taskexecutor.runningsplitsJMX統計

distributed-joins-enabled

使用hash分佈式join代替broadcast廣播的join。分佈式join須要根據join key的hash值來從新分佈表，這可能比廣播join慢，可是能夠利用更大的表之間join操做。廣播的join須要關接的右邊的表加載到每個節點的內存中，然而分佈式join是將關聯的右邊的表加載到分佈式內存中。咱們能夠在每個查詢中設置distributed_join 的session屬性值來進行選擇。

node-scheduler.network-topology

當調度split時，設置使用的網絡拓撲。

當調度split時，「legacy」將忽略拓撲，「flat」將嘗試在同一個節點調度split。

JVM配置

下面的參數能夠幫助診斷GC問題：

-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCCause
-XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-XX:+PrintReferenceGC
-XX:+PrintClassHistogramAfterFullGC
-XX:+PrintClassHistogramBeforeFullGC
-XX:PrintFLSStatistics=2
-XX:+PrintAdaptiveSizePolicy
-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=1

7.3 隊列配置

隊列規則定義在一個Json文件中，用於控制可以提交給Presto的查詢的個數，以及每一個隊列中可以同時運行的查詢的個數。用config.properties中的query.queue-config-file來指定Json配置文件的名字。

隊列規則若是定義了多個隊列，查詢會按順序依次進入不一樣的隊列中。隊列規則將按照順序進行處理，而且使用第一個匹配上的規則。在如下的配置例子中，有5個隊列模板，在user.${USER}隊列中，${USER}表示着提交查詢的用戶名。一樣的${SOURCE}表示提交查詢的來源。

一樣有以下的規則定義了哪一類查詢會進入哪個隊列中：

· 第一條規則將使bob成爲管理員，bob提交的查詢進入admin隊列。

· 第二條規則表示，來源包含pipeline的查詢將首先進入用戶的我的隊列中，而後進入pipeline隊列。當一個查詢進入一個新的隊列後，直到查詢結束纔會離開以前的隊列。

· 最後一個規則包含全部的隊列，將全部的查詢加入到我的用戶隊列中

全部這些規則實現了這樣的策略，bob是一個管理員，而其餘用戶須要遵循如下的限制：

1. 每一個用戶最多能同時運行5個查詢，另外能夠運行一個pipeline。

2. 最多能同時運行10個pipeline來源的查詢。

3. 最多能同時運行100個其餘查詢。

{
  "queues": {
    "user.${USER}": {
      "maxConcurrent": 5,
      "maxQueued": 20
    },
    "user_pipeline.${USER}": {
      "maxConcurrent": 1,
      "maxQueued": 10
    },
    "pipeline": {
      "maxConcurrent": 10,
      "maxQueued": 100
    },
    "admin": {
      "maxConcurrent": 100,
      "maxQueued": 100
    },
    "global": {
      "maxConcurrent": 100,
      "maxQueued": 1000
    }
  },
  "rules": [
    {
      "user": "bob",
      "queues": ["admin"]
    },
    {
      "source": ".*pipeline.*",
      "queues": [
        "user_pipeline.${USER}",
        "pipeline",
        "global"
      ]
    },
    {
      "queues": [
        "user.${USER}",
        "global"
      ]
    }
  ]
}
---------------------

0. 計算相關序列化

presto內部使用jackson-core進行序列化. 因爲是分佈式環境, 所以須要將每一個split要計算的元數據序列化後傳輸到各個worker節點. 開發時須要注意凡是要被傳輸到其餘節點執行的信息都要序列化.

1. `ConnectorTableHandle`, `ColumnHandle` 和 `ConnectorTableMetadata` , `ColumnMetadata` 有什麼區別?

XXXMetadata 是用來表示table的元數據的, 包括 column_name 和 type, 信息是catalog 不相關的
XXXHandle 是用來表示特定的catalog的table/column的信息, 包含column name 和數據類型. 簡單來講, XXXHandle 就是XXXMetadata + connectorId. 最必需的信息是connectorId. 雖然XXXHandle 默認是一個Marker Interface(就是沒有任何一個方法), 但該數據是會被序列化後傳輸到worker節點的, 所以connectorId 這個屬性是繞不過的. 參見下面connectorId 是幹嗎呢

2. `connectorId` 是幹嗎的

presto中數據的組織方式是三層: catalog-->schema --> table. 一個catalog 只能是一種connector, 經過配置文件中connector.name 指定, 例如hive的一個catalog的配置:

connector.name=hive-cdh5
hive.metastore.uri=thrift://localhost:10000
hive.config.resources=/home/ec2-user/presto/etc/core-site.xml,/home/ec2-user/presto/etc/hdfs-site.xml
hive.s3.pin-client-to-current-region=true

而catalog 的名稱就是配置文件的名稱(去除後綴). 在Connector中, connectorId就是這個對應的catalog的名稱. XXXHandle 中connectorId的做用就是worker節點中根據這個 ID 查找對應的配置從而執行計算

3. ConnectorSplit

很簡單, 就是coordinator 計算split後要將各個任務序列化後傳輸給各個worker節點計算. 所以實現的時候僅僅把分塊計算所需的任何數據都扔到這個實現類裏面, 搞成可序列化便可.

4. Guice 不瞭解怎麼辦?

看過presto源代碼的都知道presto是使用Guice作爲依賴注入框架, 不瞭解怎麼辦? 那就不用. presto 使用了java的Service Provider Interfaces 組織connector, 本身的connector 不使用guice 沒有任何關係.

5. Presto如何初始化connector?

Service Provider Interfaces 有規範的, 簡單講就是在src/main/resources/META-INF/services/ 中添加一個名爲 com.facebook.presto.spi.Plugin 的文件, 裏面寫你的connector中實現了com.facebook.presto.spi.Plugin 這個接口的類

總結

在QCon2015 中開源大數據在Facebook與Dropbox的實踐得知, Presto 最初的原型是一個工程師一個月作出來的, 後面通過歷代版本的優化至今. 代碼質量很是高, 就是用了一個估計是幾個哥們兒本身寫的框架airlift, 文檔比較少. 但正是這種connector的結構, 可讓咱們很容易構建一個可讓異構數據源之間輕鬆 join 的數據平臺, 減小數據接入的工做.