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

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

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

Обзор

Архитектура и проектирование инженерии данных в Google Cloud балансируют границы доменов, шаблоны обработки и возможности сервисов для создания надёжных, масштабируемых и экономически эффективных платформ данных. Эффективные проекты делают хранение, вычисления, оркестрацию и предоставление данных независимо масштабируемыми; кодифицируют контракты для взаимодействия доменов; и проверяют риски на ранних этапах с помощью измеримых целевых показателей уровня обслуживания (SLO). В этом разделе кратко рассматриваются канонические архитектурные стили (сетка данных, озеро, хранилище, lakehouse, операционные хранилища), режимы обработки (пакетная, микро-пакетная, потоковая, событийно-ориентированная, лямбда) и компромиссы между масштабируемостью, задержкой, доступностью, согласованностью и стоимостью. Также рассматриваются региональное и мультиоблачное размещение, эволюция схем, полный жизненный цикл данных, выбор сервисов на основе рабочей нагрузки и методы валидации на основе рисков, адаптированные для Google Cloud.

Архитектурные парадигмы и шаблоны обработки

• Сетка данных (data mesh), домены и продукты данных:
  • Предоставьте доменным командам возможность публиковать «продукты данных» с чётким владением, SLO, политиками доступа и документацией. Используйте Dataplex для определения доменов, управления метаданными и применения единых политик в BigQuery и Cloud Storage. Продукты могут предоставлять наборы данных BigQuery, топики Pub/Sub или пути в Cloud Storage с контрактами, обеспечиваемыми схемами Pub/Sub и схемами таблиц BigQuery.
• Озеро данных (data lake):
  • Хранение необработанных данных в открытых форматах (Parquet/Avro) в Cloud Storage с управлением жизненным циклом и версионированием. Подходит для гетерогенных рабочих нагрузок (Spark в Dataproc, Dataflow, Presto/Trino) и переносимости между облаками. Компромисс: семантика согласованности в конечном счёте (eventual consistency) в объектных хранилищах; проектируйте с учётом идемпотентности и дедупликации на основе метаданных.
• Хранилище данных (data warehouse):
  • Курируемая, управляемая аналитика в BigQuery. Оптимизировано для ANSI SQL, разделения хранения и вычислений, а также гранулярной безопасности. Компромиссы: потоковые вставки демонстрируют кратковременную устарелость данных во время запроса; для строгих SLA по актуальности данных предпочитайте пакетные загрузки или вставки с буферизованными запросами.
• Lakehouse:
  • Сочетание открытого хранилища озера данных с возможностями хранилища данных. В Google Cloud храните Parquet/Avro в Cloud Storage; используйте внешние таблицы BigQuery для экономии и управляемые таблицы BigQuery для производительности и управления. Dataflow или Dataproc поддерживают семантику слияния, подобную ACID, с помощью стратегий партиционирования/кластеризации.
• Архитектура операционного хранилища:
  • Транзакционные или key-value хранилища с низкой задержкой для поддержки приложений. Выбирайте Cloud SQL для традиционных OLTP, Cloud Spanner для глобально согласованного SQL с горизонтальным масштабированием и Bigtable для очень высокой пропускной способности и шаблонов доступа к широким столбцам. Отделяйте операционные хранилища от аналитических; используйте CDC (Datastream) для захвата изменений в Pub/Sub, Cloud Storage или BigQuery.

Шаблоны обработки и когда их использовать:

• Пакетная обработка (Batch): Периодические, крупномасштабные преобразования (например, ночная генерация признаков). Инструменты: пакетный режим Dataflow, Dataproc. Режимы сбоя: тайм-ауты длительных заданий, перекос данных (skew); смягчайте с помощью автомасштабирования и перераспределения (repartitioning).
• Микро-пакетная обработка (Micro-batch): Небольшие, частые пакеты (например, каждую минуту) для баланса между актуальностью, стабильностью и стоимостью. В BigQuery используйте запланированные запросы или Dataflow с фиксированными окнами.
• Потоковая обработка (Streaming): Задержка от миллисекунд до секунд на неограниченных данных. Используйте Pub/Sub + Dataflow. Обрабатывайте запоздавшие/неупорядоченные события с помощью окон по времени события и водяных знаков (watermarks); обеспечивайте идемпотентность для предотвращения дубликатов.
• Событийно-ориентированная обработка (Event-driven): Запускается изменениями (финализация объекта в GCS, сообщения Pub/Sub). Используйте Cloud Functions или Cloud Run для реакций без сохранения состояния и Dataflow для обработки с сохранением состояния. Компромисс: стоимость обработки каждого события в сравнении с пропускной способностью.
• Лямбда-архитектура (Lambda pattern): Поддерживайте как потоковый, так и пакетный пути для точности и повторной обработки. Сложность удваивается; рассмотрите упрощение в стиле Каппа-архитектуры, где всё можно воспроизвести из неизменяемого журнала (архивация из Pub/Sub в Cloud Storage).

