Google Next 2026 для инженерии данных: Looker, BigQuery и серверы MCP.

Конференция Google Cloud Next 2026 в Лас-Вегасе прошла в полном соответствии с ожиданиями, связанными с этим брендом: ключевые выступления и секции обсуждений располагались по огромной площадке. Для тех, кто работает над проектами Looker или BigQuery, наиболее важными оказались сессии, посвящённые аналитике, интеграции данных и агентному анализу. Далее приводятся объявления, которые могут изменить подход к планированию подобных проектов в ближайшие двенадцать месяцев, а также выводы из бесед с клиентами, оказавшиеся более полезными, чем большинство новостей о продуктах.

Контекст: от ответов к действиям

Основная идея Google относительно платформ аналитики и данных — переход от «системы интеллекта» к «системе действий». Первая представляет собой реактивную BI, которая отвечает на запросы. Вторая — это набор проактивных агентов, которые отслеживают показатели, обобщают полученную информацию и принимают меры в интересах бизнеса.

В сущности, ничего нового здесь нет. Уведомления, основанные на событиях, и автоматизированные ответы существуют в инструментах корпоративного анализа данных уже двадцать лет. Тем не менее повторное внимание к этим аспектам приносит пользу, поскольку оно меняет содержание проектов по разработке решений с использованием Looker, запланированных на 2026 год.

Для тех, кто составляет техническое описание работ, это имеет практические последствия. Раньше всем, что должно было быть передано, считались отчеты и дашборды. Теперь необходимо также определить, кто или что будет использовать данные (люди или агенты), какие вопросы агенты должны решать самостоятельно, и кто будет проверять бизнес-правила, от которых зависят эти агенты. Проекты, которые пропускают этот этап обсуждения, склонны столкнуться с этими проблемами позже, на этапе реализации, при больших затратах.

Agentic Data Cloud и его три основные идеи

Основная тема выступления касалась концепции Agentic Data Cloud — решения Google проблемы несоответствия: инструменты, созданные для того, чтобы люди могли понимать данные, изначально не предназначались для мира, где ИИ-агенты могут самостоятельно работать с этими данными. Три ключевых принципа лежат в основе этой концепции.

Агентам необходимы данные вместе с контекстом их значений. Пытаться использовать мощного агента для обработки необработанных данных в надежде, что он сам разберётся в бизнес-ситуации, — это дорогостоящая авантюра. Ему необходимо узнавать, что понятие «чистый доход» не учитывает возвраты средств, что один и тот же показатель рассчитывается по-разному в разных бизнес-подразделениях или что определённое положение в контракте влияет на маршрутизацию грузов. Каталог знаний предназначен для сбора и постоянного обновления таких институциональных знаний, чтобы каждый агент, работающий с данными, начинал с одинакового основанного на правилах понимания ситуации.

Агентам необходимо действовать, а не только отчитываться. Пример с конференцией: вместо дашборда, показывающего резкий скачок числа отмен заказов, агент замечает этот скачок, проводит анализ корневых причин на основе данных логистики и продаж, определяет ответственный центр распределения, рекомендует изменить маршрут и запускает агента для мониторинга, чтобы увидеть, когда ситуация улучшится. Никто не приходил с просьбой.

Данные остаются на своем месте. Облачные платформы давно требуют, чтобы все данные собирались в одном месте перед тем, как станет возможен их использование. Здесь агенты могут запрашивать данные откуда угодно — будь то Google Cloud, AWS, Azure, Snowflake, Databricks или локальные системы — без необходимости дорогостоящей предварительной миграции.

Looker как семантический и пользовательский слои

Если говорить конкретнее, Agentic Data Cloud объединяет BigQuery, Knowledge Catalog, Gemini и Looker, причем Looker выполняет роль интерфейса для взаимодействия, а все четыре компонента работают как единая система, а не отдельные продукты. Конверсационный анализ, агенты для дашбордов, запускаемые рабочие процессы и другие функции Looker — вот какая архитектура доходит до пользователей, позволяя им ощутить разницу между BI, которое лишь предоставляет отчеты, и BI, которое выполняет действия.

