Google PDE: Хранение данных, озера и форматы файлов — Руководство по подготовке

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

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

Обзор

Хранение данных в Google Cloud охватывает необработанное объектное хранилище, курируемые озера данных и форматы, оптимизированные для аналитики. Создание надежных, управляемых и производительных озер данных требует тщательного выбора классов хранения, настроек бакетов, местоположений, форматов файлов, структуры таблиц и жизненного цикла. В этом разделе подробно рассматриваются компромиссы при проектировании, сценарии сбоев, которых следует избегать, и паттерны, совместимые с BigQuery, Spark и потоковыми конвейерами в больших масштабах.

Основы Cloud Storage: классы, бакеты, согласованность и жизненный цикл

Cloud Storage — это надежная и высокодоступная основа для хранения необработанных и курируемых файлов.

• Классы хранения

  • Standard (горячий): частый доступ, минимальная задержка. Нет минимального срока хранения.
  • Nearline (прохладный): нечастый доступ (~раз в месяц). Минимальный срок хранения 30 дней; взимается плата за извлечение.
  • Coldline (холодный): редкий доступ (~раз в квартал). Минимальный срок хранения 90 дней; более высокая плата за извлечение.
  • Archive (архивный): долгосрочное хранение (~раз в год). Минимальный срок хранения 365 дней; самая высокая плата за извлечение.
  • Autoclass может автоматически перемещать данные между классами; убедитесь, что плата за досрочное удаление и шаблоны доступа не сведут на нет экономию.

• Местоположения и репликация бакетов

  • Регион (Region): оптимален для локальности данных и соответствия требованиям в пределах одной географической зоны.
  • Двойной регион (Dual-region): два парных региона с автоматической репликацией; турбо-репликация (turbo replication) быстро фиксирует реплики с RPO, измеряемым в минутах; идеально для аварийного восстановления (DR) с низким RPO.
  • Мультирегион (Multi-region): геораспределенный в пределах континента для широкой доступности, распространения контента и аналитики на большой территории.
  • Выбирайте местоположения, чтобы соответствовать законам о резидентности данных и минимизировать исходящий трафик/задержку до вычислительных ресурсов (Dataproc, Dataflow, внешние таблицы BigQuery).

• Согласованность и семантика

  • Cloud Storage обеспечивает строгую глобальную согласованность типа «чтение после записи» (read-after-write), «чтение после обновления метаданных» (read-after-metadata-update) и «листинг после записи» (list-after-write).
  • Запись объектов атомарна и неизменяема; «переименование» — это паттерн «копирование + удаление». Проектируйте операции копирования идемпотентными и проверяйте контрольные суммы для предотвращения частичных миграций.

• Шаблоны доступа и производительность

  • Параллельные составные загрузки (parallel composite uploads) и возобновляемые загрузки (resumable uploads) повышают пропускную способность для больших файлов.
  • Чтение по диапазонам (range reads) обеспечивает эффективную работу с колоночными футерами и выборочное чтение.
  • Избегайте множества мелких файлов (<8 МБ), которые увеличивают накладные расходы на метаданные/листинг; объединяйте или уплотняйте их в более крупные объекты.
  • GZIP не поддается распараллеливанию для распределенного чтения; для масштабируемой обработки предпочитайте Parquet/ORC/Avro+Snappy.

