Databricks攻克数据管道难题，释放智能体潜能

数十年难题的新解法

数十年来，数据专业人员一直致力于在统一管理操作型和分析型数据库的同时，避免引入延迟和性能下降，这始终是一项巨大的挑战。

**智能体**的出现使这一问题变得更具结构性。一个能够持续推理并基于实时数据采取行动的系统，无法容忍自身与所需信息之间存在任何数据管道的阻隔。

在周二举行的Data + AI峰会上，Databricks宣布推出两款旨在精简此类基础设施的产品。Lakehouse//RT可直接在受管控的Delta和Iceberg表上提供毫秒级查询延迟，从而消除了企业在湖仓架构旁长期维护的专用实时服务层。LTAP（湖仓事务/分析处理）则能在写入时将原生Postgres事务数据存储为Delta和Iceberg格式，一举移除了连接操作和分析系统长达数十年的ETL管道。

Databricks联合创始人Reynold Xin在与VentureBeat的简报中，将这种简化的数据架构描述为“**智能体**的圣杯”。他认为，随着用户越来越多地通过代码编写应用，在这些应用之上进行推理分析的**智能体**需要底层基础设施不再成为阻碍，以便快速行动。

“**智能体**确实更喜欢更简单的技术栈，因为它们能以此获得更快的速度，”Xin说道。

LTAP：通过存储层统一挑战HTAP的引擎融合

几十年来，许多供应商尝试过各种方法来统一分析和事务数据。

早在2014年，分析机构Gartner就创造了HTAP（混合事务/分析处理）一词，用来描述那些试图统一两类数据库的厂商。SingleStore（原名MemSQL）、SAP HANA以及Oracle的MySQL Heatwave等都是市场中的HTAP代表厂商。

LTAP是Databricks对HTAP的回应，它利用Lakebase架构在存储层而非引擎层统一数据。Lakebase是Databricks基于云的无服务器PostgreSQL数据库服务，已于今年2月正式发布。

“对我们来说，HTAP更多是行业的一种失败，而非成功，”Xin评价道。

LTAP直接作用于存储层而非查询层。此前，Lakebase以Postgres格式将数据存储在对象存储上，湖仓分析引擎在使用前需进行转换。而在LTAP模式下，事务数据直接以Delta或Iceberg格式落地，与分析工作负载共享同一份数据副本。Postgres继续作为事务引擎，Spark和湖仓则作为分析引擎。

“核心在于，你在查询引擎层面使用最佳工具，我们只需确保底层数据只有一份，”Xin解释道。

核心工程挑战在于延迟。对象存储的响应时间以秒计，这对于需要亚毫秒级性能的OLTP工作负载来说太慢了。Lakebase通过在Postgres计算实例和对象存储之间设置缓存层来处理这一问题。关键的设计决策在于列转换的位置：利用缓存层空闲的CPU容量，在数据落入对象存储之前完成行到列的转换。

“当数据从行式转换为列式时，通常压缩率会超过10倍，这极大地降低了缓存层与对象存储之间的网络成本，”Xin补充道。

Lakehouse//RT：无需独立服务层即可实现毫秒级查询

Lakehouse//RT是Databricks对专用实时服务层的回应。企业通常在湖仓架构旁维护这一独立系统以处理低延迟查询，但这带来了数据副本、治理分离和管道复杂性问题，而**智能体**无法绕过这些问题。Lakehouse//RT的主要能力包括：

Reyden计算引擎：专为高并发、低延迟服务构建，可直接查询Delta和Iceberg表，无需将数据移出湖仓。
延迟与吞吐量：Lakehouse//RT在每秒12,000次查询下可实现亚100毫秒的延迟，小数据集响应时间低至10毫秒，性能比现有专用服务栈高出16倍。
治理与数据访问：所有查询均在Unity Catalog治理框架内运行，无需单独的权限层、数据副本或摄取管道。