AWS 宣布 Aurora PostgreSQL 可以直接查询数据湖里的 Apache Iceberg 和 Parquet 数据，中间不需要 ETL 管道。实现方式是在 Postgres 服务器内嵌入 DuckDB，分析型扫描走列式引擎，业务数据由 Aurora 自己服务，两者可以在同一条查询里协作。开启方式是 CREATE EXTENSION aurora_analytics。
这解决了什么问题
传统架构里，业务库和分析库是两套系统，中间靠 ETL 或 CDC 同步。这套架构的代价不只是同步延迟，还有一份需要维护的管道代码、一套需要监控的任务、以及两边数据不一致时的排查成本。
能直接查询之后，一部分分析需求可以就地完成，不必先把数据搬一遍。
适用场景
先看清楚它适合什么：
临时性分析、探索性查询、需要跟业务表做关联的分析——这些场景价值最大。原本要把湖里的数据导进库里再 join，现在直接 join。
对账和校验类任务也合适：拿湖里的历史数据和库里的当前状态比对。
不适合的场景
高频的、固定模式的、对延迟有严格要求的报表查询，还是应该走专门的分析引擎或物化结果。每次查询都要扫列式文件，成本模型跟查本地表不一样。
超大规模的全表扫描同理，直接扫湖的代价可能高于先做一轮聚合。
实践建议
第一，先量化。用 EXPLAIN ANALYZE 看清楚扫描量、下推条件和实际耗时，别凭感觉判断快还是慢。
第二，注意统计信息。查询优化器对外部数据的了解程度直接影响计划质量，如果计划选得差，考虑用物化视图固化中间结果。
第三，权限要单独理清楚。能查业务库不等于能查湖，两套访问控制在同一个 SQL 入口下容易混淆。
第四，成本可观测。跨服务扫描通常有独立的计费项，上线前把计量方式搞清楚，避免月底账单意外。
架构上的意义
这类能力的方向是消除「数据在哪里」这个约束。当查询层不再关心数据存在湖里还是库里，很多为了搬运数据而存在的管道就可以删掉了。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。