Presto在大數(shù)據(jù)領(lǐng)域的實(shí)踐和探索是怎樣的

本篇文章給大家分享的是有關(guān)Presto在大數(shù)據(jù)領(lǐng)域的實(shí)踐和探索是怎樣的，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

下面從原理入門、線上調(diào)優(yōu)、典型應(yīng)用等幾個(gè)方面為讀者全面剖析Presto。

我是誰？我從哪里來？要到哪里去？

Presto is an open source distributed SQL query engine for running interactive analytic queries against data sources of all sizes ranging from gigabytes to petabytes.
Presto allows querying data where it lives, including Hive, Cassandra, relational databases or even proprietary data stores. A single Presto query can combine data from multiple sources, allowing for analytics across your entire organization.
Presto is targeted at analysts who expect response times ranging from sub-second to minutes. Presto breaks the false choice between having fast analytics using an expensive commercial solution or using a slow "free" solution that requires excessive hardware.

這是官網(wǎng)對(duì)Presto的定義，Presto 是由 Facebook 開源的大數(shù)據(jù)分布式 SQL 查詢引擎，適用于交互式分析查詢，可支持眾多的數(shù)據(jù)源，包括 HDFS，RDBMS，KAFKA 等，而且提供了非常友好的接口開發(fā)數(shù)據(jù)源連接器。

Presto之所以能在各個(gè)內(nèi)存計(jì)算型數(shù)據(jù)庫中脫穎而出，在于以下幾點(diǎn)：

• 清晰的架構(gòu)，是一個(gè)能夠獨(dú)立運(yùn)行的系統(tǒng)，不依賴于任何其他外部系統(tǒng)。例如調(diào)度，presto自身提供了對(duì)集群的監(jiān)控，可以根據(jù)監(jiān)控信息完成調(diào)度。

• 簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)，列式存儲(chǔ)，邏輯行，大部分?jǐn)?shù)據(jù)都可以輕易的轉(zhuǎn)化成presto所需要的這種數(shù)據(jù)結(jié)構(gòu)。

• 豐富的插件接口，完美對(duì)接外部存儲(chǔ)系統(tǒng)，或者添加自定義的函數(shù)。

為了給大家一個(gè)更為清晰一點(diǎn)的印象，我們可以把Presto和Mysql進(jìn)行一下對(duì)比：

首先Mysql是一個(gè)數(shù)據(jù)庫，具有存儲(chǔ)和計(jì)算分析能力，而Presto只有計(jì)算分析能力；其次數(shù)據(jù)量方面，Mysql作為傳統(tǒng)單點(diǎn)關(guān)系型數(shù)據(jù)庫不能滿足當(dāng)前大數(shù)據(jù)量的需求，于是有各種大數(shù)據(jù)的存儲(chǔ)和分析工具產(chǎn)生，Presto就是這樣一個(gè)可以滿足大數(shù)據(jù)量分析計(jì)算需求的一個(gè)工具。

一覽無余之Presto的架構(gòu)

我們借用美團(tuán)的博客中的一張架構(gòu)圖：

Presto查詢引擎是一個(gè)Master-Slave的架構(gòu)，由一個(gè)Coordinator節(jié)點(diǎn)，一個(gè)Discovery Server節(jié)點(diǎn)，多個(gè)Worker節(jié)點(diǎn)組成，Discovery Server通常內(nèi)嵌于Coordinator節(jié)點(diǎn)中。Coordinator負(fù)責(zé)解析SQL語句，生成執(zhí)行計(jì)劃，分發(fā)執(zhí)行任務(wù)給Worker節(jié)點(diǎn)執(zhí)行。Worker節(jié)點(diǎn)負(fù)責(zé)實(shí)際執(zhí)行查詢?nèi)蝿?wù)。Worker節(jié)點(diǎn)啟動(dòng)后向Discovery Server服務(wù)注冊(cè)，Coordinator從Discovery Server獲得可以正常工作的Worker節(jié)點(diǎn)。如果配置了Hive Connector，需要配置一個(gè)Hive MetaStore服務(wù)為Presto提供Hive元信息，Worker節(jié)點(diǎn)與HDFS交互讀取數(shù)據(jù)。

