Presto 優(yōu)化 | Presto 常用性能優(yōu)化技巧
Presto 是一個(gè)用于分析的開源分布式 ANSI SQL 查詢引擎，支持計(jì)算和存儲(chǔ)的分離。性能對(duì)于一些分析查詢尤其重要，因此 Presto 有許多設(shè)計(jì)特性來最大化 Presto 的速度，比如內(nèi)存中的流水線執(zhí)行（memory pipelined execution）、分布式的擴(kuò)展架構(gòu)和大規(guī)模并行處理（MPP）設(shè)計(jì)。Presto支持的具體性能特性：
?數(shù)據(jù)壓縮（SNAPPY, LZ4, ZSTD 以及 GZIP）?數(shù)據(jù)分區(qū)?表統(tǒng)計(jì)信息：由 ANALYZE 命令收集并存儲(chǔ)在 Hive metastore 中，這些數(shù)據(jù)可以提供給 Presto 的查詢計(jì)劃器，以產(chǎn)生比較好的執(zhí)行計(jì)劃；?Presto 使用基于成本的優(yōu)化器（cost-based optimizer），正如您通常所期望的那樣，它依賴于收集的表統(tǒng)計(jì)信息來實(shí)現(xiàn)最佳功能。
本文，我們將介紹一些 Presto 常用的性能優(yōu)化技巧。
如果想及時(shí)了解Spark、Hadoop或者HBase相關(guān)的文章，歡迎關(guān)注微信公眾號(hào)：過往記憶大數(shù)據(jù)
Presto 性能優(yōu)化技巧
以下建議可以幫助您實(shí)現(xiàn) Presto 集群的最大性能：
?將 Presto 的 coordinator 和 workers 配置在單獨(dú)的實(shí)例/服務(wù)器上，只有在非常小的規(guī)模的開發(fā)/測(cè)試使用時(shí)，才建議讓 coordinator 和 worker 共享同一個(gè)實(shí)例。?始終根據(jù)實(shí)例的可用內(nèi)存資源調(diào)整 Presto 的 java 內(nèi)存配置。每個(gè)節(jié)點(diǎn)上的 etc/jvm.config 配置文件需要在啟動(dòng) Presto 之前配置。一個(gè)有用的經(jīng)驗(yàn)法則是：在每個(gè)節(jié)點(diǎn)的 jvm.config 文件中設(shè)置 -Xmx 為可用物理內(nèi)存的 80%，然后根據(jù)對(duì)工作負(fù)載的監(jiān)視進(jìn)行調(diào)整。?如果使用 HDFS 或 S3 存儲(chǔ)，可以考慮使用 ORC 格式來存儲(chǔ)數(shù)據(jù)。Presto 對(duì)于 ORC 有許多優(yōu)化，比如列式讀取、謂詞下推，以及跳過讀取部分文件。?使用分區(qū)。我們可以在使用 CTAS 時(shí)通過 partitioned_by 參數(shù)來啟用分區(qū)，具體參見 https://prestodb.io/docs/current/sql/create-table-as.html?使用分桶。在創(chuàng)建表時(shí)，使用 bucketed_by 和 bucket_count 來分別指定分桶列以及分桶的個(gè)數(shù)。?如果我們可以選擇 MetaStore ，請(qǐng)為我們的 Presto 集群選擇 Hive 而不是 Glue 。Hive 有一些 Glue 沒有的特性，比如列級(jí)統(tǒng)計(jì)和動(dòng)態(tài)過濾，它們可以提高查詢性能。最終的決定將取決于系統(tǒng)和需求的特定組合。以下是對(duì)兩者區(qū)別的總結(jié)：Presto Performance Tips 如果想及時(shí)了解Spark、Hadoop或者HBase相關(guān)的文章，歡迎關(guān)注微信公眾號(hào)：過往記憶大數(shù)據(jù)?收集表統(tǒng)計(jì)信息以確保生成最有效的查詢計(jì)劃，這意味著查詢會(huì)盡可能快地運(yùn)行。使用 ANALYZE TABLE
CALL system.sync_partition_metadata(‘default’, ‘customer’, ‘full’);?來同步分區(qū)；另外，在后面新增分區(qū)時(shí)可以使用這個(gè)命令來同步分區(qū)。?默認(rèn)情況下，Presto 不會(huì)自動(dòng)進(jìn)行 JOIN 重排（re-ordering）。這只在啟用基于成本的優(yōu)化（CBO）特性時(shí)才會(huì)發(fā)生(見下文)。默認(rèn)情況下，我們需要確保較小的表出現(xiàn)在 JOIN 關(guān)鍵字的右側(cè)。記住: LARGE LEFT (把大表放在 JOIN 的左邊)。如果我們?cè)趫?zhí)行一個(gè) JOIN 查詢，你應(yīng)該嘗試啟用基于成本的優(yōu)化(CBO)特性，設(shè)置?SET session join_distribution_type=’AUTOMATIC’;?和?SET session join_reordering_strategy=’AUTOMATIC’;?當(dāng)有1個(gè)或多個(gè) JOIN 時(shí)，我們應(yīng)該啟用 Dynamic Filtering，特別是當(dāng)有一個(gè)較小的維度表用于探測(cè)一個(gè)較大的事實(shí)表時(shí)。動(dòng)態(tài)過濾被下推到 ORC 和 Parquet readers，可以加速對(duì)分區(qū)表和非分區(qū)表的查詢。動(dòng)態(tài)過濾是一種 JOIN 優(yōu)化，旨在提高 Hash join 的性能。啟用這個(gè)功能需要設(shè)置?SET session enable_dynamic_filtering=TRUE;?如果可行的話，對(duì)原始表進(jìn)行排序，這可以大大提高性能，特別是動(dòng)態(tài)過濾這個(gè)功能。?監(jiān)控 Coordinator 節(jié)點(diǎn)過載的情況。如果 PrestoDB 集群有許多(>50) workers，那么根據(jù)工作負(fù)載和查詢情況，單個(gè) coordinator 節(jié)點(diǎn)可能會(huì)超載。coordinator 節(jié)點(diǎn)有很多職責(zé)，比如解析、分析、計(jì)劃和優(yōu)化查詢、合并來自 Worker 的結(jié)果、任務(wù)跟蹤和資源管理。再加上與集群中其他節(jié)點(diǎn)的所有內(nèi)部通信都是通過 http 進(jìn)行的重量級(jí)負(fù)擔(dān)，我們可以體會(huì)到事情是如何開始大規(guī)模地變慢的。同時(shí)，嘗試通過在更大的云實(shí)例上運(yùn)行來增加 Coordinator 可用的資源，因?yàn)楦嗟?CPU 和內(nèi)存可能會(huì)有所幫助。?為 workers 選擇正確的實(shí)例，以確保它們有足夠的 I/O。為 workers 節(jié)點(diǎn)選擇正確的實(shí)例類型很重要。大多數(shù)分析工作負(fù)載都是 IO 密集型的，因此可用的網(wǎng)絡(luò) IO 數(shù)量可能是一個(gè)限制因素?？傮w吞吐量將決定查詢性能。監(jiān)視 worker 節(jié)點(diǎn)的 IO 活動(dòng)以確定是否存在 IO 瓶頸是一個(gè)好主意。?考慮啟用資源組（Resource Groups）。這是 Presto 的工作負(fù)載管理器，它用于限制資源使用，并可以對(duì)在其中運(yùn)行的查詢執(zhí)行隊(duì)列策略，或者在子組之間劃分資源。查詢屬于單個(gè)資源組，并使用來自該組的資源。一個(gè)資源組表示打包在一起的可用 Presto 資源，以及與 CPU、內(nèi)存、并發(fā)性、隊(duì)列和優(yōu)先級(jí)相關(guān)的限制。除了對(duì)排隊(duì)查詢的限制外，當(dāng)資源組耗盡資源時(shí)，不會(huì)導(dǎo)致正在運(yùn)行的查詢失敗；相反，新的查詢會(huì)排隊(duì)。資源組可以有子組，也可以接受查詢，但不能兩者兼得。更多細(xì)節(jié)請(qǐng)參見文檔：https://prestodb.io/docs/current/admin/resource-groups.html
最后，為了幫助進(jìn)行速度測(cè)試，Presto 內(nèi)置了 TPC-DS 和 TPC-H 數(shù)據(jù)源，以生成不同規(guī)模的基準(zhǔn)測(cè)試所需的數(shù)據(jù)。例如，1TB TPC-H 數(shù)據(jù)集由8張表中大約86.6億條記錄組成。
本文翻譯自：https://ahana.io/learn/presto-performance/