Presto介紹與常用查詢優化方法
同步滾動：關
Presto
Hive使用MapReduce作為底層計算框架，是專為批處理設計的。但隨著數據越來越多，使用Hive進行一個簡單的數據查詢可能要花費幾分到幾小時，顯然不能滿足交互式查詢的需求。
2012年秋季開始開發，目前該項目已經在超過 1000名Facebook僱員中使用，運行超過30000個查詢，每日數據在1PB級別。Facebook稱Presto的性能比Hive要好上10倍多。2013年Facebook正式宣佈開源Presto。
Presto架構
image.png
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實現低延時查詢的原理，我認為主要是下面幾個關鍵點:
- 完全基於內存的並行計算
- 流水線
- 本地化計算
- 動態編譯執行計劃
- 小心使用內存和數據結構
- 類BlinkDB的近似查詢
- GC控制
更多詳情：https://blog.csdn.net/fly_time2012/article/details/52160140
Presto查詢優化
數據存儲
合理設置分區
與Hive類似，Presto會根據元信息讀取分區數據，合理的分區能減少Presto數據讀取量，提升查詢性能。
使用列式存儲
Presto對ORC文件讀取做了特定優化，因此在Hive中創建Presto使用的表時，建議採用ORC格式存儲。相對於Parquet，Presto對ORC支持更好。
使用壓縮
數據壓縮可以減少節點間數據傳輸對IO帶寬壓力，對於即席查詢需要快速解壓，建議採用snappy壓縮
預先排序
對於已經排序的數據，在查詢的數據過濾階段，ORC格式支持跳過讀取不必要的數據。比如對於經常需要過濾的字段可以預先排序。
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語句將子查詢分離出來
與Impala對比
Impala是Cloudera在受到Google的Dremel啟發下開發的實時交互SQL大數據查詢工具，Impala沒有再使用緩慢的Hive+MapReduce批處理，而是通過使用與商用並行關係數據庫中類似的分佈式查詢引擎。
Impala性能稍領先於presto,但是presto在數據源支持上非常豐富，presto對SQL的支持上也更多一些。同時由於版本迭代的問題，有一段時間Impala對 hadoop某些社區版本並不支持。
歡迎關注 高廣超的簡書博客 與 收藏文章 ！
本文首發在 高廣超的簡書博客 轉載請註明！
閱讀更多 互聯網技術棧 的文章
