Databricks 推出 Lakehouse//RT，面向智能体实时分析负载。

AI 代理正在推动数据仓库的极限。人类分析师可能在下午运行几十个查询。一个代理每秒可以运行数百个查询，全天候运行。随着对客户界面仪表板等用例的需求不断增长，这些仪表板以毫秒为单位刷新，以及嵌入分析的应用程序，实时工作负载正迅速成为企业使用数据的标准部分。

大多数数据仓库是为人类规模的查询量设计的，而不是代理产生的持续并发量。即使仓库能够提供低延迟，费用也会随着需求的增长而快速增长：10倍的查询量可能意味着10倍的费用。

我们构建了 Lakehouse//RT 不仅是为了直接在 lakehouse 上服务实时工作负载，而且是为了在不以与查询相同的速率增加您成本的情况下这样做。

为什么实时分析在 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. 当你需要更多容量时，你只需添加你所需要的

随着流量增长，每个仓库最终都需要更多容量。重要的是每个步骤的大小。

传统仓库通常通过启动整个副本来扩展。在一个大型仓库上，那就是另一个大型仓库的启动。虽然集群级别的扩展对于稳定的分析工作负载效果很好，但实时需求更加波动。当突发需求只需要集群的一小部分时，添加整个集群意味着在突发过去之前为未使用的容量付费。

Lakehouse//RT 可以灵活地添加容量，甚至可以一次添加一个节点，无论你选择哪种‘T恤’尺寸。实时需求很少以集群大小的块出现。代理流量的激增可能只需要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，CTO，Aurasell

VisionHeight: 90%+ 成本降低，三天内投入生产

VisionHeight 是一个攻击前智能平台，它实时映射公网上对手的基础设施。他们之前的实时层运行在 Apache Pinot 上，由始终开启的 EC2 集群 24/7 运行。切换到 Lakehouse//RT 的无服务器模型后，VisionHeight 的成本降低了 90% 以上。在他们的最大查询中，Lakehouse//RT 提供了亚秒级的响应时间，比 Pinot 快近 3 倍。整个迁移只用了三天。

“一旦我们有了 Lakehouse//RT，它就非常快。不需要提取数据，不需要维护基础设施，成本降低了约 90%。现在所有的事情都在 Databricks 中运行。” – Nitsan Daniel，CTO 和联合创始人，VisionHeight

阅读完整案例研究。

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

nOps 为数百名客户管理超过 50 亿美元的年度云支出，为企业在实时仪表板上跟踪资金去向提供动力。他们的实时查询层以前运行在 Apache Druid 上，需要一个独立的始终开启的集群和从他们的湖屋同步的 40TB 重复数据。迁移到 Lakehouse//RT 后，nOps 将基础设施成本降低了 6 倍以上，同时完全消除了重复数据。由于 Lakehouse//RT 直接查询数据存储位置，因此迁移无需数据复制、无需新的摄取管道、无需新的基础设施。

“任何人都会知道，试图将超过 380TB 的数据转移到不同的平台是一场噩梦，而且很昂贵。有了 Lakehouse//RT，我们获得了实时功能，而无需对底层数据进行任何更改。” – Jordan Stein，工程总监，nOps

阅读完整案例研究。

底线

人工智能和用户需求的浪潮不是将要到来的；它已经在这里。查询量将按数量级增长。问题不是你是否负担得起实时性能。问题是你是否负担得起没有为规模效率而构建的系统。

Lakehouse//RT 为您提供：

• 满足实时分析需求的性能 具有亚 100ms 的延迟和成千上万的并发 QPS，用于受管理的湖屋数据
• 成本增长慢于查询量因为每个查询使用的计算量更少，容量以小步骤增加
• 无需购买、同步或维护的单独基础设施与使用单独的实时服务层相比，客户的基础设施总成本降低了 6 到 10 倍

开始使用

Lakehouse//RT今日开始提供 Beta 版。创建一个新的 Lakehouse//RT 仓库，并开始测试您最苛刻的实时工作负载。

• 启用 Lakehouse//RT: 学习 如何开始使用 Lakehouse//RT
• 查看定价: 截至 2027 年 1 月，可享 30% 折扣。
• 联系您的客户团队: 他们可以帮助您为特定工作负载建模成本影响。