主要观点：曾使用“批量加载到 RDS”模式，随着平台扩展，该模式出现诸多问题，如数据延迟、运营开销大、成本上升、数据漂移等，最终转向查询源架构，移除中间环节，简化服务层，实现更精益、快速、便宜的数据服务，同时分享了在迁移过程中的经验和优化技巧。

关键信息：

• 旧模式：从数据湖（如 Snowflake 或 Delta Lake）通过 AWS Glue 转换数据后加载到 RDS，RDS 为 Lambda API 提供数据，后出现问题。
• 新模式：UI 通过 API（AWS Lambda）直接查询 Databricks SQL 从数据湖/Snowflake 获取数据，移除 RDS 层和 ETL 周期，简化服务层。
• 关键组件：前端（交互式仪表盘）、API 层（基于 AWS Lambda 的无状态 REST API）、查询引擎（受 Unity Catalog 管理的 Databricks SQL 端点）、数据源（精心策划的 Delta 表和联邦数据）。
• 优化技巧：结果缓存、服务器端端点自动扩展、分区和 Z 排序、API 防护栏、预聚合表等。

重要细节：

• 旧模式中每晚 AWS Glue 作业从 Snowflake 和 Delta Lake 填充 RDS 表，API 为仪表盘和应用提供服务，后出现作业时间长、成本高、维护困难等问题。
• 新模式中 Lambda 通过令牌认证安全建立 JDBC 会话，API 将请求转换为参数化 SQL 查询，Databricks SQL 实时执行查询并直接将结果返回客户端，移除了中间环节和固定基础设施。
• 迁移后基础设施成本降低近 70%，每周减少 4 - 6 小时维护和监控工作，消除夜间批处理窗口，数据新鲜度接近实时，简化为 AWS Lambda 和 Databricks SQL 两个组件。
• 遇到的挑战如大未优化数据集查询慢、高并发导致排队、Lambda 冷启动增加 JDBC 连接开销等，以及相应的优化措施如结果缓存、分区排序等。