一文講解大數(shù)據(jù)處理分析引擎Presto

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

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

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

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

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

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

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

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

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