Краткий пример конфигурации потоковой обработки Dataflow для запоздавших данных:

events
  .apply(Window.into(FixedWindows.of(Duration.standardMinutes(5)))
    .withAllowedLateness(Duration.standardMinutes(10))
    .accumulatingFiredPanes());

Владение доменом, продукты данных и контракты

• Владение и SLO:
  • Каждая доменная команда определяет и эксплуатирует свои продукты данных с SLO по доступности, задержке и качеству данных. Публикуйте SLO через каталоги Dataplex и отслеживайте с помощью SLI в Cloud Monitoring (например, своевременность завершения партиций).
• Контракты и совместимость:
  • Обеспечивайте соблюдение схем с помощью Pub/Sub Schema Registry (Avro/Proto) и схем таблиц BigQuery. При приёме CSV-данных выполняйте валидацию в Dataflow и направляйте некорректные строки в таблицу для отбракованных данных (dead-letter table) для анализа. Обеспечивайте взаимодействие с открытыми форматами в Cloud Storage и внешними таблицами BigQuery, когда несколько движков должны читать одни и те же данные.
• Эволюция схемы:
  • Отдавайте предпочтение обратно совместимым изменениям: добавляйте столбцы, допускающие значение NULL, добавляйте необязательные поля в Avro/Proto, избегайте переименований/удалений без периода устаревания. Сообщайте об изменениях через версионированные контракты и графики прекращения поддержки.
  • Пример для BigQuery (обратно совместимое добавление столбца):

ALTER TABLE sales.orders
ADD COLUMN coupon_code STRING;

• Влияние на потребителей:
  • Поддерживайте семантическое версионирование схем; публикуйте и v1, и v2 во время миграции. Для потоковой обработки направляйте данные в версионированные топики или включайте поле с версией схемы. Предоставляйте авторизованные представления (authorized views) в BigQuery, чтобы изолировать потребителей от физических изменений.
• Управление и происхождение данных (lineage):
  • Используйте Dataplex и Data Catalog для метаданных, тегов (например, PII) и отслеживания происхождения данных (lineage). Применяйте безопасность на уровне строк и столбцов в BigQuery. Для предотвращения утечки данных интегрируйте Cloud DLP в процесс приёма данных (например, в преобразования Cloud Run или Dataflow), чтобы токенизировать или маскировать конфиденциальные поля перед сохранением.

Нефункциональные компромиссы и топология развертывания

• Масштабируемость:
  • BigQuery эластично масштабируется для аналитики; Bigtable масштабируется линейно с количеством узлов, но требует тщательного проектирования ключей строк (row-key), например, с использованием хешированных или ротируемых префиксов, чтобы избежать хотспоттинга (hotspotting). Автомасштабирование Dataflow реагирует на накопившиеся задачи (backlogs); проектируйте с учетом противодавления (backpressure), используя управление потоком в Pub/Sub.
• Задержка:
  • Потоковая передача в BigQuery обеспечивает вставку данных с низкой задержкой, но при выполнении запросов может наблюдаться небольшое отставание; проектируйте запросы с буфером актуальности (freshness buffer) или окнами на основе водяных знаков (watermark). Для операций чтения в масштабе с задержкой менее 100 мс предварительно вычисляйте данные и предоставляйте их из Bigtable или Memorystore.
• Доступность и согласованность:
  • Cloud Spanner предоставляет строго согласованный, глобально распределенный SQL. Bigtable предлагает высокую доступность с согласованностью в конечном счете (eventual consistency) между кластерами. Доступность BigQuery может быть региональной или мультирегиональной; материализуйте критически важные наборы данных в мультирегионе для обеспечения отказоустойчивости.
• Стоимость:
  • Оптимизируйте BigQuery с помощью партиционирования и кластеризации, чтобы уменьшить объем сканируемых байтов. При передаче небольших файлов по каналам с ограниченной пропускной способностью объединяйте их в пакеты (batching/bundling), чтобы сократить накладные расходы на RPC. Используйте BigQuery BI Engine для кешированных интерактивных панелей мониторинга, где это уместно.