Presto的服務(wù)進(jìn)程

Presto集群中有兩種進(jìn)程，Coordinator服務(wù)進(jìn)程和worker服務(wù)進(jìn)程。coordinator主要作用是接收查詢請(qǐng)求，解析查詢語句，生成查詢執(zhí)行計(jì)劃，任務(wù)調(diào)度和worker管理。worker服務(wù)進(jìn)程執(zhí)行被分解的查詢執(zhí)行任務(wù)task。

Coordinator 服務(wù)進(jìn)程部署在集群中的單獨(dú)節(jié)點(diǎn)之中，是整個(gè)presto集群的管理節(jié)點(diǎn)，主要作用是接收查詢請(qǐng)求，解析查詢語句，生成查詢執(zhí)行計(jì)劃Stage和Task并對(duì)生成的Task進(jìn)行任務(wù)調(diào)度，和worker管理。Coordinator進(jìn)程是整個(gè)Presto集群的master進(jìn)程，需要與worker進(jìn)行通信，獲取最新的worker信息，有需要和client通信，接收查詢請(qǐng)求。Coordinator提供REST服務(wù)來完成這些工作。

Presto集群中存在一個(gè)Coordinator和多個(gè)Worker節(jié)點(diǎn)，每個(gè)Worker節(jié)點(diǎn)上都會(huì)存在一個(gè)worker服務(wù)進(jìn)程，主要進(jìn)行數(shù)據(jù)的處理以及Task的執(zhí)行。worker服務(wù)進(jìn)程每隔一定的時(shí)間會(huì)發(fā)送心跳包給Coordinator。Coordinator接收到查詢請(qǐng)求后會(huì)從當(dāng)前存活的worker中選擇合適的節(jié)點(diǎn)運(yùn)行task。

上圖展示了從宏觀層面概括了Presto的集群組件：1個(gè)coordinator，多個(gè)worker節(jié)點(diǎn)。用戶通過客戶端連接到coordinator，可以短可以是JDBC驅(qū)動(dòng)或者Presto命令行cli。

Presto是一個(gè)分布式的SQL查詢引擎，組裝了多個(gè)并行計(jì)算的數(shù)據(jù)庫和查詢引擎（這就是MPP模型的定義）。Presto不是依賴單機(jī)環(huán)境的垂直擴(kuò)展性。她有能力在水平方向，把所有的處理分布到集群內(nèi)的各個(gè)機(jī)器上。這意味著你可以通過添加更多節(jié)點(diǎn)來獲得更大的處理能力。

利用這種架構(gòu)，Presto查詢引擎能夠并行的在集群的各個(gè)機(jī)器上，處理大規(guī)模數(shù)據(jù)的SQL查詢。Presto在每個(gè)節(jié)點(diǎn)上都是單進(jìn)程的服務(wù)。多個(gè)節(jié)點(diǎn)都運(yùn)行Presto，相互之間通過配置相互協(xié)作，組成了一個(gè)完整的Presto集群。

上圖展示了集群內(nèi)coordinator和worker之間，以及worker和worker之間的通信。coordinator向多個(gè)worker通信，用于分配任務(wù)，更新狀態(tài)，獲得最終的結(jié)果返回用戶。worker之間相互通信，向任務(wù)的上游節(jié)點(diǎn)獲取數(shù)據(jù)。所有的worker都會(huì)向數(shù)據(jù)源讀取數(shù)據(jù)。

Coordinator

Coordinator的作用是：

• 從用戶獲得SQL語句

• 解析SQL語句

• 規(guī)劃查詢的執(zhí)行計(jì)劃

• 管理worker節(jié)點(diǎn)狀態(tài)

Coordinator是Presto集群的大腦，并且是負(fù)責(zé)和客戶端溝通。用戶通過PrestoCLI、JDBC、ODBC驅(qū)動(dòng)、其他語言工具庫等工具和coordinator進(jìn)行交互。Coordinator從客戶端接受SQL語句，例如select語句，才能進(jìn)行計(jì)算。

