单机ETL，正在偷Spark的活

两份AWS官方技术博客，几乎同时指向一个 quietly 发生的变化：ETL这件事，正在从『集群思维』切换到『负载思维』。

一边，AWS Glue 6.0的官方教程手把手教你用 DuckDB 在单个worker上跑完SQL式ETL——从 Amazon S3 读Parquet，写 Apache Iceberg 表进 Amazon S3 Tables，并且老老实实给出了和 Apache Spark 等价作业的实测成本与运行时对比。另一边，Amazon EMR 8.1.0 通过 RedirectingSessionCatalog 把 Iceberg、Delta Lake、Hudi、Hive 四种表格式塞进一个Catalog，还能跨AWS账号直接join，不用搬数据。

单机干集群的活，一个Catalog收编三种格式。这不是两个孤立的产品动作，是湖仓话语权的重新分配。

📉 一台worker的账单，先惊动了谁

最贵的计算资源，往往不是被需求养大的，是被架构惯性养大的。

场景很常见：一个中等规模的转换作业，每天跑几次，数据量几百GB级别。按惯性写法，团队会起一个多节点的 Spark 集群——driver、executor、资源配置调一遍，作业本身可能只跑了十几分钟，但集群的启动、排队和最小计费单位，让账单里一大半钱花在『等待』上。

AWS这次的做法是把 DuckDB 直接放进了 AWS Glue 6.0 的运行时：单worker、进程内执行、原生读Parquet、原生写Iceberg。整条链路不经过分布式调度，一个SQL脚本搞定。更重要的是，官方帖子不是概念演示，而是一个可运行的完整示例，并拿同一个Glue运行时上的等价Spark作业做了成本和耗时的对比测量。

这个动作本身就是信号。云厂商的产品教程是行业风向标，AWS愿意把『单机方案』作为一等公民写进官方文档，意味着至少在一类负载区间里，分布式的必要性已经被官方承认是存疑的。据多位接近云厂商解决方案团队的人士透露，这类『中小作业下放单机引擎』的架构建议，最近一两年在内部评审中出现的频率明显上升。

产业逻辑很简单：ETL市场里，绝大多数作业的数据量根本吃不满一个集群。为5%的大作业设计的平台，让95%的小作业陪跑成本。

🧩 一个Catalog，按住了三场格式战争

引擎可以随便换，表格式不能乱——这是湖仓时代的新默契。

过去五年，Iceberg、Delta、Hudi三分天下的格局让大量企业头疼。历史原因，一个公司里往往三種格式都有：A团队当年选了Delta，B团队跟着某个开源项目用了Hudi，新项目又押注Iceberg。要跨格式做联合分析？要么把数据抄一遍统一格式，要么维护好几套查询引擎，各有各的Catalog、各有各的元数据服务。

Amazon EMR 8.1.0 的 RedirectingSessionCatalog 给了一个釜底抽薪的解法：通过单一Catalog会话，直接查询Iceberg、Delta、Hudi和Hive四种表，并且在 Amazon EMR Serverless 上可以跨AWS账号join数据，不需要复制数据。

注意这里的两个关键词：跨格式和跨账号。前者消解的是技术债，后者消解的是组织墙。数据不出账号、不落副本就能参与计算，这在数据要素流通监管趋严的背景下尤其重要——复制即风险，少一次拷贝就少一份合规负担和存储账单。

业界的私下评价很直接：这不是在格式战争里选边，而是把格式战争『降维』了。当任何引擎都能通过一个Catalog透明地读到任何格式，格式之间的差异就从选型生死题，变成了工程细节题。

🔄 数据引力正在离开引擎

当数据沉到开放表格式里，引擎就退化成一个可以随手换的插头。

把这两条新闻放在一起看，能看到同一个底层趋势的两面。DuckDB写Iceberg、EMR统一读四种格式——它们共同确认了一件事：湖仓的价值锚点已经从计算引擎迁移到了存储层和表格式层。

DuckDB和Spark能写同一张Iceberg表，EMR能读四种格式的表——这意味着引擎层的竞争彻底变成了性能、成本和易用性的竞争，而不是数据绑架。据多位在企业数据平台团队任职的人士反映，『Spark only when needed』正在从口头理念变成落地的资源编排策略：调度层按负载自动路由，小作业进DuckDB这类嵌入式引擎，大作业才唤醒分布式集群。

这也是为什么Glue 6.0让DuckDB和Spark跑在同一个运行时上这个细节值得玩味：厂商自己给出的答案，不是单机替代集群，而是同一平台、按负载选引擎。

💰 ETL的成本公式被改写了

集群不是技术能力的证明，是账单的形状。

传统ETL的成本公式是：集群规模 × 运行时长 × 单价。这个公式里藏着三笔隐形支出——集群冷启动时间、为峰值预留的冗余容量、以及调优分布式作业的人力成本。而单机方案把公式简化为：单worker计费 × 实际执行时间，冷启动几乎为零，没有executor调优，没有数据倾斜。

AWS在教程中拿实测数据说话，对比同一Glue运行时上DuckDB与Spark等价作业的成本与运行时，这个对比动作本身就承认了：在中等数据量区间，分布式没有天然优势。

（具体数字以AWS公开教程实测为准，区间因负载而异。）

对成本敏感的团队，这笔账需要重新算一遍：不是问『我们能不能上Spark』，而是问『这个作业凭什么需要Spark』。EMR Serverless按作业付费的模式再叠加多Catalog，跨团队、跨账号的临时分析也不再需要常驻集群垫底。

⚠️ 单机不是银弹，别急着拆集群

工具的边界，永远比工具的性能更值得先搞清楚。

冷静说两句反方向的话。DuckDB是进程内引擎，内存天花板就在那里——超大表的join、重shuffle的聚合、需要流式增量处理的管道，分布式集群依然是不可替代的。Spark多年沉淀的生态、CDC集成、复杂DAG编排，也不是一个SQL脚本能够覆盖的。

真正的终局判断是：混合编排时代。同一个湖仓底座（Iceberg/S3 Tables）之上，按负载特征路由到不同引擎——这是Glue 6.0同运行时支持两种引擎、EMR 8.1统一Catalog读四种格式这两个产品动作共同勾勒的方向。

规划下一步前，不妨先给团队定三个规矩：新管道先测单机方案的成本基线；格式选型只看开放性和生态兼容，不押注引擎；跨账号需求优先考虑免拷贝路径。拆不拆集群不重要，重要的是别再让集群替小作业买单。

湖仓的下半场，比的不是谁的引擎更快，而是谁的数据更不挑引擎。