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 美元，5 小时完成。第一位花费 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。 
• 联系你的客户团队：他们可以帮助你针对具体工作负载建模成本影响。