每個(gè)Presto集群必須有一個(gè)coordinator，可以有一個(gè)或多個(gè)worker。在開發(fā)和測(cè)試環(huán)境中，一個(gè)Presto進(jìn)程可以同時(shí)配置成兩種角色。Coordinator追蹤每個(gè)worker上的活動(dòng)，并且協(xié)調(diào)查詢的執(zhí)行過程。Coordinator給查詢創(chuàng)建了一個(gè)包含多階段的邏輯模型，一旦接受了SQL語句，Coordinator就負(fù)責(zé)解析、分析、規(guī)劃、調(diào)度查詢?cè)诙鄠€(gè)worker節(jié)點(diǎn)上的執(zhí)行過程，語句被翻譯成一系列的任務(wù)，跑在多個(gè)worker節(jié)點(diǎn)上。worker一邊處理數(shù)據(jù)，結(jié)果會(huì)被coordinator拿走并且放到output緩存區(qū)上，暴露給客戶端。一旦輸出緩沖區(qū)被客戶完全讀取，coordinator會(huì)代表客戶端向worker讀取更多數(shù)據(jù)。worker節(jié)點(diǎn)，和數(shù)據(jù)源打交道，從數(shù)據(jù)源獲取數(shù)據(jù)。因此，客戶端源源不斷的讀取數(shù)據(jù)，數(shù)據(jù)源源源不斷的提供數(shù)據(jù)，直到查詢執(zhí)行結(jié)束。

Coordinator通過基于HTTP的協(xié)議和worker、客戶端之間進(jìn)行通信。

上圖給我們展示了客戶端、coordinator，worker之間的通信。

Workers

Presto的worker是Presto集群中的一個(gè)服務(wù)。它負(fù)責(zé)運(yùn)行coordinator指派給它的任務(wù)，并處理數(shù)據(jù)。worker節(jié)點(diǎn)通過連接器（connector）向數(shù)據(jù)源獲取數(shù)據(jù)，并且相互之間可以交換數(shù)據(jù)。最終結(jié)果會(huì)傳遞給coordinator。 coordinator負(fù)責(zé)從worker獲取最終結(jié)果，并傳遞給客戶端。

Worker之間的通信、worker和coordinator之間的通信采用基于HTTP的協(xié)議。下圖展示了多個(gè)worker如何從數(shù)據(jù)源獲取數(shù)據(jù)，并且合作處理數(shù)據(jù)的流程。直到某一個(gè)worker把數(shù)據(jù)提供給了coordinator。

一層一層剝開你的心之Presto數(shù)據(jù)模型

Presto采取了三層表結(jié)構(gòu)，我們可以和Mysql做一下類比：

• catalog 對(duì)應(yīng)某一類數(shù)據(jù)源，例如hive的數(shù)據(jù)，或mysql的數(shù)據(jù)

• schema 對(duì)應(yīng)mysql中的數(shù)據(jù)庫

• table 對(duì)應(yīng)mysql中的表

在Presto中定位一張表，一般是catalog為根，例如：一張表的全稱為 hive.testdata.test，標(biāo)識(shí) hive(catalog)下的 testdata(schema)中test表。

可以簡(jiǎn)理解為：數(shù)據(jù)源.數(shù)據(jù)庫.數(shù)據(jù)表。

另外，presto的存儲(chǔ)單元包括：

• Page： 多行數(shù)據(jù)的集合，包含多個(gè)列的數(shù)據(jù)，內(nèi)部僅提供邏輯行，實(shí)際以列式存儲(chǔ)。

• Block：一列數(shù)據(jù)，根據(jù)不同類型的數(shù)據(jù)，通常采取不同的編碼方式，了解這些編碼方式，有助于自己的存儲(chǔ)系統(tǒng)對(duì)接presto。

Presto中處理的最小數(shù)據(jù)單元是一個(gè)Page對(duì)象，Page對(duì)象的數(shù)據(jù)結(jié)構(gòu)如下圖所示。一個(gè)Page對(duì)象包含多個(gè)Block對(duì)象，每個(gè)Block對(duì)象是一個(gè)字節(jié)數(shù)組，存儲(chǔ)一個(gè)字段的若干行。多個(gè)Block橫切的一行是真實(shí)的一行數(shù)據(jù)。一個(gè)Page最大1MB，最多16 * 1024行數(shù)據(jù)。

