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

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Обзор

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

Архитектура хранилищ и объектов

Проектирование бакетов Cloud Storage

• Местоположение (Location): выберите регион для рабочих нагрузок, чувствительных к задержкам и стоимости; dual-region для обеспечения непрерывности бизнеса с предсказуемым переключением при сбое; multi-region для глобального доступа на чтение. Dual-region предлагает опциональную турбо-репликацию (turbo replication) для низкого RPO с поддержкой SLA; в противном случае репликация асинхронна.
• Пространство имен и разделение: используйте отдельные бакеты для разных доменов данных, сред и уровней конфиденциальности. Применяйте единый доступ на уровне бакета (uniform bucket-level access) и предотвращение публичного доступа для согласованности разрешений.
• Классы хранения: Standard для «горячих» данных; Nearline для редко используемых (ежемесячно); Coldline для ежеквартального доступа; Archive для долгосрочного хранения. Autoclass может автоматически оптимизировать размещение по классам с минимальными операционными затратами.
• Политики жизненного цикла: автоматизируйте перемещение и удаление по возрасту, классу хранения или префиксу объекта. Пример удаления объектов старше 90 дней: { “rule”: [ { “action”: {“type”: “Delete”}, “condition”: {“age”: 90} } ] } Применить с помощью: gsutil lifecycle set lifecycle.json gs://my-bucket
• Хранение и удержание по юридическим причинам (legal holds): настройте политики хранения бакета и при необходимости заблокируйте их для предотвращения сокращения срока (соответствие требованиям). Удержание на основе событий (event-based holds) и версионирование объектов позволяют восстанавливаться после случайных удалений или перезаписей.
• Репликация: выберите dual-region для семантики синхронной согласованности на уровне API с фоновой репликацией между двумя регионами; используйте репликацию между бакетами (для копий между проектами или регионами) для достижения особых требований RPO/RTO или разделения обязанностей.

Режимы сбоев и компромиссы

• Несоответствие класса хранения увеличивает стоимость и задержку. Autoclass уменьшает эту проблему, но добавляет накладные расходы на управление каждым объектом.
• Блокировка хранения (retention lock) необратима; тестируйте политики в непродуктивной среде.
• Репликация повышает долговечность, но может увеличить задержку записи и стоимость; проектируйте пути чтения/записи для целевых местоположений.

Паттерны

• Озеро данных (Data lake): «сырые» (raw) и обработанные (curated) зоны в Cloud Storage; управление через Dataplex; внешние схемы в Data Catalog.
• Архивирование: класс Archive с блокировкой хранения (retention lock) для соответствия требованиям, с внешними таблицами BigQuery или восстановлением по требованию для редкого анализа.
• Lakehouse: используйте BigLake для унификации доступа к данным в Cloud Storage и BigQuery с единой системой безопасности.

Операционные хранилища данных и кеширование

Cloud SQL

• Высокая доступность: региональная высокая доступность (HA) с синхронной репликацией на резервный экземпляр; автоматическое аварийное переключение обычно занимает от нескольких секунд до пары минут. Конечная точка экземпляра остается прежней, что минимизирует изменения в приложении.
• Реплики чтения: внутри региона или между регионами, асинхронные; подходят для горизонтального масштабирования чтения и аварийного восстановления (DR). Отслеживайте задержку; устаревшие данные при чтении могут повлиять на корректность.
• Резервные копии и PITR: плановые резервные копии плюс восстановление на момент времени (point-in-time recovery) с использованием журналов транзакций (обычно окно до 7 дней, в зависимости от движка). Регулярно тестируйте восстановление.
• Приватное подключение: приватный IP-адрес через VPC-пиринг уменьшает уязвимость и задержку; планируйте диапазоны IP-адресов, чтобы избежать их пересечения.
• Миграция: Database Migration Service поддерживает перенос с минимальным временем простоя с локальных площадок или из других облаков; для каналов с высокой нагрузкой предпочтительнее использовать Dedicated или Partner Interconnect вместо VPN, чтобы уменьшить потерю пакетов и задержку.

Компромиссы и сценарии сбоев

• Аварийные переключения HA сбрасывают соединения; приложения должны выполнять повторные попытки с экспоненциальной задержкой. Окна обслуживания могут кратковременно снижать производительность.
• Длительные транзакции увеличивают задержку репликации и время восстановления PITR.
• Избыточное выделение хранилища — дешевая страховка; недостаточное количество IOPS вызывает скрытые сбои при пиковой нагрузке.

Cloud Spanner

