Lakehouse//RT：AI Agent 时代的实时分析如何避免成本随查询量暴涨

AI 智能体正在挑战数据仓库的极限。人类分析师可能在一个下午运行几十个查询。而智能体可以全天候每秒运行数百个查询。随着对面向客户的仪表板（毫秒级刷新）和嵌入分析应用等用例的需求不断增长，实时工作负载正迅速成为企业使用数据的标准组成部分。

大多数数据仓库是为人类规模的查询量设计的，而不是智能体产生的持续并发量。即使仓库能够提供低延迟，账单也会随着需求一样快速增长：查询量增加 10 倍很可能意味着成本增加 10 倍。

我们构建了 Lakehouse//RT，不仅是为了直接在 湖仓 上服务实时工作负载，而且是为了在不使成本随查询量同比例增长的情况下做到这一点。

为什么实时分析在 Lakehouse//RT 上具有成本效益？

大多数数据仓库的容量随需求同步扩展：查询越多，计算越多，成本越高。这对许多分析工作负载来说效果很好，因为查询量跟提问人数相关。实时工作负载则不同。当 AI 智能体和数千名并发用户都需要毫秒级答案时，查询量的增长可能远远超过人员数量的增长，成本也随之增长。

实时工作负载通常还具有突发性。处理这种情况的通常做法是过度配置：以大批量增加容量并保持运行，以便在峰值时维持延迟。结果是一天中大部分时间你都在为闲置计算付费。

Lakehouse//RT 扭转了这一局面。它不随需求扩展成本，而是扩展效率。其引擎的架构设计能够在相同资源上服务多得多的查询，因此当需求翻倍（或增长十倍）时，你的基础设施能够跟上，而支出不会成比例飙升。

Lakehouse//RT 通过在四个方面采取不同方法来实现这一点：

1. 高并发支持，让更多查询共享相同资源
2. 更快的执行，让每个查询占用计算的时间更短
3. 以小增量自动扩缩容，让容量紧密跟随需求，而非以整集群为步长跳跃
4. 一个系统而非多个系统，让你不再为重复的基础设施和保持系统同步的工作付费

企业将无法在支出上超越需求曲线。唯一可持续的路径是采用一个在单位计算量上做更多事的系统。

1. 更高的并发让每个仓库服务更多查询

并发通常是实时成本增长最快的地方。传统仓库一次只能运行这么多查询；其余查询排队等待或触发更多容量。服务数百个智能体意味着要运行多个集群才能保持响应时间稳定。即使这些查询大多数是不需要强大算力的小型查找，情况也是如此。

Lakehouse//RT 的设计目标是在每个仓库上并行运行多得多的查询。在我们的 发布博客 中，我们分享了可以在每秒 12,000 次查询下提供低于 100 毫秒的延迟，而且我们只会越来越好。

每个查询也能快速完成，因此容量能更快释放给下一个查询。相同的峰值只需少得多的计算即可容纳，而智能体仍能在毫秒内获得答案。

客户正在真实工作负载中体验到这一点。Aurasell 从每秒 200 次查询的多个集群迁移到一个小型 Lakehouse//RT 仓库，后者持续承载超过 250 QPS，查询执行速度提升 4-5 倍，同时成本降低 10 倍。

继续阅读更多客户成功案例！

2. 更快的查询使用更少的计算

假设你雇了一个承包商。一个每小时收费 20 美元，需要 10 小时。另一个每小时收费 22 美元，五小时完成。第一个花费 200 美元，第二个花费 110 美元。你为完成的工作付费，而不是为小时付费。

计算也是同样的道理：你的账单是费率乘以运行时间。Lakehouse//RT 旨在快速完成实时查询，包括执行周围的步骤，如规划、路由和返回结果。每个查询占用计算的时间更短。每天数百万次智能体查询累积起来，效果显著。

3. 当你需要更多容量时，只添加你需要的量

每个仓库最终都会随着流量增长而需要更多容量。重要的是每一步的粒度大小。

传统仓库通常通过启动自身的完整副本来扩展。在 Large 仓库上，就是再启动一个 Large 仓库。虽然集群级扩展对稳定的分析工作负载很有效，但实时需求更具突发性。当突发只需要一个集群的一小部分时，添加整个集群意味着为突发过去前未使用的容量付费。

Lakehouse//RT 可以灵活地添加容量，甚至可以一次添加一个节点，无论你选择哪种规格大小。实时需求很少以集群大小的块到来。智能体流量的激增可能只需要多 10% 的容量，而不是 100%，Lakehouse//RT 可以添加那样大小的步长，而不是翻倍。

