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 и операционные детали, используемые для надежной и масштабируемой загрузки необработанных данных в платформу данных. Инженеры данных должны выбирать между пакетными и потоковыми точками входа, обеспечивать каталогизацию данных и возможность их обнаружения, а также проектировать систему с учетом пропускной способности, возможности повторного воспроизведения и режимов отказа. Ключевыми строительными блоками AWS являются S3 и Glue для пакетной загрузки, Kinesis и Firehose для потоковой, DMS для миграции баз данных и CDC, а также компоненты на основе API и событий (API Gateway, Lambda, SNS, SQS, события S3) для специализированной (ad-hoc) и push-ориентированной загрузки данных.

Пакетная загрузка с помощью AWS Glue и S3

Glue — это основной управляемый сервис для ETL и работы с метаданными при пакетной загрузке в S3 и ваш каталог данных. Типичный паттерн: выгружать необработанные файлы в S3 (используя отдельные префиксы для сырых данных, например, raw/zone), запускать краулер Glue для определения схемы и наполнения Glue Data Catalog, а затем запускать задания Glue ETL (на базе Spark) для преобразования, партиционирования, конвертации в колоночные форматы (Parquet/ORC) и записи оптимизированных данных обратно в S3. Настраивайте краулеры с подходящими классификаторами (встроенными для CSV/JSON/Parquet или кастомными на основе grok/regex) и предоставьте краулеру IAM-роль с разрешениями s3:GetObject/s3:ListBucket и glue:catalog — отсутствие этих разрешений является частой операционной ошибкой.

При настройке заданий и краулеров Glue используйте следующие паттерны и параметры для консоли/CLI:

Создание краулера:

undefined

и запуск с помощью

undefined

Задание Glue:

undefined

; включите закладки заданий (job bookmarks), чтобы избежать повторной обработки данных. Критерии выбора между Glue и альтернативами:

Используйте Glue, когда вам нужен управляемый Spark ETL, обнаружение схем и интеграция каталога с Athena/Redshift Spectrum.
Используйте EMR, когда требуется тонкая настройка кластера, кастомные библиотеки или долго работающие кластеры.
Используйте простые функции Lambda или Glue on-demand для легковесных преобразований небольших файлов.

Потоковая загрузка с помощью Kinesis Data Streams и Firehose

Kinesis Data Streams (KDS) предназначен для загрузки данных в реальном времени с возможностью повторного воспроизведения, контролем потребителей и гранулярным масштабированием. Один шард Kinesis обеспечивает пропускную способность на запись 1 МБ/с или 1000 записей/с и на чтение 2 МБ/с; используйте

undefined

и отправляйте данные с помощью

undefined

. Ключи партиционирования (partition keys) определяют распределение по шардам; низкая кардинальность ключей приводит к появлению «горячих» шардов — избегайте этого, увеличивая энтропию ключа или добавляя к нему хэш-суффикс. Масштабируйте шарды с помощью

undefined

или включите режим On-Demand для автоматического масштабирования.

Firehose — это сервис для доставки потоковых данных, оптимизированный для доставки в режиме, близком к реальному времени (в S3, Redshift, OpenSearch, Splunk), со встроенной буферизацией, сжатием и опциональным преобразованием с помощью Lambda. Настройте буферизацию с помощью BufferingHints: buffer_size (МБ) и buffer_interval (секунды), чтобы сбалансировать задержку доставки и стоимость; включите сжатие (GZIP, Snappy) и установите обрабатывающую Lambda-функцию для преобразований на уровне записей. Ключевые различия:

Kinesis Data Streams:
- Реальное время, поддержка нескольких потребителей, повторное воспроизведение сохраненных данных, явное управление шардами
- Пропускная способность на шард (1МБ/1тыс. записей), необходимо проектировать ключи партиционирования
Kinesis Data Firehose:
- Управляемая доставка в целевые системы, автоматические повторы/откаты, нет повторного воспроизведения доставленных записей
- Поддерживает буферизацию (по размеру/времени), сжатие, преобразование через Lambda, промежуточное хранение в S3 для загрузки в Redshift

Выбирайте KDS, когда вам нужна возможность повторного воспроизведения, строгий контроль потребителей или несколько нижестоящих потребителей; выбирайте Firehose, когда вам нужна простая доставка и преобразование данных для S3/Redshift/OpenSearch с минимальными операционными издержками.

Миграция баз данных и CDC с помощью DMS

AWS DMS используется для гомогенных/гетерогенных миграций и непрерывной репликации данных (CDC). Разверните инстанс репликации (

undefined

), размер которого подбирается под требуемую пропускную способность, а решения о размере принимаются на основе скорости изменений, объема полной загрузки и параллелизма задач. Типы задач DMS:

full-load: только копирование существующих данных
cdc: потоковая передача текущих изменений
full-load + cdc: начальная загрузка с последующей потоковой передачей изменений Настройте эндпоинты с соответствующими параметрами движка (JDBC/строка подключения), включите дополнительное логирование или плагины на источнике и предоставьте JSON-файл с маппингом таблиц для их фильтрации/включения. Для источников на базе MySQL для CDC в DMS требуется включенный бинарный лог (binlog) и соответствующий binlog_format (рекомендуется ROW) на источнике; для PostgreSQL необходимо включить логическую репликацию и плагин, такой как wal2json, или использовать слоты репликации. Отслеживайте задачи с помощью метрик CloudWatch и логов задач; для увеличения пропускной способности настраивайте параметры batchApplyEnabled и maxFullLoadSubTasks.