Новая версия Explore идет еще дальше. Старая модель с выбором полей и фильтрами заменяется визуальным интерфейсом с возможностью перетаскивания элементов, более похожим на Google Search или Google Docs. Внутри нее расположены три ассистента Gemini: один для навигации с использованием естественного языка, один для преобразования простого английского текста в выражения для Looker и один для выбора подходящего типа графика для заданного вопроса.

Для команд по доставке это означает меньше времени, затрачиваемого на пошаговую помощь пользователей при работе с визуализационным слоем, и больше внимания к качеству и семантической корректности кода LookML, поскольку ассистенты делают выводы на основе того, что определено моделью. Некачественный семантический слой приводит к некачественным ответам, причем теперь в масштабах диалога.

Агенты дашбордов теперь в общем доступе. Дашборды больше не являются статичными объектами, предназначенными только для трансляции информации: пользователи могут задавать им вопросы, запрашивать краткие сводки по содержимому и изменениям, а также выяснять причины указанных чисел в ходе диалога. Самым ярким примером в корпоративной среде стал YouTube, где менеджеры партнеров получают информацию о портфелях создателей из пятнадцати объединенных источников данных, всё это через обычный дашборд Looker.

Автоматизированные рабочие процессы превращают агентов из пассивных ответчиков в активных наблюдателей. Показатели отслеживаются круглосуточно, и команды получают уведомления сразу при превышении установленных порогов. В ближайших планах — возможность для агентов самостоятельно составлять электронные письма или публиковать сообщения в Slack. Для операционного анализа это имеет гораздо большую ценность, чем кажется, и это тот тип функций, о которых клиенты раньше даже не просили.

Стоит упомянуть и другие новости от Looker:

• Агенты Looker внутри Gemini Enterprise. Агенты, созданные в Looker, могут быть размещены в Gemini Enterprise и управляться вместе с другими корпоративными агентами. Для клиентов, вкладывающих средства в этот решение, Looker становится частью более широкой стратегии использования ИИ, а не отдельным инструментом аналитики данных.

API для анализа диалогов, теперь в составе GA. Он включает в себя нативную интеграцию с SDK Looker, возможность встраивания через iframe и реализацию на основе открытого кода. Команды, внедряющие функции анализа диалогов в собственные приложения, теперь имеют поддерживаемый способ реализации, а диалоги, которые застопорились из-за того, что API находился только в превью-режиме, могут быть возобновлены.

LookML Agent для VS Code (превью). Расширение, охватывающее весь жизненный цикл LookML, начиная с обработки естественного языка.

Looker MCP как открытый стандарт. Существует администрируемый сервер MCP наряду с вариантами на основе открытого кода через MCP Toolbox. Подключение Looker к таким ассистентам, как Claude, позволяет выполнять межсистемный анализ и использовать агентные алгоритмы рассуждений, выходящие за рамки возможностей Looker в одиночку.

Интеграция с нативными семантическими слоями. Looker напрямую читает определения графов в BigQuery и семантические представления в Snowflake, поэтому семантическая логика, уже существующая в BigQuery, больше не требует пересоздания в LookML.

Агенты для множественного анализа. Один агент может использовать до пяти различных способов анализа одновременно. В решении Yahoo данные из отделов кадров, финансов, поиска и поддержки объединяются в единые агенты в нескольких экземплярах Looker.

Чему научились Yahoo и 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 и затем опубликованный там. Третий — это новая концепция «data apps», при которой блокноты Colab публикуются в виде интерактивных приложений.

Data apps находятся между панелями управления и полноценными приложениями. Они полезны для клиентов, которые используют Looker для оперативной отчетности, нуждаются в большей интерактивности и не хотят разрабатывать полноценное встроенное приложение.

Одним из последствий смены бренда и появления новых инструментов самообслуживания является то, что интегрированный решение «Studio in Looker», ранее представленное как будущее интерфейса Looker, стало недоступно для организаций, которые не включили его в свою инфраструктуру, причем его планируется устранить 15 июня 2026 года.

