presto是什么

是Facebook開源的，完全基于內(nèi)存的并?計算，分布式SQL交互式查詢引擎

是一種Massively parallel processing (MPP)架構(gòu)，多個節(jié)點管道式執(zhí)?

?持任意數(shù)據(jù)源（通過擴展式Connector組件），數(shù)據(jù)規(guī)模GB~PB級

使用的技術(shù)，如向量計算，動態(tài)編譯執(zhí)?計劃，優(yōu)化的ORC和Parquet Reader等

presto不太支持存儲過程，支持部分標(biāo)準(zhǔn)sql

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

上面講述了presto是什么，查詢速度，現(xiàn)在來看看presto適合干什么

適合：PB級海量數(shù)據(jù)復(fù)雜分析，交互式SQL查詢，?持跨數(shù)據(jù)源查詢

不適合：多個大表的join操作，因為presto是基于內(nèi)存的，多張大表在內(nèi)存里可能放不下

和hive的對比：

hive是一個數(shù)據(jù)倉庫，是一個交互式比較弱一點的查詢引擎，交互式?jīng)]有presto那么強，而且只能訪問hdfs的數(shù)據(jù)

presto是一個交互式查詢引擎，可以在很短的時間內(nèi)返回查詢結(jié)果，秒級，分鐘級，能訪問很多數(shù)據(jù)源

hive在查詢100Gb級別的數(shù)據(jù)時，消耗時間已經(jīng)是分鐘級了

但是presto是取代不了hive的，因為p全部的數(shù)據(jù)都是在內(nèi)存中，限制了在內(nèi)存中的數(shù)據(jù)集大小，比如多個大表的join，這些大表是不能完全放進內(nèi)存的，實際應(yīng)用中，對于在presto的查詢是有一定規(guī)定條件的，比比如說一個查詢在presto查詢超過30分鐘，那就kill掉吧，說明不適合在presto上使用，主要原因是，查詢過大的話，會占用整個集群的資源，這會導(dǎo)致你后續(xù)的查詢是沒有資源進行查詢的，這跟presto的設(shè)計理念是沖突的，就像是你進行一個查詢，但是要等個5分鐘才有資源繼續(xù)查詢，這是很不合理的，交互式就變得弱了很多

presto基本架構(gòu)

在談presto架構(gòu)之前，先回顧下hive的架構(gòu)

hive：client將查詢請求發(fā)送到hive server，它會和metastor交互，獲取表的元信息，如表的位置結(jié)構(gòu)等，之后hive server會進行語法解析，解析成語法樹，變成查詢計劃，進行優(yōu)化后，將查詢計劃交給執(zhí)行引擎，默認(rèn)是MR，然后翻譯成MR

presto：presto是在它內(nèi)部做hive類似的邏輯

接下來，深入看下presto的內(nèi)部架構(gòu)

這里面三個服務(wù)：

Coordinator是一個中心的查詢角色，它主要的一個作用是接受查詢請求，將他們轉(zhuǎn)換成各種各樣的任務(wù)，將任務(wù)拆解后分發(fā)到多個worker去執(zhí)行各種任務(wù)的節(jié)點

1、解析SQL語句

2、?成執(zhí)?計劃

3、分發(fā)執(zhí)?任務(wù)給Worker節(jié)點執(zhí)?

Worker，是一個真正的計算的節(jié)點，執(zhí)行任務(wù)的節(jié)點，它接收到task后，就會到對應(yīng)的數(shù)據(jù)源里面，去把數(shù)據(jù)提取出來，提取方式是通過各種各樣的connector：

1、負(fù)責(zé)實際執(zhí)?查詢?nèi)蝿?wù)

Discovery service，是將coordinator和woker結(jié)合到一起的服務(wù)：

1、Worker節(jié)點啟動后向Discovery Server服務(wù)注冊

2、Coordinator從Discovery Server獲得Worker節(jié)點

coordinator和woker之間的關(guān)系是怎么維護的呢？是通過Discovery Server，所有的worker都把自己注冊到Discovery Server上，Discovery Server是一個發(fā)現(xiàn)服務(wù)的service，Discovery Server發(fā)現(xiàn)服務(wù)之后，coordinator便知道在我的集群中有多少個worker能夠給我工作，然后我分配工作到worker時便有了根據(jù)

最后，presto是通過connector plugin獲取數(shù)據(jù)和元信息的，它不是?個數(shù)據(jù)存儲引擎，不需要有數(shù)據(jù)，presto為其他數(shù)據(jù)存儲系統(tǒng)提供了SQL能?，客戶端協(xié)議是HTTP+JSON

Presto支持的數(shù)據(jù)源和存儲格式

Hadoop/Hive connector與存儲格式：

