Google PDE: Машинное обучение, AI и предоставление данных — Руководство по подготовке

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

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

Обзор

Создание систем машинного обучения и предоставления данных промышленного уровня в Google Cloud требует дисциплинированного моделирования данных, надёжных конвейеров и операционных мер предосторожности. В этом разделе рассматриваются разработка моделей в BigQuery ML, управляемый жизненный цикл в Vertex AI (наборы данных, обучение, конвейеры, эндпоинты, конструирование признаков и мониторинг), проектирование путей прогнозирования (пакетный или онлайн-режим), хранилища признаков и корректность на определённый момент времени, разметка данных и контроль смещений, векторный поиск и паттерны генерации с дополнением извлекаемой информацией (RAG), отслеживание происхождения данных и управление, мониторинг дрейфа и триггеры для переобучения, слои для предоставления аналитики и использование данных с учётом конфиденциальности. Особое внимание уделяется проектным решениям, стратегиям масштабирования и распространённым сценариям сбоев, которых следует избегать.

BigQuery ML и конструирование признаков

BigQuery ML позволяет выполнять обучение, оценку и прогнозирование непосредственно на SQL, устраняя необходимость перемещения данных и согласуя разработку моделей с аналитическими наборами данных.

• Создание модели: используйте CREATE MODEL с явным указанием целевых столбцов (label) и преобразований признаков, чтобы избежать утечки данных и стандартизировать входные данные. Пример: CREATE OR REPLACE MODEL ds.churn_model OPTIONS( model_type=‘logistic_reg’, input_label_cols=[‘churned’], l1_reg=0.0, l2_reg=1.0, data_split_method=‘AUTO’ ) TRANSFORM( standardize(tenure_months) AS tenure_std, quantile_bucketize(monthly_spend, 10) AS spend_bkt, one_hot_encoder(region) AS region_ohe, ml.feature_cross(struct(bucketize(lat, 60), bucketize(lon, 60))) AS latlon_cross, (xx + yy) AS r2 – добавьте поддержку круговой границы принятия решений, если это полезно ) AS SELECT churned, tenure_months, monthly_spend, region, lat, lon, x, y FROM ds.customer_features;

• Оценка: используйте ML.EVALUATE для получения метрик, соответствующих типу модели (например, ROC AUC для классификации, RMSE для регрессии). Отслеживайте базовые показатели и доверительные интервалы; храните наборы данных для оценки упорядоченными по времени, чтобы приблизительно оценить будущую производительность. SELECT * FROM ML.EVALUATE(MODEL ds.churn_model, TABLE ds.eval_features);

• Прогнозирование: используйте ML.PREDICT для скоринга в BigQuery, подобного онлайн-режиму, или экспортируйте модели для развёртывания в других системах. Учитывайте бюджеты задержки модели при использовании BigQuery для синхронного скоринга; для API с высоким QPS (запросов в секунду) развёртывайте модели на управляемых эндпоинтах. SELECT user_id, predicted_churn FROM ML.PREDICT(MODEL ds.churn_model, TABLE ds.scoring_candidates);

• Преобразования признаков: для обеспечения воспроизводимости и привязки предварительной обработки к артефакту модели отдавайте предпочтение декларативным функциям в блоке TRANSFORM (standardize, one_hot_encoder, bucketize, quantile_bucketize, ml.feature_cross). Преобразования должны быть идемпотентными и детерминированными.

Операционные аспекты и сценарии сбоев:

• Потоковые вставки и свежесть данных в запросах: Потоковая вставка в BigQuery обеспечивает согласованность в конечном счёте (eventual consistency). Для агрегаций в реальном времени, которые должны включать только что записанные строки, выполняйте запросы с задержкой, превышающей измеренную задержку буфера потоковой передачи. Консервативной отправной точкой будет ожидание примерно в 2 раза дольше наблюдаемой средней задержки доступности данных, или проектирование водяных знаков (watermarks) и обработки запаздывающих данных в Dataflow перед их загрузкой в BigQuery.
• Стоимость и параллелизм: если лимиты параллелизма слотов по требованию (on-demand) становятся узким местом, переключитесь на резервирования с фиксированной ставкой (flat-rate) или гибкие резервирования (flexible) и внедрите управление рабочей нагрузкой (иерархии и назначения резервирований) для обеспечения предсказуемой ёмкости.
• Качество данных: для пакетных загрузок из GCS, содержащих некорректно сформированные строки, используйте Dataflow для разбора и валидации записей, записывая корректные строки в BigQuery, а некорректные — в таблицу недоставленных сообщений (dead-letter table) для анализа. Это позволит избежать ситуации, когда BigQuery отклоняет целые файлы из-за небольшого числа некорректных строк.

