Amazon DEA-C01: Запросы к данным и аналитика — Руководство по подготовке

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

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

Этот раздел охватывает проектирование, настройку и эксплуатацию сервисов AWS, которые поддерживают аналитические запросы и BI для больших наборов данных. Основное внимание уделяется экономически эффективным, высокопроизводительным шаблонам запросов в Athena, Redshift, OpenSearch и QuickSight, а также их взаимодействию с S3, Glue и транзакционными хранилищами. Для освоения темы необходимо найти баланс между форматом хранения, партиционированием, типом вычислений и размещением данных, чтобы минимизировать количество сканируемых байт и сетевую асимметрию, обеспечивая при этом получение аналитических выводов с низкой задержкой.

Оптимизация запросов в Amazon Athena

Стоимость Athena зависит от количества отсканированных байт, поэтому физическая структура данных и метаданные являются основными рычагами управления. Используйте колоночные форматы (Parquet или ORC) со сжатием (Snappy для Parquet, опции Zlib/ORC) для уменьшения размера и нагрузки на CPU. Партиционируйте данные по столбцам с высокой кардинальностью, используемым для фильтрации в запросах (например, дата, регион), и регистрируйте партиции в Glue Data Catalog. Типичные шаблоны:

Записывайте данные в S3 по путям вроде s3://bucket/events/date=2026-08-02/ и используйте краулеры Glue или команду

undefined

для заполнения партиций.

Используйте

undefined

, чтобы принудительно использовать колоночное сжатие.

Используйте проекцию и отсечение партиций (partition pruning) с помощью выражений WHERE, которые ссылаются на ключи партиционирования, чтобы избежать сканирования ненужных партиций.

Когда запросы требуют объединения с транзакционными хранилищами, используйте Federated Query в Athena (коннекторы Lambda) для выполнения объединений между источниками, такими как RDS, DynamoDB или Redshift. Коннекторы развертываются как функции Lambda и регистрируются в качестве источников данных в Athena; пример действий в консоли: Athena > Data sources > Connectors > New. Критерии принятия решений:

Используйте Federated Query, когда объемы данных в RDS/DynamoDB невелики или когда нужно объединить небольшую таблицу измерений (dimension table) с большим набором данных в S3.
Для повторяющихся тяжелых объединений извлекайте и материализуйте операционные данные в S3 (в формате Parquet), чтобы перенести затраты на объединение на один ETL-процесс и использовать Athena для повторных чтений.

Настройка запросов и распределения данных в Amazon Redshift

Производительность Redshift зависит от стиля распределения (distribution style) и ключей сортировки (sort keys), которые минимизируют перемещение данных и задействуют карты зон (zone maps). Выбирайте стили DIST, используя следующие критерии:

DISTKEY (KEY): полезен при объединении больших таблиц по ключу с высокой кардинальностью; позволяет избежать перераспределения данных, если обе таблицы используют один и тот же DISTKEY.
ALL: реплицирует небольшую таблицу измерений на все узлы, чтобы избежать сетевых перемешиваний (network shuffles) при объединениях.
EVEN: стиль по умолчанию для непредсказуемых рабочих нагрузок или когда нет подходящего ключа; позволяет избежать появления «горячих точек» (hotspots).
AUTO: позволяет Redshift выбрать стиль на основе размера таблицы и рабочей нагрузки, если у вас нет четких указаний.

Определяйте SORTKEYs для столбцов, используемых в фильтрах по диапазону или в ORDER BY, чтобы задействовать карты зон и сократить количество чтений с диска. Распространенные операционные команды:

undefined

;

Периодически используйте VACUUM и ANALYZE:

undefined

; отслеживайте метрики асимметрии (skew) и распределения в

undefined

. Redshift Spectrum позволяет запрашивать внешние таблицы S3 через Glue Data Catalog. Создайте внешнюю схему с помощью:

undefined

; Критерии выбора между Spectrum и нативным Redshift:

Используйте Spectrum для редко запрашиваемых, больших «холодных» данных, хранящихся в S3, или для многоуровневых архитектур данных.
Храните «горячие», часто объединяемые наборы данных внутри Redshift для повышения производительности; при объединении со Spectrum выбирайте DISTKEYs для совместного размещения ключей объединения или используйте перераспределение для минимизации сетевого ввода-вывода.

Amazon OpenSearch Service для анализа логов

OpenSearch оптимизирован для приема (ingest) и быстрого специального (ad-hoc) анализа логов; его конфигурация индекса и кластера определяет пропускную способность и стоимость. Проектирование и жизненный цикл индекса:

Используйте шаблоны индексов, такие как logs-YYYY.MM.DD, и шаблон индекса для установки

undefined

(для маленьких индексов: 1 шард; для больших: несколько шардов размером ~10–50 ГБ) и

undefined

для обеспечения доступности.

