13分钟同步10亿行：这家小公司凭什么挑战Flink？

数据管道（data pipeline，指数据在不同系统间流动的自动化流程）的延迟战争里，大厂工具动辄需要小时级配置，一家叫Supermetal的创业公司却把时间压缩到了13分钟——不是demo，是生产环境跑出来的真实数字。

反常识的起点：为什么"快"成了新战场？

PostgreSQL到Iceberg（一种开源的表格数据存储格式，专为大规模分析设计）的数据同步，听起来是基础设施团队的脏活。但脏活的效率，直接决定AI训练、实时报表、合规审计的上线速度。

传统方案的典型路径：用Apache Flink做流处理，或Kafka Connect（Kafka的数据集成框架）做管道，再或者用Spark（大数据处理引擎）批处理。这些工具功能完备，但配置复杂度高——调参、调优、监控告警，一套下来几小时甚至几天。

Supermetal的切入点很刁钻：不做通用引擎，只做"PG到Iceberg"这一件事，把端到端时间压到13分钟。

时间线拆解：13分钟是怎么算出来的？

原文给出的关键节点值得细品：

第0分钟：从空的Iceberg表开始，Supermetal启动初始快照（snapshot，数据在某一时刻的完整副本）。

第7分钟：完成10亿行历史数据的批量加载。这里的技术选型是亮点——没有走传统的全表扫描，而是直接对接PostgreSQL的物理复制槽（replication slot，数据库用于持续同步变更的机制），绕过查询层开销。

第10分钟：增量变更流（change data capture，变更数据捕获）开始实时追加，历史与实时数据无缝衔接。

第13分钟：整个管道进入稳定状态，延迟控制在秒级。

对比测试数据同样具体：Flink CDC方案在同等硬件下，初始快照需要45-90分钟；Kafka Connect + Debezium（开源CDC工具）的组合，配置时间就得2小时以上，还不算调优。

架构取舍：做减法比做加法难

Supermetal的核心设计是"无状态单进程"。没有Kafka集群，没有YARN（Hadoop的资源调度系统）或Kubernetes编排，单机部署，配置即一个YAML文件。

这种极简主义的代价是明显的：不支持PG以外的源，不支持Iceberg以外的目标，复杂转换逻辑需要外挂。但换来的收益是确定的——部署成本从"需要专门团队"降到"一个后端工程师10分钟搞定"。

原文提到一个细节：Supermetal利用Iceberg的隐藏分区（hidden partitioning）和元数据层，直接生成查询引擎（Trino/Spark/Flink）可识别的优化统计信息。这意味着数据落地即可查，不需要额外的"优化"作业。

大厂工具的回应：生态壁垒 vs 场景极致

Flink、Spark、Kafka Connect的护城河在于生态。Flink的SQL层、Spark的机器学习集成、Kafka的实时流生态，都是Supermetal短期内无法复制的。

但Supermetal赌的是另一个趋势：数据栈的"垂直切片"。当Snowflake、Databricks、BigQuery把存储计算分离做到极致，中间的数据搬运环节反而成了瓶颈——而瓶颈环节的专业化，正是创业公司机会。

原文作者对比了四种方案的TCO（总拥有成本）：Supermetal在<10TB、单PG源、Iceberg目标的场景下，运维人力成本是大厂方案的1/5；但当数据量突破100TB、源系统超过5个，Flink的规模化优势就会显现。

13分钟背后的行业信号

这个数据点本身不值得神话。真正有趣的是它揭示的选型逻辑变化：

五年前，数据团队倾向于"一套Flink打天下"，用通用性对冲学习成本；现在，随着基础设施即服务（IaaS）成熟，"组合最佳单品"成为新共识——Supermetal管PG到Iceberg，dbt管转换，Superset管可视化，各取所长。

原文没有透露Supermetal的融资情况或客户名单，但提到其设计参考了Materialize和Estuary的产品哲学：把流处理做得像批处理一样简单。这条路线上的玩家正在增多。

一个待验证的假设是：如果Supermetal的模式成立，会不会出现"Redshift到Iceberg""MySQL到Delta Lake"的垂直工具矩阵？数据管道的终极形态，是几个通用巨头，还是一堆场景专家？