AWS为S3 Tables加入托管的Hive到Iceberg迁移：上线范围是同账户同区域、在Glue中注册的Parquet表，共十个区域，迁移完成前目标表只读

2026年11月4日，AWS宣布Amazon S3 Tables支持把Apache Hive表托管迁移到Apache Iceberg。What's New公告和AWS新闻博客的发布文章把它描述为由API驱动的操作：S3 Tables会验证源表、转换数据类型、复制数据、重新压缩并合并小文件，同时生产负载继续运行。AWS说，过去从Hive迁到Iceberg需要数周的工程投入，因为每张表都要有自己的迁移管道。这个时长是AWS的说法，文章没有给出测量，也没有说明对应的是多大规模的表。

上线范围很窄，应当先读。上线时，该功能支持在AWS Glue中注册的、以Parquet格式存储的Hive表，并且源和目标要在同一个AWS账户、同一个区域。它在十个区域可用：美国东部（弗吉尼亚北部、俄亥俄）、美国西部（俄勒冈）、亚太（孟买、新加坡、悉尼、东京）和欧洲（法兰克福、爱尔兰、斯德哥尔摩）。其他格式的Hive表、跨账户的表，或在这个清单之外的区域，都不在所述范围内。文章没有说明何时会放宽，使用前请按所在账户和区域逐项核对。

命令行版的流程有三步：启动、同步和完成。迁移启动时，S3 Tables先找出范围内的每个源对象，并在复制任何数据之前生成兼容性报告。默认情况下，任务在规划之后自动继续；设置审核标志可以让它暂停，先读报告。目标是表存储桶里的一张新的Iceberg表，使用推荐的默认设置创建，迁移期间是只读的。你可以随意多次调用同步，每次只复制发生变化的部分。完成迁移后，目标表升级为可读写。Athena和Amazon SageMaker Unified Studio在控制台中直接集成，任何支持Iceberg REST API的引擎都可以查询结果。

各来源对源表的影响说得并不完全一样。开发者指南说，迁移任务期间源表保持不变，读写都完全可用。发布博客说，你可以按需多次同步而不用停止对源表的写入，只是在切换时有几分钟的例外。这两句并不矛盾，但也不相同：文档说的是任务，博客说的是最后的切换。不能接受切换时短暂暂停写入的团队，应该为这一步做计划，而不是假定零停机。文章还说可以回滚到源数据，这与文档所说的源表保持完好是吻合的。

类型和模式的处理是明确的。迁移把Hive的模式和分区映射为Iceberg的模式和分区规格，你可以提供目标模式，也可以让迁移根据Glue的模式生成一个兼容的。迁移策略决定出现不匹配时怎么办，博客的示例把未匹配字段策略和不兼容值策略都设为失败。这是示例请求里的取值，不是声明的默认值。示例请求还展示了可调的维护设置：目标文件大小512 MB的压缩合并，以及至少保留三个快照、168小时后过期的快照管理。复制完成后，对象迁移报告会给出每个源对象的结果。

费用只做了定性描述。你只为任务复制的数据付费，Hive到Iceberg的转换本身不收费，位于S3 Intelligent-Tiering的源对象保持在当前访问层，并保留自上次访问以来的天数。转换不收费不等于迁移免费：复制的数据按S3价格计费，文章只指向S3价格页，没有给出每GB的数字。如果表使用Snappy压缩，S3 Tables会把它们重新压缩为Zstandard并合并，AWS说这能减少存储和对象数量，并提高查询性能，但没有给出前后对比的数字。

智能体也是卖点之一。AWS工具包里的一项迁移技能，可以让Kiro之类的编码智能体分析现有IAM策略并推荐对应的目标策略、验证计划、执行启动、同步和完成调用并监控进度，同时带有安全护栏。这项技能是给智能体的操作指引，调用的仍是同样的API，而不是另一套迁移引擎。

我们的判断：这个功能省掉了搭建管道的步骤，所述限制决定它是否适合你。依赖它之前先核对四点：表在Glue中注册、数据是Parquet、源与目标在同一账户和区域、该区域在清单之内。然后规划切换窗口；如果模式中有不常见的类型，先读兼容性报告再复制；并按数据量估算复制成本。目标表在迁移期间是只读的，也就是说在你完成迁移之前，新表不能承接写入。