Hive 表迁移到 Iceberg：S3 Tables 托管迁移的能力边界与核对项

可以，但有明确的前提。按 AWS 在 2026 年 11 月 4 日发布的公告，Amazon S3 Tables 现在支持把 Apache Hive 表托管迁移为 Apache Iceberg 表：迁移对象是在 AWS Glue Data Catalog 中注册、以 Parquet 格式存放在 Amazon S3 的 Hive 表，且要求同一 AWS 账号、同一 AWS 区域。整个迁移是托管的 API 驱动操作，不需要自己搭管道，也不用预置计算资源，生产工作负载在迁移期间继续运行（切换阶段除外）。来源：AWS News Blog

所以真正要判断的不是“能不能迁”，而是“我的表是否落在它的支持范围内，以及哪些参数需要我先核对”。后者包括：格式与区域、失败策略、同步节奏、切换窗口的长度，以及成本口径。

它做了什么，又没有做什么#

按公告，S3 Tables 承担的是整条迁移工作流：数据校验、兼容性检查、类型转换、文件重压缩（recompression）和 compaction。在复制任何数据之前，它会识别迁移范围内每一个源对象，并生成一份兼容性报告。

这条流程带来两个直接后果。第一，它不是只改元数据：迁移会真实复制文件，并可能重写文件布局，因此耗时和费用都和源数据量相关。第二，它给你一个先看报告再执行的机会：兼容性问题在复制前就能暴露，而不是等到查询时报错。

材料没有说明的部分包括：单表数据量上限、可同时运行的迁移任务数、迁移吞吐速度、源数据在迁移完成后是否会被清理、是否提供回滚机制。这些都是上线前需要另行确认的项，我在这里标为待核实。

先确认自己是否在支持范围内#

四个阶段，各自可以核对什么#

1. 校验与生成兼容性报告：识别范围内全部源对象，产出兼容性报告。这是成本最低的一次“试运行”，应当先看报告再决定是否继续。
2. 首次复制：把数据写入目标 Iceberg 表。目标表此时只读。
3. 多次同步：调用 sync-table-migration 追平源表变化，每次只复制变化的部分。材料明确说可以按需同步任意多次，且不打断源表写入。
4. 完成迁移（cutover）：调用完成操作，目标表提升为读写。材料说切换期间有“几分钟”需要停写，但没有给出它与数据量、表数量的关系，因此实际窗口需要按自己的表自行估算并预留。

报告写入位置由请求中的 migrationOutput 指定，包括表级兼容性报告、对象级兼容性报告和对象迁移报告三个前缀。这一结构意味着报告本身会落到你指定的 S3 桶里，可以把它们纳入已有的审计或告警链路。

失败策略决定“报错还是继续”#

请求中的 migrationPolicies 有两个关键字段：unmatchedSourceFieldsPolicy（源字段对不上目标 schema 时怎么办）和 incompatibleValuesPolicy（值不兼容时怎么办）。AWS 博客给出的示例值都是 fail，即失败即停。

这两个值是迁移风险的开关。示例只展示了 fail，是否还存在其他取值、各自语义如何，材料未说明，待核实。在此之前，建议先保持失败即停，再结合兼容性报告逐项处理，而不是一开始就挑一个更宽松的策略。

一个未执行的请求示例#

下面的 JSON 与 CLI 来自 AWS 博客示例的节选，本次未执行。账号 ID、ARN、KMS 密钥均为占位符，不能直接使用；实际字段以官方文档为准。

