从管道到平台：Google Cloud Next 2026上的数据战略

过去十年的数据基础设施围绕管道（Pipeline）构建。移动数据、转换数据、存储数据，然后对它做些有用的事情。这种方法变得如此普遍，以至于大多数团队已经接受它。

在Cloud Next 2026大会上，Google似乎在倾向于一种不同的数据处理方式——一种围绕直接访问、统一平台和AI驱动执行的方式。未来的愿景不是更好的管道，而是更少的管道。

大多数数据系统依赖一系列定时任务和转换。每个步骤都依赖前一步骤正确执行。随着系统增长，这些依赖关系增加，使管道更难管理、运行成本更高。数据被提取、转换、存储，然后用于分析或下游系统。这种方法仍然有效并被广泛使用，但随着时间推移，它创造了层层ETL、ELT和编排，在规模扩大时增加了复杂性。

这正是Google开始着手设计解决的问题。

在今年的大会上，BigQuery呈现在同一个地方数据进行AI和处理运行。这不仅关乎数据最终落在哪里，更关乎模型在哪里与实时数据集交互。这消除了通常位于中间的系统间来回传递。它也改变了转换工作的发生位置。更多工作可以留在BigQuery内部，而不是将数据推送到其他工具再取回来。

据Google表示，这意味着更少的传输、更少的定时任务、更少的管道逻辑需要维护。管道当然仍然存在，但不是在原始数据和实际使用之间的每一步都需要它们。

Lakehouse公告指向类似方向——数据在不同工具需要时不应每次都要移动。在大会上，Google引入了围绕Apache Iceberg构建的跨云数据湖屋（lakehouse），支持BigQuery和Spark等服务。目标是让多个系统在同一数据上工作，而无需每次创建新副本。Google预计这将减少大多数管道存在所支持的持续复制。

这意味着，平台不是构建更多数据摄取流程，而是试图让这些流程变得不那么必要，这与大会上数据公告的整体基调一致。

Google对AlloyDB采取了类似方法。它增加了联合查询功能，使AlloyDB可以直接查询BigQuery和lakehouse中的数据。它还支持组合运营数据和分析数据，而无需先将所有数据拉入一个系统。这取代了复制数据、同步数据、然后查询数据的常见管道模式。在这里，数据留在原地，查询移动。

这意味着更少的步骤、更少的复制、更少的管道工作。

很多管道复杂性并非来自移动数据。它来自追踪数据实际意味着什么——即上下文。这包括定义、结构和起源，所有这些往往需要在各系统中重新创建。这正是问题经常开始出现的地方。

在大会上，Dataplex被进一步推向知识编目（Knowledge Catalog），目标是将元数据和业务含义更贴近数据本身。与其在每个工具中重建上下文，不如让它存在于同一个地方。这也使应用一致的策略和治理规则更容易，无需在多个系统中复制逻辑。

BigQuery成为执行层。Lakehouse成为共享数据层。联合查询消除了持续复制的需要。治理将上下文维系在一起。不同的组件，相同的结果——更少的重复、更少的移动、更少的编排。

它也减少了故障点数量，因为在数据使用前涉及移动和重塑数据的系统更少。

管道仍然有价值。有太多系统依赖它们，尤其是在控制性和可预测性重要的地方。批处理、定时报告、受监管的工作流程将继续依赖结构化数据移动。这些用例不会被取代。

数据更频繁地留在原地。工作移向数据。管道仍在那里，只是压力小了一些。

随着时间推移，这改变了团队投入精力的地方——更少花在移动数据上，更多花在直接处理数据上。