Жизненный цикл Vertex AI, пути прогнозирования и хранилища признаков

Vertex AI предоставляет комплексные управляемые сервисы для обучения, конвейеров, реестра моделей, эндпоинтов и мониторинга.

• Наборы данных и обучение: регистрируйте наборы данных и метаданные; используйте кастомные задания обучения или AutoML, где это уместно. Выбирайте алгоритмы на основе ограничений:

  • Для рабочих нагрузок с ограниченными ресурсами на одной ВМ предпочтительны простые модели (например, линейная или логистическая регрессия) из-за низких требований к памяти/ЦП.
  • Задачи с высокой размерностью часто выигрывают от отбора признаков или объединения избыточных признаков для ускорения обучения с минимальной потерей точности.
  • Обнаружение аномалий без учителя подходит, когда положительные примеры редки, а будущие аномалии, как ожидается, будут похожи на известные аномальные сигнатуры.

• Конвейеры: используйте Vertex AI Pipelines для кодификации подготовки данных, обучения, оценки и шлюзов развертывания. Сохраняйте параметры, SHA коммитов, дайджесты контейнеров и снимки наборов данных для гарантии воспроизводимости.

• Эндпоинты и прогнозирование:

  • Онлайн-прогнозирование для нагрузок с низкой задержкой. Настройте минимальное и максимальное количество реплик и политики автомасштабирования; профилируйте задержку модели на уровне P95 и устанавливайте SLO соответственно. Добавьте канареечные развертывания и разделение трафика для безопасного выката.
  • Пакетное прогнозирование для задач, где важна пропускная способность (например, ночной скоринг). Пакетный режим позволяет избежать накладных расходов на каждый запрос и дешевле для больших объемов, но имеет более высокую задержку.

• Инжиниринг признаков и хранилища признаков: используйте Vertex AI Feature Store для:

  • Офлайн-хранилище в BigQuery для обучения.
  • Онлайн-хранилище для поиска по ID сущности с низкой задержкой. Обеспечьте согласованность между обучением и обслуживанием (training-serving consistency), используя общую логику преобразований (например, библиотеку Dataflow или определения признаков) и временные метки признаков для предотвращения утечки данных (leakage). Поддерживайте корректность на определенный момент времени (point-in-time correctness) с помощью темпоральных соединений: SELECT f.* FROM ds.labels l JOIN ( SELECT entity_id, feature_ts, feature_val, ROW_NUMBER() OVER (PARTITION BY entity_id ORDER BY feature_ts DESC) AS rn FROM ds.features WHERE feature_ts <= l.event_ts ) f ON f.entity_id = l.entity_id WHERE f.rn = 1;

Компромиссы проектирования:

• Задержка онлайн-хранилища vs. свежесть данных: онлайн-хранилища на базе Bigtable обеспечивают низкую задержку; убедитесь, что операции обратного заполнения (backfills) и потоковые вставки/обновления (streaming upserts) идемпотентны. Чрезмерный перекос записи (write skew) или «горячие» ключи (hot keys) снижают производительность — проектируйте ID сущностей так, чтобы равномерно распределять трафик.
• Пакетный vs. онлайн-режим: пакетный режим снижает сложность и стоимость обслуживания, но может предоставлять устаревшие прогнозы. Для динамического поведения (например, рекомендаций) комбинируйте периодическое переобучение с использованием актуальных признаков во время обслуживания.

Качество данных, разметка, смещение, конфиденциальность и управление

Высококачественная разметка и строгое управление лежат в основе надежных моделей.

• Разметка и дисбаланс:

  • Используйте четкие инструкции по разметке и выборочный контроль качества (QA sampling). Отслеживайте согласованность между разметчиками (inter-annotator agreement).
  • Устраняйте дисбаланс классов с помощью стратифицированной выборки, перевзвешивания или повторной выборки (resampling); отслеживайте точность/полноту (precision/recall) для каждого класса, а не только общую точность (accuracy).
  • Сохраняйте значения null намеренно. Если модель требует числовые входы, кодируйте null явно (например, 0 с индикатором «was_null») и проверяйте влияние на последующие этапы; избегайте молчаливого удаления информативных пропусков.

• Переобучение и обобщение:

  • Меры по смягчению включают более разнообразные обучающие данные, меньшие наборы признаков и более сильную регуляризацию.
  • Ранняя остановка (early stopping) и кросс-валидация необходимы для нейронных сетей; субдискретизация (subsampling) может сократить время обучения, когда масштабирование архитектуры или оборудования нецелесообразно.