• Глобальный масштаб и согласованность: строго согласованные операции чтения/записи между регионами с использованием TrueTime и двухфазной фиксации. Выбирайте региональную конфигурацию для минимальной задержки записи; мультирегиональную — для более высокой доступности и глобального чтения.
• Транзакции: внешняя согласованность и полная поддержка ACID для строк и таблиц; транзакции только для чтения масштабируются по репликам.
• Проектирование схемы: выбирайте первичные ключи, которые позволяют избежать «горячих точек» (hotspots); используйте чередующиеся таблицы (interleaved tables) для локальности данных; учитывайте усиление записи (write amplification) и поведение обратного заполнения (backfill) для вторичных индексов.
• Региональность: расположение ведущего региона (leader region) определяет задержку записи; мультирегиональная конфигурация добавляет затраты на кворум и задержку фиксации.

Компромиссы

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

Firestore, Bigtable, Memorystore и выбор между ними

• Firestore: документо-ориентированная база данных для бэкендов мобильных/веб-приложений; строгая согласованность для отдельных документов; гранулярная безопасность; автоматическое индексирование. Остерегайтесь конфликтов (contention) при частом обновлении документов; используйте распределенные счетчики и пакетные операции записи.
• Bigtable: ширококолоночная база данных петабайтного масштаба со сверхнизкой задержкой для временных рядов и IoT; проектируйте ключи строк так, чтобы избежать «горячих точек» (например, с помощью хеширования или «соли»); масштабирование за счет узлов и кластеров; маршрутизация между несколькими кластерами для обеспечения доступности. Репликация асинхронная; строгая согласованность обеспечивается в рамках одного кластера.
• Memorystore for Redis: кеш в оперативной памяти; уровень Basic — это один экземпляр (без HA); уровень Standard предоставляет реплику и автоматическое аварийное переключение (возможны кратковременные разрывы соединений). Рассматривайте его как кеш, а не как источник истины; функции сохранения данных (persistence) снижают волатильность, но не заменяют резервные копии базы данных.

Выбор в зависимости от рабочей нагрузки

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

BigQuery

• Наборы данных (Datasets): логические границы для безопасности и биллинга; применяйте соглашения об именовании по доменам и этапам жизненного цикла.
• Секционирование (Partitioning): по времени загрузки или по столбцу для фильтрации по времени; также доступно секционирование по диапазону целых чисел. Используйте секционирование по единицам времени для event_ts, чтобы сократить объем сканирования.
• Кластеризация (Clustering): до четырех столбцов для совместного размещения связанных данных в хранилище; улучшает производительность и снижает стоимость выборочных запросов.
• Резервирования (Reservations): управляйте выделенными слотами через резервирования и назначения; используйте flex slots для экспериментов с пиковыми нагрузками; изолируйте критически важные рабочие нагрузки, чтобы избежать «голодания» ресурсов.
• Контроль доступа: IAM на уровне проекта и набора данных; контроль на уровне таблиц/столбцов с помощью политик на уровне строк и тегов политик; предоставляйте доступ к отобранным данным через авторизованные представления и процедуры.

Полезный пример: bq mk –dataset myproj:analytics bq mk –table –time_partitioning_field=event_ts –clustering_fields=user_id,device_type myproj:analytics.events ./schema.json

Компромиссы и сценарии сбоев

• Неправильное секционирование приводит к полному сканированию таблиц и неконтролируемому росту затрат.
• Кластеризация помогает только тогда, когда фильтры или JOIN включают кластеризованные столбцы; частые перегруппировки могут снизить ее пользу.
• Недостаточное выделение слотов приводит к очередям заданий; избыточное — повышает стоимость. Отслеживайте утилизацию слотов и сброс данных при перемешивании (spilled shuffle).

Прием и обработка данных

• Pub/Sub: глобальная, надежная доставка с гарантией «хотя бы один раз» (at-least-once); ключи упорядочивания обеспечивают порядок для каждого ключа, но с компромиссами по пропускной способности. Проектируйте идемпотентные потребители.
• Dataflow: унифицированная пакетная и потоковая обработка с автомасштабированием, обработкой с сохранением состояния и гарантией «ровно один раз» (exactly-once), оконными функциями и триггерами; Streaming Engine выносит обработку состояния. Используйте топики для недоставленных сообщений (dead-letter topics) и источники с возможностью повторного воспроизведения.
• Dataproc: управляемый Spark/Hadoop для существующего кода и экосистем; эфемерные кластеры или автомасштабирование; используйте для библиотек ML или когда перенос кода слишком затратен.

Компромиссы между пакетной и потоковой обработкой