核心問題之Presto為什么這么快？

我們?cè)谶x擇Presto時(shí)很大一個(gè)考量就是計(jì)算速度，因?yàn)橐粋€(gè)類似SparkSQL的計(jì)算引擎如果沒有速度和效率加持，那么很快就就會(huì)被拋棄。

美團(tuán)的博客中給出了這個(gè)答案：

• 完全基于內(nèi)存的并行計(jì)算

• 流水線式的處理

• 本地化計(jì)算

• 動(dòng)態(tài)編譯執(zhí)行計(jì)劃

• 小心使用內(nèi)存和數(shù)據(jù)結(jié)構(gòu)

• 類BlinkDB的近似查詢

• GC控制

和Hive這種需要調(diào)度生成計(jì)劃且需要中間落盤的核心優(yōu)勢(shì)在于：Presto是常駐任務(wù)，接受請(qǐng)求立即執(zhí)行，全內(nèi)存并行計(jì)算；Hive需要用yarn做資源調(diào)度，接受查詢需要先申請(qǐng)資源，啟動(dòng)進(jìn)程，并且中間結(jié)果會(huì)經(jīng)過磁盤。

欲先攻其事，必先利其器之Presto調(diào)優(yōu)

合理設(shè)置分區(qū)

與Hive類似，Presto會(huì)根據(jù)元信息讀取分區(qū)數(shù)據(jù)，合理的分區(qū)能減少Presto數(shù)據(jù)讀取量，提升查詢性能。

使用列式存儲(chǔ)

Presto對(duì)ORC文件讀取做了特定優(yōu)化，因此在Hive中創(chuàng)建Presto使用的表時(shí)，建議采用ORC格式存儲(chǔ)。相對(duì)于Parquet，Presto對(duì)ORC支持更好。

使用壓縮

數(shù)據(jù)壓縮可以減少節(jié)點(diǎn)間數(shù)據(jù)傳輸對(duì)IO帶寬壓力，對(duì)于即席查詢需要快速解壓，建議采用snappy壓縮

預(yù)排序

對(duì)于已經(jīng)排序的數(shù)據(jù)，在查詢的數(shù)據(jù)過濾階段，ORC格式支持跳過讀取不必要的數(shù)據(jù)。比如對(duì)于經(jīng)常需要過濾的字段可以預(yù)先排序。

內(nèi)存調(diào)優(yōu)

Presto有三種內(nèi)存池，分別為GENERAL_POOL、RESERVED_POOL、SYSTEM_POOL。這三個(gè)內(nèi)存池占用的內(nèi)存大小是由下面算法進(jìn)行分配的：

builder.put(RESERVED_POOL, new MemoryPool(RESERVED_POOL, config.getMaxQueryMemoryPerNode()));
builder.put(SYSTEM_POOL, new MemoryPool(SYSTEM_POOL, systemMemoryConfig.getReservedSystemMemory()));
long maxHeap = Runtime.getRuntime().maxMemory();
maxMemory = new DataSize(maxHeap - systemMemoryConfig.getReservedSystemMemory().toBytes(), BYTE);
DataSize generalPoolSize = new DataSize(Math.max(0, maxMemory.toBytes() - config.getMaxQueryMemoryPerNode().toBytes()), BYTE);
builder.put(GENERAL_POOL, new MemoryPool(GENERAL_POOL, generalPoolSize));

簡(jiǎn)單的說，RESERVED_POOL大小由config.properties里的query.max-memory-per-node指定；SYSTEM_POOL由config.properties里的resources.reserved-system-memory指定，如果不指定，默認(rèn)值為Runtime.getRuntime().maxMemory() * 0.4，即0.4 * Xmx值；而GENERAL_POOL值為 總內(nèi)存（Xmx值）- 預(yù)留的（max-memory-per-node）- 系統(tǒng)的（0.4 * Xmx）。

從Presto的開發(fā)手冊(cè)中可以看到：

GENERAL_POOL is the memory pool used by the physical operators in a query.
SYSTEM_POOL is mostly used by the exchange buffers and readers/writers.
RESERVED_POOL is for running a large query when the general pool becomes full.

