Google Next 2026中的数据工程：Looker、BigQuery与MCP服务器。
Google Cloud Next 2026对Looker和BigQuery数据工程的意义：代理、LookML语义层、托管式MCP服务器以及知识目录。
来源: Google Next 2026: What’s New for Looker, BigQuery, Data Platforms and Agentic Analytics
在拉斯维加斯举行的2026年Google Cloud Next大会上，其规模完全符合该品牌的定位，主题演讲和分组讨论在庞大的会场中依次进行。对于那些负责Looker或BigQuery项目的人来说，关于分析、数据集成以及智能分析的环节最为重要。下文将梳理那些可能在未来十二个月内改变此类项目开展方式的公告，同时介绍客户交流中的经验，这些经验比大多数产品新闻更具实用价值。
核心理念：从响应到行动
Google在分析及数据平台方面的整体理念是从“智能系统”转向“行动系统”。前者是被动式的商业智能，仅在被询问时才给出答案；后者则是一组主动式的智能体，它们会持续监控各项指标，总结分析结果，并为企业采取行动。
从本质上讲，这些并非什么新鲜事物。基于事件的警报与自动响应功能早在二十年前就已出现在企业BI工具包中。尽管如此，如今人们再度重视这些功能确实能带来实际益处，因为它改变了2026年委托开展的Looker项目所涵盖的范围。
对于任何撰写工作说明书的人来说，这都会带来实际影响。过去，报告和仪表板就是全部交付内容。而现在，讨论范围还必须包括谁或什么会使用这些数据（是人还是智能代理），这些智能代理需要独立处理哪些问题，以及由谁来验证这些智能代理所依赖的业务规则。那些跳过这些讨论的项目往往会在后续开发过程中重新面对这些问题，且成本会更高。
智能代理数据云及其三大核心理念
主题演讲围绕“智能数据云”展开，这是谷歌针对一种矛盾状况提出的解决方案：那些为人类理解数据而设计的工具，原本并不适用于人工智能智能体能够独立处理这些数据的世界。这一方案基于三个核心理念。
智能体除了需要数据外，还需要相关含义。将强大的智能体投入到原始数据海中，期望它能自行解决业务问题，其实是一种代价高昂的冒险。智能体必须了解“净收入”并不包括回报、不同业务部门对同一指标的计算方式存在差异，以及合同中的某些条款会改变货物的运输路线。知识目录旨在捕捉并持续维护这些机构知识，这样每个处理数据的智能体都能基于相同的规范化理解来开展工作。
客服人员需要采取行动，而不仅仅是汇报情况。以一次会议为例：系统仪表板并未显示订单取消数量的激增，但客服人员注意到了这一异常，通过分析物流和销售数据找出根本原因，确定负责的配送中心，建议调整配送路线，并启动监控机制以观察情况何时好转。根本无需他人催促。
数据始终留在原处。传统云平台要求所有数据先集中到一处才能发挥价值。而在这里，客服人员可以直接在数据所在的位置进行查询，无论这些数据是在 Google Cloud、AWS、Azure、Snowflake、Databricks 还是本地系统中，无需先进行昂贵的数据迁移。
Looker 作为语义层与体验层
具体而言，Agentic Data Cloud将BigQuery、知识目录、Gemini和Looker整合在一起，其中Looker承担体验层功能，这四者作为一个整体系统运行而非独立产品。对话式分析、仪表板智能体、触发式工作流以及Looker的其他新功能，都是该架构与用户交互的方式，也正是人们能够感受到仅能生成报告的BI与能够主动执行的BI之间差异的体现。
新的Explore功能更进一步。传统的字段选择和筛选模式已被一种更接近Google搜索或Google文档的可视化拖放界面所取代。该界面内置了三个Gemini助手：一个用于通过自然语言进行导航，一个能够将普通英语转化为Looker表达式，还有一个负责为相应问题选择合适的图表类型。
对于交付团队而言，这意味着他们不必再花费大量时间指导用户使用可视化界面，而可以更多精力关注底层LookML的质量与语义正确性，因为助手会依据模型所定义的内容进行推理。如果语义层存在缺陷，那么即便在对话模式下也会产生错误的答案。
仪表板智能体现已普遍可用。仪表板不再仅仅是静态的、仅用于信息播报的工具：用户可以对其提出疑问，要求获取内容摘要及变更信息，还能在对话中探究某个数值背后的原因。最典型的企业应用案例来自YouTube，其合作伙伴经理可以通过一个看似普通的Looker仪表板，查询整合自15个数据源的创作者作品集信息。
触发式工作流让客服人员从被动的响应者转变为主动的监控者。各项指标会全天候被追踪，一旦超过设定阈值，团队就会立即收到警报。近期的发展计划还包括让客服人员能够自动撰写邮件或在 Slack 上发帖。对于运营分析而言，这带来的价值远超想象，这也是两年前客户们还未曾提出过的需求。
其他与 Looker 相关的动态也值得提及：
- Gemini Enterprise 内的 Looker 客服机器人。 在 Looker 中开发的客服机器人可以发布到 Gemini Enterprise 中，并与其他企业级客服机器人一同管理。对于选择在此投资的客户而言，Looker 就成了更广泛 AI 战略的一部分，而不再仅仅是独立的商业智能工具。
雅虎与Virgin Media O2的收获
对于从事这项工作的人来说，Yahoo和Virgin Media O2提供的对话分析案例最具参考价值。主要研究发现是：分析精度主要取决于两个因素，即“黄金查询”以及用YAML格式编写的智能体指令。Yahoo在将智能体指令从JSON格式改为YAML格式后，发现输出结果有所提升。随后他们还将“黄金查询”和业务术语表迁移到了LookML中，而非继续存储在其他地方，这大大降低了指令的复杂性，因为模型现在是基于语义层进行推理，而非依赖手写的上下文。
Yahoo自己的总结是此次会议中最值得引用的观点：对话分析应从语义层开始，而非从人工智能开始。一旦数据和模型准备就绪，对话分析几乎就是接下来的发展步骤了。
对于团队而言，实际的操作方式发生了变化。过去需要编写冗长且精心调优的智能体提示语，现在则转为优化模型本身——因为放入LookML中的任何内容都能被所有智能体和用户使用，而放入提示语中的内容仅服务于单个智能体，且会逐渐失效。
因此，用于对话分析的优质LookML模型也发生了变化。现在的基准配置包括每个字段的标签、描述、同义词和注释、嵌入在LookML中的标准查询，以及模型内的YAML格式业务术语表。智能体指令被刻意简化，因为语义层承担了大部分工作。设置仪表板智能体、触发式工作流以及标准查询，如今应属于任何正式Looker项目的基准配置，而非可选附加项。
Data Studio回归
Looker Studio 已更名为 Data Studio，其功能范围也有所扩展。它现在可以处理三种类型的分析成果。第一种是常见的报告或仪表板，数据来源包括 BigQuery、Google 及合作伙伴的 SaaS 接口，或是 Looker 的语义层。第二种是在 BigQuery 中构建并发布在其中的对话式分析代理。第三种则是全新的“数据应用”概念，即把 Colab 笔记本发布为交互式应用。
数据应用介于仪表板和完整应用之间。对于那些依赖 Looker 进行运营报告、希望获得更高交互性但又不想定制完整嵌入式应用的客户来说，这类应用非常合适。
品牌重塑及新自助服务功能推出所带来的一个后果是：曾被宣传为Looker前端未来的集成式“Studio in Looker”功能，对于尚未启用该功能的组织已不可用，且计划于2026年6月15日停止使用。
BigQuery：数据工程代理与托管式MCP服务器
去年发布的许多预览版本现已正式推出。这些功能包括用于数据工程和数据科学领域的代理、BigQuery内的对话式分析功能及其API、BigQuery ADK、专为BigQuery设计的托管式远程MCP服务器、开源的MCP Toolbox，以及用于收集代理运行情况监控数据的插件。
有些较新的功能其实比最初看上去更重要。
动态资源调度。BigQuery会在智能体处于活跃状态时增加计算资源，而在其空闲时则自动释放资源，无需手动调整规模。因此，关于大规模对话分析成本过高的常见质疑也大大减弱了。
BigQuery Graphs。这是一种无需ETL步骤的原生图计算引擎，能够支持数十亿个节点，并兼容ISO GQL标准。更值得关注的是BigQuery Graphs中的度量功能，它将受管控的指标与关系映射相结合，使智能体能够处理多跳依赖关系。
作为推理扩展的度量标准。区分这两种度量标准的一个有效方法：LookML度量标准负责计算，明确指标的含义，并确保所有使用Looker的分析师和智能体都能获得一致的SQL结果。而图表度量标准则负责推理，将相同的指标定义置于由产品、供应商、枢纽和路线等相互关联的实体构成的图表中，这样智能体就能通过追踪各影响因素之间的关联来了解指标变化的原因。
迁移服务
BigQuery Migration Service现已更名为Data Analytics Migration Services，且此次改革幅度很大，因此任何计划在2026年从Snowflake、Cloudera或Databricks迁移的用户都应重新评估这一选择。对于Cloudera和Databricks，评估过程是自动化的，会生成一份清单，列明各工作负载的总体拥有成本估算值。Hive、Snowflake等数据库中的SQL语句会在编译阶段被转换为GoogleSQL。Lakehouse迁移功能可处理Iceberg、Parquet和Hive格式的表格，同时还会有一项代理验证服务在迁移过程中实时运行，逐表逐列评估数据准确性。由于迁移API可通过MCP访问，因此像Claude Code这样的工具便可用来统筹整个迁移流程。
该服务的早期版本在处理复杂SQL转换时表现参差不齐，而新一代产品在这一方面显然强多了。验证控制面板尤为出色，因为它承担了多年来一直耗费大量人工时间、进而拖慢迁移进度的检查工作。那些此前预计需要数周时间让分析师手动对比行数和列值的团队，应当重新评估这些时间预估。
跨云联合
在联合功能方面，AWS S3上的Databricks Unity Catalog现在支持双向读取，同时Snowflake Polaris和AWS Glue也能从BigQuery中读取数据。所有功能均基于Apache Iceberg REST目录标准，因此BigQuery可以直接查询这些外部目录，而无需数据传输。
对于那些无法或不愿完全迁移的客户，策略会发生变化。不再坚持要求所有数据都迁移到BigQuery，而是提供这样的方案：让数据留在原处，通过BigQuery进行访问，同时在之上叠加Looker和Conversational Analytics。那些原本会被排除在以GCP为主的分析方案之外的Snowflake用户，现在有了真正的选择，而这很可能会成为他们实现全面迁移的过渡途径。
Target、Wells Fargo和Virgin Media O2的迁移经验
由这三家公司组成的讨论小组揭示了一些许多人已通过痛苦经历才了解到的规律，但这些规律仍值得重申。
第一条，也是最重要的一条：首先实现语义层的迁移。在GCP上搭建Looker或BI层，这样在数据工程迁移进行中的时候，业务用户仍可访问相关数据；同时通过战术性复制任务将关键数据集复制到BigQuery中来填补空白。Virgin Media O2已通过六次大规模平台迁移实现了这一目标，Wells Fargo也认可了这种做法。
其他模式：
- 在迁移前先缩减数据规模。人工智能可以提前找出未使用和重复的数据；小组中的一家企业发现其超过80%的数据都是重复的。
- 先进行整体迁移，后再进行现代化改造。在迁移过程中进行代码重构会不可预测地延长时间线。
Target还提出了一个值得借鉴的概念——“非理性目标”：选择那些除非围绕人工智能原生方法重新构建平台否则无法实现的目标。这样就能将讨论焦点从如何迁移转向如何转型。
数据代理工具包
在预览版本中，Data Agent Kit将VS Code扩展与Gemini CLI、Cloud Code和Codex的插件相结合。它们共同为BigQuery数据工作流提供了各类技能与MCP工具：代理技能、MCP服务器、连接BigQuery的工具，以及用于深度定制VS Code的插件。这些技能本身是开源的，可进行修改。
那些已经在构建内部代理式交付工具的咨询公司和客户团队应当认真评估它。初步看来，它涵盖了BigQuery层面的开发工作，能够补充更广泛的交付编排与LookML功能，与现有基于技能的方法相辅相成。
作为代理上下文的知识目录（原名为Dataplex）
Dataplex现已更名为Knowledge Catalog，成为Google Cloud智能工作流的上下文后端。其运行依赖于三大核心支撑。第一项功能是从Google的各项服务（包括Looker）以及Atlan、Collibra和SAP等合作伙伴的目录中收集元数据。第二项功能通过自动化生成机制及已正式投入使用的业务术语表来丰富这些元数据。第三项功能则提供语义搜索功能，借助Context API让智能体能够获取所需信息。
最具参考价值的案例来自Bloomberg Media。该公司的“知识缺口智能体”能够从智能体的失败中学习，识别数据上下文错误或缺失的地方，并提出对Knowledge Catalog的更新建议以供人工确认。最终成果是：在20个MVP表格中自动生成了102条使用说明，使得数据访问智能体的SQL查询准确率提升了63%。
对于规模较小的项目，知识目录会处于后台运行状态。而对于那些需要大规模构建对话分析智能体、且机构知识尚未被整理到智能体可访问的任何地方的客户而言，知识目录正是他们所缺少的关键组件。彭博社将这一根本问题称为“42美元难题”，它同样困扰着人类分析师和人工智能智能体：那些在数据平台上没有任何记录的知识。
在他们的示例中，一名初级分析师选对了表格，编写了有效的SQL语句，也应用了标准的净收入计算逻辑，却得到了错误的数值。支付服务提供商会对每起客户纠纷收取42美元的费用，而这笔费用必须计入收入计算中。然而这条规则既不在任何数据架构中，也不在任何处理流程中，更不存在于任何可访问的文档里。它仅保存在2017年的一篇Confluence页面上，而该页面的创建者早已离开公司。
是否缺少语义引擎？
事后出现的一种批评观点认为，谷歌过度专注于智能体层，而其语义处理和业务上下文能力相对薄弱。按照这种看法，知识目录更像是元数据聚合工具，缺乏类似OpenAI的Frontier或Palantir的Foundry那样真正的企业级操作系统的特性。如果没有强大的语义引擎将业务含义与智能体相连，即便是先进的工具也有可能出现输出偏差、产生幻觉，或是给出错误问题的正确答案。
上述诊断大多成立，在以智能体为主导的世界中，语义层的重要性远超传统控制面板式系统。更为乐观的看法是，LookML的语义层已经能够承担企业操作系统应有的大部分业务场景相关功能。它解决了“多版本真相”的问题，提供了规范化的指标定义，并通过MCP Toolbox为Claude这类智能助手提供可信的指标存储服务。
尽管在会议上知识目录对LookML的集成提及甚少，但这并不意味着LookML处于闲置状态。相关工作其实是在批评者所关注的层级之下进行的。
具体证据可见谷歌为在Looker中配置对话分析而制定的最佳实践文档。这些实践主要基于两个来源：LookML模型中的结构、字段、标签、描述及同义词，以及从数据中抽取的独特字段值，其中值的唯一性数量决定了这些值的使用方式。
为获取这些独特值，对话分析会调用长期存在的Looker API方法model_fieldname_suggestions。这与字段选择器及仪表板过滤器中的筛选建议机制相同，现在被重新用作模型的参考信号。因此，现有的三个LookML参数suggestions、suggest_explore和suggest_dimension也同时成为开发者控制对话分析应识别哪些值的手段。
团队无需等待产品来实现这一功能；同样的思路也可以在 BigQuery 数据仓库中手动构建。除了从 INFORMATION_SCHEMA 生成的标准化数据字典外，还可以维护一份 Markdown 指南，将其作为技能提供给助手，并通过定期分析步骤重新生成。该指南会说明每个表的行数、日期范围，以及高价值分类字段的取值集合和基数，这样助手就能准确知道消息表在 iMessage、Slack、WhatsApp 等平台上的数据分布比例，而无需猜测。
对话分析现在在LookML层面实现了类似功能，并为所有Looker用户提供通用支持。以从客户数据或运营数据中提取的city维度为例，系统会抽取其中的不同值，如布赖顿、霍夫和伦敦，然后根据这些值的唯一性来决定在用户提问时各值应被赋予多大的权重。
对于LookML开发者而言，可调整的参数就是这三个，使用方式如下：
view: customer {
dimension: city {
label: "Customer City"
description: "The city associated with the customer's primary address. Most operational activity occurs in Brighton and Hove (UK head office) and London (UK secondary office)."
type: string
sql: ${TABLE}.customer_city ;;
# Hard-code a curated list of values rather than letting Looker
# run SELECT DISTINCT against a large table.
suggestions: ["Brighton", "Hove", "London", "Edinburgh", "Manchester"]
}
dimension: customer_segment {
label: "Customer Segment"
description: "Customer tier based on annual recurring revenue."
type: string
sql: ${TABLE}.segment ;;
# Pull suggestions from another view rather than scanning
# the much larger customer fact table.
suggest_explore: segments
suggest_dimension: segments.segment_name
}
}
结合描述、同义词以及嵌入模型中的若干关键查询，它们为LookML语义层提供了批评者期望企业操作系统具备的功能：为代理层提供有依据、受管控的业务上下文，同时能够基于基数意识对真实值进行采样，所有这些功能均源自仪表板和探索工具背后的同一套LookML。
因此，对知识目录与LookML的理解是不同的。目前LookML在知识目录架构中仅被视为众多输入之一，很容易看出为何会显得地位较低。在接下来的十二到十八个月内，这种情况有望发生显著变化，因为谷歌完全有理由将LookML打造成目录中最核心的输入，而不仅仅是众多输入中的一个。
批评者所呼吁的语义引擎其实并不存在缺失，因为其大部分功能早已内置于LookML中。目前尚未明确的是，Knowledge Catalog能否发展成能在整个智能体架构中传递LookML含义的业务上下文层，还是会有其他产品承担这一角色。无论哪种情况，花在完善LookML上的时间都是值得的。
相关阅读
- 实用笔记：RAG已过时，Andrej Karpathy提出的LLM Wiki才是未来方向：针对“实用笔记：RAG已过时，Andrej Karpathy提出的LLM Wiki才是未来方向”一文的详细操作指南，包括合同、检查项以及供团队直接使用的代码模板。