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

С помощью универсального решения Google Cloud Lakehouse вы теперь можете выполнять запросы к управляемым Databricks таблицам Apache Iceberg напрямую из BigQuery. Этот подход без копирования устраняет необходимость дублирования данных: BigQuery читает те же файлы, которые записывает Databricks, а новые изменения появляются после следующего запланированного обновления метаданных Lakehouse (так часто, как каждые 5 минут).

Как Lakehouse и Databricks работают вместе

Управляемые таблицы Iceberg автоматически генерируют метаданные, совместимые с Iceberg, наряду с собственными журналами Delta. Команды инженеров по обработке данных могут единожды сохранить файлы Parquet в Google Cloud Storage (GCS) с помощью Databricks. Вместо загрузки этой информации в BigQuery, Lakehouse считывает метаданные Iceberg напрямую, применяя векторизованный движок BigQuery непосредственно к файлам открытого формата в GCS.

Хотя Google Cloud Storage (GCS) служит основным уровнем хранения в приведенном выше примере, Lakehouse распространяет эту универсальную федерацию непосредственно на внешние облачные среды, такие как Amazon S3 и Azure Blob Storage. Объединяя открытый каталог Apache Iceberg REST Catalog с межоблачными подключениями, Lakehouse позволяет BigQuery запрашивать данные в разных облаках без их перемещения. Каждый федеративный каталог располагается в выбранном вами регионе Google Cloud, в идеале — в регионе, наиболее близком к вашим данным. Это позволяет BigQuery считывать файлы Parquet открытого формата там, где они находятся, обеспечивая мультиоблачную аналитику без конвейеров репликации. Плата за исходящий трафик удаленного облака по-прежнему взимается, но межоблачное соединение Cross-Cloud Interconnect (AWS) и кэширование Lakehouse могут ее снизить.

Помимо простого запроса внешних данных, фреймворк Lakehouse устанавливает истинную оперативную совместимость чтения и записи (R/W) между движками. Поскольку платформа построена на открытой основе Apache Iceberg, команды специалистов по работе с данными могут легко выполнять многооператорные SQL-команды непосредственно внутри BigQuery.

Централизованная безопасность и управление

Управление контролем доступа в разрозненных системах может создавать уязвимости. Lakehouse решает эту проблему посредством делегированного доступа. Администраторы могут настроить подключение к облачным ресурсам BigQuery (Cloud Resource Connection), привязанное к сервисному аккаунту, который управляет правами IAM для бакаутов GCS. Предоставление пользователям доступа к сущности таблицы Lakehouse позволяет применять средства контроля BigQuery, включая безопасность на уровне строк и столбцов, а также динамическое маскирование данных для внешних таблиц Iceberg, в то время как Databricks занимается загрузкой данных.

Федерация каталогов и выдача учетных данных

Раньше подключение этих платформ означало ручную настройку запросов BigQuery для указания на статические пути к метаданным. Современные настройки используют открытый API каталога Apache Iceberg REST Catalog. Databricks Unity Catalog функционирует как центральный уровень метаданных, позволяя администратору BigQuery настроить каталог среды выполнения Lakehouse с федеративным подключением. При выполнении запроса Lakehouse обращается к Unity Catalog за текущим состоянием таблицы, а через выдачу учетных данных (credential vending) выдаются краткосрочные токены, предоставляющие BigQuery временный доступ на чтение к GCS.

Усечение разделов

BigQuery использует метаданные Iceberg каждой таблицы для планирования запроса, а затем считывает на месте только релевантные файлы данных. Скрытое секционирование Iceberg позволяет выполнять фильтрацию по логическим столбцам, таким как метки времени, без знания структуры каталогов. Обратите внимание, что управляемые таблицы Iceberg в Databricks не поддерживают преобразования разделов; вместо этого Databricks рекомендует использовать жидкую кластеризацию (liquid clustering).

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

Быстрые запросы с метаданными Iceberg и кэшированием Lakehouse