HDFS，ORC，RCFILE，Parquet，SequenceFile，Text

開源數(shù)據(jù)存儲系統(tǒng)：

MySQL & PostgreSQL，Cassandra，Kafka，Redis

其他：

MongoDB，ElasticSearch，HBase

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

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

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

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

4、在每一個task里面，他會把對應(yīng)的位置信息全部給提取出來，交給執(zhí)行的plan，由plan把對應(yīng)的task發(fā)給對應(yīng)的worker去執(zhí)行，這就是整個的一個過程

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

Presto中SQL運行過程：MapReduce vs Presto

task是放在每個worker上該執(zhí)行的，每個task執(zhí)行完之后，數(shù)據(jù)是存放在內(nèi)存里了，而不像mr要寫磁盤，然后當(dāng)多個task之間要進行數(shù)據(jù)交換，比如shuffle的時候，直接從內(nèi)存里處理

Presto監(jiān)控和配置：監(jiān)控

Web UI

Query基本狀態(tài)的查詢

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監(jiān)控和配置：配置

執(zhí)行計劃計劃（Coordinator）

node-scheduler.include-coordinator

? 是否讓coordinator運行task

query.initial-hash-partitions

? 每個GROUP BY操作使?的hash bucket(=tasks)最大數(shù)目(default: 8)

node-scheduler.min-candidates

? 每個stage并發(fā)運行過程中可使用的最大worker數(shù)目（default：10）

query.schedule-split-batch-size

? 每個split數(shù)據(jù)量

任務(wù)執(zhí)行（Worker）

query.max-memory (default: 20 GB)

? 一個查詢可以使用的最大集群內(nèi)存

? 控制集群資源使用，防止一個大查詢占住集群所有資源

? 使用resource_overcommit可以突破限制

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

? 一個查詢在一個節(jié)點上可以使用的最大內(nèi)存

舉例

? 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個數(shù)

? 調(diào)大可以增加吞吐率，但是會增加內(nèi)存的消耗

隊列（Queue）

任務(wù)提交或者資源使用的一些配置，是通過隊列的配置來實現(xiàn)的

資源隔離，查詢可以提交到相應(yīng)隊列中

? 資源隔離，查詢可以提交到相應(yīng)隊列中
? 每個隊列可以配置ACL（權(quán)限）
? 每個隊列可以配置Quota
　　可以并發(fā)運行查詢的數(shù)量
　　排隊的最大數(shù)量

大數(shù)據(jù)OLAP引擎對比

Presto：內(nèi)存計算，mpp架構(gòu)

Druid：時序，數(shù)據(jù)放內(nèi)存，索引，預(yù)計算

Spark SQL：基于Spark Core，mpp架構(gòu)

Kylin：Cube預(yù)計算

最后，一些零散的知識點

presto適合pb級的海量數(shù)據(jù)查詢分析，不是說把pb的數(shù)據(jù)放進內(nèi)存，比如一張pb表，查詢count，vag這種有個特點，雖然數(shù)據(jù)很多，但是最終的查詢結(jié)果很小，這種就不會把數(shù)據(jù)都放到內(nèi)存里面，只是在運算的過程中，拿出一些數(shù)據(jù)放內(nèi)存，然后計算，在拋出，在拿，這種的內(nèi)存占用量是很小的，但是join這種，在運算的中間過程會產(chǎn)生大量的數(shù)據(jù)，或者說那種查詢的數(shù)據(jù)不大，但是生成的數(shù)據(jù)量很大，這種也是不合適用presto的，但不是說不能做，只是會占用大量內(nèi)存，消耗很長的時間，這種hive合適點

presto算是hive的一個補充，需要盡快得出結(jié)果的用presto，否則用hive

work是部署的時候就事先部署好的，work啟動100個，使用的work不一定100個，而是根據(jù)coordinator來決定拆分成多少個task，然后分發(fā)到多少個work去

一個coordinator可能同時又多個用戶在請求query，然后共享work的去執(zhí)行，這是一個共享的集群

coordinator和discovery server可以啟動在一個節(jié)點一個進程，也可以放在不同的node上，但是現(xiàn)在公司大部分都是放在一個節(jié)點上，一個launcher start會同時把上述兩個啟動起來

對于presto的容錯，如果某個worker掛掉了，discovery server會發(fā)現(xiàn)并通知coordinator

但是對于一個query，是沒有容錯的，一旦一個work掛了，那么整個qurey就是敗了

因為對于presto，他的查詢時間是很短的，與其查詢這里做容錯能力，不如重新執(zhí)行來的快來的簡單

對于coordinator和discovery server節(jié)點的單點故障，presto還沒有開始處理這個問題貌似

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。