簡(jiǎn)單說GENERAL_POOL用于普通查詢的physical operators；SYSTEM_POOL用于讀寫buffer；而RESERVED_POOL比較特殊，大部分時(shí)間里是不參與計(jì)算的，只有當(dāng)同時(shí)滿足如下情形下，才會(huì)被使用，然后從所有查詢里獲取占用內(nèi)存最大的那個(gè)查詢，然后將該查詢放到 RESERVED_POOL 里執(zhí)行，同時(shí)注意RESERVED_POOL只能用于一個(gè)Query。

我們經(jīng)常遇到的幾個(gè)錯(cuò)誤：

Query exceeded per-node total memory limit of xx
適當(dāng)增加query.max-total-memory-per-node。

Query exceeded distributed user memory limit of xx
適當(dāng)增加query.max-memory。

Could not communicate with the remote task. The node may have crashed or be under too much load
內(nèi)存不夠，導(dǎo)致節(jié)點(diǎn)crash，可以查看/var/log/message。

并行度

我們可以通過調(diào)整線程數(shù)增大task的并發(fā)以提高效率。

SQL優(yōu)化

• 只選擇使用必要的字段： 由于采用列式存儲(chǔ)，選擇需要的字段可加快字段的讀取、減少數(shù)據(jù)量。避免采用 * 讀取所有字段

• 過濾條件必須加上分區(qū)字段

• Group By語句優(yōu)化： 合理安排Group by語句中字段順序?qū)π阅苡幸欢ㄌ嵘?。將Group By語句中字段按照每個(gè)字段distinct數(shù)據(jù)多少進(jìn)行降序排列， 減少GROUP BY語句后面的排序一句字段的數(shù)量能減少內(nèi)存的使用.

• Order by時(shí)使用Limit， 盡量避免ORDER BY： Order by需要掃描數(shù)據(jù)到單個(gè)worker節(jié)點(diǎn)進(jìn)行排序，導(dǎo)致單個(gè)worker需要大量內(nèi)存

• 使用近似聚合函數(shù)： 對(duì)于允許有少量誤差的查詢場(chǎng)景，使用這些函數(shù)對(duì)查詢性能有大幅提升。比如使用approx_distinct() 函數(shù)比Count(distinct x)有大概2.3%的誤差

• 用regexp_like代替多個(gè)like語句： Presto查詢優(yōu)化器沒有對(duì)多個(gè)like語句進(jìn)行優(yōu)化，使用regexp_like對(duì)性能有較大提升

• 使用Join語句時(shí)將大表放在左邊： Presto中join的默認(rèn)算法是broadcast join，即將join左邊的表分割到多個(gè)worker，然后將join右邊的表數(shù)據(jù)整個(gè)復(fù)制一份發(fā)送到每個(gè)worker進(jìn)行計(jì)算。如果右邊的表數(shù)據(jù)量太大，則可能會(huì)報(bào)內(nèi)存溢出錯(cuò)誤。

• 使用Rank函數(shù)代替row_number函數(shù)來獲取Top N

• UNION ALL 代替 UNION ：不用去重

• 使用WITH語句： 查詢語句非常復(fù)雜或者有多層嵌套的子查詢，請(qǐng)?jiān)囍肳ITH語句將子查詢分離出來

當(dāng)然還有很多優(yōu)化的方式，建議大家都在網(wǎng)上搜一些資料，并且參考Presto操作手冊(cè)。

它山之石可以攻玉之行業(yè)典型應(yīng)用

這部分內(nèi)容是小編參考的各大公司的行業(yè)應(yīng)用進(jìn)行的總結(jié)，目的是可以幫大家找到適合自己公司業(yè)務(wù)的應(yīng)用方式。具體的原文可以再最后的參考鏈接中找到。

Presto 在滴滴的應(yīng)用

滴滴 Presto 用了3年時(shí)間逐漸接入公司各大數(shù)據(jù)平臺(tái)，并成為了公司首選 Ad-Hoc 查詢引擎及 Hive SQL 加速引擎，支持了包含以下的業(yè)務(wù)場(chǎng)景：

• Hive SQL查詢加速

• 數(shù)據(jù)平臺(tái)Ad-Hoc查詢

• 報(bào)表（BI報(bào)表、自定義報(bào)表）

• 活動(dòng)營銷

• 數(shù)據(jù)質(zhì)量檢測(cè)

• 資產(chǎn)管理

• 固定數(shù)據(jù)產(chǎn)品

為了適配各個(gè)業(yè)務(wù)線，二次開發(fā)了 JDBC、Go、Python、Cli、R、NodeJs 、HTTP 等多種接入方式，打通了公司內(nèi)部權(quán)限體系，讓業(yè)務(wù)方方便快捷的接入 Presto 的，滿足了業(yè)務(wù)方多種技術(shù)棧的接入需求。

Presto 接入了查詢路由 Gateway，Gateway 會(huì)智能選擇合適的引擎，用戶查詢優(yōu)先請(qǐng)求 Presto，如果查詢失敗，會(huì)使用 Spark 查詢，如果依然失敗，最后會(huì)請(qǐng)求 Hive。在 Gateway 層，我們做了一些優(yōu)化來區(qū)分大查詢、中查詢及小查詢，對(duì)于查詢時(shí)間小于 3 分鐘的，我們即認(rèn)為適合 Presto 查詢，比如通過 HBO（基于歷史的統(tǒng)計(jì)信息）及 JOIN 數(shù)量來區(qū)分查詢大小，架構(gòu)圖如下：

在滴滴內(nèi)部，Presto 主要用于 Ad-Hoc 查詢及 Hive SQL 查詢加速，為了方便用戶能盡快將 SQL 遷移到 Presto 引擎上，且提高 Presto 引擎查詢性能，我們對(duì) Presto 做了大量二次開發(fā)。這些功能主要包括：

• Hive SQL 兼容

• 物理資源隔離

• 直連Druid 的 Connector

• 多租戶等

Presto 在使用過程中會(huì)遇到很多穩(wěn)定性問題，比如 Coordinator OOM，Worker Full GC 等。

滴滴給我們總結(jié)了 Coordinator 常見的問題和解決方法：

• 使用HDFS FileSystem Cache導(dǎo)致內(nèi)存泄漏，解決方法禁止FileSystem Cache，后續(xù)Presto自己維護(hù)了FileSystem Cache

• Jetty導(dǎo)致堆外內(nèi)存泄漏，原因是Gzip導(dǎo)致了堆外內(nèi)存泄漏，升級(jí)Jetty版本解決

• Splits太多，無可用端口，TIME_WAIT太高，修改TCP參數(shù)解決

• Presto內(nèi)核Bug，查詢失敗的SQL太多，導(dǎo)致Coordinator內(nèi)存泄漏，社區(qū)已修復(fù)

而 Presto Worker 主要用于計(jì)算，性能瓶頸點(diǎn)主要是內(nèi)存和 CPU。內(nèi)存方面通過三種方法來保障和查找問題：

• 通過Resource Group控制業(yè)務(wù)并發(fā)，防止嚴(yán)重超賣

• 通過JVM調(diào)優(yōu)，解決一些常見內(nèi)存問題，如Young GC Exhausted

• 善用MAT工具，發(fā)現(xiàn)內(nèi)存瓶頸

Presto 在有贊的應(yīng)用

有贊在Presto上主要用來進(jìn)行以下業(yè)務(wù)支持：

• 數(shù)據(jù)平臺(tái)(DP)的臨時(shí)查詢: 有贊的大數(shù)據(jù)團(tuán)隊(duì)使用臨時(shí)查詢進(jìn)行探索性的數(shù)據(jù)分析的統(tǒng)一入口，同時(shí)也提供了脫敏，審計(jì)等功能。

• BI 報(bào)表引擎：為商家提供了各類分析型的報(bào)表。

• 元數(shù)據(jù)數(shù)據(jù)質(zhì)量校驗(yàn)等：元數(shù)據(jù)系統(tǒng)會(huì)使用 Presto 進(jìn)行數(shù)據(jù)質(zhì)量校驗(yàn)。