• Управление и происхождение данных (lineage):

  • Отслеживайте происхождение данных с помощью Vertex ML Metadata, Model Registry и Data Catalog. Записывайте версии наборов данных, преобразования, гиперпараметры и окружение.
  • Процессы утверждения: требуйте ручного утверждения перед развертыванием, используя состояния Model Registry и Cloud Build/Deploy с проверками политик. Храните артефакты в Artifact Registry; подписывайте контейнеры и применяйте Binary Authorization для контролируемых выкатов.

• Мониторинг, дрейф и переобучение:

  • Включите мониторинг модели для отслеживания смещения прогнозов (prediction skew), дрейфа признаков (feature drift) и ухудшения производительности. Используйте метрики распределения (например, PSI, дивергенция Кульбака-Лейблера) и оценку с учетом задержки истинных меток (ground-truth lag-aware evaluation), когда они поступают позже.
  • Установите триггеры для переобучения на основе статистически значимого дрейфа, нарушений SLO или окон бизнес-событий. Автоматизируйте конвейеры переобучения, но контролируйте продвижение модели с помощью оценок и проверок на смещение.
  • Остерегайтесь скрытого дрейфа данных из-за изменений схемы в вышестоящих системах; применяйте контракты схем и настройте оповещения об отсутствующих или смещенных признаках.

• Проектирование с учетом конфиденциальности:

  • Классифицируйте данные с помощью тегов политик (policy tags) в Data Catalog; применяйте безопасность на уровне столбцов и строк в BigQuery с политиками маскирования данных.
  • Минимизируйте сбор данных; внедряйте SLA по хранению и удалению данных, привязанные к ограничению цели использования.
  • Применяйте DLP для обнаружения и деидентификации; шифруйте данные с помощью CMEK; изолируйте сервисы с помощью VPC Service Controls; обеспечьте гранулярный доступ с помощью IAM и используйте выделенные сервисные аккаунты с минимальными привилегиями.
  • При мониторинге и логировании скрывайте PII и избегайте логирования полезной нагрузки (payload), если в этом нет необходимости.

Векторный поиск, RAG-пайплайны и уровни обслуживания аналитики

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

• Векторный поиск и эмбеддинги:

  • Используйте Vertex AI Vector Search или векторный поиск в BigQuery для крупномасштабного поиска ближайших соседей с низкой задержкой; выбирайте AlloyDB for PostgreSQL с pgvector для семантики, ориентированной на приложение, и транзакционных задач.
  • Генерируйте эмбеддинги в пакетном режиме с помощью Vertex Pipelines; храните векторы вместе с плотными метаданными; разумно партиционируйте и индексируйте (например, по домену документа), чтобы ограничить задержку.

• Пайплайны генерации с дополненной выборкой (RAG):

  • Загружайте контент через Dataflow или Dataproc, извлекайте текст, разделяйте на части (чанкование), создавайте эмбеддинги и индексируйте в векторном хранилище. Сохраняйте ссылки на источник истины для отслеживаемости.
  • Реализуйте стратегии поддержания актуальности: периодическое повторное создание эмбеддингов, инвалидация при обновлении источника и канареечное индексирование для проверки качества перед заменой индексов.
  • Отслеживайте качество извлечения (hit rate, MRR, nDCG) и безопасность контента; применяйте защитные механизмы и контроль доступа для данных с ограниченным доступом.

• Уровни обслуживания аналитики и продукты данных:

  • Формируйте продукты данных уровней bronze/silver/gold в BigQuery; используйте партиционирование и кластеризацию для минимизации затрат на сканирование. Материализованные представления могут ускорить выполнение распространенных запросов.
  • Для хранилищ типа «ключ-значение» с низкой задержкой или счетчиков с высоким QPS используйте Bigtable с хорошо распределенными ключами строк; избегайте хотспотов (горячих точек), добавляя соль или хешируя префиксы.
  • Для OLTP-нагрузок и строгой согласованности используйте Cloud SQL или Spanner; переносите аналитику в BigQuery с помощью ELT по расписанию.
  • Архитектура потоковой обработки: Pub/Sub → Dataflow → BigQuery/Bigtable с автомасштабированием. Отслеживайте метрики отставания (backlog) и водяных знаков (watermark); автомасштабирование по умолчанию достаточно для эластичных нагрузок при контроле затрат.

Операционный совет:

• Чтобы настроить уведомления о завершении конкретных заданий вставки в таблицу BigQuery, экспортируйте соответствующие записи Cloud Logging в Pub/Sub с помощью расширенного фильтра, а затем настройте оповещения от подписки:

undefined

undefined

undefined

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

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

Подход:

1. Прием потоковых данных и контроль качества

