40年数据库规则被Agent打破：LTAP统一OLTP与OLAP负载

当代理基于过期数据行动时会出现什么问题

请举一个具体的代理工作流示例，说明它目前因为读取并基于过期数据行动而出现故障或性能下降的情况。实际发生了什么问题？

Jonathan Katz：欺诈检测是最明显的例子。信用卡交易在几百毫秒甚至更短时间内完成清算。如果负责捕捉欺诈的代理基于的是几分钟或几小时前的批处理数据副本，那么它根本来不及在交易完成之前捕捉任何欺诈。因此，你希望该代理直接针对运营系统工作。

但运营系统处理的是持续不断的写入和短查询流，并且它并非为同时吸收重型分析查询而设计。如果代理运行一个扫描客户整个购买历史以检查异常的查询，那么对于针对相反工作负载进行优化的系统来说，这是一个昂贵的查询。它可能降低其他同时尝试清算的交易性能。而且现代架构通常需要来自运营和分析两侧的数据才能做出好的决策，因此代理必须从两者获取数据。一个代理可能负责任地处理这个情况。如果一群代理同时运行类似的查询，并且没有限制它们对系统施加的负载，那么它们可能会迅速压垮运营系统。

治理、开放性和企业案例

Databricks目前如何具体实现LTAP？你会如何向已经理解HTAP为何不足的人描述这一点？

Jonathan Katz： 除了存储机制之外，另一个主要部分是目录。Lakehouse 真正的创新之一是为组织提供对其所有数据的集中统一视图：谁能访问什么，整个企业的策略一致，这样除非用户在特权组中，否则无法读取社会安全号码等数据。这从未真正适用于运营系统，因为运营系统从一开始就是作为数据孤岛构建的。运营数据和分析数据之间的关系过去是：你构建管道，运送数据，之后祝你好运。没有人负责下游发生什么。LTAP改变了这一点。所有的数据都在一个统一的存储模型下，位于一个目录下。你不必担心运营数据仅仅因为有人需要分析它而离开治理边界。

还有一个需要建立在开放基础之上的理由。Postgres在DB-Engines排名中正接近成为第三大最受情感青睐的数据库。这不一定是采用率的衡量标准，但它是未来趋势的强烈信号，并显示了灵活性和选择的价值。开源几十年来一直为世界上一些最重要的系统提供动力。LTAP扩展了相同的原则。即使在Postgres内部，你的数据也可以在不同Postgres系统之间移植，但你仍然绑定在Postgres上。使用LTAP的统一存储层，你不再需要移动数据以获得正确的引擎。而是将引擎带入数据。

核心转变：统一存储

如果必须用一句话描述LTAP所代表的核心转变，无论你怎么概述，你会怎么说？

Jonathan Katz：过于简化的版本是统一存储。告诉分析侧的人，他们几乎立刻明白。告诉运营侧的人，他们可能会问你的意思。但是一旦你能将同一数据的运营和分析表示放在一起而无需移动任何东西，无需任何比特改变，它就能化解许多过去看起来不可避免的问题。我不再需要运行管道来将数据放入青铜层或银层。我可以在数据写入的那一刻开始分析。我也可以反过来看：这与其说是发明新东西，不如说是将两个本不应分离的世界重新结合在一起。数据就是数据。我们越能以这种方式对待它，人们以及现在的代理就越容易使用它，而不必每个人先跨管道进行协商。

将两个世界重新结合在一起

四十年来，运营数据和分析数据之间的界限之所以存在，是因为存储的物理条件要求如此。代理是第一个无法容忍该界限造成的延迟的工作负载。LTAP并不试图消除事务和分析查询之间的区别。它消除了同时对同一数据运行两者时曾有的代价。对于数据架构师评估代理工作负载是否真正需要这种模式，Jonathan描述的这个测试很有用：如果代理的下一个决策依赖于仍在稳定中的数据，而该系统旨在保持数据紧密且受保护，那么旧的管道和复制模型将不够快。这就是LTAP为解决而构建的具体问题。

想了解更多关于LTAP，请阅读从单体到Lakebase再到LTAP：从存储开始重新思考数据库。