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

23 阅读1分钟

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 做数据湖,实时写入场景下这些问题躲不掉:

  1. 小文件爆炸:高频写入产生大量小文件,查询性能直线下降。得定期跑 Spark 做 rewrite_data_files
  2. 快照堆积:历史快照越来越多,占存储空间。得写脚本做 expire_snapshots
  3. 孤立文件:被删除的数据文件残留在存储里。得跑 remove_orphan_files
  4. 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 ConnectFlink 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;

踩坑记录

  1. REST Catalog URI 别写错:格式是 https://s3tables.<region>.amazonaws.com/iceberg,少个 /iceberg 就连不上
  2. SigV4 签名必须开signing-names3tables 不是 s3
  3. Iceberg V3 兼容性:S3 Tables 支持 V3,但 Athena 目前(2026-03)还不支持 V3 查询,用 EMR 可以
  4. 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/…