压缩JSON文件：直接用PySpark处理还是先解压？

我有多年软件工程经验，但刚接触大数据领域。目前需处理几TB的gzip压缩JSON文件，从中提取数据子集并存为S3上的Parquet文件用于后续分析。文件大小从几MB到几十GB不等，生产环境计划用AWS Glue的PySpark做ETL，探索阶段在Google Colab测试。

最初测试代码如下：

df_test = spark.read.option("multiline", "true").json('/content/sample_data/test_files/*')
df_test.printSchema()
df_test = df_test.select(explode("in_scope").alias("in_scope"))
df_test.count()

但发现16MB的压缩文件竟占用近10GB内存，针对以下三个问题解答：

1. 小文件导致高内存占用的原因 #

• multiline=true的强制加载：开启这个选项后，Spark会将整个文件视为单一JSON对象，一次性加载到单个Executor的内存中。你的JSON里包含大数组in_scope，解压后整个数组会被完整读入内存，内存占用会比原压缩文件大很多倍（JSON是文本格式，解压后体积膨胀，加上Spark对嵌套结构的内存存储开销）。
• gzip的不可拆分性：gzip是单块压缩格式，Spark无法并行读取，只能由一个Executor处理整个文件，所有数据集中在一个节点，进一步推高内存占用。
• 嵌套JSON的解析开销：Spark解析嵌套JSON时，会生成复杂的Schema对象，加上大数组的存在，内存中会存储大量的中间结构，进一步放大内存消耗。

2. 用普通Python/Linux脚本解压后再处理是否更高效？ #

不会，反而可能降低效率并增加复杂度：

• 手动解压并没有解决核心问题：解压后的文件仍是单一大JSON，Spark读取时还是会因为multiline=true一次性加载整个文件，内存占用问题依旧存在。
• 额外开销：手动解压会增加磁盘IO、存储占用（几十GB的文件解压后体积会暴涨），在Colab这种资源有限的环境中很容易出现磁盘不足的问题；生产环境（Glue）中，手动解压还会增加额外的任务步骤，浪费计算资源。
• Spark原生支持gzip读取：Spark可以直接读取gzip压缩文件，无需手动解压，手动处理完全是多此一举。

3. 转成JSONL后再用PySpark处理是否效率更高？ #

是的，这是解决当前问题的最优方案之一：

• 降低内存压力：JSONL是每行一个独立JSON对象，读取时无需开启multiline=true，Spark可以按行解析数据，将文件拆分到多个分区并行处理，不会把整个大JSON加载到单个Executor内存中。
• 提前拆分大数组：将in_scope数组中的对象单独写入JSONL后，Spark读取时直接得到单条记录，无需再执行explode操作，减少了内存中处理大数组的开销。
• 解析效率更高：JSONL的结构更适合Spark的批量解析，解析速度比multiline JSON更快，且Schema推断更准确。
• 生产环境适配：在AWS Glue中，你可以直接处理S3上的JSONL文件（即使是gzip压缩的JSONL，只要文件拆分合理），Glue的分布式架构可以充分并行处理，内存占用可控。

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