Amazon SAP-C02: Базы данных и аналитика — Руководство по подготовке

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Транзакционные базы данных, шаблоны масштабирования и кэширование

Выбор между Amazon RDS (MySQL/PostgreSQL/Oracle/SQL Server), Amazon Aurora и Amazon DynamoDB начинается с определения профиля нагрузки: строгая реляционная схема и сложные транзакции — в пользу RDS/Aurora; огромный масштаб, поиск с задержкой в единицы миллисекунд и гибкая схема — в пользу DynamoDB. Aurora предлагает высокую пропускную способность с распределенным хранилищем, автомасштабирование реплик, быстрое переключение при сбоях, Global Database для межрегионального чтения и аварийное восстановление с меньшей задержкой. RDS Multi-AZ обеспечивает синхронную репликацию для высокой доступности, но не для масштабирования чтения; реплики чтения (read replicas) в RDS/Aurora справляются с нагрузками с интенсивным чтением. Для кэширования по типу «ключ-значение» и задержек на уровне микросекунд ElastiCache (Redis или Memcached) снижает нагрузку на БД; MemoryDB for Redis добавляет долговечность и Redis-совместимое постоянное хранение данных, где требуется высокая доступность и восстанавливаемость. Распространенные ловушки включают недооценку лимитов подключений (MySQL max connections), отказ от использования пулов соединений (когда Lambda/контейнеры создают множество подключений), «горячие» партиции в DynamoDB из-за плохого дизайна ключей и пренебрежение политиками вытеснения/дизайном кэша, что приводит к устареванию данных. Компромиссы при принятии решений часто сводятся к выбору между стоимостью, производительностью и отказоустойчивостью: подготовленные (provisioned) инстансы Aurora/крупные инстансы RDS стоят дороже, но снижают задержку и упрощают транзакции, в то время как DynamoDB с режимом on-demand или автомасштабированием может снизить операционные расходы, но требует тщательного планирования схемы и емкости. Шифрование, автоматическое резервное копирование, восстановление на момент времени (PITR) и шаблоны межрегиональной репликации следует выбирать в соответствии с требованиями RPO/RTO.

Озера данных, ETL и движки для аналитических запросов

S3 — это каноническое долговечное озеро данных; проектируйте его с учетом партиционирования, колоночных форматов (Parquet/ORC), сжатия и уплотнения (compaction) для экономически эффективных запросов. AWS Glue и AWS Glue Data Catalog предоставляют бессерверный ETL, обнаружение схем и каталогизацию; Lake Formation добавляет централизованный контроль доступа, гранулярные разрешения и меж-аккаунтный доступ для управляемых озер данных. Для интерактивной аналитики Amazon Athena выполняет запросы напрямую к данным в S3 (бессерверный, оплата за запрос), в то время как Amazon Redshift (с поддержкой RA3/Iceberg) предоставляет производительное, управляемое MPP-хранилище для сложной бизнес-аналитики (BI) и соединений (joins). Используйте Redshift Spectrum, чтобы запрашивать данные из S3 через Redshift, не загружая их полностью. Kinesis Data Firehose — это управляемый способ для приема и загрузки потоковых событий в S3 или Redshift. Распространенные архитектурные ловушки включают слишком большое количество мелких файлов, что вызывает высокие накладные расходы в Athena/Redshift, неудачно выбранные ключи партиционирования, создающие перекосы данных (skews), и отказ от уплотнения или преобразования в колоночные форматы. Компромисс заключается в выборе между задержкой и стоимостью: Athena имеет низкие операционные затраты для нерегламентированных (ad-hoc) запросов; Redshift обеспечивает более высокую стабильную производительность при более высокой стоимости подготовленных ресурсов. Управление данными (data governance) и отслеживание происхождения данных (lineage) с помощью Glue/Lake Formation необходимы для соответствия требованиям (compliance) и совместного владения данными несколькими командами.

Потоковая обработка, обработка в реальном времени и поиск

Для приема и обработки данных в реальном времени используются Kinesis Data Streams (пропускная способность на основе шардов и гарантии порядка), Kinesis Data Firehose (управляемая доставка в приемники/sinks), Kinesis Data Analytics (обработка с помощью SQL/Apache Flink) или Amazon MSK для задач, требующих совместимости с Kafka. Выбирайте Kinesis для простой нативной бессерверной интеграции с AWS; выбирайте MSK, когда клиенты зависят от инструментов экосистемы Kafka. Семантика доставки «хотя бы один раз» (at-least-once), лимиты на количество шардов, параллелизм потребителей (consumer parallelism) и выделение недостаточного количества шардов — распространенные эксплуатационные ошибки. Для последующего быстрого поиска и наблюдаемости (observability) сервис Amazon OpenSearch Service предоставляет индексацию, поиск в почти реальном времени и встроенные дашборды Kibana; управление жизненным циклом индексов и уровни хранения warm/cold снижают стоимость хранения старых данных. Используйте связку Kinesis + Lambda или Kinesis + KDA для обогащения/преобразования событий перед их сохранением в OpenSearch или S3. Проектируйте идемпотентность и дедупликацию в потребителях (consumers), так как повторные попытки или воспроизведения (replays) приводят к появлению дубликатов. Критерии выбора балансируют между пропускной способностью и задержкой: Kinesis с большим количеством шардов поддерживает высокую пропускную способность, но увеличивает стоимость и сложность управления; Firehose снимает нагрузку с потребителей, но предлагает менее гибкие возможности преобразования.

Миграция, репликация, управление и операционная отказоустойчивость

Database Migration Service (AWS DMS) и Schema Conversion Tool (SCT) — это основные инструменты для гомогенных и гетерогенных миграций, обеспечивающие непрерывный захват изменяемых данных (CDC). Паттерны миграции включают rehost (lift-and-shift), replatform (например, перенос на Aurora) и refactor (перепроектирование) под DynamoDB или бессерверные решения, где это уместно. Используйте DMS с проверкой данных до и после миграции, параллельным копированием таблиц и аккуратной обработкой LOB/LOBLOB. Межрегиональная репликация и репликация между аккаунтами требуют доступа к ключам KMS, пиринга VPC или Transit Gateway, а также планирования пропускной способности сети; Global Databases и реплики чтения являются альтернативами, когда требуются чтения с низкой задержкой между регионами. Управление и безопасность должны включать Lake Formation для обмена данными, принцип наименьших привилегий в IAM, политики ресурсов для снимков S3 и RDS, а также эндпоинты VPC/PrivateLink для предотвращения исходящего трафика в интернет. Операционные ловушки включают недостаточный мониторинг (пропущенное отставание реплики), отсутствие тестирования отказоустойчивости/ранбуков и скрытые затраты на исходящий трафик при массовой передаче данных. Резервное копирование, стратегия восстановления на момент времени (PITR) и автоматическое восстановление влияют на компромиссы между RTO/RPO; сочетайте репликацию для обеспечения доступности с регулярными бэкапами для долгосрочного хранения и соответствия требованиям.

Практическая задача: сценарий использования

Сценарий: Acme Retail управляет платформой электронной коммерции в мультиаккаунтной организации AWS с производственными нагрузками в us-east-1 и europe-west-1. Они хранят потоки кликов и события транзакций в S3 и используют локальную OLTP-базу данных, которую необходимо перенести в AWS с минимальным временем простоя.

Задача: Мигрировать OLTP-базу данных на высокодоступную, масштабируемую для чтения в разных регионах целевую платформу, одновременно создавая управляемое аналитическое озеро на S3 с возможностью приема и запроса данных в реальном времени.

Рекомендуемый подход:

1. Использовать AWS DMS с SCT для преобразования схемы и настроить непрерывный CDC из локальной БД в Amazon Aurora (Global Database) в регионе us-east-1 с репликой чтения Aurora в europe-west-1.
2. Принимать потоки кликов и события транзакций через Amazon Kinesis Data Streams и Firehose; буферизировать и доставлять необработанные события в S3 в формате Parquet, партиционируя их по дате и региону.
3. Каталогизировать данные в S3 с помощью AWS Glue, применять контроль доступа через Lake Formation и выполнять ETL с помощью заданий Glue (или Glue Studio) для создания обработанных наборов данных; предоставлять их аналитикам через Amazon Athena и Redshift Spectrum.
4. Добавить ElastiCache (Redis) для кэширования «горячих» данных о продуктах и сессиях с высокой интенсивностью чтения; настроить сквозной мониторинг с помощью CloudWatch, включить расширенный мониторинг (Enhanced Monitoring) на Aurora и проверить отказоустойчивость с помощью ранбуков.

Обоснование: Этот подход минимизирует время простоя за счет использования CDC в DMS, обеспечивает глобальные чтения с низкой задержкой через Aurora Global Database, создает управляемое озеро данных на S3 для аналитической гибкости и снижает нагрузку на OLTP-системы с помощью кэширования и разделенного потокового приема данных в соответствии с лучшими практиками корпоративной отказоустойчивости и производительности.

← Хранение и управление данными · Все домены · Миграция и модернизация →

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

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