大數(shù)據(jù)時代對數(shù)據(jù)的處理分析提出了很多需求，企業(yè)用戶希望能從業(yè)務(wù)數(shù)據(jù)生成報表、進行運營分析、進行實時推薦計算。因此，在大數(shù)據(jù)處理分析領(lǐng)域出現(xiàn)了很多工具，列式數(shù)據(jù)庫Clickhouse、Hbase提供了存儲和分析能力，Hadoop家族中的MapReduce、HDFS提供了離線計算能力，Hive以數(shù)據(jù)倉庫的形態(tài)提供了簡單易學(xué)的分析能力，實時計算引擎Flink更是提供了流批處理計算能力，可謂是各有千秋??！不過工具千千萬，唯有適合自己的才是最好的，今天我們要介紹的便是Presto

Presto是Facebook公司開源的分布式SQL查詢引擎，支持PB級別的數(shù)據(jù)計算，之所以在眾多分析引擎中選擇它，主要是因為它是一個能夠獨立運行、不依賴其他外部系統(tǒng)；此外簡單的數(shù)據(jù)結(jié)構(gòu)使得大部分?jǐn)?shù)據(jù)的接入很容易；最后豐富的插件接口可以對接很多數(shù)據(jù)源系統(tǒng)。基于內(nèi)存計算的模式、基于流水線設(shè)計邊運行邊出結(jié)果的運行模式也使得Presto很快就能獲取處理數(shù)據(jù)。綜上原因，諸如阿里、美團等互聯(lián)網(wǎng)巨頭在數(shù)據(jù)分析中也使用Presto做底層引擎。

Presto的架構(gòu)如下所示，它包含Client、DiscoveryService、Coordinator、Worker、Connector五大部分。Client包含presto自帶的客戶端、通過API調(diào)用的JDBC客戶端；DiscoveryService是一個注冊中心，所有的Worker節(jié)點都向其進行注冊，Coordinator從其獲取worker節(jié)點，有點類似微服務(wù)架構(gòu)中的“生產(chǎn)者-注冊中心-消費者”之間的關(guān)系；Worker負(fù)責(zé)從Connector獲取數(shù)據(jù)，執(zhí)行數(shù)據(jù)分析任務(wù)；Connector負(fù)責(zé)獲取數(shù)據(jù)源信息，可以接收來自文件系統(tǒng)如HDFS的數(shù)據(jù)，也可以接收數(shù)據(jù)庫如Mysql、Clickhouse的數(shù)據(jù)，甚至是消息隊列如Kafka中的數(shù)據(jù)。

那么在Presto中如何執(zhí)行一個SQL查詢?nèi)蝿?wù)呢？簡單來說，大概是這樣的：用戶在客戶端發(fā)出一個SQL查詢請求，Coordinator接受來自客戶端的請求，并對該SQL語句進行解析，生成查詢計劃，按查詢計劃依次生成SQLQueryExecution—》SQLStageExecution—〉HTTPRemotePlan，把最后的Plan任務(wù)分配給到Worker節(jié)點；Worker節(jié)點根據(jù)任務(wù)內(nèi)容從Connector中獲取數(shù)據(jù)，執(zhí)行計算，計算完畢后把結(jié)果給到Coordinator，Coordinator獲取結(jié)果把結(jié)果寫入緩存，客戶端不斷輪詢Coordinator中的查詢結(jié)果，一次任務(wù)執(zhí)行完畢，把數(shù)據(jù)給用戶展示出來。

介紹完P(guān)resto如何執(zhí)行一個SQL任務(wù)后，我們再來看看它的數(shù)據(jù)結(jié)構(gòu)和存儲模型。在Presto中的數(shù)據(jù)結(jié)構(gòu)是三層模型，Catalog-》Schema-〉Table，Catalog對應(yīng)一個數(shù)據(jù)源，Schema對應(yīng)數(shù)據(jù)源中的數(shù)據(jù)庫，Table對應(yīng)數(shù)據(jù)庫中的表。在Presto的存儲模型中包含Page-》Block，Page是多行數(shù)據(jù)的集合（每一行又包含多個列的數(shù)據(jù)），也是Presto計算處理的最小數(shù)據(jù)單元，Block是具體的一列數(shù)據(jù)。清晰了Presto的數(shù)據(jù)結(jié)構(gòu)和存儲模型，在接入Presto時就比較清晰了。

Presto處理速度快，除了Worker節(jié)點基于內(nèi)存進行運算處理之外，在Worker節(jié)點內(nèi)部、Worker節(jié)點之間都是采用流水線模型進行計算。這給用戶造成的感覺就是很快，剛輸入就有結(jié)果了，先看前面的結(jié)果再看后面的結(jié)果。

同樣是數(shù)據(jù)處理分析引擎，處理速度的差別卻是各不相同，這主要和使用工具的架構(gòu)及運行原理有關(guān)系。早期Facebook是使用Hive做數(shù)據(jù)分析處理，后來因為實在太慢了，所以才自己開發(fā)寫了Presto，據(jù)說同樣的一個SQL查詢?nèi)蝿?wù)，在Hive中需要差不多一分鐘，但Presto人中卻不到1秒，那今天我們也感受一波Facebook公司的數(shù)據(jù)分析處理歷史吧。

關(guān)于Hive，它是基于Hadoop的數(shù)據(jù)倉庫工具，使用Hive也可以進行數(shù)據(jù)查詢分析處理，我們一起來看看Hive中又是如何運轉(zhuǎn)的呢？在Hive中，所有的HQL語句轉(zhuǎn)化成數(shù)據(jù)查詢?nèi)蝿?wù)，所有的數(shù)據(jù)在進行處理前會劃分成大小相同的數(shù)據(jù)，經(jīng)過Map模型初次處理數(shù)據(jù)，得到中間結(jié)果，再經(jīng)過Reduce模型二次處理中間結(jié)果數(shù)據(jù)，最后得到分析數(shù)據(jù)，存儲在HDFS。在該模型中，所有的數(shù)據(jù)分析處理需要經(jīng)過多次轉(zhuǎn)換成中間結(jié)果，比較慢；其次在MR模型中所生成的中間數(shù)據(jù)都是存儲在磁盤中的，每次數(shù)據(jù)進入磁盤，再從磁盤讀取出來，非常的耗費IO，時間延遲太長了。

介紹完P(guān)resto后，我們再回歸現(xiàn)實，了解下互聯(lián)網(wǎng)現(xiàn)況?；ヂ?lián)網(wǎng)、移動互聯(lián)網(wǎng)、物聯(lián)網(wǎng)、5G、人工智能、云計算等技術(shù)的不斷發(fā)展，越來越多數(shù)據(jù)的產(chǎn)生，企業(yè)精細(xì)化運營的要求，在催生了大量的數(shù)據(jù)處理分析工具之時，也催生了諸如數(shù)據(jù)倉庫、數(shù)據(jù)集市、數(shù)據(jù)湖、數(shù)據(jù)中臺等業(yè)態(tài)，不斷的在給大數(shù)據(jù)領(lǐng)域輸送力量，對于數(shù)據(jù)分析人才的訴求也一直有增無減，后浪們，我們一起加油吧！