Presto原理&調(diào)優(yōu)&面試&實戰(zhàn)全面升級版

很久之前，曾經(jīng)寫過一篇 《Presto在大數(shù)據(jù)領(lǐng)域的實踐和探索》 。文中詳細講解了Presto的原理和應(yīng)用。

今天這篇文章是升級版本，把我個人讀過的文章和書籍的筆記進行了系統(tǒng)整理。從起源、原理、調(diào)優(yōu)、面試、實踐應(yīng)用進行了全方位的升級。希望對你們有幫助。

一、起源

Presto 是由 FaceBook 開源的一個 MPP 計算引擎，主要用來以解決 Facebook 海量 Hadoop 數(shù)據(jù)倉庫的低延遲交互分析問題，F(xiàn)acebook 版本的 Presto 更多的是以解決企業(yè)內(nèi)部需求功能為主，也叫 PrestoDB，版本號以 0.xxx 來劃分。

后來，Presto 其中的幾個人出來創(chuàng)建了更通用的 Presto 分支，取名 Presto SQL，版本號以 xxx 來劃分，例如 345 版本，這個開源版本也是更為被大家通用的版本。前一段時間，為了更好的與 Facebook 的 Presto 進行區(qū)分，Presto SQL 將名字改為 Trino，除了名字改變了其他都沒變。不管是 Presto DB 還是 Presto SQL，它們”本是同根生“，因此它們的大部分的機制原理是一樣的。

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

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)對Presto的定義，Presto 是由 Facebook 開源的大數(shù)據(jù)分布式 SQL 查詢引擎，適用于交互式分析查詢，可支持眾多的數(shù)據(jù)源，包括 HDFS，RDBMS，KAFKA 等，而且提供了非常友好的接口開發(fā)數(shù)據(jù)源連接器。

二、特點及場景介紹

1.特點

Presto 引擎相較于其他引擎的特點正如文章標題描述的這樣，多源、即席。多源就是它可以支持跨不同數(shù)據(jù)源的聯(lián)邦查詢，即席即實時計算，將要做的查詢?nèi)蝿?wù)實時拉取到本地進行現(xiàn)場計算，然后返回計算結(jié)果。除此之外，對于引擎本身，它有幾個值得關(guān)注的特點：

（1）多租戶：它支持并發(fā)執(zhí)行數(shù)百個內(nèi)存、I/O 以及 CPU 密集型的負載查詢，并支持集群規(guī)模擴展到上千個節(jié)點；
（2）聯(lián)邦查詢：它可以由開發(fā)者利用開放接口自定義開發(fā)針對不同數(shù)據(jù)源的連接器（Connector),從而支持跨多種不同數(shù)據(jù)源的聯(lián)邦數(shù)據(jù)查詢；
（3）內(nèi)在特性：為了保證引擎的高效性，Presto 還進行了一些優(yōu)化，例如基于 JVM 運行，Code- Generation 等。

2.場景

Presto 的應(yīng)用場景非常廣泛，接下來我們主要介紹幾種使用比較廣泛的場景進行介紹。

（1）交互式分析：交互式查詢是 Presto 主打的應(yīng)用場景，Presto 的即席計算特性和內(nèi)部設(shè)計機制就是為了能夠更好地支持用戶進行交互式分析。可以類比用戶基于 Hive 交互式查詢 HDFS 中的數(shù)據(jù)，用戶可以基于 Presto 查詢各種不同的數(shù)據(jù)源的數(shù)據(jù)。
（2）批量 ETL。
（3）Facebook 的 A/B Test 基礎(chǔ)架構(gòu)也是基于Presto 構(gòu)建的。

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

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

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

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

三、整體架構(gòu)

圖 1 Presto 架構(gòu)圖

Presto 主要是由 Client、Coordinator、Worker 以及 Connector 等幾部分構(gòu)成。

1.SQL 語句提交：

用戶或應(yīng)用通過 Presto 的 JDBC 接口或者 CLI 來提交 SQL 查詢，提交的 SQL 最終傳遞給 Coordinator 進行下一步處理；

2.詞/語法分析：

首先會對接收到的查詢語句進行詞法分析和語法分析，形成一棵抽象語法樹。
然后，會通過分析抽象語法樹來形成邏輯查詢計劃。

圖 2 查詢 SQL

3.生成邏輯計劃：

圖 2 是 TPC-H 測試基準中的一條 SQL 語句，表達的是兩表連接同時帶有分組聚合計算的例子，經(jīng)過詞法語法分析后，得到 AST，然后進一步分析得到如下的邏輯計劃。

