Lakehouse//RT：扩展实时分析规模，而非账单
内容提要
Databricks推出Lakehouse//RT，专为AI代理和实时分析的高并发查询设计，可直接在湖仓上运行，无需复制数据或搭建独立实时层。它通过提升单节点并发、加快查询完成速度、按节点小步扩容，避免成本随查询量同比例增长。Aurasell、VisionHeight和nOps等客户报告查询提速、成本大幅下降且架构简化。
延伸解读
实时分析的成本结构正在改变
文章指出，传统数仓按查询量线性扩容，AI代理带来的高并发会让成本同比例飙升。Lakehouse//RT 通过提升单节点并发和查询完成速度，让成本增长慢于查询量增长。这提示读者：评估实时分析方案时，不能只看单价，更要看单位计算能支撑多少查询，以及扩容粒度是否匹配波峰需求。
小步扩容比整集群扩容更贴合实时负载
实时负载往往突发且不均匀，传统按整集群扩容容易为闲置容量付费。Lakehouse//RT 支持按节点小步增加容量，避免一次性翻倍。对读者而言，这意味着在选型时应关注系统能否细粒度伸缩，以及扩容时是否影响延迟，而非仅看峰值吞吐指标。
去掉独立实时层可简化架构但需评估迁移
文章以 Aurasell、VisionHeight 和 nOps 为例，说明直接在湖仓上运行实时查询可避免数据复制、同步管道和额外运维。VisionHeight 迁移仅用三天，nOps 消除了 40TB 重复数据。但读者需注意，这些是客户自述案例，实际迁移成本取决于现有数据布局和查询模式，应结合自身情况验证。
Q&A
Lakehouse//RT 是什么？它主要解决什么问题？
Lakehouse//RT 是 Databricks 推出的实时分析引擎，专为 AI 代理和实时分析的高并发查询设计，可直接在湖仓上运行，无需复制数据或搭建独立实时层。它解决的是传统数据仓库在面临 AI 代理产生的高查询量时，成本随查询量同比例增长的问题。
为什么传统数据仓库难以应对 AI 代理带来的实时查询负载？
传统数据仓库按人类查询量设计，而 AI 代理可每秒运行数百次查询，且实时工作负载常呈尖峰式。传统仓库通常以集群为单位扩容，导致过度配置和闲置计算，成本随查询量线性增长。
Lakehouse//RT 如何避免成本随查询量同比例增长？
Lakehouse//RT 通过提升单节点并发能力、加快查询完成速度（包括规划、路由和返回结果等步骤）、以及按节点小步扩容来实现。这样在需求翻倍或增长十倍时，基础设施能跟上而无需比例性增加支出。
Lakehouse//RT 在并发和延迟方面有哪些具体性能数据？
根据发布博客，Lakehouse//RT 能在每秒 12,000 次查询下提供低于 100 毫秒的延迟，并且性能还在持续提升。
有哪些客户案例可以说明 Lakehouse//RT 的实际效果？
Aurasell 从多个集群（200 QPS）迁移到单个小型 Lakehouse//RT 仓库（超过 250 QPS），查询速度提升 4-5 倍，成本降低 10 倍；VisionHeight 从 Apache Pinot 迁移后成本降低超过 90%，查询速度提升近 3 倍，迁移仅用 3 天；nOps 从 Apache Druid 迁移后基础设施成本降低 6 倍以上，并消除了 40TB 的重复数据。
与传统的实时层（如 Apache Druid、Apache Pinot）相比，Lakehouse//RT 在架构上有何优势？
传统实时层需要始终在线的独立基础设施、数据第二副本、同步管道和运维工程师。Lakehouse//RT 直接查询湖仓中受治理的数据，无需复制数据或构建独立实时层，从而简化架构并避免第二套技术栈随数据量增长而扩张。
Lakehouse//RT 目前是否可用？如何开始使用？
Lakehouse//RT 目前处于 beta 阶段，用户可创建新的 Lakehouse//RT 仓库并开始测试最苛刻的实时工作负载。
