MySQL 实时入湖零运维？S3 Tables 两种方案实战

做数据分析的都知道痛：MySQL 里的业务数据想实时同步到数据湖，Apache Iceberg 是好选择------ACID 事务、Schema Evolution、Time Travel 都支持。但问题来了：小文件合并、快照清理、孤立文件删除这些运维活谁来干？

亚马逊云科技的 Amazon S3 Tables 就是来解决这个问题的------专为 Iceberg 优化的全托管存储，自动帮你做 Compaction、清快照、删孤儿文件。你只管写数据，运维的事它包了。

这篇走两条路线把 MySQL 数据实时搬进 S3 Tables：MSK Connect 方案和 Flink CDC 方案，各有适用场景。

Iceberg 数据湖的运维之痛

先说为什么需要 S3 Tables。用 Iceberg 做数据湖，实时写入场景下这些问题躲不掉：

小文件爆炸 ：高频写入产生大量小文件，查询性能直线下降。得定期跑 Spark 做 rewrite_data_files
快照堆积 ：历史快照越来越多，占存储空间。得写脚本做 expire_snapshots
孤立文件 ：被删除的数据文件残留在存储里。得跑 remove_orphan_files
Manifest 膨胀 ：元数据文件越来越大。得做 rewrite_manifests

这四件事每件都需要额外的计算资源和调度系统。折腾半天，你的 Spark 集群一半时间在做运维而不是跑业务。

S3 Tables 怎么解决的

S3 Tables 是亚马逊云科技推出的 Iceberg 专属存储方案，核心卖点：

查询性能提升 3 倍：底层针对 Iceberg 格式做了存储优化
10 万次/秒事务写入：流式场景扛得住
全托管表维护：Compaction 约 3 分钟执行一次，快照清理和孤立文件删除自动搞定
REST Catalog 标准接口：任何支持 REST Catalog 的引擎都能直接连

一句话：你把数据写进来，剩下的 S3 Tables 全管了。

方案一：MSK Connect + Iceberg Kafka Connect

适合已有 Amazon MSK 集群的团队，全托管不用管服务器。

架构

scss 复制代码

MySQL → Debezium(binlog捕获) → Amazon MSK → Iceberg Kafka Connect → S3 Tables

核心步骤

1. 创建 S3 Table Bucket

bash 复制代码

aws s3tables create-table-bucket \
  --name iceberg-data-${ACCOUNT_ID} \
  --region us-east-1

2. 创建 Namespace

bash 复制代码

aws s3tables create-namespace \
  --table-bucket-arn "<s3table-bucket-ARN>" \
  --namespace "mydb"

3. 配置 Debezium MySQL Connector

在 MSK Connect 创建 Connector，关键配置：

properties 复制代码

connector.class=io.debezium.connector.mysql.MySqlConnector
tasks.max=1
database.hostname=<mysql-host>
database.port=3306
database.user=<username>
database.password=<password>
topic.prefix=mydb
database.include.list=<database-name>
snapshot.mode=when_needed
# Kafka Topic 自动创建
topic.creation.enable=true
topic.creation.default.replication.factor=3
topic.creation.default.partitions=3

4. 配置 S3 Tables Sink Connector（核心）

这里是和传统 Glue Catalog 不一样的地方------用 REST Catalog + SigV4 签名：

properties 复制代码

connector.class=io.tabular.iceberg.connect.IcebergSinkConnector
tasks.max=2
# S3 Tables REST Catalog
iceberg.catalog.type=rest
iceberg.catalog.uri=https://s3tables.us-east-1.amazonaws.com/iceberg
iceberg.catalog.warehouse=<table-bucket-arn>
iceberg.catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO
# SigV4 签名（必须）
iceberg.catalog.rest.sigv4-enabled=true
iceberg.catalog.rest.signing-name=s3tables
iceberg.catalog.rest.signing-region=us-east-1
# 自动建表 + Schema 演进
iceberg.tables.auto-create-enabled=true
iceberg.tables.evolve-schema-enabled=true
# CDC 配置
iceberg.tables.cdc-field=_cdc.op
iceberg.tables.dynamic-enabled=true