Настройте политики жизненного цикла индексов (ILM) для перемещения индексов между уровнями: hot, warm, cold и UltraWarm для контроля затрат; UltraWarm снижает затраты на хранение исторических данных на узлах hot. Шардирование и реплики влияют на производительность запросов и индексации:
Больше шардов увеличивает параллелизм, но добавляет накладные расходы; настраивайте количество шардов на узел в зависимости от кучи (heap) и CPU.
Реплики повышают пропускную способность чтения и отказоустойчивость; устанавливайте количество реплик в зависимости от количества одновременных запросов и SLA. Операционные команды и шаблоны действий в консоли:
Используйте OpenSearch Dev Tools (или curl) для применения шаблонов индексов и политик ILM с помощью PUT-запросов, а также для мониторинга с помощью API состояния кластера. Назначайте атрибуты узлам и используйте механизм осведомленности о распределении шардов (shard allocation awareness) для предотвращения «горячих точек». Критерии принятия решений:
Выбирайте UltraWarm, когда требования к задержке запросов к историческим логам допускают более высокую задержку чтения в обмен на более низкую стоимость хранения.
Храните свежие индексы на узлах hot для поддержки быстрых агрегаций и дашбордов.

QuickSight для BI и визуализации

QuickSight предоставляет быстрые дашборды с двумя основными режимами получения данных: SPICE (in-memory) и прямой запрос (direct query). SPICE обеспечивает субсекундную производительность для дашбордов и подходит для повторяющихся чтений; прямые SQL-запросы (к Athena, Redshift, RDS) предпочтительны для очень больших или часто меняющихся наборов данных. Ключевые настройки и лучшие практики:

Создавайте наборы данных в консоли: New dataset > Выберите источник (Athena/Redshift/RDS/OpenSearch) > Import to SPICE или Use direct query.
Используйте запланированные обновления SPICE для ежедневных нужд или потребностей, близких к реальному времени; настройте инкрементальное обновление на основе партиционирования по временной метке, чтобы ограничить перемещение данных. Безопасность и управление:
Внедряйте безопасность на уровне строк (row-level security) с помощью сопоставлений пользователей/групп QuickSight и правил набора данных.
Для доступа к данным между аккаунтами настройте IAM-роль и разрешения на основе ресурсов, которые сможет принять QuickSight. Критерии принятия решений:
Используйте SPICE для дашбордов с большим количеством одновременных пользователей и предсказуемыми окнами обновления.
Используйте прямой запрос, когда критична свежесть данных или ограничена емкость SPICE; комбинируйте с вычисляемыми полями и параметрами для интерактивного взаимодействия с пользователем.

Распространенные ошибки и критерии выбора

Athena взимает плату за объем сканированных данных — всегда разбивайте данные на партиции по предикатам запросов и храните их в колоночных форматах (Parquet/ORC) со сжатием (Snappy/Zlib), чтобы уменьшить объем сканируемых байтов.
Использование DISTKEY в Redshift для столбца с низкой кардинальностью вызывает перекос данных (data skew) — выбирайте для DISTKEY ключи соединения с высокой кардинальностью или используйте DISTSTYLE ALL для небольших таблиц-измерений.
Внешние таблицы Redshift Spectrum требуют наличия Glue Data Catalog — убедитесь, что Glue включен в целевом регионе и что IAM-роли разрешают Redshift доступ к каталогу.
Ошибки в количестве и размере шардов OpenSearch — избегайте создания слишком большого количества мелких шардов; задавайте размер шардов в десятки ГБ и используйте ILM для перемещения старых индексов в UltraWarm для экономии средств.
Отсутствие запуска RUN ANALYZE/VACUUM в Redshift после массовых загрузок — планируйте выполнение ANALYZE и VACUUM для обновления статистики и освобождения дискового пространства для оптимальных планов запросов.
Переполнение SPICE в QuickSight и устаревшие данные — планируйте емкость SPICE, используйте инкрементальные обновления или переключитесь на прямой запрос (direct query) для задач, требующих данных в реальном времени.

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

Компании Acme Retail требуются ежедневные BI-отчеты, объединяющие транзакционные заказы из Amazon RDS, события clickstream из S3 и профили пользователей из DynamoDB, с учетом ограничений по стоимости и с обновлением дашбордов по свежим данным менее чем за минуту.

Преобразовать данные clickstream в S3 в партиционированный Parquet (на основе даты), сжать с помощью Snappy и зарегистрировать метаданные в AWS Glue с помощью crawler.
Использовать Athena для ad-hoc запросов к S3 и развернуть коннекторы Federated Query для RDS и DynamoDB для выполнения соединений с небольшими таблицами-измерениями; материализовать результаты часто выполняемых соединений в формате Parquet, если запросы повторяются.
Подготовить Redshift для тяжелых аналитических соединений: загрузить агрегированные срезы данных в Redshift, установить DISTKEY для столбца с высокой кардинальностью customer_id и определить SORTKEY по order_date; использовать Spectrum для доступа к «холодным» историческим данным в S3.
Загружать логи приложений в OpenSearch с ежедневными шаблонами индексов; применять ILM для хранения свежих индексов на «горячих» узлах (hot nodes) и перемещения старых индексов в UltraWarm для экономии средств.
Создать дашборды в QuickSight: импортировать свежие агрегированные данные в SPICE с запланированными инкрементальными обновлениями для достижения воспринимаемой скорости отклика менее минуты, и использовать прямые запросы (direct queries) для метрик, требующих постоянной свежести.

Обоснование: Такой подход минимизирует затраты на сканирование в Athena за счет партиционирования и колоночных форматов, уменьшает сетевой обмен (network shuffle) в Redshift благодаря правильным ключам распределения и сортировки, использует Spectrum, чтобы не хранить «холодные» данные в Redshift, применяет ILM в OpenSearch для оптимизации стоимости хранения и задействует SPICE для создания отзывчивых дашбордов, сохраняя при этом критическую свежесть данных с помощью прямых запросов.

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

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