Databricks的Lake Transactional/Analytical Processing (LTAP) 让分析查询可直接在实时操作数据上运行而无需移动数据或加重事务系统负担，其依据是统一存储层而非统一引擎。
AI解读：长期以来，操作型数据库（如处理信用卡交易的系统）和分析型数据库（如用于数据扫描和聚合的数据仓库）必须分离，因为前者采用行式存储以快速处理单条查询，后者采用列式存储以高效扫描大量数据，二者物理结构不同。Databricks推出的LTAP（Lake Transactional/Analytical Processing）试图通过统一存储层而非统一引擎来解决这一矛盾：数据以原始行格式存储于热层以支持操作型工作负载，同时以列式格式（如Parquet）存储于冷层供分析引擎（如Spark或SQL）直接读取，无需额外复制或数据管道。这主要受益于Lakebase架构（从Neon继承的无状态、可弹性伸缩的计算与存储解耦）。LTAP的关键优势在于，它允许操作型计算和分析型计算独立扩展，用户只需为每种工作负载所需的计算资源付费，而非为一个试图兼顾两者的庞大系统付费。对于正构建AI智能体的企业，这一模式能避免智能体基于过期数据做决策，同时防止大量分析查询拖垮操作型系统。数据架构师若面临智能体需要实时状态数据做即时判断的场景，LTAP提供了一种替代传统数据管道和复制的方案，但实际效果和规模化表现仍有待验证。
Databricks高级产品经理Jonathan Katz在官方博客中详细介绍了LTAP（Lake Transactional/Analytical Processing），这是一种让分析查询直接运行于实时操作数据之上的架构模式，无需移动数据或加重事务系统负担。
Katz表示，LTAP通过将事务数据和分析数据统一在单一逻辑存储层中，避免了两者通过管道连接、复制和妥协的传统路径。
AI智能体如何打破四十年旧规
Katz解释，操作型数据（如信用卡交易处理）需要短快查询，而分析型数据（如长期积累的销售记录）需全量扫描，两者因物理存储格式（行式vs列式）不同而被迫分离。传统上，分析操作数据需先将其复制到其他系统。
AI智能体改变了数据库需求：例如，欺诈检测智能体需要处理数百毫秒内发生的事件，同时系统还要处理大量写入和短读取。一个智能体可能知道需要执行什么查询，但一群智能体若无监管措施，极易压垮操作型系统。
LTAP的底层工作原理
LTAP依赖于Lakebase架构：无状态、临时计算完全与湖中存储解耦（继承自Neon）。存储层可以处理高吞吐写入并定期刷新至对象存储以确保持久性，与运行中的计算资源无关。
由于数据已针对云存储优化，可以将其表示为湖屋已使用的列式格式，使Apache Spark和SQL等引擎直接读取，获得高性能分析读取而无需第二次复制。
技术挑战在于保留Postgres数据类型的精确物理表示（不改变一位）并写入Parquet文件，使得操作与分析的表示能合并为一份。在实践中，存储层分两层：热层保留行格式以支持快速操作访问，冷层用列式格式支持分析读取。
LTAP为何优于传统HTAP
Katz认为，HTAP系统成本高、笨重、难以运行且通常不开源。LTAP则将无服务器操作计算和服务器分析计算分离，让用户独立调整每种工作负载的计算资源，避免为兼顾两者的单一系统付费。
存储是数据系统的廉价部分，计算才是昂贵部分。因此统一存储层而非引擎更合理：保留每种工作的专用高效引擎，按需付费，而非运行一个试图面面俱到的昂贵系统。
智能体基于陈旧数据运行的具体故障
以欺诈检测为例：信用卡交易在数百毫秒内完成结算。若负责欺诈的智能体依赖分钟或小时前的批量数据副本，则无法在交易完成前及时拦截。因此智能体需直接连接操作型系统。
操作型系统持续处理写入和短读取，不适合承受重型分析查询。若智能体查询客户完整购买历史以检查异常，可能降低同时处理的其他交易性能。现代架构通常需要操作与分析两侧数据才能做决策，若一群智能体同时执行类似查询而无负载管理，将迅速压垮操作型系统。
治理、开放性与企业应用
Databricks当前实现包含目录统一管理：湖屋通过集中视图控制数据访问权限和一致政策，适用于操作型和分析型数据。LTAP将操作数据纳入同一目录和治理边界，分析时无需担心其离开治理范围。
LTAP构建在开放基础之上。Postgres在DB-Engines排名中接近第三位，显示灵活性和选择的价值。开源长期驱动重要系统，LTAP延续此原则。用户无需为了用正确引擎而移动数据，而是将引擎带到数据旁。
核心转变：统一存储
Katz形容LTAP的核心是“统一存储”，无需移动数据或改变任何位，就能将同一数据的操作和分析表示结合在一起，消除了过去看似不可避免的诸多问题。
这简化了数据架构：不再需要仅为将数据放入银层或金层而运行管道，数据写入即可立即分析。Katz认为这更像是将不该分离的两个世界重新合一——数据就是数据。
LTAP并非要抹去事务与分析查询之间的差异，而是消除同时运行两者时产生的代价。