BigQuery: агенты для обработки данных и управляемый сервер MCP

Значительная часть пробных версий прошлого года уже вышла в стадию общедоступности. К ним относятся агенты для обработки данных и проведения научных исследований, инструменты анализа в режиме диалога внутри BigQuery и его API, BigQuery ADK, управляемый удаленный сервер MCP для BigQuery, инструментарий MCP Toolbox с открытым исходным кодом, а также плагин для сбора данных о работе агентов.

Некоторые из новых решений имеют большее значение, чем кажется на первый взгляд.

Масштабирование ресурсов. BigQuery автоматически увеличивает вычислительные мощности, когда агенты активны, и сокращает их, когда они неактивны, без необходимости вручную настраивать размер ресурсов. Таким образом, распространённое возражение относительно высокой стоимости анализа диалогов в масштабах значительно ослабевает.

Графы в BigQuery. Встроенный движок графов без этапа ETL, способный масштабироваться до миллиардов узлов и поддерживающий язык ISO GQL. Особенно интересным нововведением являются функции измерений в BigQuery Graph, которые сочетают стандартизированные метрики с картографированием связей, позволяя агентам анализировать зависимости между различными элементами в несколько этапов.

Метрики как расширения процесса рассуждения. Полезный способ различить эти два вида метрик: метрики LookML управляют процессом вычислений, определяя смысл показателя и обеспечивая единообразие SQL-запросов для всех аналитиков и агентов, использующих Looker. Графовые метрики управляют процессом рассуждения, размещая одинаковые определения показателей внутри графа взаимосвязанных элементов, таких как продукты, поставщики, узлы и маршруты, что позволяет агенту выяснить причины изменения показателя, проследив связи между факторами, влияющими на него.

Услуги миграции

Сервис миграции BigQuery был переименован в Data Analytics Migration Services, и изменения касаются значительной части функционала, поэтому тем, кто планирует перейти с Snowflake, Cloudera или Databricks в 2026 году, следует пересмотреть свои планы. Для Cloudera и Databricks оценка осуществляется автоматически и позволяет получить план с перечнем рабочих нагрузок и оценкой общей стоимости владения. SQL из Hive, Snowflake и других диалектов конвертируется в GoogleSQL на уровне компилятора. Миграция таблиц формата Lakehouse поддерживает форматы Iceberg, Parquet и Hive, причем сервис агентной верификации работает в реальном времени, оценивая точность каждой таблицы и каждой колонки. Поскольку API миграции доступны через MCP, инструменты вроде Claude Code могут координировать весь процесс миграции.

В более ранних версиях сервиса были проблемы с обработкой сложных SQL-запросов, но новое поколение значительно улучшило этот аспект. Особое внимание заслуживает панель проверки корректности данных, поскольку она заменяет множество ручных проверок, которые на протяжении многих лет затягивали процесс миграции. Командам, которые ранее планировали, что аналитикам потребуются недели на ручное сравнение количества строк и значений столбцов, следует пересмотреть эти оценки.

Федерация между облаками

Что касается федерации, то каталог Databricks Unity Catalog на AWS S3 теперь можно читать в обоих направлениях, а Snowflake Polaris и AWS Glue также можно читать из BigQuery. Все это основано на стандарте каталогов Apache Iceberg REST, поэтому BigQuery может выполнять запросы к этим внешним каталогам напрямую без перемещения данных.

Для клиентов, которые не могут или не хотят полностью мигрировать, подход меняется. Вместо настойчивого требования переместить всё в BigQuery предлагается оставить данные на месте, получать к ним доступ через BigQuery, а сверху использовать Looker и Conversational Analytics. Компании Snowflake, которые в противном случае были бы исключены из практики аналитики, ориентированной прежде всего на GCP, получают реальную альтернативу, которая, скорее всего, станет ступенькой к более полной миграции.

Уроки миграции от Target, Wells Fargo и Virgin Media O2

Дискуссия с участием этих трех компаний выявила закономерности, которые многие усвоили на собственном горьком опыте, но которые стоит повторить.

