Presto在大數據領域的實踐和探索是怎樣的

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

下面從原理入門、線上調優、典型應用等幾個方面為讀者全面剖析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.

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

Presto之所以能在各個內存計算型數據庫中脫穎而出，在于以下幾點：

• 清晰的架構，是一個能夠獨立運行的系統，不依賴于任何其他外部系統。例如調度，presto自身提供了對集群的監控，可以根據監控信息完成調度。

• 簡單的數據結構，列式存儲，邏輯行，大部分數據都可以輕易的轉化成presto所需要的這種數據結構。

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

為了給大家一個更為清晰一點的印象，我們可以把Presto和Mysql進行一下對比：

首先Mysql是一個數據庫，具有存儲和計算分析能力，而Presto只有計算分析能力；其次數據量方面，Mysql作為傳統單點關系型數據庫不能滿足當前大數據量的需求，于是有各種大數據的存儲和分析工具產生，Presto就是這樣一個可以滿足大數據量分析計算需求的一個工具。

一覽無余之Presto的架構

我們借用美團的博客中的一張架構圖：

Presto查詢引擎是一個Master-Slave的架構，由一個Coordinator節點，一個Discovery Server節點，多個Worker節點組成，Discovery Server通常內嵌于Coordinator節點中。Coordinator負責解析SQL語句，生成執行計劃，分發執行任務給Worker節點執行。Worker節點負責實際執行查詢任務。Worker節點啟動后向Discovery Server服務注冊，Coordinator從Discovery Server獲得可以正常工作的Worker節點。如果配置了Hive Connector，需要配置一個Hive MetaStore服務為Presto提供Hive元信息，Worker節點與HDFS交互讀取數據。

Presto的服務進程

Presto集群中有兩種進程，Coordinator服務進程和worker服務進程。coordinator主要作用是接收查詢請求，解析查詢語句，生成查詢執行計劃，任務調度和worker管理。worker服務進程執行被分解的查詢執行任務task。

Coordinator 服務進程部署在集群中的單獨節點之中，是整個presto集群的管理節點，主要作用是接收查詢請求，解析查詢語句，生成查詢執行計劃Stage和Task并對生成的Task進行任務調度，和worker管理。Coordinator進程是整個Presto集群的master進程，需要與worker進行通信，獲取最新的worker信息，有需要和client通信，接收查詢請求。Coordinator提供REST服務來完成這些工作。

Presto集群中存在一個Coordinator和多個Worker節點，每個Worker節點上都會存在一個worker服務進程，主要進行數據的處理以及Task的執行。worker服務進程每隔一定的時間會發送心跳包給Coordinator。Coordinator接收到查詢請求后會從當前存活的worker中選擇合適的節點運行task。

上圖展示了從宏觀層面概括了Presto的集群組件：1個coordinator，多個worker節點。用戶通過客戶端連接到coordinator，可以短可以是JDBC驅動或者Presto命令行cli。

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

利用這種架構，Presto查詢引擎能夠并行的在集群的各個機器上，處理大規模數據的SQL查詢。Presto在每個節點上都是單進程的服務。多個節點都運行Presto，相互之間通過配置相互協作，組成了一個完整的Presto集群。

上圖展示了集群內coordinator和worker之間，以及worker和worker之間的通信。coordinator向多個worker通信，用于分配任務，更新狀態，獲得最終的結果返回用戶。worker之間相互通信，向任務的上游節點獲取數據。所有的worker都會向數據源讀取數據。

Coordinator

Coordinator的作用是：

• 從用戶獲得SQL語句

• 解析SQL語句

• 規劃查詢的執行計劃

• 管理worker節點狀態

Coordinator是Presto集群的大腦，并且是負責和客戶端溝通。用戶通過PrestoCLI、JDBC、ODBC驅動、其他語言工具庫等工具和coordinator進行交互。Coordinator從客戶端接受SQL語句，例如select語句，才能進行計算。

每個Presto集群必須有一個coordinator，可以有一個或多個worker。在開發和測試環境中，一個Presto進程可以同時配置成兩種角色。Coordinator追蹤每個worker上的活動，并且協調查詢的執行過程。Coordinator給查詢創建了一個包含多階段的邏輯模型，一旦接受了SQL語句，Coordinator就負責解析、分析、規劃、調度查詢在多個worker節點上的執行過程，語句被翻譯成一系列的任務，跑在多個worker節點上。worker一邊處理數據，結果會被coordinator拿走并且放到output緩存區上，暴露給客戶端。一旦輸出緩沖區被客戶完全讀取，coordinator會代表客戶端向worker讀取更多數據。worker節點，和數據源打交道，從數據源獲取數據。因此，客戶端源源不斷的讀取數據，數據源源源不斷的提供數據，直到查詢執行結束。