• Потоковая обработка сокращает задержку и поддерживает реальное время, но увеличивает сложность (состояние, водяные знаки, опоздавшие данные) и текущие затраты.
• Пакетная обработка упрощает обеспечение корректности и контроль затрат; приемлема, когда SLA допускают задержку.
• Гибридные паттерны: сохраняйте необработанные события в Cloud Storage, передавайте агрегированные KPI в BigQuery потоком и запускайте ночные пакетные перерасчеты для точности.

Паттерны хранилищ данных

Управление, защита и производительность

Управление и безопасность данных

• Метаданные и происхождение данных (lineage): используйте Data Catalog для технических и бизнес-метаданных; включите отслеживание происхождения данных из Dataflow, BigQuery и Dataproc для отслеживания зависимостей.
• Качество: применяйте правила с помощью Dataplex data quality и организуйте проверки в Composer или Dataform; помещайте некорректные записи в карантин.
• Границы доступа: используйте VPC Service Controls для BigQuery и Cloud Storage, чтобы снизить риск эксфильтрации данных; IAM Conditions для контекстно-зависимого доступа; CMEK для криптографического контроля; теги политик (policy tags) для ограничений на уровне столбцов.
• Хранение: приведите в соответствие с юридическими требованиями сроки хранения в бакетах Cloud Storage, функцию time travel для таблиц BigQuery (настраивается до 7 дней) и сроки действия наборов данных/таблиц.

Резервное копирование, PITR и защита от удаления

• Проверка резервных копий: периодически восстанавливайте резервные копии Cloud SQL и Spanner в изолированные среды и выполняйте проверку контрольных сумм и валидацию на уровне приложений.
• Bigtable: включите PITR для восстановления на определённую метку времени в пределах настроенного срока хранения; тестируйте восстановление на уровне таблиц или кластеров.
• Spanner: используйте резервные копии для аварийного восстановления; используйте устаревшие чтения (stale reads) в пределах срока хранения версий для аудиторских запросов.
• Cloud Storage: включите версионирование объектов и блокировку хранения в бакете (bucket retention lock) для защиты от случайных удалений; реплицируйте в отдельный проект для изоляции от ошибок оператора.
• BigQuery: используйте time travel и снимки таблиц (table snapshots); избегайте удаления производственных наборов данных, требуя подтверждения и используя защиту от удаления на уровне набора данных.

Производительность данных и контроль затрат

• Избегайте горячих ключей (hot keys): распределяйте ключи строк (row keys) в Bigtable (хэш-префиксы), выбирайте первичные ключи Spanner, которые рандомизируют выборы лидера (leadership elections), шардируйте счётчики в Firestore.
• Индексы: поддерживайте необходимые индексы SQL и NoSQL; в BigQuery кластеризуйте по часто используемым фильтрам; в Cloud SQL отслеживайте медленные запросы и регулярно выполняйте vacuum/analyze для Postgres.
• Планирование мощностей: определите базовую производительность с помощью нагрузочных тестов; установите SLO и бюджеты ошибок (error budgets); отслеживайте утилизацию слотов BigQuery, задержки CPU/read-modify-write в Bigtable, CPU/IOPS в Cloud SQL и очередь сообщений (backlog) в Pub/Sub.
• Контроль затрат: используйте обязательства по слотам (slot commitments) BigQuery для стабильных нагрузок, Autoclass для Cloud Storage, уплотняйте таблицы Bigtable и настраивайте фильтры Блума (Bloom filters), удаляйте старые партиции и наборы данных, а также внедряйте бюджеты и оповещения для каждой команды.

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

Компании Acme Retail Group нужна единая аналитическая платформа для кликстрима и заказов с низкой задержкой. Требования: KPI в реальном времени в течение 10 секунд, исторический анализ за пять лет с помощью SQL, целевое время восстановления менее часа, строгая резидентность данных в США и предотвращение случайной потери данных.

1. Приём необработанных событий и реализация надёжного поглощения данных

• Создайте dual-region бакеты Cloud Storage в us-central1/us-east1 для зон с необработанными (raw) и обработанными (curated) данными; включите Autoclass и версионирование объектов для необработанных данных.
• Обоснование: dual-region обеспечивает надёжность и резидентность; версионирование защищает от некорректных обратных заполнений (backfills); Autoclass автоматически оптимизирует стоимость хранения.

2. Надёжная потоковая передача событий с помощью Pub/Sub и Dataflow

• Публикуйте события кликстрима и заказов в топики Pub/Sub с ключами упорядочивания (ordering keys) по user_id; реализуйте потоковый конвейер Dataflow для валидации, дедупликации, обогащения и разветвления вывода в BigQuery (горячие KPI) и Cloud Storage (parquet в зоне обработанных данных).
• Обоснование: Pub/Sub обеспечивает глобальную, надёжную доставку «хотя бы один раз» (at-least-once); Dataflow предлагает состояние «ровно один раз» (exactly-once) и автомасштабирование; разветвление поддерживает паттерн lakehouse для повторной обработки.