Критерии выбора между full-load и CDC: используйте full-load+CDC, когда требуется миграция с минимальным временем простоя; используйте только CDC для непрерывной репликации после того, как начальная загрузка была выполнена другим способом. Всегда проверяйте маппинг схем и проводите тестовые миграции на репрезентативных объемах данных.

Паттерны приёма данных на основе API и событий

API и события предназначены для push-моделей приёма и оркестрации данных. Распространённые паттерны:

API Gateway -> Lambda -> Firehose/Kinesis: подходит для случаев, когда клиенты отправляют JSON-события. Используйте троттлинг в API Gateway и управление параллелизмом в Lambda для создания противодавления (backpressure) и принудительного использования заголовков идемпотентности.
Уведомления о событиях S3: настройте уведомления бакета для отправки событий создания объекта в Lambda, SQS или SNS через консоль или с помощью

undefined

; используйте фильтры по префиксам/суффиксам для ограничения срабатываний. Для веерной рассылки (fan-out) направляйте события по маршруту S3 -> топик SNS -> несколько очередей SQS/подписчиков Lambda, чтобы доставить одно и то же событие нескольким потребителям без жёсткой связи между ними.

SQS и SNS для надёжного, слабосвязанного приёма данных: SQS для обработки по pull-модели с помощью воркеров и таймаутом видимости (visibility timeout), SNS для веерной рассылки по push-модели.

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

Используйте DLQ (очереди недоставленных сообщений) для сбоев в Lambda/SQS; настройте политику повторных попыток для подписок SNS.
Для высокопроизводительной потоковой передачи данных из API предпочитайте пакетную отправку в Kinesis или Firehose вместо синхронной записи в нижестоящие системы, чтобы избежать блокировки API-клиентов.

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

Путаница между Kinesis Data Streams (с возможностью повторного чтения, управляемые шарды) и Firehose (управляемая доставка, без повторного чтения): выбирайте KDS, когда требуется повторное чтение или несколько потребителей; выбирайте Firehose для простых конвейеров доставки.
Отсутствие IAM-разрешений для краулера Glue: всегда назначайте IAM-роль, предоставляющую разрешения

undefined

, чтобы краулеры могли заполнять Data Catalog.

Отсутствие бинарного логирования/логической репликации для DMS CDC: включите

undefined

в MySQL (в формате ROW) или логическую репликацию и

undefined

в PostgreSQL перед запуском задач CDC.

Низкая кардинальность ключа партиционирования, вызывающая «горячие» шарды: увеличьте кардинальность ключа партиционирования с помощью хеширования, включите в него атрибуты с высокой кардинальностью или увеличьте количество шардов; отслеживайте метрики троттлинга Put/Get.
Чрезмерная или неправильно настроенная буферизация в Firehose, ведущая к высокой задержке: настройте

undefined

в соответствии с допустимой задержкой и объёмом запросов.

Использование уведомлений о событиях S3 без DLQ или механизма повторных попыток: используйте веерную рассылку через SNS/SQS или Lambda с DLQ, чтобы избежать потери событий и обеспечить надёжную доставку.

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

Компания RetailCo собирает кликстрим-данные с мобильных устройств (большой объём в реальном времени) и ежедневные файлы с каталогом продуктов; им необходимы дашборды в реальном времени и консолидированное озеро данных для аналитики.

Принимать кликстрим-данные в Kinesis Data Streams, используя ключи партиционирования, полученные из сессии пользователя + хешированный суффикс шарда; создавать потребителей с помощью Kinesis Data Analytics или Lambda/Kinesis Client Library для обработки в реальном времени.
Использовать Kinesis Data Firehose с трансформирующей Lambda-функцией для сохранения обогащённых потоковых данных в S3 (в формате Parquet), сжимать с помощью Snappy и опционально загружать в Redshift Spectrum для аналитики.
Размещать ежедневные файлы каталога в S3

undefined

и запускать по расписанию краулер Glue для обновления Glue Data Catalog, затем запускать Glue ETL-задания для преобразования данных в партиционированный Parquet в curated-зоне. 4. Использовать уведомления о событиях S3 -> SNS -> Lambda для запуска легковесных обновлений метаданных или инвалидации кеша; направлять доставку в SQS для надёжной последующей обработки. 5. Отслеживать метрики шардов Kinesis (

undefined

) и использовать

undefined

или потоки On-Demand для управления ростом нагрузки; включить оповещения CloudWatch.

Обоснование лучших практик AWS: разделение путей обработки данных в реальном времени и пакетной обработки, использование Kinesis Data Streams, когда требуется повторное чтение и изоляция потребителей, использование Firehose для управляемой доставки в S3/другие назначения, и поддержка Glue Data Catalog для обнаружения данных и интеграции запросов с Athena/Redshift.

Все домены · Хранение данных и архитектура озера данных →

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