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

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

BigQuery и безграничный Lakehouse от Google Cloud предлагают оптимизированный способ решения этой задачи на основе открытой спецификации Apache Iceberg REST catalog. Вместо перемещения данных в вычислительный движок вы можете перенести вычислительные мощности Google Cloud и генеративный ИИ непосредственно к вашим данным, выполняя запросы по месту их нахождения в Databricks, Snowflake и AWS Glue.

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

Рисунок 1: BigQuery объединяет метаданные из внешних каталогов Apache Iceberg REST через Lakehouse, обеспечивая разговорную аналитику по месту нахождения данных без их миграции.

Архитектура безграничного Lakehouse

Это решение использует каталог среды выполнения Lakehouse для синхронизации метаданных от других облачных провайдеров, что позволяет запрашивать данные с помощью BigQuery или внешних движков с открытым исходным кодом через конечную точку Apache Iceberg REST catalog, и все это без миграции данных. Поскольку Databricks Unity Catalog, Snowflake Horizon Catalog и AWS Glue Data Catalog поддерживают открытую спецификацию Apache Iceberg REST catalog, вы можете применять единый шаблон подключения ко всем трем платформам.

Когда вы выполняете федеративный запрос, каталог среды выполнения Lakehouse отделяет синхронизацию метаданных от доступа к хранилищу:

Синхронизация метаданных: каталог среды выполнения Lakehouse периодически синхронизирует схемы, указатели снимков и определения таблиц из удаленного каталога в соответствии с заданным вами графиком обновления.

Синхронизация метаданных: каталог среды выполнения Lakehouse периодически синхронизирует схемы, указатели снимков и определения таблиц из удаленного каталога в соответствии с заданным вами графиком обновления.

Прямой доступ к хранилищу: во время выполнения запроса совместимый движок считывает файлы данных Parquet непосредственно из удаленного объектного хранилища, такого как Amazon S3, используя временные учетные данные, выданные удаленной платформой.

Прямой доступ к хранилищу: во время выполнения запроса совместимый движок считывает файлы данных Parquet непосредственно из удаленного объектного хранилища, такого как Amazon S3, используя временные учетные данные, выданные удаленной платформой.

Вся обработка запросов выполняется в рамках вычислительных мощностей Google Cloud, таких как BigQuery или Managed Service for Apache Spark. Удаленные кластеры Databricks, виртуальные хранилища Snowflake и вычислительные экземпляры AWS во время выполнения не задействуются.

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

Вы можете использовать ИИ для создания образцов данных. Сведения о схемах таблиц приведены ниже.

Настройка Databricks Unity Catalog

Мы начинаем в Databricks с подготовки каталога и таблицы. В Unity Catalog для федеративного доступа требуется, чтобы ваша целевая схема была связана с внешним расположением, зарегистрированным в Databricks:

Вы можете использовать ИИ для создания образцов данных. Сведения о схемах таблиц приведены в каждом разделе.

Вы можете использовать ИИ для создания образцов данных. Сведения о схемах таблиц приведены в каждом разделе.

Прежде чем внешние движки смогут прочитать эту таблицу, администратор метахранилища Databricks должен включить доступ к внешним данным (External data access) на вкладке сведений о метахранилище.

Перейдите в учетную запись администратора Databricks и в разделе управления пользователями (User Management) создайте субъект-службу (Service Principal) Databricks и запишите его UUID "6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx"

Подключение Databricks к BigQuery

Затем создайте федеративный каталог внутри Google Cloud с помощью командной строки gcloud. Вам понадобятся URL-адрес вашего рабочего пространства Databricks и идентификатор приложения вашего субъекта-службы Databricks:

После создания опишите каталог, чтобы просмотреть назначенную ему учетную запись службы:

Вернитесь в Databricks, чтобы назначить разрешения вашему субъекту-службе:

Вы должны предоставить привилегию EXTERNAL USE SCHEMA субъекту-службе Databricks для целевых схем или каталога, чтобы включить выдачу учетных данных для доступа к внешним данным.

Наконец, чтобы завершить подключение, настройте политику федерации для субъекта-службы Databricks со следующими данными -

URL-адрес издателя* - https://accounts.google.com

URL-адрес издателя* -

Субъект* - числовой идентификатор субъекта, возвращенный командой описания каталога, например 1124251400450xxxxxxxx

