基于Parquet的RedShift增量更新方案合理性咨询

现有方案的优缺点 #

优点 #

• 保留了Parquet文件的独立性，后续切换数据仓库时无需重新转换，直接复用，这个设计很务实。
• 代理键生成逻辑清晰，确保账户标识的一致性，避免重复生成。

缺点 #

• 每次增量处理都加载全量Parquet文件，随着数据量增长，会导致计算资源消耗剧增、处理时间拉长，尤其是账户数据量达到TB级后，EMR的运行成本和延迟都会成为问题。
• 全量合并后再导出增量Parquet的步骤，可能引入数据冗余，且全量文件的维护成本会越来越高。

优化方向：在保留Parquet可移植性的前提下减少全量依赖 #

1. 单独维护代理键映射表（Parquet格式） #

• 把代理键与账户自然键的映射关系单独存储为小体积的Parquet文件（如account_key_mapping.parquet），放在S3固定路径。
• 增量处理步骤调整：
  • 新CSV上传后，先加载映射表，与新CSV的账户自然键关联。
  • 筛选出映射表中不存在的新账户，通过读取映射表最大代理键值+1生成连续新代理键。
  • 将新生成的代理键追加更新到映射表中。
  • 用更新后的映射表为新CSV所有账户匹配代理键，生成增量账户数据Parquet文件。
  • 可选：将增量Parquet合并到全量账户Parquet目录（保留全量快照），同时将增量文件加载到Redshift。
• 好处：映射表体积远小于全量账户数据，大幅降低EMR加载和计算开销，同时依然保留Parquet格式的映射表与账户数据，后续换数仓可直接复用。

2. 利用S3分区+增量扫描减少全量加载 #

• 对全量账户Parquet文件按时间分区（如load_date）存储，每次增量处理时，仅扫描最近几个分区（或根据CSV生成时间筛选对应分区），而非全量加载。
• 结合代理键映射表使用：先通过映射表判断账户是否存在，若映射表无记录，再去历史分区验证（避免映射表遗漏）。
• 好处：进一步缩小处理数据范围，同时保留Parquet分区结构，提升后续查询与迁移效率。

3. Redshift侧配合增量更新，降低全量Parquet依赖 #

• 在Redshift中维护代理键映射表（如account_dim维度表）：
  • 增量处理时，PySpark连接Redshift，查询account_dim获取已有代理键映射关系。
  • 为新账户生成代理键后，先插入Redshift的account_dim，再生成增量Parquet文件。
  • 定期从Redshift导出account_dim为Parquet格式存储到S3，确保后续换数仓时有可复用的Parquet文件。
• 好处：利用Redshift高效查询能力获取映射关系，避免加载全量Parquet，同时通过定期快照保留Parquet可移植性。

4. 采用CDC思路处理数据更新 #

• 若本地数据有变更标识（如update_timestamp、is_deleted），增量CSV仅包含变更/新增记录：
  • PySpark仅针对这些变更记录匹配代理键，无需加载全量账户数据。
  • 生成增量Parquet时标记变更类型（新增/更新/删除），加载到Redshift时用MERGE语句同步更新。
• 好处：从源头上减少处理数据量，Parquet文件可按变更类型分区，方便后续迁移。

总结 #

你的核心需求（保留Parquet可移植性）非常合理，优化关键是将代理键映射逻辑与全量账户数据解耦，通过维护独立映射表（Parquet或Redshift+定期快照）避免全量加载。推荐先从「单独维护代理键映射表」入手，实现成本低，能显著提升增量处理效率，且完全保留Parquet文件的复用价值。

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