PySpark3.3+Delta Lake存储Parquet嵌套数据类型的技术咨询

1. 嵌套信息会存储为单个列，还是拆分为info.topic_1、info.digit_1等列？ #

Parquet（Delta Lake的底层存储格式）会严格保留DataFrame的嵌套结构，info会作为单个Struct类型列存储，不会自动拆分为扁平化的独立列。物理存储时，子字段topic_1、digit_1等是作为info列的一部分打包序列化的；读取时可以通过info.topic_1的语法直接访问子字段，Spark会按需解析对应的数据，无需额外处理。

2. 数组列或映射列的存储情况如何？ #

数组（ArrayType）和映射（MapType）同样以嵌套类型的形式存储，不会扁平化：

• 数组列：整个数组作为单个列的内容存储，内部元素会被序列化为Parquet的数组结构，支持高效的随机访问操作
• 映射列：以键值对的嵌套结构存储，Parquet会分别序列化键集合和值集合，同时保持键值的关联关系，读取时可直接还原为Spark的Map类型

3. 早期Stack Overflow帖子提及嵌套列会导致读取更多列，Spark 3中该问题是否仍存在？ #

Spark 3.x已针对嵌套列的读取做了核心优化，解决了Spark 2.x中“读取嵌套列时必须加载整个父列所有子字段”的性能问题。现在Spark支持嵌套列的部分读取：如果仅查询info.topic_1，Parquet只会读取info列中对应topic_1的部分数据，不会加载整个info列的所有子字段，读取性能与普通顶级列基本一致。

4. 存储此类嵌套数据类型有哪些最佳实践？ #

• 控制嵌套深度：避免超过3层的深度嵌套，过深的层级会增加Schema解析复杂度，降低查询效率
• 拆分超大嵌套结构：如果嵌套列的子字段数量过多（如数百个），可评估拆分多个独立Struct列，或提取高频访问的子字段作为顶级列，减少单个嵌套列的复杂度
• 结合分区/分桶优化：若嵌套列中有高频过滤的字段，可将其提取为顶级列作为分区键，或对核心子字段进行分桶，提升查询过滤的性能
• 明确Nullable属性：合理设置嵌套列及子字段的nullable属性，Parquet会根据该属性优化空值的存储空间占用
• 避免不必要的扁平化：Spark 3.x嵌套读取性能已足够优秀，若查询经常访问多个子字段，保留嵌套结构更利于数据语义的维护，无需提前扁平化
• 提前做性能测试：针对大规模嵌套数据，先进行小批量读写测试，验证Schema设计是否匹配业务查询需求

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