• Региональная, мультирегиональная, гибридная и мультиоблачная архитектура:
  • Региональная архитектура снижает задержку и стоимость; мультирегиональное хранилище (например, мультирегионы US/EU в BigQuery, dual-region/multi-region в Cloud Storage) повышает долговечность данных и расширяет возможности их размещения. Для аварийного восстановления (DR) определите RPO/RTO и реплицируйте критически важные наборы данных. В гибридных сценариях используйте Datastream для отслеживания измененных данных (CDC) и Transfer Appliances или Storage Transfer Service для массовой миграции. Для мультиоблачных сред стандартизируйте использование открытых форматов в Cloud Storage и применяйте переносимые вычислительные решения (Apache Beam/Dataflow, Spark в Dataproc), учитывая при этом затраты на исходящий трафик (egress) и операционные накладные расходы.

Разделение на слои, жизненный цикл и выбор сервисов

• Разделение на слои:
  • Хранение: Cloud Storage для необработанных (raw/bronze) и архивных данных; BigQuery для обработанной аналитики и предоставления данных; Bigtable для доступа по ключу с низкой задержкой; Spanner/Cloud SQL для OLTP.
  • Вычисления: Dataflow для бессерверной потоковой/пакетной обработки; Dataproc для экосистем Spark/Hadoop; BigQuery для ELT внутри хранилища; Cloud Run/Functions для микросервисов, управляемых событиями.
  • Оркестрация: Cloud Composer (Airflow) или Workflows для DAG и оркестрации API; Scheduler для триггеров по расписанию (cron-like).
  • Предоставление данных: Bigtable или Spanner для оперативных чтений (online reads); BigQuery для BI; Looker/BI Engine для дашбордов; Memorystore для кеширования.
• Жизненный цикл данных:
  • Прием (Ingest): Pub/Sub для потоков; Storage Transfer или gsutil для файлов; Data Transfer Service для SaaS. Валидировать, дедуплицировать и сохранять неизменяемые необработанные данные в Cloud Storage с версионированием объектов.
  • Обработка (Process): Использовать Dataflow или BigQuery для преобразования данных из необработанных (raw) в silver (очищенные, согласованные), а затем в gold (готовые для бизнеса витрины).
  • Предоставление (Serve): Публиковать представления/таблицы BigQuery для аналитики; предварительно вычислять признаки или прогнозы и сохранять их в Bigtable для API.
  • Хранение и архивирование: Применять правила жизненного цикла Cloud Storage для перемещения данных на уровни Coldline/Archive; использовать секционирование по времени в BigQuery с истечением срока действия секций для управления хранением. Включать CMEK, где это необходимо, и VPC Service Controls для защиты от утечки данных.
• Выбор сервиса на основе характеристик рабочей нагрузки:
  • Временные ряды с высокой пропускной способностью, широкими строками и низкой задержкой: Bigtable.
  • Глобальная OLTP со строгой согласованностью и поддержкой ANSI SQL: Cloud Spanner.
  • Традиционные реляционные транзакции с умеренным масштабом: Cloud SQL.
  • Аналитика петабайтного масштаба с ANSI SQL и разделением хранения и вычислений: BigQuery.
  • Прием и обработка в реальном времени: Pub/Sub + Dataflow.
  • Пакетная обработка Spark/Hadoop или инструменты для конкретных библиотек: Dataproc.

Краткий пример секционирования в BigQuery:

CREATE TABLE ops.events
PARTITION BY DATE(event_ts)
CLUSTER BY device_id AS
SELECT * FROM staging.events_clean;

Практический сценарий

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

Подход:

1. Организовать прием событий с помощью Cloud Pub/Sub.

• Обоснование: Pub/Sub предоставляет единую глобальную конечную точку, надежную буферизацию и горизонтальное масштабирование для пикового трафика от устройств. Использовать упорядоченные ключи для каждого самоката, чтобы сохранить порядок событий внутри одного устройства в пределах 1-часовых окон.

2. Реализовать потоковую обработку с помощью Cloud Dataflow (Apache Beam).

• Обоснование: Автомасштабирование Dataflow справляется с пиковыми нагрузками и предлагает приемники с семантикой exactly-once в сочетании с идемпотентными ключами. Использовать окна по времени события и водяные знаки (watermarks) для обработки опоздавшей/неупорядоченной телеметрии. Направлять основной вывод в потоки с обработанными данными и дополнительный вывод для записей, не подлежащих обработке (dead-letter).
• Конфигурация:

