AWS Athena无where条件select *报单行超32MB错，带where正常原因问询

Athena底层基于Presto引擎实现，默认设定单条记录（含所有列序列化后的总大小）最大不能超过32MB，该限制为服务端硬限制，不可自行调整。 #

问题1：不带where条件的查询触发报错、带where条件查询正常的原因 #

你的表中存在至少一条满足col1 is null的记录，该记录的总大小超过32MB：

• 执行select * from tableName时会扫描全表所有行，读到这条超限记录时直接触发大小校验报错
• 执行select * from tableName where col1 is not null时，Parquet列存的谓词下推能力会先过滤掉所有col1 is null的行，这些行的完整字段数据不会被读取、也不会进入大小校验环节，因此查询可以正常返回

问题2：两条查询的后台执行逻辑差异 #

• 谓词下推逻辑差异
  • 无过滤条件的查询：没有谓词下推动作，引擎会读取目标表对应所有Parquet文件的全量列、全量行数据，拼装成完整记录后返回
  • 带col1 is not null过滤的查询：过滤条件会下推到Parquet文件扫描层，引擎首先仅读取所有Parquet文件中col1列的存储块，筛选出符合col1 is not null的行索引，之后仅读取这些行索引对应的其他列数据拼装返回
• 大小校验范围差异
  • 无过滤条件的查询：全表所有行都会被拼装完成并触发32MB大小校验，只要有一行超限就立即终止查询返回报错
  • 带过滤条件的查询：仅通过过滤条件的行才会完成拼装并触发大小校验，被过滤的行不会进入校验环节
• IO读取量差异
  • 无过滤条件的查询：读取数据量等于全表总存储大小
  • 带过滤条件的查询：仅读取过滤列+符合条件行的其他列数据，实际IO量远小于全表扫描

排查建议 #

如果需要定位超限行，直接执行select * from tableName where col1 is null即可复现报错，再通过逐步缩小查询字段范围，即可定位到具体超限的字段。 #

内容的提问来源于stack exchange，提问作者Rahul.bigdata