Presto+Alluxio性能調優五大技巧
- 2019 年 12 月 30 日
- 筆記
Presto是一個開源的分散式SQL引擎，因其查詢具有低延遲、高並發性和原生支援多數據源的特點而廣受認可。Alluxio是一個開源分散式文件系統，以記憶體速度提供統一的數據訪問層。Presto和Alluxio的組合(見文末鏈接1)在京東(見文末鏈接2)、網易(見文末鏈接3)等許多公司中越來越受歡迎，這些公司將Alluxio構建在慢速或遠程存儲之上作為分散式快取層，以便查詢熱數據，避免反覆從雲存儲中讀取數據。
之前的一篇部落格文章(見文末鏈接4)中，我們已經在高層次上討論了Presto+Alluxio數據分析技術棧的優勢。本文將深入探討Presto+Alluxio數據分析技術棧的五大性能調優技巧。
關於數據本地性注意事項
默認情況下，當Presto從遠程數據源（例如AWS S3）讀取數據時，其任務調度不會考慮數據位置因素，因為數據源始終都是遠程的。但是當Presto與Alluxio服務同置(collocated)運行時，Alluxio可能會將輸入數據快取到Presto worker的本地，並以記憶體速度提供下次檢索。在這種情況下，Presto可以利用Alluxio從本地的Alluxio worker存儲讀取數據（稱之為短路讀取），無需任何額外的網路傳輸。因此，為了最大化數據輸入吞吐量，用戶應確保實現任務本地性和Alluxio短路讀取。
要檢查是否按照預期實現了本地性和短路讀取，可以在Alluxio Metrics（見文末鏈接5）UI頁面監控Short-circuit Read和From Remote Instances這兩項：
如果短路讀取的百分比較低，可以使用dstat來監控Alluxio worker的網路流量模式。
1、本地性感知調度 (Locality-aware Scheduling)
為了使Presto能夠利用數據本地性，可以啟用本地性感知調度模式，以便Presto協調器(coordinator)可以在Presto worker上調度具有本地快取的數據分片或數據塊的任務。在config.properties中設置node-scheduler.network-topology=flat；並且如果你正使用Hiveconnector從Alluxio讀取數據，在catalog/hive.properties中設置hive.force-local-scheduling=true。
2、確保主機名匹配
感知本地性任務調度是基於Alluxio worker的文件塊地址與Presto worker地址之間的字元串匹配進行的。如果使用IP指定Presto worker地址，並使用機器主機名指定Alluxio worker地址，即便Presto worker和Alluxio worker是同置的，地址也將不匹配。為了避免這種情況，需配置alluxio.worker.hostname和alluxio.user.hostname屬性，以匹配Presto worker地址的主機名。用戶可以在alluxio-site.properties中設置這些屬性，並在Presto的etc/jvm.config的-Xbootclasspath/p:<path toalluxio-site.properties>里設置其路徑。
使用高並發來均衡 I/O 和CPU負載
在開啟感知本地性調度後，一旦輸入數據快取到在Alluxio中，Presto就可以從本地Alluxio存儲（例如，Alluxio worker配置中的Ramdisk）直接高效地讀取數據。在這種情況下，查詢的性能瓶頸可能會從I/O頻寬轉移到CPU資源。請檢查Presto worker上的CPU使用情況：如果CPU沒有完全飽和，則可能表明Presto worker執行緒的數量可以設置地更高，或者在批處理中數據分片的數量還不夠大。
3、更多worker執行緒
可以通過設置config.properties中的task.max-worker-threads來調整worker執行緒數量，典型的設置數量為CPU核數乘以Presto worker節點單核的超執行緒(hyper-thread)數。可能還需要調整task.concurrency來調節某些並行運算符（如連接和聚合）的本地並發性。
4、批處理中的數據分片數量
Presto會定期調度並將數據分片分配到批處理中。每個批處理的數據分片之間的調度間隙會浪費可用於查詢處理的CPU周期。數據分片會處於兩種狀態：「待處理(pending)」和「正在運行(running)」。將數據分片分配給Presto worker時，數據分片會處於待處理狀態，然後當Presto worker執行緒開始處理數據分片時，數據分片會轉換到正在運行狀態。node-scheduler.max-splits-per-node屬性控制Presto節點上待處理和正在運行的數據分片的數量上限，node-scheduler.max-pending-splits-per-task屬性控制待處理數據分片的數量上限。提高這兩個屬性的值，可以防止Presto worker執行緒飢餓(starvation)並減少調度開銷。請注意，如果這兩個屬性的值太高，則可能導致僅將所有數據分片只分配給一小部分worker，從而導致worker負載不均衡。
其 他
5、防止Alluxio客戶端超時
在瓶頸為網路頻寬的I/O密集型工作負載下，用戶可能會遇到由Alluxio1.8中的Netty超時引起的異常，例如：
這是因為Presto中的Alluxio客戶端未能在預設超時時間內從Alluxio worker獲取數據。在這種情況下，可以將alluxio.user.network.netty.timeout增加到更大的值（例如，10分鐘）。
結 論
通過本文，我們總結了運行Presto+Alluxio技術棧的性能調優技巧。我們發現實現數據高度本地性和足夠的並行度是獲得最佳性能的關鍵。如果你有興趣加速Presto工作負載中緩慢的I/O，你可以按照此文檔（見文末鏈接6）試試！
附錄鏈接：
鏈接1：
http://www.alluxio.org/docs/1.8/en/compute/Presto.html
鏈接2：
http://www.alluxio.org/docs/1.8/en/operation/Metrics-System.html
鏈接3：
https://www.alluxio.com/blog/presto-on-alluxio-how-netease-games-leveraged-alluxio-to-boost-ad-hoc-sql-on-hdfs?platform=hootsuite
鏈接4：
https://www.alluxio.com/blog/starburst-presto-alluxio-better-togethe
鏈接5：
http://www.alluxio.org/docs/1.8/en/operation/Metrics-System.html
鏈接6：
http://www.alluxio.org/docs/2.0-preview/en/compute/Presto.html