3. Предоставление данных для функций реального времени в Bigtable и Redis

• Записывайте подмножество обогащённых событий в Bigtable с ключом строки (row key) вида user_id#timestamp с добавлением соли (salting); используйте Memorystore for Redis в качестве фронтального кэша для самых последних сессий.
• Обоснование: Bigtable обеспечивает запись временных рядов с низкой задержкой и высокой пропускной способностью; добавление соли помогает избежать «горячих точек» (hotspots); Redis снижает хвостовую задержку (tail latency) для персонализации в реальном времени.

4. Хранение данных и оптимизация запросов в BigQuery

• Создайте наборы данных, партиционированные по event_date и кластеризованные по user_id, channel. Используйте материализованные представления для KPI и плановые уплотнения (compactions) для загрузок мелких файлов; приобретите базовое резервирование слотов с небольшим буфером гибких слотов (flex slots) для всплесков нагрузки.
• Обоснование: партиционирование и кластеризация сокращают сканирование и снижают затраты; материализованные представления ускоряют дашборды; резервирование ограничивает затраты и защищает критически важные рабочие нагрузки от постановки в очередь.

5. Управление доступом и предотвращение эксфильтрации

• Примените IAM на уровне наборов данных для групп аналитиков; используйте теги политик (policy tags) для ограничения доступа к столбцам с PII и авторизованные представления (authorized views) для доступа поставщиков. Примените VPC Service Controls для BigQuery и Cloud Storage; используйте CMEK для регулируемых наборов данных.
• Обоснование: принцип наименьших привилегий на уровне наборов данных и столбцов; VPC SC снижает риск эксфильтрации данных; CMEK удовлетворяет требованиям криптографического контроля.

6. Внедрение резервного копирования, PITR и тестов восстановления

• Включите PITR в Bigtable на 7–14 дней; создавайте еженедельные резервные копии Spanner или Cloud SQL для хранилищ транзакционных заказов; ежедневно создавайте снимки критически важных таблиц BigQuery и полагайтесь на time travel для исправления ошибок. Ежеквартально проводите учения по восстановлению в изолированном проекте.
• Обоснование: многоуровневые варианты восстановления решают проблемы логических ошибок и аварий; регулярные учения подтверждают RPO/RTO и корректность планов действий (runbooks).

7. Контроль хранения и жизненного цикла данных

• Примените правило жизненного цикла для удаления необработанных объектов через 30 дней и обработанных через пять лет; заблокируйте политику хранения на уровне бакета, соответствующую требованиям комплаенса. Установите срок действия по умолчанию для наборов данных/таблиц BigQuery для временных данных.
• Обоснование: автоматическое применение правил снижает операционные риски; блокировка хранения предотвращает случайное или несанкционированное ослабление политики.

8. Мониторинг производительности и затрат, а также устранение «горячих точек»

• Отслеживайте утилизацию слотов BigQuery, объём сканированных байт и параллелизм BI-запросов; отслеживайте CPU и задержку read-modify-write в Bigtable; настройте оповещения о накоплении очереди (backlog) в Pub/Sub. Если возникают «горячие точки» по user_id, увеличьте ширину соли и выполните обратное заполнение ключей через Dataflow.
• Обоснование: непрерывная телеметрия позволяет выявлять узкие места на ранней стадии; проактивное изменение стратегии ключей сохраняет SLO без полной перестройки архитектуры.

9. Обеспечение приватного подключения и изоляции

• Для гибридных зависимостей используйте Partner Interconnect или Dedicated Interconnect с Cloud Router; убедитесь, что диапазоны IP-адресов не пересекаются; используйте Private Service Connect для конечных точек управляемых сервисов.
• Обоснование: приватные каналы снижают задержку и потерю пакетов; чёткое планирование IP-адресов и PSC обеспечивают изоляцию и предсказуемую маршрутизацию.

10. Внедрение практик для обеспечения надёжности

• Включите канареечные (canary) развёртывания для конвейеров Dataflow и сине-зелёные (blue/green) развёртывания для представлений BigQuery; контролируйте эволюцию схемы через подтверждения в Data Catalog; интегрируйте очереди недоставленных сообщений (dead-letter queues) с процессом реагирования на инциденты.
• Обоснование: контролируемые выкатки ограничивают радиус поражения (blast radius); управляемые изменения схемы поддерживают качество данных; DLQ гарантируют, что данные не будут потеряны во время инцидентов.

← Вычислительные ресурсы · Все домены · Сетевое взаимодействие →

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

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