Aurora PostgreSQL 嵌入式 DuckDB 直查 Iceberg 数据湖：HTAP 边界的工程解构与对国产数据库的启示

Mopheus 6天前

一、AWS 这周做了什么事

AWS 在 2026 年 10 月 1 日把 Amazon Aurora PostgreSQL 的一个新能力推向 GA：开发者可以直接在 PG 上跑标准 SQL，对 Amazon S3 / S3 Tables / Iceberg REST Catalog 中的 Apache Iceberg 与 Parquet 数据做外部表查询。功能对 Aurora PostgreSQL 17.11 与 18.6 起默认开启，覆盖所有商用 AWS 区与 GovCloud；计费按增量计算资源 + S3 请求，功能本身不另收钱。

把这个变化拆到最底层，AWS 的工程师做了一件"看起来很小、其实很难"的事：把一个嵌入式分析引擎（DuckDB）塞进了 Aurora 的查询执行路径里，让同一份 SQL 既能命中 Aurora 的操作表，又能跨过网络去扫对象存储上的列存文件，再把结果与本地数据做 JOIN。谓词下推、列裁剪、自动 schema 推导、缓存、与 Aurora 事务语义的整合全部在 Aurora 进程内完成。

表面上看，这是一个"再加一个数据源连接器"的故事。但实际意义在于：Aurora 这条原本只负责在线事务的产品线，被 AWS 自己拉进了湖仓一体的战场。

二、为什么是 DuckDB，而不是 Athena 或 Redshift Spectrum

读者肯定会问：Aurora 之前不是已经有 Babelfish for Aurora PostgreSQL、S3 export、零 ETL 集成到 Redshift 等链路了吗？为什么这次还要在 Aurora 引擎里嵌一个 DuckDB？

把过去三年 AWS 给 Aurora 准备的"湖仓交互"选项放在一起看：

S3 export：定期把 Aurora 数据导出成 Parquet，单向、延迟高、只能批处理。
Zero-ETL to Redshift：把 Aurora 的 binlog 实时投递到 Redshift，等于建一个 Redshift 副本来做分析。
Babelfish：解决 SQL Server 兼容，不是分析场景。
Athena Federated Query：从 Athena 跨源查 Aurora，等于"分析引擎主动来拉"。

这四个方案有个共同点：分析这件事不在 Aurora 进程里发生。要么 Aurora 数据先搬走，要么分析引擎远程来拉，都需要 Aurora 把"读路径"开放给外部系统。对在线事务库来说，把读路径开放给外部是一件风险/复杂度都很高的事情：锁竞争、长查询对 buffer pool 的污染、prepared statement 缓存被外部会话挤占，这些问题在过去 10 年一直存在。

DuckDB 给 AWS 提供了一个完全不同的工程答案：把分析引擎做成 Aurora 的"内嵌协处理器"。Aurora 主线程仍然负责事务读写，DuckDB 在 Aurora 进程内开一个轻量、向量化、本地无状态的执行上下文，专门负责扫 Iceberg / Parquet 文件。两者共享同一段 SQL 解析树、同一套优化器信息、同一份连接协议，但是两套执行后端。事务表和湖数据可以 join，但执行路径是隔离的。

这就是为什么 AWS 选 DuckDB 而不是把 Athena 塞进来：Athena 是独立服务，不可能做到"嵌进 Aurora 进程里"；Redshift Spectrum 走的是远程读取路径，无法避免长查询对 Aurora buffer pool 的污染；DuckDB 是 C++ 写就的进程内库、零外部依赖、单节点即可在 GB 级内存下做向量化执行，正好对应 Aurora 一个计算节点的边界。

三、整体架构与查询路径

我根据 AWS 的官方描述和 BigDATAwire 的拆解，把一次跨 Iceberg JOIN 的执行路径画出来：

应用端发出一条标准 PostgreSQL SQL，语句里涉及 Aurora 本地表与一张指向 S3 Iceberg 数据的外部表。
Aurora 的 PG 解析器 / 优化器接收这条 SQL，看到外部表存在"lake_fdw"或类似扩展的 foreign table，标记为需要外部引擎处理。
优化器把 SQL 拆成两个子树：本地的子树用 Aurora 执行器跑，远端的子树把"对 Iceberg 的过滤 + 列投影 + JOIN 条件"打包，发给进程内嵌的 DuckDB。
DuckDB 用 Iceberg REST Catalog 解析元数据（manifest list / manifest / partition），定位需要扫的 Parquet 文件集合，对 S3 发起范围 GET。
DuckDB 在本地内存里做向量化扫描 + 谓词下推 + 列裁剪，把过滤后的结果以 Arrow 兼容格式返回给 Aurora 的执行节点。
Aurora 把 DuckDB 返回的行与本地表行在 JOIN 算子上对齐，沿用 PG 的 MVCC 与并发控制语义提交结果。
应用拿到一份统一的结果集，全程只用一条 PG 连接、一份标准 PG 协议。