.withAllowedLateness(Duration.standardMinutes(15))
.discardingFiredPanes();

3. Сохранять необработанные и обработанные данные в Cloud Storage и BigQuery соответственно.

• Обоснование: Сохранять необработанные (bronze) файлы Avro в бакет Cloud Storage в двух регионах (dual-region) для повторного воспроизведения и аудита. Записывать потоки с обработанными (silver) данными в секционированные таблицы BigQuery для аналитики, с кластеризацией по scooter_id для эффективного точечного поиска. Применять небольшой буфер свежести в запросах для дашбордов, чтобы избежать временного устаревания потоковых данных.

4. Обслуживать оперативные запросы и проверки на мошенничество из Cloud Bigtable.

• Обоснование: Оценка правил с задержкой менее 100 мс требует произвольного доступа с низкой задержкой. Предварительно вычислять агрегаты (например, количество поездок на устройство за 5-минутное окно) в Dataflow и записывать их в Bigtable, используя ключ строки с хешированным префиксом (например, h(prefix)+device_id+window_start), чтобы избежать хотспоттинга (hotspotting) и распараллелить чтения по планшетам (tablets).

5. Управлять транзакционным биллингом в Cloud Spanner.

• Обоснование: Биллинг требует глобально согласованного SQL, строгой согласованности и высокой доступности. Использовать лидер в основном регионе с репликами только для чтения во вторичных регионах, чтобы уменьшить задержки чтения для клиентских порталов.

6. Обеспечить управление (governance) с помощью Dataplex, Data Catalog и Cloud DLP.

• Обоснование: Классифицировать поля с PII, тегировать наборы данных и применять безопасность на уровне столбцов в BigQuery. Интегрировать Cloud DLP в конвейер Dataflow для токенизации конфиденциальных атрибутов перед сохранением. Домены Dataplex отражают организационную принадлежность; каждый домен публикует документированные продукты данных с SLO.

7. Выполнять оркестрацию и эксплуатацию с помощью Cloud Composer и Cloud Monitoring.

• Обоснование: Composer координирует пакетные дозагрузки данных (backfills), уплотнения (compactions) и материализацию признаков для ML. Monitoring отслеживает сквозные SLI: отставание (backlog) в Pub/Sub, отставание водяного знака (watermark lag) в Dataflow, полноту секций в BigQuery и хвостовые задержки (tail latencies) в Bigtable. Оповещать о нарушениях SLO; автоматически масштабировать Dataflow в зависимости от роста отставания.

8. Оптимизировать затраты и жизненный цикл с помощью секционирования и уровней хранения.

• Обоснование: Таблицы BigQuery секционированы по event_ts с хранением в течение 90 дней и кластеризованы по scooter_id. Cloud Storage использует правила жизненного цикла для перемещения необработанных данных в Coldline через 30 дней и в Archive через 180 дней. Запланированные задания BigQuery уплотняют небольшие файлы из микро-батчей в более крупные объекты parquet, чтобы уменьшить накладные расходы, связанные с большим количеством файлов для последующих заданий Spark.

9. Проверить риски и отказоустойчивость.

• Обоснование: Провести нагрузочные тесты с двукратной ожидаемой пиковой нагрузкой, чтобы проверить квоты Pub/Sub и автомасштабирование Dataflow. Провести учения по региональному аварийному переключению: наборы данных BigQuery в нескольких регионах и бакеты в двух регионах поддерживают доступность; экземпляр Spanner в нескольких регионах поддерживает RPO=0 и настроенный RTO за счет автоматического аварийного переключения. Использовать инфраструктуру как код (Terraform) с валидацией политик для принудительного применения CMEK и VPC Service Controls.

Эта архитектура четко разделяет зоны ответственности: Pub/Sub буферизует прием данных, Dataflow выполняет вычисления, Cloud Storage и BigQuery хранят и предоставляют аналитику, Bigtable ускоряет оперативные чтения, а Spanner гарантирует согласованность транзакций. Она балансирует масштабируемость и задержку, контролируя затраты с помощью секционирования, кластеризации, политик жизненного цикла и автомасштабирования, а также внедряет управление и надежность через документированные продукты данных, контракты и непрерывную проверку.

Все домены · Хранение данных →

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

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