Субъект* - числовой идентификатор субъекта, возвращенный командой описания каталога, например 1124251400450xxxxxxxx

Аудитории - https://accounts.cloud.databricks.com

Аудитории - https://accounts.cloud.databricks.com

Выполнение одного запроса по трем облакам

К федеративным таблицам Iceberg в BigQuery обращаются с помощью четырехкомпонентных путей: project.catalog.namespace.table.

В нашей среде транзакции продаж находятся непосредственно в BigQuery:

Теперь мы можем выполнить один SQL-запрос, объединяющий наши собственные транзакции продаж с записями клиентов в Snowflake, линейками продуктов в Databricks и местоположениями магазинов в AWS Glue:

BigQuery обрабатывает объединения по месту нахождения данных. Обратите внимание, что идентификаторы Snowflake отображаются в верхнем регистре (CORE.DIM_CUSTOMERS), в то время как Databricks и AWS Glue сохраняют пути к таблицам в нижнем регистре.

Рисунок 2 - Результаты запроса, объединяющие данные из Snowflake, Databricks и AWS Glue.

Изучение межоблачных данных с помощью естественного языка

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

Чтобы предоставить разговорной аналитике полный операционный контекст, мы сохраняем наше федеративное объединение как логическое представление:

Анализ эффективности продаж на естественном языке

Когда вы спрашиваете разговорную аналитику в BigQuery:

"Кто наши лучшие клиенты по общему доходу от продаж, какие товары они купили и в каких магазинах они совершали покупки?"

Разговорная аналитика оценивает схему во всех трех удаленных каталогах, генерирует SQL-запрос, выполняет его и представляет ответ.

Рисунок 3: Разговорная аналитика в BigQuery преобразует запросы на обычном языке в федеративные запросы к Snowflake, Databricks и AWS Glue.

Планирование кэширования и резидентности данных

Перед развертыванием федеративных каталогов в рабочей среде рассмотрите следующие особенности работы:

Время фонового обновления: флаг --refresh-interval управляет синхронизацией метаданных. Минимальный интервал составляет 300 секунд. Для крупных каталогов, содержащих сотни таблиц, получение метаданных может занять больше времени. Если цикл синхронизации превышает установленное время, BigQuery пропускает следующий запланированный запуск, чтобы избежать накопления задач в очереди.

Время фонового обновления: флаг --refresh-interval управляет синхронизацией метаданных. Минимальный интервал составляет 300 секунд. Для крупных каталогов, содержащих сотни таблиц, получение метаданных может занять больше времени. Если цикл синхронизации превышает установленное время, BigQuery пропускает следующий запланированный запуск, чтобы избежать накопления задач в очереди.

Автоматическое кэширование запросов: BigQuery кэширует полученные блоки межоблачных данных в регионе, где находится ваш федеративный каталог (например, us-central1). Это помогает сократить сетевой трафик при повторных запросах. Поскольку кэшированные блоки хранятся в хранилище Google Cloud в этом регионе, убедитесь, что это соответствует политикам резидентности данных вашей организации.

Автоматическое кэширование запросов: BigQuery кэширует полученные блоки межоблачных данных в регионе, где находится ваш федеративный каталог (например, us-central1). Это помогает сократить сетевой трафик при повторных запросах. Поскольку кэшированные блоки хранятся в хранилище Google Cloud в этом регионе, убедитесь, что это соответствует политикам резидентности данных вашей организации.

Управление шифрованием: для блоков межоблачного кэша используются ключи шифрования, управляемые Google. Если в вашей организации применяется ограничение политики constraints/gcp.restrictNonCmekServices, BigQuery будет обходить кэш и считывать данные напрямую из удаленного хранилища для каждого запроса.

Управление шифрованием: для блоков межоблачного кэша используются ключи шифрования, управляемые Google. Если в вашей организации применяется ограничение политики constraints/gcp.restrictNonCmekServices, BigQuery будет обходить кэш и считывать данные напрямую из удаленного хранилища для каждого запроса.

Мониторинг метрик доступа: вы можете оценить использование кэша в планах выполнения запросов. Проверьте раздел objectStorageStats в статистике заданий BigQuery, чтобы сравнить cacheBytesRead с objectStorageBytesRead.

