如何转换行超2GB的150GB+超大型JSON文件？能否用jq实现？

问题背景 #

每月需处理1-50GB、偶尔超150GB的复杂JSON文件，加载至AWS EMR Hive表时，行长度超过2GB的文件会处理失败。此前用jq -c . < source.json > output.json压缩格式化小文件有效，但无法扩展到大文件；尝试jq流函数重建结构时出现内存耗尽，现寻求无需加载整个文件即可重写行超2GB JSON文件的方法，询问是否可通过jq实现。

基于jq的可行方案 #

完全可以用jq的流式解析+增量输出解决，全程无需加载整个文件到内存，核心是利用--stream模式逐块处理JSON结构，同时输出符合Hive要求的格式。

核心命令示例 #

针对嵌套层级深、数组元素多的大型JSON（如包含大量子条目结构的文件），可将顶级数组的每个元素拆分为单独的压缩行：

zcat 2023_06_430_65B0_in_network_rates.json.gz | jq --stream -n 'fromstream(1|truncate_stream(inputs))' | gzip > split_output.json.gz

命令解释 #

• zcat：直接读取压缩JSON文件，无需提前解压，节省磁盘空间
• jq --stream -n：启用流式解析模式，-n表示不直接读取原始JSON，而是处理流式输入
• fromstream(1|truncate_stream(inputs))：
  • truncate_stream(inputs)：将流式输入的路径截断到第1层，即仅保留顶级数组的单个元素层级
  • fromstream：把截断后的流重新组装为完整JSON对象，每个顶级数组元素会单独输出为一行
• 最后用gzip重新压缩输出，控制文件大小

内存友好的关键 #

该命令全程逐块处理，内存仅保留当前正在处理的单个JSON元素，不会加载整个大文件，哪怕150GB的文件也能稳定运行，不会出现内存耗尽问题。

适配Hive的优化调整 #

如果Hive需要保留顶级元数据（如报表主体名称），同时拆分数组元素，可以调整jq脚本，将元数据与每个数组元素组合输出：

zcat input.json.gz | jq --stream -n '
  # 先捕获顶级元数据
  ($reporting_entity_name = (inputs | select(length==2 and .[0][0]=="reporting_entity_name") | .[1]))
  | ($reporting_entity_type = (inputs | select(length==2 and .[0][0]=="reporting_entity_type") | .[1]))
  # 遍历处理数组元素并拼接元数据
  | reduce (inputs | select(length==2 and .[0][0]=="in_network")) as $item (
    {};
    . + {
      reporting_entity_name: $reporting_entity_name,
      reporting_entity_type: $reporting_entity_type,
      in_network_entry: $item[1]
    }
  )
' | gzip > hive_compatible.json.gz

这个脚本会先提取顶级元数据字段，再逐个处理目标数组的元素，将每个元素与元数据组合成一行，完美适配Hive的行式处理要求。

极端场景替代方案 #

若文件超150GB，jq单进程处理有瓶颈，可结合AWS服务：

• AWS Glue ETL：自带JSON流式处理能力，直接读取S3上的大文件，拆分后写入Hive表，无需手动处理文件
• Hadoop Streaming：编写简单Python脚本逐块解析JSON，配合Hadoop分布式能力处理超大文件

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