Pandas 处理嵌套 JSON 数据的展开策略与优化实践
在数据工程场景中，从 Web 接口、消息队列或文档型数据库获取的 JSON 数据往往呈现深度嵌套特征。这类半结构化数据在导入 pandas 后，常见的情况是某些单元格内嵌套着字典或数组，形成"单元格内再藏表格"的复杂形态，直接阻碍了后续的向量化运算与统计分析。
尽管 pandas 内置了数据展平工具，但面对一对多的层级关系时，机械地展开会导致数据急剧膨胀。本文以一个三层嵌套的典型业务场景为例，剖析不同展开策略的适用边界，并提供可落地的优化方案。
示例数据结构
以下模拟电商领域的用户-订单数据，包含用户基本信息、嵌套的个人资料，以及可变长度的订单列表：
raw_records = [
{
"uid": 101,
"username": "张三",
"metadata": {
"years_old": 28,
"location": {
"province": "广东",
"municipality": "深圳"
}
},
"transactions": [
{"tid": "T1001", "value": 299.0},
{"tid": "T1002", "value": 158.5},
{"tid": "T1003", "value": 89.0}
]
},
{
"uid": 102,
"username": "李四",
"metadata": {
"years_old": 35,
"location": {
"province": "浙江",
"municipality": "杭州"
}
},
"transactions": [
{"tid": "T1004", "value": 520.0}
]
}
]业务需求是将每笔交易独立成行，同时携带用户属性。直观的结果是交易记录多的用户，其个人信息被反复复制。
方案一：递进式展平与爆炸展开
首先利用 pd.json_normalize() 处理字典嵌套，再通过 explode() 拆解数组：
import pandas as pd
# 第一阶段：展平字典层级
df_flat = pd.json_normalize(
raw_records,
sep='_'
)
# 此时 transactions 列仍为对象数组
# 第二阶段：分离基础属性与待展开数组
base_cols = [c for c in df_flat.columns if c != 'transactions']
df_base = df_flat[base_cols].copy()
# 第三阶段：爆炸展开并归一化
df_exploded = df_flat[['uid', 'transactions']].explode('transactions')
df_txn_detail = pd.json_normalize(df_exploded['transactions'].tolist())
# 第四阶段：对齐索引后横向拼接
df_base_expanded = df_base.loc[
df_base.index.repeat(df_flat['transactions'].apply(len))
].reset_index(drop=True)
final_df = pd.concat([df_base_expanded, df_txn_detail], axis=1)该方法逻辑清晰，但当某个用户的交易记录达到数千条时，years_old、province 等字段的重复存储会造成严重的内存浪费。
方案二：基于分析意图的模式选择
数据建模应服务于分析目标，而非追求表面的规整。
情形 A：交易级分析为主
若核心指标是客单价分布、地域交易总额等，宽表格式可接受，但需实施压缩优化：
# 对低基数类别型字段启用分类存储
low_cardinality = ['username', 'province', 'municipality']
for field in low_cardinality:
final_df[field] = final_df[field].astype('category')
# 对数值精度进行合理降级
final_df['value'] = final_df['value'].astype('float32')
final_df['years_old'] = final_df['years_old'].astype('int16')分类编码可将字符串的存储开销降低至原始大小的 10%-30%，在百万级数据量下效果显著。
情形 B：用户级分析为主
若关注用户留存、生命周期价值等，应保持星型模型结构：
# 构建用户维度表
user_dimension = pd.json_normalize(raw_records)[
['uid', 'username', 'metadata.years_old',
'metadata.location.province', 'metadata.location.municipality']
]
user_dimension.columns = ['uid', 'username', 'age', 'province', 'city']
# 构建交易事实表（列表推导式高效展开）
fact_records = [
{**{'uid': rec['uid']}, **txn}
for rec in raw_records
for txn in rec['transactions']
]
transaction_fact = pd.DataFrame(fact_records)分析时按需关联，避免预计算冗余：
# 计算各城市交易总额
city_revenue = (
transaction_fact
.merge(user_dimension[['uid', 'city']], on='uid')
.groupby('city')['value']
.sum()
)方案三：大规模数据的工程化方案
当数据规模突破单机内存阈值，需引入更高效的工具链：
| 场景特征 | 推荐方案 | 关键优势 |
|---|---|---|
| 内存受限，需流式处理 | Dask DataFrame | 分块读取，延迟计算 |
| 追求极致性能 | Polars | 零拷贝操作，向量化执行 |
| 持久化与跨团队共享 | Parquet + Hive 分区 | 列式压缩，谓词下推 |
以 Polars 为例，其原生支持嵌套结构的惰性展开：
import polars as pl
lf = pl.LazyFrame(raw_records)
# 直接展开嵌套结构，无需中间爆炸步骤
result = (
lf.explode('transactions')
.unnest('transactions')
.unnest('metadata')
.unnest('location')
.collect()
)反模式警示
实践中需避免以下陷阱：
- 过度规范化：为追求"第三范式"而创建过多关联表，增加查询复杂度
- 过早物化：将临时分析用的宽表持久化为生产数据，造成维护负担
- 忽视空值处理：嵌套路径中的缺失字段会导致
json_normalize产生NaN，需显式指定errors='ignore'或填充策略
决策框架
处理嵌套 JSON 时，建议按以下优先级决策：
- 明确分析粒度——是实体级还是事件级？
- 评估数据规模——万级以内可用 pandas，百万级考虑 Polars，亿级引入 Spark/DuckDB
- 选择存储策略——分析型场景用宽表+分类编码，运营型场景用星型模型
- 延迟计算——优先保留原始结构，在查询时动态展开所需字段
核心原则在于：数据形态应随用随变，而非一次性定型。理解业务语义比掌握工具技巧更为关键。