Мониторинг метрик доступа: вы можете оценить использование кэша в планах выполнения запросов. Проверьте раздел objectStorageStats в статистике заданий BigQuery, чтобы сравнить cacheBytesRead с objectStorageBytesRead.

Дальнейшие шаги

Подводя итог, borderless Lakehouse от Google Cloud помогает вам активировать данные независимо от того, где они находятся, без дорогостоящей миграции или создания дополнительных конвейеров данных. Начните сегодня, изучив документацию по архитектуре borderless Lakehouse, чтобы узнать больше о поддерживаемых регионах и конфигурациях учетных данных. Вы можете пройти codelab по borderless Lakehouse, чтобы пошагово попрактиковаться в федерации внешних каталогов. Наконец, свяжитесь с вашей командой по работе с клиентами Google Cloud или инженером по работе с клиентами, чтобы оценить паттерны borderless lakehouse для ваших конкретных платформ данных или отраслей.

Приложение

Настройка межоблачного доступа к данным Snowflake и AWS Glue

Подключение Snowflake и BigQuery

Настройка каталога Snowflake Horizon

Мы начнем в Snowflake с создания базы данных, схемы и таблицы Iceberg. В Snowflake Horizon управляемые таблицы Iceberg автоматически предоставляют открытый интерфейс каталога Apache Iceberg REST:

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

SQL

Затем создайте федеративный каталог внутри Google Cloud с помощью инструмента командной строки gcloud. Вам понадобятся идентификатор вашей учетной записи Snowflake, роль читателя и имя корневой базы данных Iceberg:

bash

В спецификации Apache Iceberg REST параметр --snowflake-warehouse ссылается на имя корневой базы данных каталога (SF_RETAIL_DB), а не на виртуальное вычислительное хранилище.

После создания выполните команду describe для каталога, чтобы просмотреть назначенный ему числовой идентификатор сервисного аккаунта:

bash

Вернитесь в Snowflake, чтобы привязать числовой идентификатор Google Cloud к сервисному пользователю без пароля через Workload Identity Federation (WIF):

SQL

Это устанавливает аутентификацию без пароля через OpenID Connect, позволяя BigQuery обнаруживать метаданные таблиц и предоставлять временные учетные данные во время выполнения запроса напрямую из Snowflake Horizon.

Настройка каталога данных AWS Glue

Мы начнем в AWS с подготовки идентификатора IAM, настройки разрешений доступа к AWS Glue и Amazon S3 и регистрации таблицы Iceberg.

Сначала создайте временную политику доверия с именем trust_policy.json. Это позволит вам подготовить роль AWS IAM до того, как Google Cloud назначит уникального сервисного агента каталога:

Создайте роль IAM с помощью AWS CLI. Установка длительности сеанса в 12 часов (43200 секунд) предотвращает истечение срока действия учетных данных во время длительных аналитических запросов:

Затем определите политику разрешений в файле с именем permissions_policy.json. Эта политика предоставляет BigQuery разрешение на чтение метаданных каталога AWS Glue и доступ к базовым файлам данных Parquet в Amazon S3:

Прикрепите эту политику разрешений к вашей только что созданной роли:

Важно (AWS Lake Formation): если ваша среда AWS использует AWS Lake Formation, убедитесь, что группа IAMAllowedPrincipals имеет доступ к целевой базе данных и таблице (или предоставьте явные разрешения Lake Formation для lakehouse_glue_federation_role, если корзина зарегистрирована в AWS Lake Formation). Без этого настройки безопасности Lake Formation заблокируют доступ роли IAM к метаданным каталога.

После настройки разрешений создайте базу данных и таблицу Iceberg в AWS Glue с помощью Amazon Athena:

Подключение AWS Glue к BigQuery

Затем зарегистрируйте федеративный каталог внутри Google Cloud с помощью инструмента командной строки gcloud. Вам понадобятся ваш 12-значный идентификатор аккаунта AWS, регион AWS и ARN роли, созданной выше:

Чтобы предотвратить преждевременные сбои фонового обновления во время распространения политики доверия AWS, инициализируйте каталог без настройки расписания обновления.

Затем извлеките уникальный числовой идентификатор субъекта, назначенный каталогу Google Cloud:

Вернитесь в AWS CLI и обновите политику доверия вашей роли IAM, заменив временное значение проверенным идентификатором Google Cloud: