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

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

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

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

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

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

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

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

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