Первое и самое важное правило: сначала внедрите семантический слой. Создайте слой Looker или BI в GCP, чтобы бизнес-пользователи могли получать доступ к данным ещё до завершения процесса их перемещения, и преодолейте этот разрыв с помощью задач тактической репликации, копирующих ключевые наборы данных в BigQuery. Virgin Media O2 добилась этого за счёт шести крупных миграций платформ, а Wells Fargo одобрила этот подход.

Другие подходы:

• Сократите объём данных перед миграцией. Искусственный интеллект может заранее выявить неиспользуемые и дублирующиеся данные; одна из компаний из группы исследований обнаружила, что более 80% её данных были дублированными.
• Сначала выполните миграцию в неизменном виде, а затем модернизируйте систему. Рефакторинг в процессе миграции приводит к непредсказуемым задержкам.

С самого начала необходимо внедрять механизмы управления. Договоры на обработку данных, бизнес-глоссарий и правила качества данных должны входить в программу миграции, поскольку их внедрение позже часто терпит неудачу, когда политические возможности уже исчерпаны.

Начните с простых договоров на обработку данных. Выберите ограниченную область, разработайте четкие договоры с поставщиками и потребителями для этой области и используйте их в качестве образца идеального варианта перед масштабированием.

Команда Target также предложила полезную концепцию — «иррациональные цели»: выбирайте такие цели, которые невозможно достичь, если платформа не будет перестроена с использованием методов, оптимизированных под ИИ. Это отвлекает внимание от вопросов миграции к вопросам трансформации.

Набор инструментов Data Agent

В превью набор Data Agent Kit сочетает расширение для VS Code с плагинами для Gemini CLI, Cloud Code и Codex. Вместе они предоставляют функции и инструменты MCP для рабочих процессов с данными BigQuery: агентные функции, серверы MCP, инструменты для взаимодействия с BigQuery и плагины для глубокой настройки VS Code. Сами функции являются открытым исходным кодом и могут быть адаптированы.

Консалтинговые фирмы и команды клиентов, уже разрабатывающие внутренние инструменты для агентного взаимодействия, должны серьезно рассмотреть этот набор. По предварительным оценкам, он охватывает аспекты инженерии на уровне BigQuery и дополняет более широкие механизмы оркестрации задач и формат LookML, сочетаясь с уже используемыми подходами, основанными на функциях.

Каталог знаний, ранее называвшийся Dataplex, в качестве контекста для агентов

Dataplex теперь называется Knowledge Catalog и выступает в роли контекстного бэкенда для агентных рабочих процессов Google Cloud. Его функционирование обеспечивают три основных компонента. Первый собирает метаданные из сервисов Google, включая Looker, а также из каталогов партнеров, таких как Atlan, Collibra и SAP. Второй обогащает эти метаданные с помощью автоматической генерации информации и бизнес-глоссария, уже находящегося в стадии полного внедрения. Третий предоставляет возможности семантического поиска через Context API, позволяющего агентам получать необходимую информацию.

Наиболее показательным примером стала компания Bloomberg Media. Их «Knowledge Gap Agent» извлекает уроки из неудач агентов, выявляет случаи неверного или отсутствующего контекста данных и предлагает обновления для Knowledge Catalog с целью их утверждения человеком. Основной результат: автоматическое создание 102 примечаний к использованию для двадцати таблиц MVP, что позволило повысить точность работы агента по доступу к данным на 63%.

Для более небольших проектов Knowledge Catalog будет работать в фоновом режиме. Однако для клиентов, которые разрабатывают агентов для анализа диалогов в масштабах, у которых институциональные знания ещё не зафиксированы в формате, доступном для агентов, этот инструмент становится незаменимым. Bloomberg назвал основную проблему «проблемой в 42 доллара», с которой сталкиваются как люди-аналитики, так и ИИ-агенты: знания, которые не задокументированы нигде в платформе данных.