Coordinator通過基于HTTP的協議和worker、客戶端之間進行通信。

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

Workers

Presto的worker是Presto集群中的一個服務。它負責運行coordinator指派給它的任務，并處理數據。worker節點通過連接器（connector）向數據源獲取數據，并且相互之間可以交換數據。最終結果會傳遞給coordinator。 coordinator負責從worker獲取最終結果，并傳遞給客戶端。

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

一層一層剝開你的心之Presto數據模型

Presto采取了三層表結構，我們可以和Mysql做一下類比：

• catalog 對應某一類數據源，例如hive的數據，或mysql的數據

• schema 對應mysql中的數據庫

• table 對應mysql中的表

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

可以簡理解為：數據源.數據庫.數據表。

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

• Page： 多行數據的集合，包含多個列的數據，內部僅提供邏輯行，實際以列式存儲。

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

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

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

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

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

• 完全基于內存的并行計算

• 流水線式的處理

• 本地化計算

• 動態編譯執行計劃

• 小心使用內存和數據結構

• 類BlinkDB的近似查詢

• GC控制

和Hive這種需要調度生成計劃且需要中間落盤的核心優勢在于：Presto是常駐任務，接受請求立即執行，全內存并行計算；Hive需要用yarn做資源調度，接受查詢需要先申請資源，啟動進程，并且中間結果會經過磁盤。

欲先攻其事，必先利其器之Presto調優

合理設置分區

與Hive類似，Presto會根據元信息讀取分區數據，合理的分區能減少Presto數據讀取量，提升查詢性能。

使用列式存儲

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

使用壓縮

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

預排序

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

內存調優

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

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值為 總內存（Xmx值）- 預留的（max-memory-per-node）- 系統的（0.4 * Xmx）。

從Presto的開發手冊中可以看到：

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比較特殊，大部分時間里是不參與計算的，只有當同時滿足如下情形下，才會被使用，然后從所有查詢里獲取占用內存最大的那個查詢，然后將該查詢放到 RESERVED_POOL 里執行，同時注意RESERVED_POOL只能用于一個Query。

我們經常遇到的幾個錯誤：

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
內存不夠，導致節點crash，可以查看/var/log/message。

并行度

我們可以通過調整線程數增大task的并發以提高效率。

SQL優化

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

• 過濾條件必須加上分區字段

• Group By語句優化： 合理安排Group by語句中字段順序對性能有一定提升。將Group By語句中字段按照每個字段distinct數據多少進行降序排列， 減少GROUP BY語句后面的排序一句字段的數量能減少內存的使用.

• Order by時使用Limit， 盡量避免ORDER BY： Order by需要掃描數據到單個worker節點進行排序，導致單個worker需要大量內存

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

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

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

• 使用Rank函數代替row_number函數來獲取Top N

• UNION ALL 代替 UNION ：不用去重

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

當然還有很多優化的方式，建議大家都在網上搜一些資料，并且參考Presto操作手冊。

它山之石可以攻玉之行業典型應用

這部分內容是小編參考的各大公司的行業應用進行的總結，目的是可以幫大家找到適合自己公司業務的應用方式。具體的原文可以再最后的參考鏈接中找到。

Presto 在滴滴的應用

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

• Hive SQL查詢加速

• 數據平臺Ad-Hoc查詢

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

• 活動營銷

• 數據質量檢測

• 資產管理

• 固定數據產品

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

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

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

• Hive SQL 兼容

• 物理資源隔離

• 直連Druid 的 Connector

• 多租戶等

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

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

• 使用HDFS FileSystem Cache導致內存泄漏，解決方法禁止FileSystem Cache，后續Presto自己維護了FileSystem Cache

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

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

• Presto內核Bug，查詢失敗的SQL太多，導致Coordinator內存泄漏，社區已修復

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

• 通過Resource Group控制業務并發，防止嚴重超賣

• 通過JVM調優，解決一些常見內存問題，如Young GC Exhausted

• 善用MAT工具，發現內存瓶頸

Presto 在有贊的應用

有贊在Presto上主要用來進行以下業務支持：

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

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

• 元數據數據質量校驗等：元數據系統會使用 Presto 進行數據質量校驗。

• 數據產品：比如 CRM 數據分析，人群畫像等會使用 Presto 進行計算。

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

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

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

• 第三階段: 低延時業務專用 Presto 集群階段

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

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

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

• HDFS 小文件問題

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

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

• 多個列 Distinct 的問題

簡單的說，正常的優化器應該使用 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
 
   轉換為
 
   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并沒有實現這樣的功能。

以上就是Presto在大數據領域的實踐和探索是怎樣的，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。