Parquet嵌套数据类型的优势及性能收益相关技术问询

这个问题问得非常到位——很多人在使用Parquet配合Athena这类查询工具时，都会纠结嵌套类型到底有没有存在的必要，毕竟扁平化看起来更“直观”。咱们一步步拆解清楚：

一、嵌套类型的核心优势 #

首先，嵌套类型（比如struct、array<struct>）最核心的价值是贴合真实的数据模型：

• 避免冗余列名：比如用户的地址信息，用struct<province: string, city: string, district: string>比拆成user_province、user_city、user_district要简洁得多，不会出现大量重复的前缀，schema可读性拉满。
• 保证数据关联性：嵌套结构天然把相关字段绑定在一起，比如地址的省市区永远是一个整体，不会出现某一行有province值但city为空的逻辑错误（只要schema定义合理），而扁平化列很容易出现这类数据不一致的问题。
• 适配复杂业务场景：对于天然存在层级或重复的数据（比如订单里的多个商品、文章里的多条评论），用array<struct>比拆成item_1_id、item_2_id这种“伪数组”要合理得多，不会出现列数无限膨胀的schema爆炸问题。

二、嵌套类型真的能带来性能收益吗？ #

答案是肯定的，甚至在某些场景下优于扁平化，这得益于Parquet的列存储编码逻辑：

• 精准IO读取：Parquet对嵌套类型的存储是按字段层级拆分编码的，比如customer: struct(name, email)会被拆成customer.name和customer.email两个独立的列存储块。当你查询SELECT customer.name FROM table时，Parquet只会读取customer.name对应的存储块，和扁平化的customer_name列性能完全一致，不会因为是嵌套结构而额外读取冗余数据。
• 减少元数据开销：相比扁平化的多列，嵌套类型能大幅减少schema的元数据量。比如10个扁平化列对应10份元数据，而一个包含10个字段的struct只需要一份顶层元数据，这在分区数量多、表规模大的场景下，能显著降低查询引擎加载元数据的开销。
• 关联字段的批量读取：如果你的查询需要同时访问嵌套结构里的多个字段（比如同时取customer.name和customer.email），Parquet会把这些关联字段的存储块放在相邻位置，减少磁盘寻道次数，反而比读取多个分散的扁平化列效率更高。

三、对比扁平化schema的额外收益（针对Athena等查询场景） #

你提到的扁平化确实能带来便捷性，但嵌套类型在以下场景下的收益是扁平化无法替代的：

• 扩展性更强：如果需要给嵌套结构新增字段（比如给地址加zip_code），只需要修改struct的schema即可，下游应用和查询语句不需要大规模调整；而扁平化的话要新增user_zip_code列，可能需要修改大量ETL脚本和查询语句。
• 统计信息同样可用：Parquet对嵌套类型的每个子字段都能存储统计信息（比如min/max、null值数量），Athena这类查询引擎完全可以利用这些统计信息做查询优化（比如跳过不相关的分区），并不是只有扁平化列才有统计信息。
• 简化复杂查询：对于包含重复数据的场景（比如订单的多个商品），用array<struct>配合UNNEST函数查询，比处理一堆item_N_*列要简洁得多。比如：

  -- 嵌套类型的查询
  SELECT order_id, item.id, item.name 
  FROM orders, UNNEST(items) AS t(item)
  

  对比扁平化的查询要写一堆UNION ALL或者处理空值，代码复杂度天差地别。

总结 #

嵌套类型不是“反直觉”的设计，而是Parquet为复杂数据模型量身打造的特性：如果你的数据天然存在层级或关联关系，需要保证数据一致性、扩展性，嵌套类型会是更好的选择；如果是简单的扁平数据，扁平化可能更直观。但无论哪种场景，Parquet的嵌套类型都不会带来性能损失，反而在很多场景下能提升效率和可维护性。

内容的提问来源于stack exchange，提问作者user976850