企业真的需要分别使用不同的系统来存储交易数据、处理流式数据以及分析历史信息吗?长期以来，企业一直都是这样做的。然而，情况正在发生变化。Confluent、Google Cloud和EDB最近的公告表明，这些技术之间的界限正逐渐模糊。这三家企业都在寻求减少企业数据堆栈中所需层级数量的方法。

这些系统之所以一直保持独立，是有充分理由的。数据库处理日常交易;流式处理平台实时处理数据;数据仓库和湖仓则用于分析海量信息。问题在于如何让它们协同工作。

当企业需要调用多个系统的信息时，问题便随之而来。将所有数据整合到一个地方往往需要大量额外工作，更不用说数据迁移和存储的成本——而AI代理又进一步增加了这一工作量。它们不仅需要了解当前发生的情况，还需访问历史记录。当这些数据分散在不同系统中时，问题就出现了。

Confluent很好地体现了行业正在发生的变化，以及企业如何应对此类挑战。上周，这家隶属于IBM的公司推出了Streamhouse，它使客户能够对流数据进行更多操作，而不仅仅是将其在系统之间迁移。其主要功能之一是Lightning Tables，它允许企业直接查询Kafka数据，而无需先将其发送到另一个数据库。Confluent表示，这些表可以在100毫秒内反映新信息。当然，这一数据基于其自身的测试结果。该功能目前已在AWS上提供。

Confluent还推出了Tableflow，该功能可将Kafka数据迁移至Apache Iceberg和Delta Lake表中。这减少了对独立管道的需求，从而将流式数据导入湖仓。

另一个例子是EDB。该公司上周（11月5日）宣布收购Altinity。EDB最广为人知的是PostgreSQL，该数据库被广泛用于事务处理。Altinity带来了在ClickHouse方面的专业知识，这是一款专为对海量数据执行分析查询而构建的数据库。EDB计划让这两者更易于协同使用，包括通过共享的Iceberg目录和通用的访问控制。

EDB还非常重视数据主权。客户将能够更好地控制其数据的存储位置以及数据库的运行位置。鉴于计划中的集成功能尚未上线，这些举措在实践中能发挥多大作用仍有待观察。

谷歌云上周的公告也聚焦于部分相同的问题。作为其Agentic Data Cloud更新的一部分，谷歌扩展了AlloyDB与Apache Iceberg的协作方式。使用AlloyDB的企业无需先将数据复制到数据库中，即可查询存储在湖仓中的历史数据，并可将这些信息与运营数据结合使用。

谷歌还宣布了改进措施，用于跨不同云平台访问数据，并控制谁可以查看或使用这些数据。与Confluent和EDB不同，谷歌并非将新类型的工作负载整合到一个系统中，而是让访问已分散在多个系统中的数据变得更加容易。企业仍将保留自己的数据库和湖仓，但可能不需要在它们之间建立那么多数据管道和数据副本。

关键在于，企业最终能省去多少现有基础设施。如果Confluent允许企业直接查询流式数据，他们或许就不需要专门为此目的再建一个数据库。而如果Google能将运营数据和历史数据整合提供，企业也就没有必要再在系统之间反复复制数据了。这不仅能为企业节省大量工作量，而且还能节省成本。

这正是事情变得有趣的地方。企业花费大量资金维护数据管道、存储重复信息，并保持不同系统之间的连接。如果能避免其中部分工作，节省的成本将十分可观。AI代理也能从中受益，因为它们无需等待数据在系统间传输，即可获取最新信息。

我们必须牢记，一个平台功能越强大，并不意味着它能同样出色地处理所有任务。PostgreSQL、ClickHouse、Kafka和湖仓(lakehouses)都是为不同的任务而设计的。在某些情况下，使用专用系统仍然更为合理。

此外还存在供应商锁定的风险，即对单一供应商过度依赖。企业可能淘汰了若干工具，却发现自己反而与某家供应商绑定得更紧。而且近期宣布的部分功能仍在开发中。我们尚不清楚它们最终能为客户节省多少资金或精力。

因此，现在就断言企业数据堆栈的任何主要部分正在变得过时，可能为时过早，也有些言过其实。更可能的情况是，企业最终只需更少的工具就能完成数据传输并使其可被利用。核心技术将得以保留，但围绕这些技术构建的某些层级可能会消失。