过去十年间，数据基础设施的构建主要围绕数据管道展开。先传输数据，再进行转换和存储，最后利用这些数据完成有价值的任务。这种方法已变得如此司空见惯，以至于大多数团队不再对其提出质疑。

　　在 Cloud Next 2026 大会上，谷歌似乎正倾向于一种不同的数据处理方式，这种方式更侧重于直接访问、统一平台以及由 AI 驱动的执行。其核心理念并非构建更完善的管道，而是减少管道数量。

　　大多数数据系统依赖于一系列定时任务和转换流程，每个步骤都取决于前一个步骤能否正确运行。随着系统规模的扩大，这些依赖关系不断增加，导致管道管理难度加大，运行成本也随之攀升。

　　数据被采集、转换、存储，随后用于分析或输送至下游系统。这种方法依然有效且被广泛采用，但随着时间推移，它已形成多层级的ETL、ELT及编排架构，在规模扩大时不断增加复杂性。

　　这正是谷歌开始着手解决的问题。在今年的活动中，BigQuery被定位为处理与AI在同一数据集上协同运行的平台。关键不在于数据的最终归宿，而在于模型与实时数据集的交互位置。这消除了系统之间通常存在的、位于中间环节的大量往返传输。

　　这也改变了数据转换工作的发生位置。不再需要将数据推送到其他工具再取回，更多转换工作可直接在 BigQuery 内部完成。据谷歌称，这意味着数据传输次数减少、定时任务减少，以及需要维护的管道逻辑更少。毫无疑问，数据管道依然存在，但从原始数据到实际应用的每个步骤并不都需要依赖它们。

　　关于湖仓架构的公告也指向了类似的方向——数据不应因不同工具的需求而每次都进行移动。在此次活动中，谷歌推出了一款基于 Apache Iceberg 构建的跨云湖仓架构，支持 BigQuery 和 Spark 等服务，其目标是让多个系统能够处理同一数据，而无需每次都创建新的副本。

　　谷歌预计这将减少大多数数据管道原本用于支持的持续复制工作。这意味着，平台不再致力于构建更多数据摄取流程，而是试图降低这些流程的必要性，这与本次活动数据相关公告的整体主题相契合。

　　Google 针对 AlloyDB 也采取了类似的策略，添加了联合查询功能，使 AlloyDB 能够直接查询 BigQuery 和湖仓中的数据，它还支持将运营数据与分析数据结合，而无需先将所有数据拉入一个系统。这取代了常见的管道模式——即复制数据、同步数据，然后进行查询。在此模式下，数据保留在原地，查询则在不同系统间移动。这意味着步骤更少、副本更少，整体管道工作量也更少。

　　管道的复杂性往往并非源于数据迁移，而是源于对数据实际含义(即上下文)的追踪。这包括定义、结构和血统，而这些信息往往会在不同系统中被重复创建。这正是系统故障的常见起点。

　　在此次活动中，Dataplex 被进一步整合到 Knowledge Catalog 中，其目标是让元数据和业务含义更贴近数据本身。其设计初衷是让上下文信息集中存于一处，而非在每个工具中重新构建，这也有助于更轻松地应用一致的数据策略和治理规则，避免多套系统间出现逻辑冗余重复的问题。

　　将此与其他公告结合起来看，其发展方向更加明确，BigQuery 成为执行层，湖仓架构成为共享数据层，联邦架构消除了持续复制的需求，治理机制将上下文整合在一起，不同的组件，相同的结果：更少的重复、更少的移动、更少的协调。这也减少了故障点，因为在数据被使用之前，参与数据移动和重塑的系统更少。

　　数据管道依然具有价值，依赖管道的系统依然众多，尤其在控制与可预测性至关重要的场景中，批处理、定时报告以及受监管的工作流将继续依赖结构化数据传输。这些用例并未被取代，数据更多时候会保留在原地，而工作流程则向数据靠近。管道依然存在，只是压力稍减。随着时间推移，这将改变团队的工作重心：减少在数据迁移上的投入，更多地直接处理数据。