AI智能体正在从根本上改变企业数据架构的需求。一个客服智能体需要实时读取客户订单状态、调用历史交互记录、分析当前上下文，然后做出决策并执行操作。整个过程涉及事务数据的读写和分析数据的查询，但传统数据架构中这两类数据分属不同系统。
几十年来，企业数据架构遵循一个基本模式：运营数据库处理事务，分析平台处理查询，中间用ETL或CDC管道连接。这个模式在人类驱动的时代够用，但在智能体驱动的时代开始崩坏。智能体不像人类。人类可以等待数据同步完成，智能体不能。人类可以接受几分钟的数据延迟，智能体需要毫秒级响应。人类每次查询只消耗少量数据，智能体可能同时发出数千个查询。
这正是Databricks在2026年Data+AI峰会上推出LTAP架构的核心动机。本文将系统解析LTAP的技术原理、与HTAP的本质区别、Lakehouse//RT的性能表现，以及这一架构对AI智能体时代数据基础设施的深远影响。
一、传统数据架构的困境
1.1 OLTP与OLAP的天然割裂
企业数据架构长期存在一个根本性的分裂：事务处理和分析查询使用两套完全不同的系统。
在线事务处理系统负责日常业务运营。订单创建、支付处理、库存更新、用户注册，这些操作需要高并发、低延迟的写入能力，同时保证ACID事务一致性。PostgreSQL、MySQL这类关系型数据库是典型代表。
在线分析处理系统负责大规模数据查询和商业智能。销售趋势分析、用户行为洞察、财务报表生成，这些查询需要扫描海量数据、执行复杂聚合、进行多表关联。数据仓库和湖仓一体平台是典型代表。
这两类系统的技术需求几乎完全相反。OLTP需要行式存储和快速单行访问，OLAP需要列式存储和大范围扫描。OLTP强调事务一致性和写入性能，OLAP强调查询吞吐和读性能。OLTP通常服务于在线用户请求，对延迟极度敏感，OLAP服务于分析师和决策者，对吞吐量更敏感。
为了弥合这个鸿沟，企业不得不部署复杂的数据管道网络。ETL管道将运营数据从事务系统提取、转换后加载到分析系统。CDC管道持续监听事务数据库的变更日志，将新增和修改的数据实时同步到下游。数据副本在多个系统间流转，同一份数据可能在运营数据库、数据仓库、缓存层、搜索索引中存在多个不同版本。
这种架构的代价极其高昂。每一次数据移动都引入延迟，每一个副本都增加存储成本，每一条管道都需要开发和维护。Databricks产品管理副总裁Shanku Niyogi指出，许多组织正在被日益增多的数据同步管道压垮。一家大型银行客户目前维护着数十万个PostgreSQL数据库，每个数据库都有对应的CDC管道将数据回传至数据湖。
1.2 智能体时代的新需求
AI智能体的到来将这种架构推到了崩溃边缘。Databricks联合创始人兼首席执行官Ali Ghodsi在峰会主题演讲中直言：几十年来，复杂的数据基础设施一直是团队被迫承受的负担。随后智能代理应运而生。短短数月内，企业的劳动力实际上翻了一番，只不过这些劳动力并非人类。智能代理编写代码、发起调用并执行循环的速度，是人类团队无法企及的。支撑上一代计算的基础设施，如今已成为无人可承受的瓶颈。
智能体对数据架构提出了三个全新要求。
实时性是第一道门槛。智能体在执行任务时需要即时访问最新数据。如果一个客服智能体查询到的订单状态是五分钟前的快照，它可能给出错误的信息。如果库存智能体看不到最新的库存变动，它可能承诺无法履行的交付时间。传统管道引入的秒级甚至分钟级延迟，对智能体而言是不可接受的。
高并发是第二道门槛。一个智能体在单个任务中可能发出数百次查询，如果一个企业同时运行数十个智能体，查询量可达每秒数千甚至数万次。传统分析系统面向人类分析师设计，并发能力有限。
读写混合是第三道门槛。智能体不仅需要读取历史数据进行分析，还需要将决策结果写回运营系统。它需要在一个流程中同时完成分析和事务两种操作。传统架构中，分析系统只读，事务系统只写，这种明确的分工在智能体场景中变得模糊。
Moor Insights and Strategy首席分析师Michael Leone指出：智能体的行为不像人类，甚至不像我们为人类构建的应用。它们阅读上下文、循环、尝试各种方法，然后写回一些内容，以你无法完全预测的方式重复数千次。在这种规模下，生产系统和分析系统之间的持续来回切换开始成为瓶颈。消除这个差距的压力是真实的，LTAP是解决这个问题的一种方式。
1.3 CDC管道的悖论
CDC变更数据捕获是连接事务和分析系统的传统技术。它通过监听数据库的事务日志，捕获数据的插入、更新和删除事件，将其流式传输到下游系统。
这个技术本身很成熟，但它在智能体时代暴露出根本性矛盾。CDC的本质是异步复制，数据从产生到可查询之间存在时间差。对于批处理报表场景，秒级延迟可以接受。对于智能体场景，任何延迟都可能导致决策错误。
CDC还引入了巨大的运维负担。每一个数据源都需要配置CDC管道，每一条管道都需要监控、排错和维护。当数十个智能体并发运行，模式变更频繁发生时，管道的脆弱性被急剧放大。Databricks产品管理副总裁Shanku Niyogi在采访中直言：我们开玩笑说CDC其实是持续数据污染。每次发生变更，就会新增一条管道。
当开发人员加速迭代时，模式会发生变化，数据管道会中断，而且中断的速度比以前更快。Databricks Lakebase和Neon产品管理总监Brian Clark在采访中解释道。
二、LTAP：一种新的数据架构范式
2.1 LTAP的定义与核心思想
LTAP的全称是Lake Transactional/Analytical Processing，湖式事务分析处理。Databricks将其定义为一种全新的数据架构，旨在将操作型和分析型工作负载统一在数据湖的单一数据副本上。
LTAP的核心思想可以概括为一句话：数据写一次，各取所需。事务型应用继续使用PostgreSQL兼容的接口进行读写，分析型引擎直接从同一份存储中读取数据，无需任何管道或数据复制。
这个思想与过去几十年的架构实践截然不同。传统架构中，数据从产生到可用于分析，需要经过提取、转换、加载等多个步骤，中间涉及多次数据复制和格式转换。LTAP试图消除这些中间步骤，让数据在写入时就同时服务于事务和分析两种工作负载。
2.2 LTAP与HTAP的本质区别
HTAP混合事务分析处理并非新概念。早在2014年，Gartner就提出了这个术语，用来描述能够同时处理事务和分析工作负载的数据库系统。SAP HANA、SingleStore、Oracle MySQL HeatWave等都是HTAP的代表性产品。
那么LTAP和HTAP的区别在哪里。HTAP试图在单个数据库引擎中同时实现事务和分析能力。它的目标是让一个系统同时擅长两种工作负载。但实践中，这种方案往往面临两难困境。优化事务会牺牲分析性能，优化分析会牺牲事务性能。
LTAP采取了完全不同的路径。它不试图在引擎层面统一，而是在存储层面统一。LTAP使用同一个存储层存放数据，但为事务和分析分别使用不同的计算引擎。PostgreSQL引擎处理事务工作负载，Spark和Lakehouse引擎处理分析工作负载。
存算分离使两个引擎可以独立扩展。事务工作负载高峰时，PostgreSQL计算层可以弹性扩容。分析工作负载高峰时，Spark集群可以按需伸缩。两者互不干扰。
开放格式是LTAP的另一个关键设计。事务数据直接以Delta Lake和Apache Iceberg等开放列式格式写入存储层。任何兼容这些格式的引擎都可以直接读取数据，无需转换或复制。
Databricks联合创始人Reynold Xin在采访中解释道：HTAP对我们来说更像是行业的一个失败而非成功案例。LTAP的方式是去存储层而非查询层。关键在于，你在查询引擎层面为每个任务使用最好的工具，我们只是确保底层存储是数据的单一副本。
分析师们也认可这种思路的合理性。Moor Insights and Strategy的Michael Leone指出：HTAP从未真正成功，因为要求一个紧密绑定的系统既擅长事务又擅长分析，通常会让它在两方面都表现平庸，客户最终为这种妥协付出了溢价。我认为存算分离是正确的直觉，这也是现代云数据世界能够运转的根本原因。它之所以重要，是因为让HTAP失败的原因是一个工作负载饿死另一个，而给每一方自己的专用引擎正是防止这种情况发生的方法。
ISG软件研究执行总监David Menninger补充道：HTAP失败的另一个原因是它要求企业用新架构替换现有数据平台。LTAP建立在存算分离这个已经被广泛接受的实践之上，增加一个操作层更像是一种演进而非革命，这降低了采用门槛。
三、LTAP的技术架构
3.1 存储层的统一
LTAP架构的核心是统一存储层。所有数据，无论是来自事务应用还是分析系统，都存储在同一个数据湖中，使用Delta Lake或Apache Iceberg等开放表格式。
这个统一存储层带来几个关键优势。数据只有一份拷贝，没有事务数据库、分析仓库、实时服务层之间的数据复制，存储成本显著降低。治理可以在单一副本上应用。权限、审计、数据血缘在Unity Catalog中统一管理，不会出现多副本之间策略漂移的问题。消除了数据同步延迟。分析查询直接读取事务写入的数据，没有CDC或ETL管道引入的延迟。
从技术实现角度看，LTAP的关键创新在于事务数据写入流程。传统上，PostgreSQL等事务数据库使用行式存储格式优化单行访问。但行式存储对分析查询效率低下，列式存储更适合大规模扫描和聚合。
Lakebase之前的版本将PostgreSQL数据以行式格式存储在对象存储上，分析引擎读取之前需要先进行行转列的转换。LTAP将转换时机提前到写入路径。在缓存层中，利用空闲计算资源在数据写入对象存储之前就完成行到列的转换。这一设计使数据在写入时就以列式格式可用，分析引擎可以直接读取。
Reynold Xin解释了这个设计在成本方面的收益：当你将数据从行式转换为列式时，压缩比通常超过10倍，这大大降低了缓存层和对象存储之间的网络成本。
3.2 Lakebase：事务引擎
Lakebase是LTAP架构中的事务计算引擎。它是一个完全托管的、无服务器的PostgreSQL兼容数据库服务，专为智能体时代设计。
Lakebase的核心特性包括以下几点。
存算分离是基础能力。Lakebase将计算层和存储层解耦，使数据库可以独立于存储进行扩缩容。事务工作负载高峰时，计算资源可以弹性扩展，无需迁移数据。
数据库分支是一项关键创新。Lakebase支持即时写时复制数据库分支。开发人员可以在几秒内创建一个生产数据库的完整副本分支，用于调试、测试或实验。这个能力对AI智能体特别有价值，智能体可以在隔离环境中安全地尝试各种操作，而不影响生产数据。
跨云容灾支持将数据库副本部署到不同云区域。Brian Clark分享了一个有趣的使用案例：一位客户正在评估Lakebase的跨云灾难恢复能力。虽然该功能最初是为增强弹性而设计的，但客户发现了另一个用例，将数据库迁移到更接近可用且价格实惠的GPU的位置。他们表示，这太完美了，因为我们正在寻找廉价的GPU。有时其他云平台能提供价格低廉且可用的GPU资源。因此，我们希望能够将数据库迁移到GPU价格最低的地方。
这个案例展示了AI如何重塑基础设施决策。企业越来越希望拥有根据计算资源的可用性灵活迁移工作负载的能力。Brian Clark说：我认为，正因如此，情况会变得更加灵活。如果你无法迁移到GPU价格低廉的地方，要么就得花更多钱，要么就只能放弃使用它们。
3.3 Lakehouse//RT：分析引擎
Lakehouse//RT是LTAP架构中的实时分析引擎。它是一个全新的计算引擎，专门为高并发、低延迟的分析查询场景设计。
Lakehouse//RT由名为Reyden的执行引擎驱动。Reyden采用完全异步的执行模型，能够在数万并发查询下保持一致的毫秒级响应。
性能数据令人印象深刻。在标准分析基准测试中，Lakehouse//RT在每秒12000个查询的负载下实现100毫秒以内的延迟。对于小型数据集，响应时间可低至10毫秒。早期预览客户报告的性能比现有专用实时服务栈高出最高16倍。
Lakehouse//RT的关键特性包括以下几点。
直接查询湖仓数据是核心能力。Lakehouse//RT直接查询Delta Lake和Apache Iceberg表，无需数据移动或复制。不需要额外的提取管道、同步流程或专用存储格式。
统一治理通过Unity Catalog实现。每个查询都在Unity Catalog的治理框架内运行，包括策略、权限和审计。不需要单独维护治理层，分析服务和企业数据资产之间没有治理鸿沟。
支持全范围分析复杂度。与仅优化简单键值查找的专用服务引擎不同，Lakehouse//RT将性能优化技术应用于完整范围的分析复杂度，包括多表连接、窗口函数和子查询。
早期客户验证了这些能力。Cisco数据平台负责人Chris Kopek表示：威胁查询需要持续的低延迟，即使使用量在用户和智能体之间扩展。我们在Lakehouse//RT上看到的是对实时数据的毫秒级性能和5倍的响应时间改善，这为在这些工作负载上运行我们的湖仓而不是维护单独的服务系统创造了条件。
3.4 从6个组件到3个组件的架构简化
一个经常被忽视但同样重要的技术细节是架构简化。在LTAP之前，Databricks的数据架构包含多个独立的组件。Lakebase处理事务，Lakehouse处理分析，两者之间通过数据管道连接。此外还有服务层、缓存层、消息队列等多种基础设施。
LTAP将这些组件压缩为三个核心层。存储层是Delta Lake和Apache Iceberg的统一存储，数据只存一份。事务计算层是Lakebase，处理PostgreSQL兼容的事务工作负载。分析计算层包括Lakehouse和Lakehouse//RT，处理分析和实时查询工作负载。
这个简化带来直接的可运维性收益。需要管理的组件更少，故障排查范围更小，资源利用率更高。对于正在从实验阶段转向生产级AI工作负载的企业，架构简化可能比单个组件的性能提升更具吸引力。
四、LTAP对AI智能体的战略价值
4.1 智能体的数据访问模式
理解LTAP的价值，需要先理解智能体与传统应用在数据访问模式上的根本差异。
传统应用的数据访问模式相对可预测。用户登录、浏览商品、下单支付，每个操作都对应预先定义的数据库查询。应用可以通过缓存、连接池、查询优化等手段来保证性能。
智能体的数据访问模式完全不同。智能体在推理过程中动态决定需要查询什么数据、查询多少次、以什么顺序查询。它的行为不是预先定义的，而是根据上下文实时生成的。
这意味着智能体的查询模式更不可预测。它可能在一个任务中发出数百次查询，其中大部分是读操作，但也可能包含写操作。查询的范围可能从简单的键值查找到复杂的多表聚合。
Michael Leone解释了这一差异：智能体阅读上下文、循环、尝试各种方法，然后写回一些内容，以你无法完全预测的方式重复数千次。在这种规模下，生产系统和分析系统之间的持续来回切换开始成为瓶颈。
LTAP对智能体的战略价值在于它消除了这种来回切换的成本。智能体在分析数据时不需要切换系统，事务数据和分析数据在同一个存储层中。智能体在写入决策结果时也不需要切换系统，同一个PostgreSQL接口支持事务写入。
4.2 数据库分支与智能体调试
数据库分支是Lakebase的一项关键能力，它对智能体开发和调试具有特殊价值。
在传统架构中，调试生产环境中的智能体行为极为困难。智能体的错误可能源于数据问题，但生产数据无法直接用于调试，因为任何修改都可能破坏生产环境。开发和测试环境中的数据与生产环境不一致，许多问题只能在生产环境中复现。
Lakebase的分支功能解决了这个问题。开发人员可以在几秒内创建一个生产数据库的完整副本分支。这个分支拥有与生产相同的模式和全量数据，但完全隔离，不会影响生产工作负载。
智能体可以指向这个分支进行调试和实验。如果智能体的行为出现异常，开发人员可以在分支上重现问题，修改代码，反复测试，直到问题解决。整个过程不会对生产环境造成任何风险。
Brian Clark指出：代理非常喜欢分支功能，因为这本质上是一个隔离的环境。你可以从数据库中创建一个分支，这实际上是一个完整的副本。这些隔离的环境使代理能够在不影响生产工作负载的情况下进行实验。
4.3 消除管道复杂性
管道是传统数据架构中最脆弱的部分。ETL管道在数据移动过程中可能失败，CDC管道在模式变更时可能中断，实时服务管道在负载高峰时可能延迟。
这些管道问题在智能体时代变得更严重。智能体加速了开发周期，模式变更更加频繁，管道中断的风险更高。当一个智能体依赖的数据管道出现延迟或错误，整个智能体的输出都可能受到影响。
LTAP的目标是创建不需要管道的默认模式。数据在写入时就自动以列式格式存储在湖仓中，分析引擎可以直接读取。没有ETL，没有CDC，没有数据复制，没有同步延迟。
Brian Clark说：我们将提供无需管道的默认模式。例如，这些数据会自动存储在你的Lakehouse中，你无需进行任何管理操作。
五、性能与成本优势
5.1 性能数据
Databricks在峰会中公布了Lakehouse//RT的多个性能数据点。
在标准分析基准TPC-H测试中，Lakehouse//RT在每秒12000个查询的负载下保持100毫秒以内的延迟。随着并发查询数从个位数增长到数千，延迟曲线保持平坦，而备选方案的延迟在并发增加时显著上升，甚至完全停止响应。
在TPC-DS测试中，Lakehouse//RT在复杂查询场景下表现更加突出。一个备选方案在最大数据规模下运行速度比Lakehouse//RT慢25倍，且无法完成全部查询。
早期客户验证了这些性能数据。SES高级数据云架构师Dennis Rossberg报告：Lakehouse//RT直接在我们的Databricks数据上提供性能，比我们之前的查询时间快20倍，成本只占一小部分，因为我们不再需要运营单独的服务层来满足延迟要求。
Enverus企业分析总监Paul Lamb报告：对于某些查询，查询在几十毫秒内返回，对于其他查询，比我们专用的实时引擎快100倍。这种性能意味着我们可以将单独的分析栈折叠到一个统一的湖仓中。
PointClickCare工程高级副总裁Mehrshad Setayesh报告：Lakehouse//RT在我们的医疗数据集上平均比我们之前的仓库快三分之一，某些工作负载的查询速度快10倍。我们曾考虑用专用实时系统来增强湖仓架构，但Lakehouse//RT消除了这种需求，以统一的治理方式原生地提供了这种速度。
5.2 成本优势
LTAP架构的另一个关键价值是成本降低。成本节约来自三个来源。
存储成本降低是最直接的收益。数据只存一份，没有事务数据库、分析仓库、实时服务层之间的多份拷贝。列式存储的压缩比行式存储高出10倍以上，进一步降低存储费用。
管道成本消除同样重要。ETL和CDC管道涉及计算资源、存储资源和人力维护成本。管道越复杂，成本越高。LTAP消除管道，相应的成本也随之消失。
治理成本降低也是一个因素。在传统多副本架构中，安全策略、访问控制和业务逻辑需要在每个系统中独立配置，当策略漂移时还需要人工对齐。LTAP的统一治理模型消除了这种重复劳动。
六、行业评价与未来展望
6.1 分析师的评价
行业分析师对LTAP的整体方向持积极态度，但也指出了需要进一步验证的方面。
HyperFRAME Research AI栈实践负责人Stephanie Walter认为LTAP的智能体定位是真正的差异化因素：企业多年来一直拥有HTAP、流处理、云仓库和运营存储。不同之处在于智能体AI的定位。智能体需要实时运营数据、历史上下文、治理、检索和写回在同一个工作流中。这是一个强有力的架构论证，但Lakebase仍然需要证明它能够满足CIO们期望的延迟、可靠性和运营成熟度。
HFS Research执行研究主管Ashish Chaturvedi指出：最突出的优势将是更少的数据管道以及消除它们所带来的一切级联效应。大多数企业没有意识到他们的数据工程预算中有多少是纯粹的管道维护。
Kanerika联合创始人兼CRO Bhupendra Chopra补充道：我们直接看到客户部署多智能体系统时的情况，管道层几乎立即成为天花板，因为一个智能体每个任务运行数百次。
6.2 LTAP vs HTAP的争论
分析师们普遍认为LTAP在架构上优于HTAP。Moor Insights and Strategy的Michael Leone说：HTAP从未真正起飞，因为要求一个紧密绑定的系统同时擅长事务和分析通常会让它在两方面都表现平庸，客户最终为这种妥协付出了溢价。
ISG软件研究执行总监David Menninger补充道：HTAP失败的另一个原因是它要求企业用新架构替换现有数据平台。LTAP建立在存算分离这个已经被广泛接受的实践之上，增加一个操作层更像是一种演进而非革命。
6.3 未来的挑战
尽管LTAP的架构设计优雅，但它仍面临几个需要在实际部署中验证的挑战。
大规模下的延迟稳定性是首要问题。LTAP承诺在数万并发查询下保持毫秒级响应，但在真实企业环境中能否兑现，需要更多生产级验证。
生态系统的成熟度也是一个因素。LTAP基于开放格式构建，但与现有PostgreSQL应用和分析工具的兼容性需要实际检验。
运维模式的转变也需要考虑。从传统多系统架构迁移到LTAP，企业的运维流程、安全策略和团队技能都需要相应调整。
七、总结
LTAP代表了数据架构领域一次根本性的范式转变。它不是在现有架构上增量优化，而是重新思考了事务和分析工作负载应该如何共享数据。
传统架构中，数据在多个系统间流动，通过管道连接，以复制换性能。LTAP架构中，数据驻留在单一存储层，通过存算分离实现隔离，以开放格式换灵活性。
这个转变对AI智能体的意义尤为深远。智能体不需要在事务系统和分析系统之间来回切换，不需要等待数据同步，不需要处理管道故障。它可以直接在统一的数据平台上完成从分析到决策到执行的全流程。
Databricks联合创始人兼首席执行官Ali Ghodsi的总结点明了这个转变的核心：LTAP消除了支撑上一代计算的瓶颈。它不是让现有架构变得更好，而是让架构本身不再是限制。
对于正在构建AI驱动的企业应用的技术决策者来说，LTAP提供了一个值得认真评估的方向。