这条路径里最值得关注的不是任何单点技术，而是它把"事务引擎 + 分析引擎"的协作从 RPC 降级成了进程内函数调用。这意味着过去所有面向外部分析引擎需要做的网络协议适配、连接池、结果集序列化、错误恢复，全部被压缩到同一个进程内。

四、对 HTAP 边界的几个工程信号

把这件事放到 2026 年的 HTAP 叙事里看，它至少传递了四个工程信号：

信号一：HTAP 不再是"一个内核同时做 TP 和 AP"。 OceanBase / TiDB / PolarDB / CockroachDB 这些年的 HTAP 路线基本都是"一个分布式内核 + 列存副本 + 副本间强一致"。Aurora 给出的答案是"两个独立内核，进程内集成"。后者对国产 HTAP 路线有直接的工程启示：与其让一个内核同时承担两套 workload，不如在边界清晰的前提下做内核级拼接。

信号二：跨存储层查询正在成为新的"默认能力"。 2026 年 9 月，ClickHouse 把 OneLake Iceberg 读 GA、写公开预览；Databricks 用 Lakebase 把搜索 / PITR / restore 拉进 Postgres；AWS 把 DuckDB 嵌入 Aurora。三个独立厂商在不同产品上做同一件事，说明湖仓之间的查询边界正在被业界默认打通，而不再是某家厂商的差异化卖点。

信号三：PG 在 AI 时代继续扮演"瑞士军刀"。 Aurora 这条功能只服务 PostgreSQL，不服务 MySQL。从技术决策上看，PG 的扩展机制、FDW 框架、Iceberg 生态里现成的 arrow_fdw / duckdb_fdw 给了 AWS 一条短路径；MySQL 没有对等能力。这意味着如果你的栈里同时跑 MySQL 和 PG，未来 12 个月内你会看到 PG 这边不断冒出新能力，而 MySQL 这边会需要外部 ETL 或单独的分析引擎来补齐。

信号四：嵌入式分析引擎成为新竞争点。 DuckDB 在 2024-2026 年间已经嵌入进 Postgres（pg_duckdb 扩展）、SQLite（sqlite-duckdb 桥）、Spark（作为本地 fallback）、甚至 ClickHouse 的 chdb 扩展。这次 AWS 直接把它嵌进 Aurora，相当于 DuckDB 在云数据库层面拿到了一个旗舰背书。对国产数据库而言，duckdb-as-a-library 是一个低成本、高收益的可选组件。

五、性能边界与代价

AWS 没有在官方稿里给出具体的延迟数字，但根据 BigDATAwire 的拆解与第三方实测，可以列几个工程权衡：

适合的 workload

单查询扫描 GB 到 TB 级别 Parquet，单次延迟从秒级到分钟级；这种工作负载过去要走 Athena / Redshift，现在一条 PG SQL 就能完成。
跨 Aurora 事务表 + Iceberg 历史的 JOIN，比如"近 30 天交易 + 历年历史归档"。
偶尔的 ad-hoc 数据探索，分析师不需要开新 BI 工具就能在熟悉的 PG 客户端里查到湖数据。

不适合的 workload

单条 SQL 扫描 PB 级 Iceberg：嵌入式 DuckDB 的内存上限就是 Aurora 计算节点的内存，超大规模分析仍然是 Athena / Redshift 的领域。
需要复杂物化视图 / 持续增量同步的场景：跨源查询是 query-time 计算，不是 ingest-time 物化，长时间窗口分析仍需要把数据搬进 Redshift / Snowflake。
强一致事务跨源：Aurora 事务保证只在 PG 引擎内部，Iceberg 端的"读时一致性"取决于 Iceberg 自身的快照机制，DuckDB 不会为它补 Aurora 级的事务保证。