• Используйте Pub/Sub для приема событий из веб- и мобильных приложений. Потоковое задание Dataflow проверяет схемы, обогащает данными из каталога и записывает:
  • Очищенные события в партиционированные таблицы BigQuery (по event_date) для офлайн-аналитики и обучения.
  • Агрегированные обновления признаков пользователя в Vertex AI Feature Store (онлайн-хранилище) с ключом user_id. Обоснование: Pub/Sub разделяет производителей и потребителей; Dataflow обеспечивает семантику «ровно один раз» с идемпотентными операциями upsert; партиционирование в BigQuery управляет затратами и хранением; онлайн-хранилище обеспечивает поиск за миллисекунды.

2. Определение признаков с корректностью на определенный момент времени

• Определите такие признаки, как скользящий CTR, приверженность бренду и давность, с явным указанием event_time. Материализуйте их в:
  • Офлайн-хранилище в BigQuery для обучения с темпоральными соединениями, ограниченными условием feature_ts <= label_ts.
  • Онлайн-хранилище для обслуживания с TTL для предотвращения использования устаревших значений. Обоснование: Четкие временные метки предотвращают утечку меток (label leakage); согласованные определения для офлайн- и онлайн-режимов обеспечивают паритет между обучением и обслуживанием (training-serving parity).

3. Обучение модели и отслеживание происхождения данных (lineage)

• Реализуйте Vertex AI Pipeline, который:
  • Извлекает данные для обучения из BigQuery, используя временные окна (например, за последние 30 дней).
  • Применяет те же преобразования, что и при обслуживании (используя общую библиотеку).
  • Обучает ранжирующую модель; записывает метаданные (ID снимков наборов данных, SHA коммита кода, гиперпараметры) в ML Metadata и регистрирует модель в Model Registry. Обоснование: Пайплайны делают запуски воспроизводимыми и проверяемыми; Model Registry централизует версии и утверждения.

4. Пути пакетного и онлайн-прогнозирования

• Еженощное пакетное прогнозирование, оценивающее полную матрицу «каталог-пользователь» и записывающее результаты в BigQuery для заполнения пропущенных данных (backfill) и A/B-тестирования.
• Онлайн-прогнозирование через эндпоинт Vertex, который:
  • Получает свежие признаки пользователя из онлайн-хранилища.
  • Оценивает K лучших кандидатов, отфильтрованных по складским запасам и доступности.
  • Кэширует результаты на короткое время для поглощения всплесков нагрузки. Обоснование: Пакетная обработка обеспечивает широту охвата и экономическую эффективность; онлайн-обработка учитывает самое последнее поведение для высокоценных сессий. Автомасштабируемые эндпоинты поддерживают SLO по задержке; кэширование снижает хвостовую задержку (tail latency) и затраты.

5. Мониторинг, обнаружение дрейфа и политика переобучения

• Включите мониторинг модели для отслеживания дрейфа признаков и смещения прогнозов; сравнивайте распределения с базовыми показателями обучения. Отслеживайте SLO по CTR/CVR и оповещайте о деградации.
• Непрерывно переобучайте модель, используя скользящее окно, объединяющее исторические и новые данные; запускайте переобучение, когда дрейф превышает пороговые значения, или как минимум еженедельно. Обоснование: Модные тенденции быстро меняются; смешивание исторических данных с новыми сигналами стабилизирует обучение, сохраняя актуальность.

6. Конфиденциальность и управление

• Помечайте столбцы с персональными данными (PII) тегами политик Data Catalog; применяйте безопасность на уровне столбцов в BigQuery и маскируйте данные, где это необходимо. Запускайте сканирование DLP на необработанных событиях; храните только необходимые поля.
• Требуйте ручного утверждения для продвижения моделей из промежуточной среды (staging) в производственную (production) через триггеры Cloud Build, интегрированные со статусами утверждения в Model Registry. Обоснование: Доступ по принципу наименьших привилегий снижает риски; контроль развертываний обеспечивает соответствие требованиям и безопасность.

7. Контроль затрат и мощностей

• Используйте резервирования BigQuery, чтобы гарантировать предсказуемую емкость слотов для окон обучения.
• Автоматически масштабируйте воркеры Dataflow в зависимости от отставания (backlog); шардируйте горячие ключи в хранилище признаков, хешируя префиксы user_id, чтобы предотвратить появление хотспотов. Обоснование: Предсказуемая емкость позволяет избежать конкуренции за ресурсы; автомасштабирование соотносит расходы с потребностью; сбалансированные ключи поддерживают обновления с низкой задержкой.

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

← Оркестрация рабочих процессов и автоматизация пайплайнов · Все домены · Управление данными →

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

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