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
Конференція 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 стає частиною більш широкої стратегії використання ШІ, а не окремим інструментом аналітики даних.
Що дізналися Yahoo та Virgin Media O2
Сесії аналітики спілкування від Yahoo та Virgin Media O2 виявилися найціннішими для тих, хто займається цією роботою. Основний висновок: точність залежить переважно від двох факторів – ідеальних запитів та інструкцій для агентів, написаних у форматі YAML. Yahoo помітило кращі результати після того, як перевело інструкції для агентів з формату JSON у YAML. Потім вони перемістили ідеальні запити та бізнес-глосарій у формат LookML замість того, щоб залишати їх в іншому місці, що значно скоротило складність інструкцій, адже тепер модель обробляє інформацію на рівні семантики, а не на основі вручну написаного контексту.
Власне узагальнення Yahoo стало найцитованішою фразою заходу: аналітика спілкування починається з семантичного рівня, а не з ШІ. Як тільки дані та модель готові, аналітика спілкування є майже наступним кроком у її розвитку.
Практичним підходом для команд є зміна стратегії роботи. Натомість надмірно довгих та ретельно налаштованих інструкцій для агентів починають використовувати для покращення самої моделі, адже все, що розміщується в LookML, є доступним для кожного агента та кожного користувача, тоді як інструкції, розміщені окремо, слугують лише одному агенту та поступово втрачають актуальність.
У результаті змінився підхід до створення якісних моделей LookML для аналізу діалогів. Базова версія тепер включає мітки, описи, синоніми та коментарі до кожного поля, вбудовані запити типу „golden queries“ у форматі LookML, а також YAML-глосарій термінів у межах самої моделі. Інструкції для агентів залишаються мінімальними, оскільки семантичний шар виконує більшу частину роботи. Налаштування агентів Dashboard, запуск робочих процесів та використання „golden queries“ тепер мають бути частиною базових вимог будь-якої серйозної системи Looker, а не просто додатковими опціями.
Повернення Data Studio
Looker Studio знову отримав назву Data Studio з розширеними функціями. Тепер він обробляє три типи продуктів. Перший — це звичні звіти чи панелі керування, які формуються з даних BigQuery, з’єднувачів Google та партнерів типу SaaS чи семантичного шару Looker. Другий — це агент аналітики для спілкування, створений у BigQuery та опублікований там. Третій — це нова концепція „даних-додатків“, за якої нотатки Colab публікуються як інтерактивні додатки.
Додатки на основі даних знаходяться між панелями керування та повноцінними додатками. Вони корисні для клієнтів, які використовують Looker для оперативного звітування, прагнуть більшої інтерактивності та не хочуть створювати повноцінні вбудовані додатки.
Одним із наслідків зміни бренду та появи нової системи самообслуговування є те, що інтегрований інструмент „Studio in Looker“, який раніше пропонувався як майбутнє фронтенду Looker, став недоступним для організацій, які його не активували, і його планують вивести з експлуатації 15 червня 2026 року.
BigQuery: агенти для обробки даних та керований сервер MCP
Чимала кількість пробних версій минулого року вже стала загальнодоступними. До них належать агенти для обробки даних та наук про дані, інструменти аналітики в межах BigQuery та його API, BigQuery ADK, керований віддалений сервер MCP для BigQuery, інструментарій MCP Toolbox з відкритим кодом, а також плагін для збору даних про роботу агентів.
Деякі нові інструменти мають більше значення, ніж здається на перший погляд.
Масштабування ресурсів. BigQuery додає обчислювальні ресурси, коли агенти активні, та знімає їх, коли вони неактивні, без необхідності ручного налаштування розміру. Типові заперечення щодо витрат на аналітику розмов у масштабі значно послаблюються.
BigQuery Graphs. Вбудований графовий двигун без кроку ETL, здатний масштабуватися до мільярдів вузлів та підтримувати ISO GQL. Ще більш цікавим доповненням є функція Measures у 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 долари», яка стосується як людських аналітиків, так і AI-агентів: знання, які не задокументовані ніде в платформі даних.
У їхньому прикладі молодший аналітик обрав правильні таблиці, написав коректний 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, окупиться.
Пов’язані матеріали
- Практичні нотатки: RAG мертвий. LLM Wiki та ідея Andrej Karpathy – це те, що буде далі: Детальний огляд практичних нотаток: RAG мертвий. LLM Wiki та ідея Andrej Karpathy – це те, що буде далі: контракти, перевірки та шаблони коду для команд, які використовують RAG.