AWS 宣布，Amazon Aurora PostgreSQL 现在支持直接查询数据湖中存储的 Apache Iceberg 和 Apache Parquet 数据，并将其与 Amazon Aurora PostgreSQL 内的运营数据结合。借助这项新能力，应用程序可以使用 PostgreSQL 语法和现有工具，在单个查询中整合最新记录与历史数据，无需通过 ETL 流程将数据复制到数据库中。
实际发生了什么变化？
该功能基于直接嵌入 Aurora PostgreSQL 的 DuckDB 引擎。因此，单个查询可以读取运营数据（包括尚未提交的写入），也可以从 Amazon S3 读取 Iceberg 表或 Parquet 文件。AWS Glue Data Catalog、Amazon S3 和 S3 Tables 均受支持；此外，还可以通过 Glue 中的 federation 机制支持兼容 Iceberg REST Catalog 的 Catalog。
用户需要创建 Aurora PostgreSQL 集群，附加包含 AuroraAnalytics 功能的 IAM 角色，然后启用 aurora_analytics 扩展。之后，可以创建指向外部数据的 foreign tables，或使用 IMPORT FOREIGN SCHEMA，根据元数据推断数据模式并自动创建多个表。
为什么这条消息很重要？
过去，需要将 Aurora 中的最新事务与 S3 中的历史记录结合起来的应用通常必须通过 reverse ETL 复制数据，这会增加同步操作、运营成本和工程复杂性。现在，这种整合可以在查询过程中完成。这对于需要历史背景的仪表板、将事务与既往记录关联起来的应用，以及处理分布在运营数据库和数据湖中的数据的系统都很有帮助。
对于使用人工智能代理的应用，这一点尤其重要，因为很难预先预测代理可能需要哪些数据集，并将其复制到运营数据库中。直接访问可以扩大可用数据的范围，而无需针对每种使用场景创建副本。
性能与访问选项
Aurora 会应用将过滤条件下推至数据源、减少读取列数等优化，同时还会将频繁使用的数据临时存储在 Aurora 实例中。可以通过 aurora_analytics_stat_statements() 函数检查每个查询的行为，该函数会显示包括扫描行数、从 S3 读取的数据量以及缓存命中次数在内的指标。
这些查询可在集群内的不同 Aurora 实例上执行，包括写入实例和专用只读副本，从而可以将分析扫描操作分配到远离运营负载的位置。对于需要亚毫秒级响应时间的场景，则可以使用 CREATE TABLE AS SELECT、INSERT INTO ... SELECT 或 MERGE INTO 将数据具体化到原生 Aurora 表中。由具体化产生的写入操作会在写入实例上执行。
可用性与成本
该能力支持 Aurora PostgreSQL 17（从 17.11 开始）和 18（从 18.6 开始）。它在所有 AWS 商业区域以及 AWS GovCloud（US）区域均可用，该功能本身不收取额外费用。成本仍与查询消耗的 Aurora 计算资源增加量相关，此外还包括读取数据湖文件时产生的 Amazon S3 请求费用。
certi.news 解读：核心变化并不是增加一种新的存储格式，而是缩短运营数据库与数据湖之间的距离。不过，这并不会消除工作负载设计方面的考量：直接查询适合灵活访问数据，而当极低响应时间是优先事项时，仍然需要进行具体化。此外，Aurora 计算资源和 S3 请求的消耗仍将是需要根据查询模式和数据量进行衡量的因素。