圖 3 邏輯計劃

上圖就是一棵邏輯計劃樹，每個節(jié)點代表一個物理或邏輯操作，每個節(jié)點的子節(jié)點作為該節(jié)點的輸入。邏輯計劃只是一個單純描述 SQL 的執(zhí)行邏輯，但是并不包括具體的執(zhí)行信息，例如該操作是在單節(jié)點上執(zhí)行還是可以在多節(jié)點并行執(zhí)行，再例如什么時候需要進行數(shù)據(jù)的 shuffle 操作等。

4.查詢優(yōu)化：

Coordinator 將一系列的優(yōu)化策略（例如剪枝操作、謂詞下推、條件下推等）應(yīng)用于與邏輯計劃的各個子計劃，從而將邏輯計劃轉(zhuǎn)換成更加適合物理執(zhí)行的結(jié)構(gòu)，形成更加高效的執(zhí)行策略。

下面具體來說說優(yōu)化器在幾個方面所做的工作：

（1）自適應(yīng)：Presto 的 Connector 可以通過 Data Layout API 提供數(shù)據(jù)的物理分布信息（例如數(shù)據(jù)的位置、分區(qū)、排序、分組以及索引等屬性），如果一個表有多種不同的數(shù)據(jù)存儲分布方式，Connector 也可以將所有的數(shù)據(jù)布局全部返回，這樣 Presto 優(yōu)化器就可以根據(jù) query 的特點來選擇最高效的數(shù)據(jù)分布來讀取數(shù)據(jù)并進行處理。

（2）謂詞下推：謂詞下推是一個應(yīng)用非常普遍的優(yōu)化方式，就是將一些條件或者列盡可能的下推到葉子結(jié)點，最終將這些交給數(shù)據(jù)源去執(zhí)行，從而可以大大減少計算引擎和數(shù)據(jù)源之間的 I/O，提高效率。

圖 4 圖 3 的邏輯計劃進一步轉(zhuǎn)換后的執(zhí)行計劃（未進行）

（3）節(jié)點間并行：不同 stage 之間的數(shù)據(jù) shuffle 會帶來很大的內(nèi)存和 CPU 開銷，因此，將 shuffle 數(shù)優(yōu)化到最小是一個非常重要的目標。圍繞這個目標，Presto 可以借助一下兩類信息：

• 數(shù)據(jù)布局信息：上面我們提到的數(shù)據(jù)物理分布信息同樣可以用在這里以減少 shuffle 數(shù)。例如，如果進行 join 連接的兩個表的字段同屬于分區(qū)字段，則可以將連接操作在在各個節(jié)點分別進行，從而可以大大減少數(shù)據(jù)的 shuffle。

• 再比如兩個表的連接鍵加了索引，可以考慮采用嵌套循環(huán)的連接策略。

（4）節(jié)點內(nèi)并行：優(yōu)化器通過在節(jié)點內(nèi)部使用多線程的方式來提高節(jié)點內(nèi)對并行度，延遲更小且會比節(jié)點間并行效率更高。

• 交互式分析：交互式查詢的負載大部分是一次執(zhí)行的短查詢，查詢負載一般不會經(jīng)過優(yōu)化，這就會導致數(shù)據(jù)傾斜的現(xiàn)象時有發(fā)生。典型的表現(xiàn)為少量的節(jié)點被分到了大量的數(shù)據(jù)。

• 批量 ETL：這類的查詢特點是任務(wù)會不加過濾的從葉子結(jié)點拉取大量的數(shù)據(jù)到上層節(jié)點進行轉(zhuǎn)換操作，致使上層節(jié)點壓力非常大。

針對以上兩種場景遇到的問題，引擎可以通過多線程來運行單個操作符序列（或 pipeline），如圖 5 所示的，pipeline1 和 2 通過多線程并行執(zhí)行來加速 build 端的 hash-join。

圖 5 pipeline1 和 2 通過多線程并行執(zhí)行來加速 build 端的 hash-join

當然，除了上述列舉的 Presto 優(yōu)化器已經(jīng)實現(xiàn)的優(yōu)化策略，Presto 也正在積極探索 Cascades framework，相信未來優(yōu)化器會得到進一步的改進。

5.容錯

Presto 可以對一些臨時的報錯采用低級別的重試來恢復(fù)。Presto 依靠的是客戶端的自動重跑失敗查詢。內(nèi)嵌容錯機制來解決 coordinator 或者 worker 節(jié)點壞掉的情況目前Presto支持的并不理想。

