Google PDE: Аналитика с BigQuery и инженерия хранилищ — Руководство по подготовке

By Laurynas Brazys · 22 August 2026 · #google #PDE #certification #exam-prep #study-guide

Часть Google Professional Data Engineer — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

BigQuery — это бессерверное, колоночное, MPP-хранилище для аналитики, которое разделяет хранение и вычисления, обеспечивая практически неограниченное масштабирование, поддержку ANSI SQL и встроенное управление. Проектирование хранилища на BigQuery требует баланса между дизайном схемы (партиционирование, кластеризация, денормализация в сравнении с нормализацией, вложенные записи), шаблонами загрузки данных (пакетная загрузка, потоковая передача, Storage Write API) и управлением рабочими нагрузками (редакции on-demand и на основе емкости, резервирования). Надежная безопасность (авторизованные представления, политики на уровне строк/столбцов, теги политик) сочетается с инструментами контроля затрат и производительности для минимизации количества сканируемых байт и сокращения задержки. В этом разделе рассматриваются ключевые аспекты проектирования, эксплуатации и сценарии сбоев, которые необходимо предвидеть в производственной среде.

Хранение и семантика: наборы данных, таблицы, представления и доступ к озеру данных

• Наборы данных (Datasets), таблицы, представления:

  • Наборы данных определяют область действия IAM и управления. Используйте отдельные наборы данных для каждого клиента (tenant) для изоляции и прозрачности биллинга.
  • Стандартные таблицы хранят данные в нативном формате; партиции и кластеризация управляют размещением данных и отсечением (pruning).
  • Представления инкапсулируют SQL-логику, не храня данных. Авторизованные представления позволяют владельцу представления предоставлять доступ к ограниченным подмножествам данных другим проектам или клиентам, скрывая базовые таблицы.
  • Материализованные представления (MVs) сохраняют предварительно вычисленные результаты и автоматически обновляются. Перезапись запросов использует MV прозрачно, если они совместимы; несовместимые предикаты или функции обходят их.
  • Внешние таблицы ссылаются на данные в Cloud Storage, Google Drive или Google Sheets. Они позволяют избежать загрузки данных, но жертвуют пропускной способностью и поддержкой функций ради удобства. Для повторяющейся аналитики загружайте данные в нативные таблицы.

• Партиционирование, кластеризация и вложенные записи:

  • Партиционируйте по времени загрузки, DATE/TIMESTAMP/DATETIME или диапазону целых чисел, чтобы сокращать объем сканирования. Используйте фильтры WHERE по столбцу партиционирования или декораторы, такие как _PARTITIONDATE, чтобы включить отсечение.
  • Кластеризуйте по столбцам с высокой кардинальностью, по которым часто выполняется фильтрация или объединение (до 8 столбцов). BigQuery выполняет перекластеризацию автоматически; повторяющиеся небольшие DML-операции могут временно ухудшить качество кластеризации.
  • Вложенные и повторяющиеся записи (STRUCT, ARRAY) моделируют отношения «один ко многим» без накладных расходов на объединение (join). Используйте UNNEST осмотрительно; многократное применение UNNEST к большим массивам может привести к резкому увеличению объема данных.

• Денормализация в сравнении с нормализацией:

  • Денормализуйте атрибуты измерений в таблицы фактов, чтобы минимизировать объединения и использовать преимущества колоночного сканирования; это идеально подходит для аналитики с преобладанием операций чтения.
  • Нормализуйте, когда умножение операций записи, «горячие точки» обновлений или самообъединения (self-joins) вызывают конфликты или усложняют схему (например, разделение таблиц с основными данными пациентов и данными о визитах, чтобы избежать взрывного роста данных при самообъединении). Рассмотрите гибридный подход: нормализованные ключевые сущности с широкими, денормализованными таблицами фактов или вложенными дочерними записями.

• Материализованные представления: соображения по проектированию

  • Лучше всего подходят для стабильных, инкрементальных агрегатов над партиционированными базовыми таблицами. Обновление MV происходит асинхронно; потребители данных должны допускать окна устаревания данных или запрашивать базовые таблицы в качестве запасного варианта.
  • Для инкрементального обновления фильтруйте и группируйте по столбцу партиционирования. Недетерминированные функции, неподдерживаемые объединения или UDF могут сделать MV непригодными для перезаписи запроса.

• Федеративные запросы, BigLake и проталкивание операций (pushdown):

  • Федеративные запросы считывают данные напрямую из внешних систем (например, Cloud SQL) с помощью SQL. Они удобны для легких объединений или разовых исследований, но имеют более высокую задержку и более строгие квоты; для интенсивной аналитики извлекайте данные в BigQuery.
  • Таблицы BigLake объединяют управление озером данных (lake) и хранилищем с контролем на уровне столбцов и строк над данными в Cloud Storage или в открытых табличных форматах (например, Parquet). Проталкивание предикатов и проекций (pushdown) уменьшает количество загружаемых байт; при больших сканированиях все же предпочтительнее загрузка в нативные таблицы для максимальной производительности.

• Таблицы с использованием wildcards и устаревшее шардирование:

  • Запросы с использованием wildcards — это устаревший шаблон для таблиц, шардированных по дате. Предпочитайте нативное партиционирование, но при необходимости используйте:

undefined

.

← Хранение данных · Все домены · Потоковая обработка с Dataflow и Apache Beam →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Google →