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去執行各種任務的節點

1、解析SQL語句

2、?成執?計劃

3、分發執?任務給Worker節點執?

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

1、負責實際執?查詢任務

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

1、Worker節點啟動后向Discovery Server服務注冊

2、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運行過程：整體流程

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

2、如果語法是符合sql語法規范，之后會經過一個邏輯查詢計劃器的組件，他的主要作用是，比如說你sql里面出現的表，他會通過connector的方式去meta里面把表的schema，列名，列的類型等，全部給找出來，將這些信息，跟語法樹給對應起來，之后會生成一個物理的語法樹節點，這個語法樹節點里面，不僅擁有了它的查詢關系，還擁有類型的關系，如果在這一步，數據庫表里某一列的類型，跟你sql的類型不一致，就會在這里報錯

3、如果通過，就會得到一個邏輯的查詢計劃，然后這個邏輯查詢計劃，會被送到一個分布式的邏輯查詢計劃器里面，進行一個分布式的解析，分布式解析里面，他就會去把對應的每一個查詢計劃轉化為task

4、在每一個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還沒有開始處理這個問題貌似

總結

以上是生活随笔為你收集整理的【大数据-Hadoop】Presto的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。