以小步长扩展而不损害延迟说起来容易做起来难。这正是 Lakehouse//RT 的设计目标，它让容量与需求同步增长，而不是超前于需求。

4. 一个系统消除重复的基础设施

实时过去意味着在仓库上附加一个单独的服务层，例如 Apache Druid、Apache Pinot 或缓存。这意味着常开的基础设施、数据的第二份副本、同步管道，以及保持一切一致的工程师。

Lakehouse//RT 直接查询受治理的湖仓数据，因此随着数据量增长，不会有一个第二套栈随之增长。

客户正在看到什么

Aurasell：成本效率提升 10 倍，查询速度最高提升 5 倍

Aurasell 的 AI 原生市场进入平台运行着各类智能体，全天候进行潜在客户挖掘、管理销售管道并辅导销售代表。这些智能体工作流依赖高查询吞吐量，而 Aurasell 希望在不将数据移动或索引到外部系统的情况下获得实时性能。借助 Lakehouse//RT，该团队通过单个小型集群直接在 Databricks 中服务该工作负载。

"高查询吞吐量对 Aurasell 的智能体工作流至关重要。在采用 Lakehouse//RT 之前，要达到每秒 200 次查询，我们需要启动多个独立集群，这增加了复杂性。借助 Lakehouse//RT，单个小型集群即可轻松持续承载超过 250 QPS，同时执行查询的速度提升 4-5 倍。除了通过整合集群实现基础设施和成本效率 10 倍的提升之外，最大的收益是架构上的简化；我们无需将数据移动或索引到外部系统，就能直接在 Databricks 中获得所需的实时性能。"——Srinivas Bandi，Aurasell 首席技术官

VisionHeight：成本降低 90% 以上，三天内投入生产

VisionHeight 是一个攻击前情报平台，可实时映射公共互联网上的对手基础设施。其此前的实时层运行在 Apache Pinot 上，使用 24/7 全天候运行的始终在线 EC2 集群。在切换到 Lakehouse//RT 的无服务器模式后，VisionHeight 的成本降低了 90% 以上。在其负载最重的查询上，Lakehouse//RT 提供了亚秒级响应时间，比 Pinot 快近 3 倍。整个迁移仅耗时三天。

"我们启用 Lakehouse//RT 后，它非常快。无需提取数据，无需维护基础设施，成本降低了约 90%。现在这一切都能在 Databricks 中直接运行。"——Nitsan Daniel，VisionHeight 首席技术官兼联合创始人

阅读完整案例研究。

nOps：基础设施成本降低 6 倍，消除 40TB 重复数据

nOps 为数百家客户管理着超过 50 亿美元的年度云支出，支撑着企业实时跟踪资金流向的实时仪表板。其此前的实时查询层运行在 Apache Druid 上，需要单独的始终在线集群以及从数据湖仓同步的 40TB 重复数据。迁移到 Lakehouse//RT 后，nOps 将基础设施成本降低了 6 倍以上，同时完全消除了重复数据。由于 Lakehouse//RT 直接在数据所在位置查询数据，此次迁移无需复制数据、无需新的数据摄取管道，也无需新的基础设施。

"任何人都知道，尝试将超过 380TB 的数据迁移到不同平台是一场噩梦，而且成本高昂。借助 Lakehouse//RT，我们获得了实时能力，且无需对底层数据做任何更改。"——Jordan Stein，nOps 工程总监

阅读完整案例研究。

结论

AI 和用户需求的浪潮不是即将到来，而是已经到来。查询量将呈指数级增长。问题不在于你能否负担实时性能，而在于你是否负担得起不去采用一个为规模化效率而构建的系统。

Lakehouse//RT 为你提供：

• 满足实时分析需求的性能在受治理的数据湖仓数据上实现低于 100ms 的延迟和数千并发 QPS
• 增长速度慢于查询量的账单因为每次查询使用的计算更少，并且容量以小步幅增加
• 无独立基础设施无需购买、同步或维护；与使用独立的实时服务层相比，客户的总基础设施成本降低了 6 倍至 10 倍

开始使用

Lakehouse//RT现已推出测试版。启动新的 Lakehouse//RT 仓库，开始测试你最严苛的实时工作负载。

• 启用 Lakehouse//RT：了解如何开始使用 Lakehouse//RT
• 查看定价：截至 2027 年 1 月，以30% 折扣试用 Lakehouse//RT。
• 联系你的客户团队：他们可以帮助你针对特定工作负载建模成本影响。