• Жизненный цикл, хранение и версионирование

  • Политики хранения на уровне бакета и блокировки объектов (на основе событий или временные) обеспечивают неизменяемость для соответствия требованиям и сокращения случайных удалений.
  • Версионирование объектов сохраняет предыдущие поколения; полезно для восстановления после перезаписи/удаления. Следите за ростом затрат на хранение.
  • Правила жизненного цикла автоматизируют перемещение и удаление. Пример (JSON) для перемещения старых данных в более холодное хранилище и удаления через год: { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
  • Сценарии сбоев: плата за досрочное удаление при слишком агрессивном перемещении; сроки блокировки для хранения нельзя сократить; версионирование без уплотнения может привести к росту затрат.

• Передача и миграция данных

  • Используйте Storage Transfer Service для распараллеленных перемещений с контрольными точками из локальной среды или других облаков; Transfer Appliance — для офлайн-передачи петабайтов данных.
  • Проверяйте целостность с помощью CRC32C/MD5 и предварительных условий совпадения поколений (generation-match) для предотвращения состояний гонки.
  • Предпочитайте использовать gsutil/gcloud storage с флагом -m (параллельное выполнение) и контрольными суммами; избегайте узких мест SFTP при передаче больших объемов входящих данных.

Унифицированное управление озером данных с помощью BigLake и Dataplex

BigLake и Dataplex стандартизируют безопасность и управление файлами и таблицами.

• BigLake

  • Представляет данные из Cloud Storage в виде управляемых BigQuery таблиц (внешних) с едиными гранулярными средствами контроля доступа, включая политики доступа на уровне строк и теги политик на уровне столбцов.
  • Обеспечивает отсечение столбцов (column pruning) и проталкивание предикатов (predicate pushdown) для Parquet/ORC, сокращая объем сканируемых байтов и исходящего трафика к таким движкам, как BigQuery, Spark на Dataproc и Dataflow.
  • Централизует аудит через Cloud Logging и применение политик; единая плоскость управления для файлов озера и таблиц хранилища.

• Dataplex

  • Организует данные в озера (lakes), зоны (сырые, курируемые, доверенные) и ресурсы (бакеты, наборы данных); управляет метаданными, происхождением данных (lineage) и правилами качества данных.
  • Интегрируется с тегами политик для конфиденциальных столбцов и поддерживает принцип наименьших привилегий через IAM на уровне озер, зон и ресурсов.
  • Способствует стандартизации именования, партиционирования и управления схемами в средах с несколькими командами, чтобы избежать «свалок данных».

• Паттерны управления

  • Реализуйте паттерны «набор данных на клиента» и «бакет на зону»; избегайте утечки данных между клиентами.
  • Используйте политики доступа на уровне строк и теги политик на уровне столбцов для PII. Ограничивайте доступ к API только для утвержденных удостоверений.
  • Проводите аудит доступа с помощью Cloud Logging; направляйте отфильтрованные логи в Pub/Sub для мониторинга в реальном времени.

Форматы файлов, сжатие и поведение запросов

Выбор правильного формата напрямую влияет на стоимость и производительность.

• Колоночные форматы (Parquet, ORC)

  • Преимущества: отсечение колонок (column pruning), проталкивание предиката (predicate pushdown), кодирование и сжатие для каждой колонки, статистика и возможность разделения файлов (splittable files).
  • Недостатки: более высокая нагрузка на CPU во время записи; необходимо аккуратно управлять эволюцией схемы (например, добавление колонок безопасно, а изменение типов рискованно).
  • Сжатие: Snappy для скорости, ZSTD для лучшей степени сжатия, где он поддерживается. Избегайте GZIP для колоночных форматов, если только это не требуется для совместимости.

• Строковый формат Avro

  • Преимущества: эволюция схемы со строгой типизацией, сжатие на уровне блоков, возможность разделения; отлично подходит для зон первичной загрузки (landing zones) потоковых данных и для обмена данными.
  • Недостатки: менее эффективен для сканирования при аналитике, чем колоночные форматы; рекомендуется преобразовывать в Parquet/ORC в обработанных зонах (curated zones).

• CSV и JSON (полуструктурированные)

  • CSV: человекочитаемый, минимальные накладные расходы при простых значениях; отсутствуют схема, типы и единые правила экранирования; дорогой парсинг в больших масштабах.
  • JSON: самодокументируемый и гибкий; для масштабируемого распределенного чтения требуется формат с разделителями-переводами строк (newline-delimited JSON); избыточный и требует больших затрат CPU на парсинг.
  • По возможности, загружайте необработанные CSV/JSON, а затем проверяйте и преобразуйте их в Avro/Parquet для аналитики.

• Внешние таблицы BigQuery и BigLake

  • Внешние таблицы Parquet/ORC используют преимущества проталкивания предиката и отсечения колонок; CSV/JSON обычно этого не делают, что приводит к сканированию большего объема данных.
  • Сжатые внешние таблицы CSV (GZIP) не могут быть разделены между рабочими узлами (workers); ожидайте более медленного чтения.
  • Пример: создание таблицы Parquet в BigLake с партиционированием в стиле Hive: CREATE EXTERNAL TABLE lake.sales WITH CONNECTION us.biglake_conn OPTIONS ( format = ‘PARQUET’, hive_partitioning_mode = ‘AUTO’, hive_partitioning_source_uri_prefix = ‘gs://corp-raw/sales/’, uris = [‘gs://corp-raw/sales/date=/region=/part-*.parquet’] );

Структура, партиционирование, инженерия производительности, размещение данных и миграция

• Структура и партиционирование объектов

  • Используйте пути в стиле Hive для партиций и ключей кластеризации: gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
  • Поддерживайте размер отдельных файлов в диапазоне 128–1024 МБ для сбалансированного параллелизма и накладных расходов на задачи. Избегайте миллионов файлов в одной партиции.
  • Решайте проблему множества мелких файлов следующими способами:
    • Пакетная загрузка на стороне клиента.
    • Использование заданий уплотнения (compaction) в Dataflow/Spark для объединения мелких файлов в непиковые часы.
    • Архивирование исходных мелких файлов и предоставление доступа к аналитике только к уплотненным данным.

• Партиционирование и кластеризация в BigQuery

  • Партиционируйте по времени загрузки или по столбцу фильтра с высокой кардинальностью (например, event_date). Избегайте избыточного партиционирования (например, поминутного), которое приводит к разрастанию метаданных.
  • Кластеризуйте по часто используемым для фильтрации/сортировки измерениям (до четырех). Кластеризация повышает локальность данных и сокращает объем сканируемых байтов.
  • Предпочитайте нативные таблицы BigQuery для интенсивной интерактивной аналитики; используйте BigLake/внешние таблицы для управляемого доступа к озеру данных, совместного использования разными движками и изоляции затрат.

• Влияние на производительность запросов

  • Колоночные форматы существенно снижают затраты на сканирование внешних данных; внешние таблицы CSV/JSON часто требуют полного сканирования файлов.
  • Гарантии согласованности устраняют необходимость в искусственных задержках при чтении из Cloud Storage, но нижестоящие системы (например, потоковые вставки в BigQuery) могут демонстрировать небольшую задержку видимости данных — проектируйте с использованием водяных знаков (watermarks) или задержек чтения, где это необходимо.

• Размещение, долговечность и восстановление данных

  • Выбирайте расположение бакетов/наборов данных в соответствии с требованиями к размещению данных (residency); размещайте вычислительные ресурсы рядом, чтобы сократить исходящий трафик (egress) и задержку.
  • Используйте dual-region с turbo replication для низкого RPO; версионирование и политики хранения (retention policies) для восстановления после человеческих ошибок и атак программ-вымогателей.
  • Для аварийного восстановления (DR) реплицируйте бакеты в отдельный проект/регион с помощью репликации бакетов и защищайте их отдельными границами IAM.

• Безопасная миграция и валидация

  • Планируйте миграцию в несколько этапов: начальная загрузка (seed, массовый перенос), инкрементальная синхронизация (копирование по mtime/окну), переключение (источник в режиме только для чтения) и валидация после переключения.
  • Проверяйте с помощью контрольных сумм, подсчета количества, общего объема в байтах и выборочного декодирования. Для табличных данных сравнивайте количество строк и хэш-агрегаты:

undefined

• Используйте предварительные условия (preconditions, например, ifGenerationMatch), чтобы предотвратить перезапись во время параллельного копирования. Сохраняйте окно для отката с помощью версионирования или сохранения источника.
• После миграции включите lifecycle и Autoclass в соответствии с новым профилем доступа; не включайте блокировку хранения (retention lock) до завершения всех проверок.

Пример практической задачи

Компания Acme Retail ежедневно получает CSV-файлы от партнера по логистике в региональный бакет Cloud Storage. Файлы иногда содержат некорректно отформатированные строки. Acme должна принять, проверить, преобразовать в готовый для аналитики формат и загрузить данные в BigQuery для дашбордов, работающих в режиме, близком к реальному времени, сохраняя при этом некорректные строки для анализа и обеспечивая управление данными (governance).

Подход:

1. Прием и управление сырыми данными в Dataplex

   • Создайте озеро (lake) в Dataplex с ресурсом (asset) для сырой зоны (raw zone), сопоставленным с gs://acme-raw/logistics/.
   • Обоснование: Централизованное управление, метаданные и отслеживание происхождения данных (lineage). Применение IAM на уровне зоны и маркировка конфиденциальных полей тегами политик (policy tags) для последующего применения правил.

2. Применение жизненного цикла и политик хранения

   • Примените политику хранения (retention policy) для бакета на 30 дней и включите версионирование объектов (object versioning) на acme-raw.
   • Обоснование: Защищает от случайной перезаписи/удаления со стороны партнера; короткий срок хранения обеспечивает баланс между стоимостью и возможностью восстановления. Версионирование облегчает откат некорректных поставок данных.

3. Валидация и загрузка с помощью пакетного конвейера Dataflow

   • Запускайте ежедневное задание Dataflow по уведомлениям о завершении создания объекта (object finalize). Читайте CSV со схемой и проверкой каждой записи; записывайте корректные записи в промежуточную таблицу BigQuery (staging, партиционированную по event_date) и направляйте ошибки парсинга/валидации в таблицу BigQuery для неразобранных сообщений (dead-letter).
   • Обоснование: Dataflow обеспечивает масштабируемый параллельный парсинг и надежную обработку неразобранных сообщений, чтобы аналитики могли изучать некорректные строки. Это соответствует лучшим практикам работы с CSV разнородного качества.

4. Уплотнение и преобразование в Parquet в очищенной зоне (curated zone)

   • Тот же конвейер записывает проверенные данные в gs://acme-curated/logistics/date=YYYY-MM-DD/ в виде Parquet-файлов размером ~256–512 МБ.
   • Обоснование: Parquet позволяет использовать отсечение столбцов (column pruning) и проталкивание предикатов (predicate pushdown) в BigQuery и Spark, что снижает объем сканируемых данных и улучшает задержку; уплотнение решает проблему множества мелких файлов, возникающую из-за схемы их поставки партнером.

5. Предоставление доступа к управляемой аналитике через BigLake

   • Создайте внешнюю таблицу BigLake поверх очищенного пути с Parquet-файлами с автоматическим Hive-партиционированием; примените теги политик на уровне столбцов (column-level policy tags) и политики доступа на уровне строк (row access policies) для фильтров, специфичных для партнера.
   • Обоснование: Единый гранулярный доступ через BigQuery и Spark с централизованным аудитом. Отсечение партиций (partition pruning) снижает затраты на сканирование при фильтрации по дате.

6. Загрузка критически важных агрегатов в нативную таблицу BigQuery

   • Для «горячих» дашбордов запускайте по расписанию задание BigQuery, которое загружает данные за последние N дней из внешней таблицы Parquet в нативную кластеризованную, партиционированную таблицу.
   • Обоснование: Нативное хранилище ускоряет BI-запросы с высокой конкурентностью, в то время как внешняя таблица BigLake остается управляемой системой записи (system-of-record) для более широкого доступа.

7. Мониторинг и оповещения с помощью Cloud Logging и Pub/Sub

   • Создайте приемник логов (log sink), фильтрующий результаты заданий Dataflow и загрузки в BigQuery, и направляющий их в Pub/Sub; интегрируйте с инструментом мониторинга для мгновенных оповещений о сбоях или повышенном количестве некорректных строк.
   • Обоснование: Целевая операционная видимость для конкретных таблиц без необходимости опроса (polling); поддерживает практики SRE.

8. Оптимизация класса хранения и размещения данных

   • Храните очищенные Parquet-файлы в классе Standard в течение 14 дней, затем переводите в Coldline через 30 дней с помощью правила жизненного цикла (lifecycle rule); храните бакеты с сырыми и очищенными данными в том же регионе, что и наборы данных BigQuery, чтобы избежать исходящего трафика (egress).
   • Обоснование: Баланс между производительностью «горячего» чтения и стоимостью. Совместное размещение (co-location) обеспечивает соответствие требованиям (compliance) и минимизирует задержки и плату за исходящий трафик.

9. Сквозная проверка качества

   • После каждого запуска сравнивайте количество записей и хэш-агрегаты между промежуточной (staging), внешней очищенной и нативной таблицами BigQuery; помещайте аномалии в карантин.
   • Обоснование: Раннее обнаружение дрейфа схемы или регрессий при загрузке; криптографические хэши или хэши по отпечатку (fingerprint) обеспечивают легковесную проверку без полного повторного сканирования.

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

← Архитектура и проектирование инженерии данных · Все домены · Аналитика с BigQuery и инженерия хранилищ →

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

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