小編在去年的時候，寫過一篇轟動全網的文章《你需要的不是實時數倉 | 你需要的是一款強大的OLAP數據庫》，這篇文章當時被各大門戶網站和自媒體瘋狂轉載，保守閱讀量也在50萬+UV，在這篇文章中提到過Preto，Presto作爲OLAP計算領域的一員有着獨特的優勢和特點。
本篇文章是作者作爲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的一些經驗。
總結
小編在學習Presto的過程中和其他的OLAP一樣，也是通過漫長的文檔搜索，官網摸索主鍵精進的，事實上在任何一門新技術的使用過程中大家都會遇到各種各樣的問題，如果利用現在有的資料解決問題就是考驗我們的時候了。
歡迎關注，《大數據成神之路》系列文章
歡迎關注，《大數據成神之路》系列文章
歡迎關注，《大數據成神之路》系列文章