{
  "roleARN": "arn:aws:iam::123456789012:role/S3TablesMigrationRole",
  "destinationTable": {
    "tableBucketARN": "arn:aws:s3tables:us-east-1:123456789012:bucket/my-destination-bucket",
    "namespace": "mynamespace",
    "name": "my_destination_table",
    "encryptionConfiguration": { "sseAlgorithm": "aws:kms", "kmsKeyArn": "arn:aws:kms:us-east-1:123456789012:key/YOUR_KEY" },
    "storageClassConfiguration": { "storageClass": "INTELLIGENT_TIERING" },
    "properties": {
      "writeFormat": "parquet",
      "icebergFormatVersion": 2,
      "compressionCodec": "zstd",
      "dictionaryEncoding": true
    }
  },
  "sourceType": "glueTable",
  "source": {
    "glueTable": {
      "catalogId": "123456789012",
      "databaseName": "my_glue_database",
      "tableName": "my_source_table"
    }
  },
  "dataMigration": {
    "maintenanceSettings": {
      "icebergCompaction": { "targetFileSizeMB": 512, "strategy": "binpack" },
      "icebergSnapshotManagement": { "minSnapshotsToKeep": 3, "maxSnapshotAgeHours": 168 }
    },
    "migrationPolicies": {
      "unmatchedSourceFieldsPolicy": "fail",
      "incompatibleValuesPolicy": "fail"
    }
  },
  "reviewMigrationPlan": false,
  "migrationOutput": {
    "bucket": "arn:aws:s3:::my-report-bucket",
    "prefixes": {
      "tableCompatibilityReport": "reports/table-compatibility/",
      "objectCompatibilityReport": "reports/object-compatibility/",
      "objectMigrationReport": "reports/object-migration/"
    }
  }
}

aws s3tables start-table-migration \
  --cli-input-json file:///tmp/start-migration.json

示例里显式给出了 Iceberg 格式版本 2、zstd 压缩、目标文件大小 512 MB、保留至少 3 个快照且快照最长保留 168 小时。博客同时提到，控制台创建目标表时会使用“针对查询性能和存储效率调优的推荐默认值”。示例值与默认值是否一致，材料未说明，待核实。此外 reviewMigrationPlan 在示例中为 false，说明还存在先审阅迁移计划的路径，建议首次迁移时先走这条路。

成本与运维核对项#

• 计费口径：材料称只为复制的数据付费，Hive 到 Iceberg 的转换不额外收费；位于 S3 Intelligent-Tiering 的源对象保持当前访问层级。具体单价、重压缩与 compaction 产生的请求费用如何计入，待核实。
• 重复同步的成本：每次 sync 只复制变化部分，但同步次数越多，累计复制的数据量越大。切换前应规划好同步节奏。
• 目标表维护：S3 Tables 自带自动维护、优化、复制和 Intelligent-Tiering。迁移后的单表维护不再是你的运维项，但这属于产品行为，具体策略与可调参数需要查官方文档。
• 切换窗口：材料只说“几分钟”，没有给出与被迁移数据量的关系，需按实际表规模自行估算并留出回退时间。
• IAM 与工具链：博客提到 Agent Toolkit for AWS 中的 migrating-hive-tables-to-s3-tables 技能，可以分析现有 IAM 策略并推荐等效的目标策略、校验迁移计划、执行 Start → Sync → Complete 调用并跟踪进度。是否引入这类自动化，取决于团队对代理执行迁移操作的接受度。

上线前的最小核对清单#

1. 确认源表是 Glue 注册的 Parquet 表，且与目标在同一账号、同一区域，所在区域在支持列表内。
2. 先跑一次带兼容性报告的迁移，只读报告，不急于完成。
3. 把 migrationPolicies 的失败策略与团队的数据质量要求对齐，不要默认放宽。
4. 规划 sync 频率与切换时间窗，并把窗口长度写进变更单。
5. 确认下游查询侧能通过 Athena、SageMaker Unified Studio 或 Iceberg REST API 读到目标表。
6. 把报告前缀接入现有审计链路，保留迁移前后的对照记录。
7. 对材料未覆盖的项（数据量上限、并发数、清理与回滚）单独向 AWS 支持确认，不要假设。

本文依据 AWS News Blog 的公告与示例整理，示例代码未执行；标为“待核实”的项，本次材料未提供依据。