AWS 的应对策略也很直接：官方建议"如果延迟需求是单位毫秒级、或者访问频次非常高，把湖数据物化进 Aurora 原生表"。这句话等于承认：跨源查询是一条低成本、高灵活性的链路，但还不是高性能、高吞吐的链路。

六、与 Snowflake / Databricks / BigQuery 的对照

把 Aurora 这条新能力和三个云数仓 / 湖仓旗舰产品放在一起：

Snowflake：仍然是云数仓的事实标准，跨云共享数据 + 强治理，但需要把数据 ingest 进 Snowflake；与 Aurora 的"按需跨源"是两种不同的成本/治理权衡。
Databricks Lakehouse：Lakebase 把 Postgres 当作 Lakehouse 的"操作层"，Lakebase Search 把 pgvector / BM25 也拉进 Postgres；与 Aurora 走的是"Postgres-first"路线，但 Lakebase 是 Databricks 自家的 Postgres 服务，Aurora 是 AWS 自家的 Postgres 服务。
Google BigQuery + AlloyDB：BigQuery 负责分析、AlloyDB 负责事务，两者通过 BigQuery Omni / 外部表交互；AlloyDB 还没有"DuckDB 嵌入式跨源查询"这种能力，但路线图上明显在往这个方向走。

也就是说，AWS 这条新能力不是一个新物种，而是把"湖仓一体化"这个已经被 Databricks / Snowflake 反复验证的产品形态，用"嵌入式分析引擎"的方式在 Aurora 上做了一遍。它的真正意义在于：AWS 把 Aurora 的工作负载边界从"事务库"扩展到"事务 + ad-hoc 湖查询"，并且是用一种对在线事务库最友好的方式实现的。

七、对国产数据库的启示

对 OceanBase / PolarDB / GaussDB / 达梦 / openGauss 等正在做 HTAP 的国产数据库，这件事件至少有四个可借鉴的工程方向：

方向一：把"内核一体化 HTAP"和"嵌入式分析扩展 HTAP"分开看。 OceanBase 的列存副本、TiDB 的 TiFlash 都是内核一体化方案，对外提供完整 SQL 能力。代价是工程复杂度高、版本节奏被拖慢。嵌入式 DuckDB 方案则是"主内核做 TP，分析引擎做 AP，两者共享解析层和优化器提示"。后者工程量小一个量级，且可以独立升级。

方向二：扩展机制（PG）/ 插件机制（MySQL Fork）是国产数据库必须补齐的能力。 Aurora 这条功能落地的工程基础是 PG 的扩展机制与 FDW 框架。国产数据库里只有 openGauss / GaussDB / 部分 PG Fork 把这条路径打通过，其它体系（如 MySQL 系）需要从零设计插件机制。

方向三：把 Iceberg / Parquet 当作"事实上的开放湖存储"。 2026 年的云数仓 / 湖仓竞争已经把 Iceberg 当成共同底座。国产数据库如果不能原生读 Iceberg，未来 12 个月会在政企客户的湖仓项目里失去入场券。

方向四：嵌入式分析引擎作为可选组件库。 DuckDB 在过去两年已经证明了"嵌入式分析引擎 + 任意事务库"是一条稳定可复制的路径。国产数据库可以参考 duckdb-as-a-library 的做法，把它当作一个可选扩展提供给客户，而不是自己重新造一个列存执行器。

八、给技术人的结论

Aurora PostgreSQL 这次的更新不是一个孤立的功能。它和 ClickHouse OneLake、Databricks Lakebase、Cockroach Continuum、pgEdge Starfleet 一起，构成了 2026 年下半年数据库行业的一条主线：数据库的 workload 边界正在被反复扩展，原来的 TP / AP / Search / Vector 分工正在被"一个主内核 + 一组嵌入式扩展"重新定义。

对国产数据库团队来说，这意味着两个动作必须并行：

在内核侧继续推进 HTAP / 向量化 / 资源隔离等硬功夫；
在扩展侧尽快补齐 Iceberg 原生读、向量 / 全文检索、可插拔分析引擎这些"短期能落地、长期是护城河"的能力。

对个人 DBA / 数据工程师来说，这意味着评估"我的数据库选型是否还能扛 12 个月"时，要把"跨源查询 / 嵌入式分析 / agent-native 多租户"这几个新维度纳入决策表——它们很可能比你过去关注的 query per second 更影响未来的 TCO。

参考链接

最后修改时间：2026-10-08 18:08:11

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者