零ETL打通“实时业务库”与“历史数据湖”

AWS宣布，Amazon Aurora PostgreSQL现在允许用户直接使用现有的 PostgreSQL应用程序和工具，查询存储在数据湖中、以Apache Iceberg和 Apache Parquet格式保存的数据。

这意味着企业不必再把数据从数据湖提取、转换并加载（ETL）到运营数据库，就能让业务系统直接访问湖中的历史与分析数据，从而显著降低运营复杂性、简化应用开发。

更进一步，用户还可以通过 Aurora PostgreSQL查询由Iceberg REST Catalog（IRC）兼容目录所管理的数据湖数据，实现跨多种分析系统的数据访问，而无需移动或复制数据。

AWS对此的描述是：“无论你是驱动实时仪表盘、用历史上下文丰富交易，还是构建能够同时推理实时和归档数据的 AI 代理，现在你都可以通过一个熟悉的界面完成这一切。”

这项能力背后还有一个重要变化：维护DuckDB项目的团队DuckLabs已加入亚马逊，DuckDB 被直接嵌入Aurora PostgreSQL。因此，用户可以在一次查询中同时查询数据湖与实时操作数据，甚至包括尚未提交的写入；查询处理完全限制在Aurora内部，没有额外的网络跳转，也不需要重复数据的 ETL 管道。

该功能支持 Aurora PostgreSQL的两个主要版本：17（从 17.11 开始）和 18（从 18.6 开始）。目前已在所有商业AWS区域以及 AWS GovCloud（美国）区域上线，功能本身免费；用户只需为查询所消耗的增量Aurora计算资源，以及从 Amazon S3 读取数据湖文件所产生的请求费用付费。

1.认识 Amazon Aurora PostgreSQL：处于业务核心的云原生数据库

要理解这条新闻的分量，首先要看Aurora PostgreSQL在企业中的角色。它是 AWS 推出的云原生关系型数据库，完全兼容PostgreSQL，同时具备商业级数据库所需的高性能、高可用和弹性扩展能力。由于保留了PostgreSQL的语法、驱动和生态，开发者可以用熟悉的方式快速构建应用；而作为托管服务，它又提供了自动备份、故障恢复、只读副本和近乎无限的存储扩展，让企业从繁重的数据库运维中解放出来。

正因为这些特性，Aurora PostgreSQL被广泛应用于互联网、金融、零售、游戏、SaaS 和政企等关键场景，支撑着高并发的交易系统、用户中心、订单管理、库存与计费等核心业务。

换句话说，它存放的往往是企业最“热”、最实时的那部分数据——当下的订单、此刻的账户状态、刚刚发生的用户行为。谁能让外部沉淀的数据与这些实时业务数据低成本地放在一起分析，谁就能更快做出决策。

2.数据湖中的Apache Iceberg与Parquet：现代数据分析的开放基石

随着数据量持续爆发，企业普遍采用数据湖来集中保存海量原始数据与加工后的数据。数据湖通常构建在对象存储（如 Amazon S3）之上，以极低成本容纳结构化、半结构化和非结构化数据。而在数据湖中，Apache Parquet 与 Apache Iceberg 是两个几乎不可或缺的标准。

Apache Parquet是一种列式存储文件格式，拥有极高的压缩比和优秀的分析查询性能，被Spark、Hive、Presto、Trino、Flink以及DuckDB等几乎所有主流分析引擎原生支持，是数据湖中事实上的存储格式。企业沉淀的历史日志、交易明细、用户行为等，大量都以 Parquet 文件保存在湖里。

Apache Iceberg则是一种开放表格式，它在 Parquet 等底层文件之上提供完整的表语义：支持 ACID 事务、schema演进、隐藏分区、时间旅行以及并发写入，解决了传统 Hive 表在大规模数据场景下的可靠性、一致性与管理难题。

如今，Iceberg已成为 Databricks、Snowflake、Trino、Flink以及众多企业湖仓平台争相支持的核心表格式，是构建开放、可互操作“湖仓（Lakehouse）”的关键标准。可以说，谁掌握了Iceberg 与 Parquet的访问能力，谁就能触达企业绝大部分沉淀在数据湖中的长期资产。

3.直接查询的优势：从“数据搬家”走向“数据就近计算”

亚马逊此次推出的能力，最大价值在于用“零 ETL”的方式，把运营数据库与数据湖缝合在一起。

在过往架构中，如果PostgreSQL应用想使用数据湖里的Iceberg或Parquet 数据，必须先通过ETL管道把数据抽取、清洗并写入Aurora。这不仅带来同步延迟，还要维护复杂的调度任务、存储多份数据副本，并承担数据不一致和管道故障的风险。而现在，Aurora PostgreSQL借助内嵌的DuckDB引擎，可以直接在数据库内部读取S3上的 Iceberg与Parquet文件；查询处理完全在Aurora 内部完成，既没有额外的网络跳转，也不需要复制数据。

更关键的是，DuckDB的嵌入让一次查询就能同时关联“实时操作数据”和“历史湖仓数据”，甚至可以读取尚未提交的写入。这把交易系统与分析系统之间的时差压缩到近乎为零，带来几类非常直观的收益。

对实时业务来说，团队可以直接在熟悉的PostgreSQL界面里驱动实时仪表盘，或者把客户的历史行为、归档订单等Iceberg数据用来丰富当前交易上下文，而不必先做数据同步。

对AI应用来说，构建能够同时推理“实时状态”与“归档记忆”的AI代理变得非常简单——代理通过一条SQL，就能同时访问当前的业务记录和沉淀在数据湖中的长期知识。

对数据架构治理来说，通过支持Iceberg REST Catalog兼容目录，企业可以在不移动、不复制数据的前提下，让Aurora与多种分析系统共享同一份Iceberg数据，避免数据孤岛与重复存储。

对成本来说，该功能本身免费开放，用户只为实际消耗的增量Aurora计算与S3 读取请求付费，省去了中间ETL管道的存储与运维开销，整体拥有成本更低。

4.落地方式：广泛可用，且无需改造应用

目前，该能力已在所有商业AWS区域以及 AWS GovCloud（美国）区域提供，覆盖Aurora PostgreSQL 17.11及以上、18.6及以上版本。对于已经使用这些版本的企业而言，落地门槛非常低：继续使用现有的PostgreSQL驱动、ORM框架、BI工具和SQL客户端，就能直接编写查询访问数据湖中的Iceberg与Parquet 数据，不需要重构应用，也不需要学习新的查询语言。

对于那些已经把数据湖建立在S3上、并用Iceberg管理表结构的组织而言，这等于把最广泛的PostgreSQL应用生态，与最主流的开放数据湖格式连接在了一起。

总的来看，Aurora PostgreSQL对Iceberg和Parquet的直接查询，不只是一次功能更新，而是拆掉了“交易库”与“数据湖”之间的墙。它让广泛使用的PostgreSQL应用、无处不在的 Parquet文件，以及正在成为湖仓标准的Iceberg 表，在同一个熟悉的界面里协同工作，既降低了运营复杂性，也让实时业务与历史洞察第一次以如此低的成本被同时唤醒。

在实时分析与 AI 代理需求快速增长的今天，这种“既能看现在、也能看过去”的能力，正是亚马逊云数据库给出的答案。