AWS Aurora PostgreSQL 为 Iceberg 和 Parquet 数据湖添加了直接查询功能。

主页 » SQL » PostgreSQL的 » AWS Aurora PostgreSQL 为 Iceberg 和 Parquet 数据湖添加了直接查询功能。

亚马逊云服务 (AWS) 为需要将日常应用程序记录与数据湖中的文件混合使用的Aurora PostgreSQL集群开辟了一条新途径。现在，该托管数据库无需先将 Apache Iceberg 表和 Apache Parquet 文件复制到 Aurora 即可读取它们，因此一条 SQL 语句即可同时处理实时运行的数据行和归档信息。此举旨在帮助那些厌倦了构建和维护 ETL（提取、转换和加载）作业以回答涉及当前数据和历史数据的问题的团队。

该服务并非将数据湖视为一个独立的世界，而是允许现有的 PostgreSQL 客户端、工具和端点通过外部表访问数据湖中的内容。这意味着历史数据集无需在运营数据库中保留重复副本，应用程序开发人员可以继续使用他们熟悉的语法。AWS 将此服务定位为一种减少管道维护、降低基础设施蔓延并简化使用旧上下文丰富事务的方法。

Aurora PostgreSQL 新功能带来了哪些变化

该功能并非客户需要自行部署的独立分析产品。它通过aurora_analytics 扩展程序以及一个 AWS Identity and Access Management 角色启用，该角色授予集群访问 Amazon S3 和 AWS Glue 数据目录的权限。角色和扩展程序部署完成后，管理员即可创建指向 Iceberg 或 Parquet 数据的外部表，并像查询普通 PostgreSQL 表一样查询这些表。

该架构的一个显著特点是将DuckDB 直接嵌入到 Aurora 中。这款开源分析引擎负责扫描 Lakehouse 文件，而 Aurora 则继续处理其他业务工作负载。查询处理在数据库环境内完成，避免了将作业移交给单独的集群，从而有助于控制延迟和网络开销。

支持的数据源包括在 AWS Glue 数据目录中注册的 Iceberg 表、Amazon S3 中的 Parquet 和 Iceberg 对象，以及 S3 表中存储的数据。遵循Iceberg REST Catalog 接口的外部目录也可以通过与 Glue 的联合访问，因此团队无需放弃已有的目录投资。查询可以将 Aurora 中的行与分布在多个目录中的 Iceberg 表连接起来，从而为应用程序提供统一的视图，而无需移动文件。

版本、设置和支持的服务

支持的版本包括 Aurora PostgreSQL 17（版本 17.11 及更高版本）和 Aurora PostgreSQL 18（版本 18.6 及更高版本）。创建或选择集群后，管理员需要将具有AuroraAnalytics 功能的 IAM 角色附加到集群并启用该扩展。此设置可通过 Amazon RDS 控制台或 PostgreSQL 客户端（例如 psql）完成。

可以逐个创建外部表定义，但对于规模较大的环境，可以使用IMPORT FOREIGN SCHEMA一次性从 AWS Glue 数据目录数据库生成多个外部表。对于 Parquet 文件，Aurora 可以从文件元数据中读取架构，无需手动指定每一列。对于拥有庞大或频繁变化的数据集的团队来说，这一细节至关重要。

读取查询可以在写入实例或只读副本上运行，因此分析扫描可以脱离主要运维工作负载。将数据写入 Aurora 的命令（例如 CREATE TABLE AS SELECT、INSERT INTO … SELECT 或 MERGE INTO）在写入实例上运行。这使得团队能够在需要持续快速响应时，将热湖仓数据物化到原生表中。

要查看查询的执行情况，管理员可以调用 `aurora_analytics_stat_statements()` 函数。该函数会报告诸如扫描行数、从Amazon S3 读取的字节数和缓存命中数等指标。常用数据会缓存在 Aurora 实例上，因此重复访问相同的 Lakehouse 对象可以更快地返回结果，而无需重复从对象存储中读取相同的字节。

性能、缓存和低延迟路径

Aurora 应用了谓词下推和列剪枝技术，这意味着它只会从数据湖中请求相关的行和列。随着底层数据集的增长，这种过滤机制有助于防止查询变成全表扫描。缓存的结果和查询统计信息为运维人员提供了一种切实可行的方法来调整工作负载，而无需猜测时间都消耗在哪里。

对于那些需要毫秒级延迟的应用，AWS 指出物化是解决之道。选定的数据湖记录可以通过熟悉的 SQL 命令复制到Aurora PostgreSQL 原生表中，之后即可像查询其他本地表一样进行查询。这样既能保证最热门数据的快速访问，又能让整个数据湖用于更广泛的分析。

该公司列举了实时仪表盘、富含历史背景的交易记录以及需要对当前记录和存档记录进行推理的 AI 代理等典型用例。这些用例的共同点在于，工作负载无法等待夜间批处理或反向 ETL 作业。AWS 希望通过允许应用程序向同一个数据库请求新旧信息，来消除管道复杂性中一个反复出现的因素。

供货情况和价格

根据 AWS 的说法，该功能在所有商业 AWS 区域和 AWS GovCloud（美国）区域均可用，且不收取额外费用。客户仍需为查询消耗的额外 Aurora 计算资源以及读取数据湖文件相关的Amazon S3 请求费用付费。这种定价模式降低了入门门槛，但高强度的分析使用仍会在账单中体现出来。

AWS 将此次发布视为其将 DuckDB 高性能融入其托管服务的更广泛计划的一部分。维护 DuckDB 项目的 DuckLabs 团队已加入亚马逊，该公司表示，未来对这款开源引擎的改进可以应用到 Aurora 和其他 AWS 产品中。这种联系表明，此次集成旨在不断发展，而不仅仅是一次性功能。

对于数据库团队而言，这种方案的实际吸引力显而易见：更少的活动部件、更少的数据重复以及更短的从问题到答案的路径。但其代价是，访问控制、IAM 权限和目录配置仍然需要谨慎处理。能够同时访问生产环境行和 Lakehouse 文件的集群构成了一个强大的单一查询接口，因此治理仍然是工作的一部分。

实际效果是 Aurora PostgreSQL 与数据湖之间建立了更紧密的联系。当前事务和历史文件可以通过一条 SQL 查询进行交互，DuckDB 负责处理分析扫描，而物化则在需要时提供快速通道。对于已经投入 PostgreSQL 工具的团队来说，这为分析密集型工作负载提供了另一种选择；而那些对安全性或成本控制要求严格的团队，则需要在广泛部署之前审查权限、缓存行为和 S3 使用情况。