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所需要的這種數據結構。
豐富的插件接口，完美對接外部存儲系統，或者添加自定義的函數。
為了給大家一個更為清晰一點的印象，我們可以把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從用戶獲得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之間的通信。WorkersPresto的worker是Presto集群中的一個服務。它負責運行coordinator指派給它的任務，並處理數據。worker節點通過連接器（connector）向數據源獲取數據，並且相互之間可以交換數據。最終結果會傳遞給coordinator。coordinator負責從worker獲取最終結果，並傳遞給客戶端。Worker之間的通信、worker和coordinator之間的通信採用基於HTTP的協議。下圖展示了多個worker如何從數據源獲取數據，並且合作處理數據的流程。直到某一個worker把數據提供給了coordinator。一層一層剝開你的心之Presto數據模型Presto採取了三層表結構，我們可以和Mysql做一下類比：在Presto中定位一張表，一般是catalog為根，例如：一張表的全稱為 hive.testdata.test，標識 hive(catalog)下的 testdata(schema)中test表。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));
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.
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。
只選擇使用必要的欄位：由於採用列式存儲，選擇需要的欄位可加快欄位的讀取、減少數據量。避免採用 * 讀取所有欄位
過濾條件必須加上分區欄位
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 用了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。內存方面通過三種方法來保障和查找問題：數據平臺(DP)的臨時查詢: 有贊的大數據團隊使用臨時查詢進行探索性的數據分析的統一入口，同時也提供了脫敏，審計等功能。
BI 報表引擎：為商家提供了各類分析型的報表。
元數據數據質量校驗等：元數據系統會使用 Presto 進行數據質量校驗。
數據產品：比如 CRM 數據分析，人群畫像等會使用 Presto 進行計算。
當然，有贊在使用Presto的過程中也經歷了漫長的迭代：在第二階段的資源隔離主要還是靠 Resource Group，但是這種隔離方式相對比較弱，不能提供細粒度的隔離，任務之間還是會互相影響。此外，不同業務的 sql 類型，查詢數據量，查詢時間，可容忍的 SLA，可提供的最優配置都是不一樣的。有些業務方需要一個特別低的響應時間保證，於是有贊給這類業務部署了專門的集群去處理。部署在這個集群上的業務要求低延時，通常是 3 秒內，甚至有些能夠達到 1 秒內，而且會有一定量的並發。不過這類業務通常數據量不是非常大，而且通常都是大寬表，也就不需要再去 Join 別的數據，Group By 形成的 Group 基數和產生的聚合數據量不是特別大，查詢時間主要消耗在數據掃描讀取時間上。同樣也提供了資源完全獨立，具有本地 HDFS 的專用 Presto 集群給這類業務方去使用。此外，會為這種業務提供深度的性能測試，調整相應的配置，比如將 Task Concurrency 改成 1，在並發量高的測試場景中，反而由於減少了線程間切換，性能會更好。最後，有贊在使用Presto的過程中發生的主要問題包括：HDFS 小文件問題在大數據領域是個常見的問題。數倉 Hive 表有些表的文件有幾千個，查詢特別慢。Presto 下面這兩個參數限制了 Presto 每個節點每個 Task 可執行的最大 Split 數目：node-scheduler.max-splits-per-node=100
node-scheduler.max-pending-splits-per-task=10
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
參考列表：
https://tech.meituan.com/2014/06/16/presto.htmlhttps://blog.csdn.net/didi_tech/article/details/108989149https://cloud.tencent.com/developer/news/606849https://cloud.tencent.com/developer/article/1371128