Presto 0.260 版本发布解读:溢出控制精细化、Fragment 结果缓存增强与优化器新特性全解析
Presto 0.260 版本发布解读溢出控制精细化、Fragment 结果缓存增强与优化器新特性全解析【免费下载链接】prestoThe official home of the Presto distributed SQL query engine for big data项目地址: https://gitcode.com/gh_mirrors/pre/presto本指南基于仓库中的官方发布说明 release-0.260.rst 展开系统梳理 Presto 0.260 在通用引擎、Hive / Iceberg / Prometheus 连接器方面的全部变更并结合当前仓库源码逐项解读新配置的默认值、实现位置与使用注意事项。读完本文你将掌握 0.260 引入的聚合/排序/窗口溢出独立开关、fragment 结果缓存大小控制、聚合内 IF 表达式优化规则等特性的配置方法与底层原理并了解该版本的两个已知风险点及规避方式。版本概览0.260 的核心主题与升级前须知Presto 0.260 是一个以「内存管理精细化」和「结果缓存增强」为核心的版本主要变化集中在三个方面内存与溢出控制将 aggregation / order by / window 三类操作的溢出开关从统一的 spill 开关中独立出来允许按算子粒度显式控制并让 join 溢出在 spill 开启时默认生效Fragment 结果缓存修复了导致查询失败的 bug并新增单文件大小上限配置增强磁盘缓存的可控性新数据类型与连接器新增 UUID 类型新增 Prometheus 连接器Hive 支持为空 bucket 写文件Iceberg 升级依赖版本。升级到该版本前必须关注发布说明中的两条官方警告warning它们都与实际查询稳定性相关度量框架并发问题本版本度量跟踪框架metric tracking framework存在并发问题当启用 Alluxio 缓存时可能导致查询失败聚合 IF 重写规则默认开启optimizer.aggregation-if-to-filter-rewrite-enabled在本版本默认启用当IF分支对不满足IF条件的行仍会抛异常时可能引发查询失败例如SUM(IF(CARDINALITY(array) 0, array[1]))——因为即使CARDINALITY(array) 0array[1]仍可能被求值。对于正在使用 Alluxio 缓存或依赖上述 IF 语义的用户升级前应做好针对性回归测试必要时显式关闭对应开关配置方法见下文。通用引擎变更General Changes详解1. 修复 SQL 函数编译器错误inline_sql_function 与 lambda 引用发布说明修复了一个 SQL 函数SQL function编译错误当会话属性inline_sql_function设为false且 SQL 函数内部引用了 lambda 表达式中的输入参数时会触发编译器报错。从当前源码看该属性对应SystemSessionProperties.INLINE_SQL_FUNCTIONS见 SystemSessionProperties.java其功能由迭代式规划器规则InlineSqlFunctions实现见 InlineSqlFunctions.java并由 PlanOptimizers.java 挂载到优化管线中。该修复保证了 SQL 函数未被内联按名称调用时lambda 表达式内的输入引用依然能正确解析编译。2. Fragment 结果缓存bug 修复与文件大小上限控制本版本修复了 fragment 结果缓存fragment result cache导致查询失败的问题并新增配置项配置属性fragment-result-cache.max-single-pages-size用途控制单个 fragment 缓存文件的写入大小上限Maximum size of pages write to flushed该配置的实现位于 FileFragmentResultCacheConfig.java默认值为500MB源码第 40 行maxSinglePagesSize new DataSize(500, MEGABYTE)。以下是该配置类的完整参数族可帮助你从全局理解 fragment 结果缓存配置属性默认值说明fragment-result-cache.enabledfalse是否启用 fragment 结果缓存fragment-result-cache.base-directory无缓存数据的 base URIfragment-result-cache.block-encoding-compression-codecNONE块编码压缩算法fragment-result-cache.max-cached-entries10000缓存允许的最大条目数fragment-result-cache.cache-ttl2d缓存条目存活时间fragment-result-cache.max-in-flight-size1GB内存中等待刷盘的 page 最大体积fragment-result-cache.max-single-pages-size500MB单次刷盘写入的最大 page 体积0.260 新增fragment-result-cache.max-cache-size100GB磁盘缓存最大体积fragment-result-cache.input-data-stats-enabledfalse是否跟踪 fragment 缓存输入数据大小生产实践中若查询涉及超大中间结果集可结合max-cache-size与max-single-pages-size一起调整前者约束整体磁盘占用后者约束单次刷盘的写入粒度避免大 page 刷盘造成 IO 抖动。对应的配置测试可参考 TestFileFragmentResultCacheConfig.java。3. 新增 UUID 数据类型0.260 引入了uuid类型用于表示 UUID 值相关函数文档见 uuid 函数文档。该类型可配合uuid()函数生成随机 UUID适用于主键生成、去重标识等场景。4. 三类溢出Spill的显式独立控制0.260 之前spill 行为主要由总开关experimental.spill-enabled源码常量见 FeaturesConfig.java统一控制。本版本为三类易发生溢出的算子增加了独立开关算子类型配置属性会话属性聚合experimental.aggregation-spill-enabledaggregation_spill_enabled排序experimental.order-by-spill-enabledorder_by_spill_enabled窗口experimental.window-spill-enabledwindow_spill_enabled引入这些独立开关的意义在于不同算子对溢出的敏感性不同。例如聚合算子通常可通过 hash 分区天然降低内存占用而全局排序order by和窗口函数如row_number()全量排序更可能在数据倾斜或大结果集下撑爆内存。运维人员现在可以只对特定算子开启 spill避免所有算子都落盘带来的额外 IO 开销。典型配置示例写入 coordinator 的config.properties# 全局开启 spill experimental.spill-enabledtrue # 仅显式控制聚合与排序溢出 experimental.aggregation-spill-enabledtrue experimental.order-by-spill-enabledtrue # 窗口溢出保持关闭 experimental.window-spill-enabledfalse也可以在会话级别动态调整例如SET SESSION aggregation_spill_enabled true; SET SESSION order_by_spill_enabled false;5. 新增会话属性 query_max_revocable_memory_per_node新增会话属性query_max_revocable_memory_per_node用于在会话粒度覆盖已有配置属性experimental.max-revocable-memory-per-node。该属性控制单节点上查询可回收revocable即允许被 spill 释放的内存上限适合对特定大查询做精细化内存管控——例如全局配置保持默认仅对某类重型查询临时放宽或收紧可回收内存预算SET SESSION query_max_revocable_memory_per_node 8GB;6. 聚合内 IF 表达式优化规则aggregation-if-to-filter-rewrite0.260 新增配置属性optimizer.aggregation-if-to-filter-rewrite-enabled与会话属性aggregation_if_to_filter_rewrite_enabled用于切换一条优化器规则该规则将聚合函数内部的IF表达式重写为 filter 形式从而提升性能。从当前仓库源码看该特性后续演进为更通用的策略枚举配置optimizer.aggregation-if-to-filter-rewrite-strategy取值定义于AggregationIfToFilterRewriteStrategy枚举见 FeaturesConfig.java默认策略为DISABLED第 265 行读写方法见第 2670–2677 行。需要特别强调的是0.260 中该开关默认启用且发布说明明确警告当IF分支对不满足IF条件的行仍会抛出异常时重写可能导致查询失败例如SUM(IF(CARDINALITY(array) 0, array[1]))。原因是重写后不满足条件的行可能不再被短路保护array[1]在数组为空时仍会被求值而抛错。如果你在 0.260 上遇到此类聚合查询异常可显式关闭optimizer.aggregation-if-to-filter-rewrite-enabledfalse或SET SESSION aggregation_if_to_filter_rewrite_enabled false;7. Join 溢出默认启用当 spill 开启experimental.spill-enabledtrue时join 溢出join spilling在本版本起默认启用。若希望关闭可将配置属性experimental.join-spill-enabled或会话属性join_spill_enabled设为false。该开关常量定义于 FeaturesConfig.javaJOIN_SPILL_ENABLED experimental.join-spill-enabled。这意味着启用全局 spill 后大表 join 在内存不足时会自动落盘无需额外配置。Hive 连接器变更为空桶创建文件0.260 为 Hive 连接器新增了「写数据时为空 bucket 创建文件」的支持可通过配置属性hive.create-empty-bucket-files或会话属性create_empty_bucket_files控制。从当前源码看该开关位于 HiveClientConfig.javaConfig(hive.create-empty-bucket-files)默认值为true源码第 98 行private boolean createEmptyBucketFiles true;。此外同文件第 1260 行还提供了针对临时表的独立配置hive.create-empty-bucket-files-for-temporary-table。该特性的实用价值在按 bucket 分桶写入时如果某个 bucket 没有数据默认行为会为它创建空文件。这对于下游依赖固定分桶文件布局的读取方例如要求每个 bucket 都有对应文件的 ETL 任务或需要保持 partition 内文件数稳定的场景至关重要。如果希望跳过空 bucket 文件以节省小文件开销可显式关闭hive.create-empty-bucket-filesfalseIceberg 连接器变更依赖版本升级0.260 将 Iceberg 依赖版本升级到 0.11.1以获得该版本中包含的 Iceberg 上游修复与能力增强。需要说明的是发布说明描述的是历史版本状态当前仓库中 Iceberg 版本定义于根 pom.xml 的dep.iceberg.version属性已演进至更高版本1.10.1Iceberg 连接器的依赖声明见 presto-iceberg/pom.xml。升级依赖通常涉及元数据读写、快照管理、文件格式兼容性等多方面行为变化建议在升级前阅读连接器测试套件如 presto-iceberg 下的 TestIcebergSmoke / TestIcebergHadoopCatalog 等测试以确认与自有环境的兼容性。Prometheus 连接器新增支持0.260 新增了 Prometheus 连接器用于将 Prometheus 作为数据源接入 Presto 进行查询。该连接器的完整使用文档位于 prometheus.rst连接器实现代码位于 presto-prometheus 模块。通过该连接器可以在 Presto 中直接对 Prometheus 指标数据执行 SQL 查询例如按时间范围聚合指标、跨指标做关联分析为监控数据与业务数据的统一分析提供了通道。版本贡献者本版本由以下贡献者共同完成按发布说明 Credits 列出Andrii Rosa, Ariel Weisberg, Arjun Gupta, Arunachalam Thirupathi, Basar Hamdi Onat, Beinan Wang, Bin Fan, George Wang, Jack Ye, James Sun, Julian Zhuoran Zhao, Maria Basmanova, Mayank Garg, Rebecca Schlussel, Rongrong Zhong, Shixuan Fan, Timothy Meehan, Zac Wen, Zhan Yuan, Zhenxiao Luo, gxinfb.com, linzebing, shenh062326, superqtqt, v-jizhang, vaishnavibatni。升级与验证建议综合 0.260 的变更给出如下升级建议回归重点一缓存链路若集群启用了 Alluxio 缓存请优先回归查询稳定性关注发布说明第一条警告描述的度量框架并发问题回归重点二聚合 IF 重写重点回归包含SUM(IF(...))、COUNT(IF(...))等聚合内 IF 表达式的查询确认optimizer.aggregation-if-to-filter-rewrite-enabled默认开启未引入异常如遇失败按上文方法关闭该开关验证新配置通过SHOW SESSION确认aggregation_spill_enabled、order_by_spill_enabled、window_spill_enabled、join_spill_enabled、query_max_revocable_memory_per_node等会话属性是否生效Hive 写入验证对分桶表执行一次写入确认空桶文件行为符合预期默认创建空文件新连接器试用如需接入监控数据可按 prometheus.rst 配置 Prometheus 连接器并做连通性测试。总体而言Presto 0.260 通过算子级 spill 开关、可回收内存会话覆盖和 fragment 缓存文件大小控制把查询内存治理的粒度推进到了更精细的层面同时以两个已知警告为代价换来了聚合 IF 重写与 join 默认溢出的性能收益。在升级前吃透这两条警告的语义是平稳过渡到该版本的关键。【免费下载链接】prestoThe official home of the Presto distributed SQL query engine for big data项目地址: https://gitcode.com/gh_mirrors/pre/presto创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考