В приведённом ими примере младший аналитик выбрал правильные таблицы, написал корректный SQL-запрос и применил стандартную логику расчёта чистого дохода, но получил неверный результат. Поставщик платежных услуг взимает плату в размере 42 доллара за каждый спор с клиентом, и эта сумма должна учитываться при расчёте дохода. Это правило отсутствовало ни в одной схеме, ни в одном потоке обработки данных, ни в каком доступном документе. Оно хранилось на странице Confluence 2017 года, автор которой уже покинул компанию.

Отсутствует ли семантический движок?

Одна из критик, появившихся позже, гласит, что Google сосредотачивается исключительно на слое агентов, в то время как его семантические и бизнес-механизмы остаются относительно слабыми. Согласно этой точке зрения, Knowledge Catalog напоминает агрегатор метаданных и почти не имеет черт настоящей корпоративной операционной системы, такой как Frontier от OpenAI или Foundry от Palantir. Без мощного семантического движка, связывающего бизнес-значения с агентами, даже современные инструменты могут приводить к неточным результатам, галлюцинациям или правильным ответам на неверные вопросы.

Большая часть этого диагноза остается актуальной, и семантический слой играет ещё более важную роль в мире агентов, чем когда-либо в мире панелей управления. Более оптимистичная точка зрения заключается в том, что семантический слой LookML уже покрывает большинство функций, связанных с бизнес-контекстом, которые от него ожидают от операционной системы предприятия. Он устраняет проблему нескольких версий истины, обеспечивает стандартизированные определения метрик и служит надёжным хранилищем метрик для таких ассистентов, как Claude, через MCP Toolbox.

То, что на конференции в Каталоге знаний почти не говорилось об интеграции с LookML, не означает, что LookML неактивен. Работа над ним происходит на уровень ниже того, где её ищут критики.

Конкретные доказательства приведены в документированных рекомендациях Google по настройке функции Conversational Analytics в Looker. Они основаны на двух основных источниках информации: структуре, полях, метках, описаниях и синонимах в модели LookML, а также уникальных значениях полей, взятых из данных, причем кардинальность (количество уникальных значений) определяет способ их использования.

Для получения уникальных значений функция Conversational Analytics использует давно существующий метод API Looker model_fieldname_suggestions. Этот же механизм, ранее использовавшийся для предложений фильтров в выбрасывателе полей и фильтрах дашборда, теперь применяется в качестве сигнала для формирования модели. Три существующих параметра LookML — suggestions, suggest_explore и suggest_dimension — служат инструментом для разработчиков, позволяющим определять, какие значения будет учитывать функция Conversational Analytics.

Командам не обязательно ждать, пока продукт это сделает; ту же концепцию можно реализовать вручную в хранилище BigQuery. Помимо стандартного словаря данных, полученного из INFORMATION_SCHEMA, можно вести руководство в формате Markdown, которое доступно ассистенту в качестве функции и периодически генерируется в ходе анализа профиля. В нем описываются каждая таблица с количеством строк, диапазонами дат, а также наборами значений и кардинальностями категориальных полей с высокой значимостью, чтобы ассистент знал, например, что таблица сообщений распределяется между iMessage, Slack, WhatsApp и другими в известных пропорциях, вместо того чтобы догадываться.

Теперь функция Conversational Analytics выполняет аналогичные действия на уровне 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, что и интерфейсы дашбордов и инструменты анализа.

Поэтому восприятие Knowledge Catalog и LookML отличается. В настоящее время LookML выглядит как один из многих источников данных в архитектуре Knowledge Catalog, и легко понять, почему это может казаться недостаточным. В течение следующих двенадцати–восемнадцати месяцев ожидается значительное изменение ситуации, поскольку у Google есть все основания сделать LookML основным источником данных в каталоге, а не лишь одним из нескольких.

Семантический движок, к которому призывают критики, на самом деле отсутствует не полностью, поскольку большая его часть уже реализована в LookML. Остается неясным, сможет ли Knowledge Catalog развиться в слой бизнес-контекста, который будет передавать смысл LookML по всей архитектуре системы, или же эту роль возьмет на себя другой продукт. В любом случае время, затраченное на правильную настройку LookML, окупается.