Манифесты Iceberg уже определяют, какие файлы данных следует читать, поэтому BigQuery не нуждается в кэше метаданных для таблиц Iceberg. Для межоблачных таблиц, таких как таблицы в Amazon S3, кэширование Lakehouse (предварительная версия) сохраняет извлеченные блоки данных в Google Cloud, чтобы повторяющиеся запросы считывали их локально. BigQuery считывает файлы манифестов Iceberg напрямую при планировании каждого запроса; включать кэширование метаданных не требуется. Это динамическое усечение разделов обходит ненужные файлы, значительно сокращая время выполнения и объем сканируемых байтов.

Обслуживание и управление жизненным циклом

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

Поддержание оптимизации ваших таблиц

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

Запускайте регулярные конвейеры компактизации с помощью API Databricks для объединения мелких файлов Parquet в более крупные оптимизированные структуры и используйте предиктивную оптимизацию (Predictive Optimization).

Запускайте регулярные конвейеры компактизации с помощью API Databricks для объединения мелких файлов Parquet в более крупные оптимизированные структуры и используйте предиктивную оптимизацию (Predictive Optimization).

Выполняйте команду VACUUM в Databricks для очистки неиспользуемых файлов вне активных снимков (snapshots), чтобы избежать дополнительных затрат на хранение в GCS.

Выполняйте команду VACUUM в Databricks для очистки неиспользуемых файлов вне активных снимков (snapshots), чтобы избежать дополнительных затрат на хранение в GCS.

Компактизация и проблема мелких файлов

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

Запуск обычной компактизации в Iceberg устраняет эти неэффективности. Databricks управляет этим автоматически с помощью жидкой кластеризации (Liquid Clustering), которая динамически настраивает макеты файлов в зависимости от шаблонов доступа, или с помощью встроенных утилит управления таблицами.

Чтобы выполнить компактизацию мелких файлов вручную в Databricks, запуск OPTIMIZE:

Выполнение этой команды объединяет разрозненные сегменты файлов в более крупные структурированные блоки (обычно размером от 256 МБ до 512 МБ), которые могут помочь улучшить пропускную способность сканирования BigQuery. Подход binpack работает быстро, уделяя первостепенное внимание балансировке общего размера файлов, хотя альтернативные стратегии сортировки могут организовывать упорядочение набора данных по определенным ключам столбцов.

Управление потерянными файлами и хранением снимков (VACUUM)

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

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

Стандартные конфигурации применяют обязательный семидневный порог (deletedFileRetentionDuration) перед выполнением процедур VACUUM. Соблюдение этой задержки предотвращает возникновение ошибок отсутствия файлов в активных аналитических заданиях и одновременно сохраняет возможности исторического восстановления. Планирование регулярных заданий VACUUM или запуск их с помощью предиктивной оптимизации позволяет удалять нессылочные файлы данных, а для таблиц с чтением Iceberg — старые метаданные Iceberg. Это снижает затраты на хранение и поддерживает высокую производительность во всем вашем lakehouse.

Заключение

Подключение наборов данных Databricks Apache Iceberg к Lakehouse может помочь вам задействовать ваши данные с помощью BigQuery. Разделяя обработку и базовое хранилище, используя открытые форматы и стандартные REST API с выдачей учетных данных, вы можете выполнять масштабируемые инженерные рабочие нагрузки и параллельную аналитику без миграции данных или ущерба для производительности.

Сочетание чтения Databricks Iceberg (UniForm) с федерацией Lakehouse, кэшированием Lakehouse и регулярным обслуживанием OPTIMIZE и VACUUM помогает создать эффективный lakehouse без дублирования данных. Такой подход помогает снизить расходы на хранение, позволяет избежать хрупкого обслуживания конвейеров и подготавливает вашу среду данных для современной аналитики и новых рабочих нагрузок ИИ.

Создание унифицированной архитектуры больше не требует перемещения файлов данных между платформами. Вы можете начать запрашивать таблицы Databricks Iceberg, зарегистрировав их в каталоге среды выполнения Lakehouse уже сегодня для двунаправленной федерации. Узнайте больше, прочитав нашу документацию, чтобы начать работу.