• 數(shù)據(jù)產(chǎn)品：比如 CRM 數(shù)據(jù)分析，人群畫像等會(huì)使用 Presto 進(jìn)行計(jì)算。

當(dāng)然，有贊在使用Presto的過程中也經(jīng)歷了漫長的迭代：

• 第一階段: Presto 和 Hadoop 混合部署

• 第二階段: Presto 集群完全獨(dú)立階段

• 第三階段: 低延時(shí)業(yè)務(wù)專用 Presto 集群階段

在第二階段的資源隔離主要還是靠 Resource Group，但是這種隔離方式相對(duì)比較弱，不能提供細(xì)粒度的隔離，任務(wù)之間還是會(huì)互相影響。此外，不同業(yè)務(wù)的 sql 類型，查詢數(shù)據(jù)量，查詢時(shí)間，可容忍的 SLA，可提供的最優(yōu)配置都是不一樣的。有些業(yè)務(wù)方需要一個(gè)特別低的響應(yīng)時(shí)間保證，于是有贊給這類業(yè)務(wù)部署了專門的集群去處理。

部署在這個(gè)集群上的業(yè)務(wù)要求低延時(shí)，通常是 3 秒內(nèi)，甚至有些能夠達(dá)到 1 秒內(nèi)，而且會(huì)有一定量的并發(fā)。不過這類業(yè)務(wù)通常數(shù)據(jù)量不是非常大，而且通常都是大寬表，也就不需要再去 Join 別的數(shù)據(jù)，Group By 形成的 Group 基數(shù)和產(chǎn)生的聚合數(shù)據(jù)量不是特別大，查詢時(shí)間主要消耗在數(shù)據(jù)掃描讀取時(shí)間上。同樣也提供了資源完全獨(dú)立，具有本地 HDFS 的專用 Presto 集群給這類業(yè)務(wù)方去使用。此外，會(huì)為這種業(yè)務(wù)提供深度的性能測(cè)試，調(diào)整相應(yīng)的配置，比如將 Task Concurrency 改成 1，在并發(fā)量高的測(cè)試場(chǎng)景中，反而由于減少了線程間切換，性能會(huì)更好。

最后，有贊在使用Presto的過程中發(fā)生的主要問題包括：

• HDFS 小文件問題

HDFS 小文件問題在大數(shù)據(jù)領(lǐng)域是個(gè)常見的問題。數(shù)倉 Hive 表有些表的文件有幾千個(gè)，查詢特別慢。Presto 下面這兩個(gè)參數(shù)限制了 Presto 每個(gè)節(jié)點(diǎn)每個(gè) Task 可執(zhí)行的最大 Split 數(shù)目：

node-scheduler.max-splits-per-node=100
node-scheduler.max-pending-splits-per-task=10

• 多個(gè)列 Distinct 的問題

簡(jiǎn)單的說，正常的優(yōu)化器應(yīng)該使用 grouping sets 去將多個(gè) group by 整合到一起來提升性能：

   SELECT a1, a2,..., an, F1(b1), F2(b2), F3(b3), ...., Fm(bm), F1(distinct c1), ...., Fm(distinct cm) FROM Table GROUP BY a1, a2, ..., an
 
   轉(zhuǎn)換為
 
   SELECT a1, a2,..., an, arbitrary(if(group = 0, f1)),...., arbitrary(if(group = 0, fm)), F(if(group = 1, c1)), ...., F(if(group = m, cm)) FROM
       SELECT a1, a2,..., an, F1(b1) as f1, F2(b2) as f2,...., Fm(bm) as fm, c1,..., cm group FROM
         SELECT a1, a2,..., an, b1, b2, ... ,bn, c1,..., cm FROM Table GROUP BY GROUPING SETS ((a1, a2,..., an, b1, b2, ... ,bn), (a1, a2,..., an, c1), ..., ((a1, a2,..., an, cm)))
       GROUP BY a1, a2,..., an, c1,..., cm group
   GROUP BY a1, a2,..., an

但是很遺憾，Presto并沒有實(shí)現(xiàn)這樣的功能。

以上就是Presto在大數(shù)據(jù)領(lǐng)域的實(shí)踐和探索是怎樣的，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。