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 集群的团队,全托管不用管服务器。
架构
MySQL → Debezium(binlog捕获) → Amazon MSK → Iceberg Kafka Connect → S3 Tables
核心步骤
1. 创建 S3 Table Bucket
aws s3tables create-table-bucket \
--name iceberg-data-${ACCOUNT_ID} \
--region us-east-1
2. 创建 Namespace
aws s3tables create-namespace \
--table-bucket-arn "<s3table-bucket-ARN>" \
--namespace "mydb"
3. 配置 Debezium MySQL Connector
在 MSK Connect 创建 Connector,关键配置:
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 签名:
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 逻辑的场景。
架构
MySQL → Flink CDC(binlog) → Flink SQL → Iceberg Dynamic Sink → S3 Tables
核心代码
1. 配置 Flink SQL Catalog
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
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
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 都行:
-- 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/…