如何在AWS上实现20-30亿行数据集每日1亿多行的高效更新

优先落地组合：EMR Serverless + Apache Iceberg #

这是当前适配你场景成本最低、效率最高的方案，完全可以解决Glue的超量分区故障问题：

• 底层存储仍用S3，把现有表格式替换为Apache Iceberg，Iceberg的隐藏分区、快照管理、元数据独立索引能力，完全不依赖Glue元数据库的分区计数限制，哪怕单表数据量到百亿行也不会出现分区数过高的故障。
• 计算层用EMR Serverless跑Spark的MERGE INTO命令，把每日1.25亿行的增量更新集和全量表合并，仅重写涉及变更的数据文件，不需要全量重写表。按1.25亿行的变更量测算，配置100个vCPU的计算资源，整个merge操作可在30-45分钟内完成，后续全量处理可以直接基于Iceberg表的最新快照跑，完全赶得上次日任务启动。

替代方案：Redshift Serverless #

如果你的全量数据处理是SQL类逻辑，不需要自定义代码，直接用无服务器数仓方案更省心：

• 把从Oracle同步过来的全量数据导入Redshift Serverless，根据你的更新过滤条件设置表的分布键、排序键，优化update/merge性能。
• 每日变更集直接用Redshift的原生MERGE命令完成增量更新，20-30亿行的表跑1.25亿行的合并操作，配置合适的计算RU（资源单元），1小时以内即可完成所有处理，后续全量计算直接在Redshift内跑SQL即可，不需要额外处理分区、小文件等问题。

存量兼容方案：原生EMR Spark替换Glue作业 #

如果你不想改动现有存储结构，直接替换Glue的计算层即可解决故障：

• Glue的动态框架对于超5000万分区的表支持存在原生性能瓶颈，改用EMR跑原生Spark作业，调整spark.sql.shuffle.partitions、广播join、分区剪枝等参数后，完全可以支持1亿量级分区的操作，1.25亿行的更新操作耗时和上述Iceberg方案接近。

通用优化建议 #

• 每日增量更新集提前做去重、过滤预处理，仅保留最新的变更记录参与合并，可缩短至少30%的作业时长。
• 所有计算层用无服务器模式，无需维护固定集群，可根据当日数据量临时调整最大资源配额，确保任务在窗口期内跑完。
• 开启计算任务的自动重试、失败告警机制，避免偶发的资源波动导致任务超时。

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