標準檢查點或者部分修復(fù)技術(shù)是計算代價比較高的，而且很難在這種一旦結(jié)果可用就返回給客戶端（即時查詢類）的系統(tǒng)中實現(xiàn)。

五、Presto調(diào)優(yōu)

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

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

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

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

內(nèi)存調(diào)優(yōu)
Presto有三種內(nèi)存池，分別為GENERAL_POOL、RESERVED_POOL、SYSTEM_POOL。

• GENERAL_POOL：用于普通查詢的 physical operators。GENERAL_POOL 值為 總內(nèi)存（Xmx 值）- 預(yù)留的（max-memory-per-node）- 系統(tǒng)的（0.4 * Xmx）。

• SYSTEM_POOL：系統(tǒng)預(yù)留內(nèi)存，用于讀寫 buffer，worker 初始化以及執(zhí)行任務(wù)必要的內(nèi)存。大小由 config.properties 里的 resources.reserved-system-memory 指定。默認值為 JVM max memory * 0.4。

• RESERVED_POOL：大部分時間里是不參與計算的，只有當同時滿足如下情形下，才會被使用，然后從所有查詢里獲取占用內(nèi)存最大的那個查詢，然后將該查詢放到 RESERVED_POOL 里執(zhí)行，同時注意 RESERVED_POOL 只能用于一個 Query。大小由 config.properties 里的 query.max-memory-per-node 指定，默認值為：JVM max memory * 0.1。

這三個內(nèi)存池占用的內(nèi)存大小是由下面算法進行分配的：

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));

簡單的說，RESERVED_POOL大小由config.properties里的query.max-memory-per-node指定；SYSTEM_POOL由config.properties里的resources.reserved-system-memory指定，如果不指定，默認值為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ā)手冊中可以看到：

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.

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

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

Query exceeded per-node total memory limit of xx
適當增加query.max-total-memory-per-node。

Query exceeded distributed user memory limit of xx
適當增加query.max-memory。

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

并行度
調(diào)整線程數(shù)增大 task 的并發(fā)以提高效率。
修改參數(shù)

SQL優(yōu)化

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

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

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

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

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

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

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

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

• UNION ALL 代替 UNION ：不用去重

• 使用WITH語句：查詢語句非常復(fù)雜或者有多層嵌套的子查詢，請試著用WITH語句將子查詢分離出來

元數(shù)據(jù)緩存
Presto 支持 Hive connector，元數(shù)據(jù)存儲在 Hive metastore 中，調(diào)整元數(shù)據(jù)緩存的相關(guān)參數(shù)可以提高訪問元數(shù)據(jù)的效率。
修改參數(shù)

Hash 優(yōu)化
針對 Hash 場景的優(yōu)化。
修改參數(shù)

優(yōu)化 OBS 相關(guān)參數(shù)
Presto 支持 on OBS，讀寫 OBS 過程中可以調(diào)整 OBS 客戶端參數(shù)來提交讀寫效率。
修改參數(shù)

六、Presto數(shù)據(jù)模型

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

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

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

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

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

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

另外，presto的存儲單元包括：

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

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

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

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

我們在選擇Presto時很大一個考量就是計算速度，因為一個類似SparkSQL的計算引擎如果沒有速度和效率加持，那么很快就就會被拋棄。

美團的博客中給出了這個答案：

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

• 流水線式的處理

• 本地化計算

• 動態(tài)編譯執(zhí)行計劃

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

• 類BlinkDB的近似查詢

• GC控制

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

七、行業(yè)典型應(yīng)用

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

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

• Hive SQL查詢加速

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

• 報表（BI報表、自定義報表）

• 活動營銷

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

• 資產(chǎn)管理

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

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

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

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

• Hive SQL 兼容

• 物理資源隔離

• 直連Druid 的 Connector

• 多租戶等

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 第二階段: Presto 集群完全獨立階段

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

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

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

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

• HDFS 小文件問題

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

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

• 多個列 Distinct 的問題

簡單的說，正常的優(yōu)化器應(yīng)該使用 grouping sets 去將多個 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并沒有實現(xiàn)這樣的功能。以上就是有贊在使用Presto的一些經(jīng)驗。

八、總結(jié)

小編在學習Presto的過程中和其他的OLAP一樣，也是通過漫長的文檔搜索，官網(wǎng)摸索主鍵精進的，事實上在任何一門新技術(shù)的使用過程中大家都會遇到各種各樣的問題，如果利用現(xiàn)在有的資料解決問題就是考驗我們的時候了。