尧图网站建设 
Presto Release 0.130 技术解读性能回归修复、map_concat 新函数与列式字典优化【免费下载链接】prestoThe official home of the Presto distributed SQL query engine for big data项目地址: https://gitcode.com/gh_mirrors/pre/prestoPresto 0.130 是一个以性能与查询优化为核心的小版本该版本修复了GROUP BY/JOIN在特定键长下的性能回归新增了map_concat标量函数引入了默认关闭的列式字典处理优化开关并针对大分组聚合、ARRAY类型查询以及 MySQL/PostgreSQL 连接器的远程视图查询进行了改进。本文以官方发布说明 release-0.130.rst 为骨架逐条解读变更内容并结合仓库源码如 MapConcatFunction.java剖析底层实现原理帮助读者理解这些优化何时生效、如何开启以及如何验证。一、版本概览一次聚焦查询引擎内功的迭代Release 0.130 的变更共 6 项全部集中在查询执行引擎与连接器层面不涉及 SQL 语法或接口破坏性变更类别变更内容性能修复修复GROUP BY/JOIN查询在 key 长度为 1631 字节时的性能回归新函数新增map_concat函数性能优化filters、projections 与字典编码数据的性能改进默认关闭可配置性能优化改善分组数groups规模较大时聚合查询的性能性能优化改善使用ARRAY类型查询的性能连接器修复修复 MySQL、PostgreSQL 连接器中查询远程视图remote views的问题以下逐条展开。二、修复 GROUP BY / JOIN 在键长 1631 字节下的性能回归Fix a performance regression inGROUP BYandJOINqueries when the length of the keys is between 16 and 31 bytes.这是 0.130 中一处典型的哈希路径回归修复。在 Presto 的哈希聚合hash aggregation与哈希连接hash join实现中分组键或连接键需要先计算哈希值再通过哈希表进行查找与探测。当键的序列化长度处于 1631 字节区间时恰好跨越了若干内部缓冲区/对齐边界容易落入未优化的快速路径之外从而产生比预期更慢的哈希计算与内存拷贝开销。从工程角度这类修复通常涉及以下层面键哈希计算的快速路径对长度小于 16 字节的键直接以内联标量方式参与哈希而超过 31 字节的键走通用大对象路径1631 字节区间此前可能退化为通用路径。分组键的内存布局GROUP BY使用 channel 化的组键布局group-by channel键的内存布局与对齐方式直接影响哈希表的插入/探测效率。对本条修复官方未公开具体算法细节读者可以将键长 1631 字节作为复现与回归测试的关注区间如果你的查询GROUP BY或JOIN的键是 24 字节左右的定长组合列0.130 之后应能观察到该场景下的执行时间回落。三、新函数 map_concat把多个 MAP 合并为一个Addmap_concatfunction.这是 0.130 中最具新增能力色彩的变更。map_concat将多个 MAP 合并为一个 MAP其函数签名与语义在官方函数文档 map.rst 中有明确定义map_concat(map1(K,V), map2(K,V), ..., mapN(K,V)) - map(K,V)语义要点返回所有给定 MAP 的并集union如果同一个 key 出现在多个 MAP 中结果中的值取自最后一个包含该 key 的 MAP函数是确定性的deterministic即相同输入永远产生相同输出至少需要 2 个参数。3.1 源码实现剖析map_concat的实现位于 MapConcatFunction.java它是一个通过类型变量K、V泛型化的SqlScalarFunction签名设计第 6875 行签名声明为map(K,V)-map(K,V)并采用变长参数var-args适配任意数量的 MAP 入参。参数个数校验第 111113 行当 arity 小于 2 时直接抛出INVALID_FUNCTION_ARGUMENT错误错误信息为 There must be two or more concatenation arguments to map_concat。核心合并逻辑mapConcat第 134181 行先扫描所有 MAP统计总条目数并定位首个与末个非空 MAP第 139145 行如果只有一个非空 MAP直接返回它自身避免无谓拷贝第 146148 行利用OptimizedTypedSet优化类型化集合对 key 做去重合并并从最后一个 MAP 向第一个 MAP 倒序 union第 155159 行——这正是重复 key 取最后一个 MAP 的值语义的底层来源依据 union 得到的SelectedPositions将每个 MAP 的 key/value 追加写入BlockBuilder最终构建出合并后的 MAP Block第 161180 行。空值语义所有参数采用RETURN_NULL_ON_NULL约定第 129 行即任一入参为 NULL 时函数整体返回 NULL。注意注释中的一条关键细节第 153 行SingleMapBlock的 position count 是普通 Block 的两倍key、value 成对排列因此计算OptimizedTypedSet容量时需要除以 2。3.2 使用示例-- 基本用法合并两个 MAP SELECT map_concat( MAP(ARRAY[1, 2], ARRAY[a, b]), MAP(ARRAY[2, 3], ARRAY[x, y]) ); -- 结果: {1 - a, 2 - x, 3 - y} key2 取最后一个 MAP 的值 x -- 三个及以上 MAP SELECT map_concat(m1, m2, m3); -- 与其它 MAP 函数组合使用如 map_keys SELECT map_keys(map_concat(m1, m2));四、列式字典处理优化optimizer.columnar-processing-dictionaryPerformance improvements for filters, projections and dictionary encoded data. This optimization is turned off by default. It can be configured with theoptimizer.columnar-processing-dictionaryconfig property or thecolumnar_processing_dictionarysession property.本条是 0.130 中唯一引入新配置项的优化值得重点说明优化内容对 filter过滤、projection投影以及字典编码数据dictionary encoded data即大量重复值使用字典/游标编码的列数据的处理路径进行性能改进。这类数据在真实数据仓库中极为常见如低基数的维度列、枚举值列因此该优化对实际负载有较大价值。默认关闭与 Presto 一贯先默认关闭、验证稳定性后再开启的策略一致该优化默认不生效避免对既有查询计划产生意外影响。开启方式两种等价途径——集群级配置在节点配置文件etc/config.properties参见 docker 示例 与 presto-main 配置中加入optimizer.columnar-processing-dictionarytrue会话级开启仅对当前查询会话生效SET SESSION columnar_processing_dictionary true;配置属性名与会话属性名采用不同的命名风格前者点号分隔、后者下划线分隔这是 Presto 配置系统的一贯约定config.properties使用-连字符会话属性使用_下划线。需要说明的是该开关属于早期列式处理能力的一部分后续版本中列式执行相关的配置与默认策略可能继续演进读者在升级到更新版本时应以目标版本的官方配置文档为准。五、改善大分组数聚合查询的性能Improve performance of aggregation queries with large numbers of groups.该条针对的是聚合结果分组数cardinality of group-by keys很大的场景——例如对高基数字段做GROUP BY、或者分组键组合后产生海量组。此类查询的性能瓶颈通常集中在聚合哈希表随分组数增长时的扩容与再哈希成本大量GroupedAccumulator状态的内存分配与访问局部性分组键哈希计算的重复开销。0.130 从上述路径入手削减了大分组数聚合的开销。对于生产实践这通常意味着高基数GROUP BY类查询在 0.130 后更值得开启并观察执行计划若仍受限于分组规模可结合optimizer.optimize_hash_generation等既有优化配置综合调优。六、改善 ARRAY 类型查询的性能Improve performance for queries that useARRAYtype.与ARRAY类型相关的查询如UNNEST展开、ARRAY列的 filter/projection、cardinality/element_at等数组函数在此版本中获得性能提升。从实现层面看ARRAY类型在 Presto 中以Block存储其遍历、切片与函数调用的开销集中在 Block 访问路径上该优化即针对这些热点路径。用户可以关注在 0.130 上运行大量数组操作的 ETL/分析作业的执行时间变化通常无需任何配置变更即可受益。七、修复 MySQL / PostgreSQL 连接器查询远程视图的问题Fix querying remote views in MySQL and PostgreSQL connectors.该条修复了通过 presto-mysql 与 presto-postgresql 连接器访问远程数据库**视图view**时的问题。连接器基于 presto-base-jdbc 提供的通用 JDBC 框架实现元数据读取、列映射与 SQL 下推均经由该框架完成。远程视图查询问题的典型成因包括视图元数据列名、类型读取不完整、视图名/模式名解析异常或 SQL 下推时对视图的限定名生成错误。修复后SELECT * FROM mysql_schema.some_view这类直接查询远程视图的语句应与查询普通表行为一致。若你依赖 MySQL/PostgreSQL 中的视图作为分析数据源升级到 0.130 后建议回归验证视图查询路径。八、小结与验证建议Release 0.130 虽是小版本但变更集中在查询执行的核心路径性能类GROUP BY/JOIN键长 1631 字节回归修复、大分组聚合优化、ARRAY查询优化均为透明生效无需配置新能力map_concat新函数可直接使用源码见 MapConcatFunction.java语义文档见 map.rst可配置优化列式字典处理optimizer.columnar-processing-dictionary默认关闭需按需开启连接器修复MySQL/PostgreSQL 远程视图查询已修复。验证该版本效果时建议针对性地构造基准查询例如使用 20 字节左右定长分组键的GROUP BY、高基数分组聚合、大量ARRAY操作的查询在 0.130 上对比执行耗时与内存占用map_concat可结合map_keys、map_values等函数做单元级验证。整体而言0.130 属于稳内功型版本适合作为升级目标在测试环境先行回归后进入生产。【免费下载链接】prestoThe official home of the Presto distributed SQL query engine for big data项目地址: https://gitcode.com/gh_mirrors/pre/presto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Presto Release 0.130 技术解读：性能回归修复、map_concat 新函数与列式字典优化
Presto Release 0.130 技术解读性能回归修复、map_concat 新函数与列式字典优化【免费下载链接】prestoThe official home of the Presto distributed SQL query engine for big data项目地址: https://gitcode.com/gh_mirrors/pre/prestoPresto 0.130 是一个以性能与查询优化为核心的小版本该版本修复了GROUP BY/JOIN在特定键长下的性能回归新增了map_concat标量函数引入了默认关闭的列式字典处理优化开关并针对大分组聚合、ARRAY类型查询以及 MySQL/PostgreSQL 连接器的远程视图查询进行了改进。本文以官方发布说明 release-0.130.rst 为骨架逐条解读变更内容并结合仓库源码如 MapConcatFunction.java剖析底层实现原理帮助读者理解这些优化何时生效、如何开启以及如何验证。一、版本概览一次聚焦查询引擎内功的迭代Release 0.130 的变更共 6 项全部集中在查询执行引擎与连接器层面不涉及 SQL 语法或接口破坏性变更类别变更内容性能修复修复GROUP BY/JOIN查询在 key 长度为 1631 字节时的性能回归新函数新增map_concat函数性能优化filters、projections 与字典编码数据的性能改进默认关闭可配置性能优化改善分组数groups规模较大时聚合查询的性能性能优化改善使用ARRAY类型查询的性能连接器修复修复 MySQL、PostgreSQL 连接器中查询远程视图remote views的问题以下逐条展开。二、修复 GROUP BY / JOIN 在键长 1631 字节下的性能回归Fix a performance regression inGROUP BYandJOINqueries when the length of the keys is between 16 and 31 bytes.这是 0.130 中一处典型的哈希路径回归修复。在 Presto 的哈希聚合hash aggregation与哈希连接hash join实现中分组键或连接键需要先计算哈希值再通过哈希表进行查找与探测。当键的序列化长度处于 1631 字节区间时恰好跨越了若干内部缓冲区/对齐边界容易落入未优化的快速路径之外从而产生比预期更慢的哈希计算与内存拷贝开销。从工程角度这类修复通常涉及以下层面键哈希计算的快速路径对长度小于 16 字节的键直接以内联标量方式参与哈希而超过 31 字节的键走通用大对象路径1631 字节区间此前可能退化为通用路径。分组键的内存布局GROUP BY使用 channel 化的组键布局group-by channel键的内存布局与对齐方式直接影响哈希表的插入/探测效率。对本条修复官方未公开具体算法细节读者可以将键长 1631 字节作为复现与回归测试的关注区间如果你的查询GROUP BY或JOIN的键是 24 字节左右的定长组合列0.130 之后应能观察到该场景下的执行时间回落。三、新函数 map_concat把多个 MAP 合并为一个Addmap_concatfunction.这是 0.130 中最具新增能力色彩的变更。map_concat将多个 MAP 合并为一个 MAP其函数签名与语义在官方函数文档 map.rst 中有明确定义map_concat(map1(K,V), map2(K,V), ..., mapN(K,V)) - map(K,V)语义要点返回所有给定 MAP 的并集union如果同一个 key 出现在多个 MAP 中结果中的值取自最后一个包含该 key 的 MAP函数是确定性的deterministic即相同输入永远产生相同输出至少需要 2 个参数。3.1 源码实现剖析map_concat的实现位于 MapConcatFunction.java它是一个通过类型变量K、V泛型化的SqlScalarFunction签名设计第 6875 行签名声明为map(K,V)-map(K,V)并采用变长参数var-args适配任意数量的 MAP 入参。参数个数校验第 111113 行当 arity 小于 2 时直接抛出INVALID_FUNCTION_ARGUMENT错误错误信息为 There must be two or more concatenation arguments to map_concat。核心合并逻辑mapConcat第 134181 行先扫描所有 MAP统计总条目数并定位首个与末个非空 MAP第 139145 行如果只有一个非空 MAP直接返回它自身避免无谓拷贝第 146148 行利用OptimizedTypedSet优化类型化集合对 key 做去重合并并从最后一个 MAP 向第一个 MAP 倒序 union第 155159 行——这正是重复 key 取最后一个 MAP 的值语义的底层来源依据 union 得到的SelectedPositions将每个 MAP 的 key/value 追加写入BlockBuilder最终构建出合并后的 MAP Block第 161180 行。空值语义所有参数采用RETURN_NULL_ON_NULL约定第 129 行即任一入参为 NULL 时函数整体返回 NULL。注意注释中的一条关键细节第 153 行SingleMapBlock的 position count 是普通 Block 的两倍key、value 成对排列因此计算OptimizedTypedSet容量时需要除以 2。3.2 使用示例-- 基本用法合并两个 MAP SELECT map_concat( MAP(ARRAY[1, 2], ARRAY[a, b]), MAP(ARRAY[2, 3], ARRAY[x, y]) ); -- 结果: {1 - a, 2 - x, 3 - y} key2 取最后一个 MAP 的值 x -- 三个及以上 MAP SELECT map_concat(m1, m2, m3); -- 与其它 MAP 函数组合使用如 map_keys SELECT map_keys(map_concat(m1, m2));四、列式字典处理优化optimizer.columnar-processing-dictionaryPerformance improvements for filters, projections and dictionary encoded data. This optimization is turned off by default. It can be configured with theoptimizer.columnar-processing-dictionaryconfig property or thecolumnar_processing_dictionarysession property.本条是 0.130 中唯一引入新配置项的优化值得重点说明优化内容对 filter过滤、projection投影以及字典编码数据dictionary encoded data即大量重复值使用字典/游标编码的列数据的处理路径进行性能改进。这类数据在真实数据仓库中极为常见如低基数的维度列、枚举值列因此该优化对实际负载有较大价值。默认关闭与 Presto 一贯先默认关闭、验证稳定性后再开启的策略一致该优化默认不生效避免对既有查询计划产生意外影响。开启方式两种等价途径——集群级配置在节点配置文件etc/config.properties参见 docker 示例 与 presto-main 配置中加入optimizer.columnar-processing-dictionarytrue会话级开启仅对当前查询会话生效SET SESSION columnar_processing_dictionary true;配置属性名与会话属性名采用不同的命名风格前者点号分隔、后者下划线分隔这是 Presto 配置系统的一贯约定config.properties使用-连字符会话属性使用_下划线。需要说明的是该开关属于早期列式处理能力的一部分后续版本中列式执行相关的配置与默认策略可能继续演进读者在升级到更新版本时应以目标版本的官方配置文档为准。五、改善大分组数聚合查询的性能Improve performance of aggregation queries with large numbers of groups.该条针对的是聚合结果分组数cardinality of group-by keys很大的场景——例如对高基数字段做GROUP BY、或者分组键组合后产生海量组。此类查询的性能瓶颈通常集中在聚合哈希表随分组数增长时的扩容与再哈希成本大量GroupedAccumulator状态的内存分配与访问局部性分组键哈希计算的重复开销。0.130 从上述路径入手削减了大分组数聚合的开销。对于生产实践这通常意味着高基数GROUP BY类查询在 0.130 后更值得开启并观察执行计划若仍受限于分组规模可结合optimizer.optimize_hash_generation等既有优化配置综合调优。六、改善 ARRAY 类型查询的性能Improve performance for queries that useARRAYtype.与ARRAY类型相关的查询如UNNEST展开、ARRAY列的 filter/projection、cardinality/element_at等数组函数在此版本中获得性能提升。从实现层面看ARRAY类型在 Presto 中以Block存储其遍历、切片与函数调用的开销集中在 Block 访问路径上该优化即针对这些热点路径。用户可以关注在 0.130 上运行大量数组操作的 ETL/分析作业的执行时间变化通常无需任何配置变更即可受益。七、修复 MySQL / PostgreSQL 连接器查询远程视图的问题Fix querying remote views in MySQL and PostgreSQL connectors.该条修复了通过 presto-mysql 与 presto-postgresql 连接器访问远程数据库**视图view**时的问题。连接器基于 presto-base-jdbc 提供的通用 JDBC 框架实现元数据读取、列映射与 SQL 下推均经由该框架完成。远程视图查询问题的典型成因包括视图元数据列名、类型读取不完整、视图名/模式名解析异常或 SQL 下推时对视图的限定名生成错误。修复后SELECT * FROM mysql_schema.some_view这类直接查询远程视图的语句应与查询普通表行为一致。若你依赖 MySQL/PostgreSQL 中的视图作为分析数据源升级到 0.130 后建议回归验证视图查询路径。八、小结与验证建议Release 0.130 虽是小版本但变更集中在查询执行的核心路径性能类GROUP BY/JOIN键长 1631 字节回归修复、大分组聚合优化、ARRAY查询优化均为透明生效无需配置新能力map_concat新函数可直接使用源码见 MapConcatFunction.java语义文档见 map.rst可配置优化列式字典处理optimizer.columnar-processing-dictionary默认关闭需按需开启连接器修复MySQL/PostgreSQL 远程视图查询已修复。验证该版本效果时建议针对性地构造基准查询例如使用 20 字节左右定长分组键的GROUP BY、高基数分组聚合、大量ARRAY操作的查询在 0.130 上对比执行耗时与内存占用map_concat可结合map_keys、map_values等函数做单元级验证。整体而言0.130 属于稳内功型版本适合作为升级目标在测试环境先行回归后进入生产。【免费下载链接】prestoThe official home of the Presto distributed SQL query engine for big data项目地址: https://gitcode.com/gh_mirrors/pre/presto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考