MSK Connect 的好处

零基础设施：不用管 Kafka Connect 集群
自动扩缩：根据 CPU 自动调 Worker 数量
断点续传：Worker 挂了自动恢复，offset 不丢
省 70% 运维：比自建 Kafka Connect 集群省事多了

方案二：Flink CDC + Iceberg Dynamic Sink

适合需要多表动态路由、复杂 ETL 逻辑的场景。

架构

scss 复制代码

MySQL → Flink CDC(binlog) → Flink SQL → Iceberg Dynamic Sink → S3 Tables

核心代码

1. 配置 Flink SQL Catalog

sql 复制代码

CREATE CATALOG s3tables_catalog WITH (
  'type' = 'iceberg',
  'catalog-impl' = 'org.apache.iceberg.rest.RESTCatalog',
  'uri' = 'https://s3tables.us-east-1.amazonaws.com/iceberg',
  'warehouse' = '<table-bucket-arn>',
  'rest.sigv4-enabled' = 'true',
  'rest.signing-name' = 's3tables',
  'rest.signing-region' = 'us-east-1'
);

2. 定义 MySQL CDC Source

sql 复制代码

CREATE TABLE mysql_source (
  id INT,
  name STRING,
  amount DECIMAL(10,2),
  update_time TIMESTAMP(3),
  PRIMARY KEY (id) NOT ENFORCED
) WITH (
  'connector' = 'mysql-cdc',
  'hostname' = '<mysql-host>',
  'port' = '3306',
  'username' = 'flink_cdc',
  'password' = '<password>',
  'database-name' = 'mydb',
  'table-name' = 'orders'
);

3. 写入 S3 Tables

sql 复制代码

INSERT INTO s3tables_catalog.mydb.orders
SELECT * FROM mysql_source;

Flink 方案的优势

多表动态路由：一个 Flink 作业同步多张表，Iceberg 1.10+ Dynamic Sink 自动路由
Schema Evolution：源表加字段，目标表自动跟着加
复杂 ETL：可以在同步过程中做数据清洗、转换
Exactly-once：配合 Flink Checkpoint 保证精确一次语义

两种方案怎么选

维度	MSK Connect	Flink CDC
适用场景	已有 MSK，简单同步	需要 ETL、多表路由
运维成本	全托管，几乎为零	需管理 Flink 集群
灵活性	配置驱动	代码驱动，更灵活
多表支持	支持	支持（Dynamic Sink 更强）
Schema Evolution	支持	支持
学习成本	低（配置即可）	中（需懂 Flink SQL）

我的建议：

团队已有 MSK → 方案一，30 分钟就能跑起来
需要复杂数据处理 → 方案二，Flink 的灵活性值得投入

S3 Tables 自动维护实测

配好数据同步后，S3 Tables 的自动维护是真的香：

Compaction：约 3 分钟执行一次，默认合并到 512MB 大文件
快照清理：自动清过期快照
孤立文件删除：自动干掉没人引用的文件

⚠️ 注意：用了 S3 Tables 就不能再手动调 rewrite_data_files 了，维护全交给平台。

查询用 Amazon Athena 或 Amazon EMR 都行：

sql 复制代码

-- Athena 查询 S3 Tables
SELECT * FROM s3tables_catalog.mydb.orders
WHERE update_time > current_timestamp - interval '1' hour;

踩坑记录

REST Catalog URI 别写错 ：格式是 https://s3tables.<region>.amazonaws.com/iceberg，少个 /iceberg 就连不上
SigV4 签名必须开 ：signing-name 是 s3tables 不是 s3
Iceberg V3 兼容性：S3 Tables 支持 V3，但 Athena 目前（2026-03）还不支持 V3 查询，用 EMR 可以
IAM 权限 ：MSK Connect 的执行角色需要 s3tables:* 和 s3:* 权限

亚马逊云科技官博原文：aws.amazon.com/cn/blogs/ch... Amazon S3 Tables 文档：docs.aws.amazon.com/AmazonS3/la... Iceberg Kafka Connect：github.com/databricks/...