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. Этот раздел охватывает методы телеметрии, оповещения и диагностики для таких сервисов, как Kinesis, Firehose, Glue, DMS, Lambda, а также аудиторские журналы AWS, которые помогают в расследовании инцидентов. Эффективный мониторинг сокращает среднее время обнаружения/восстановления (Mean Time To Detect/Recover), выявляя отставание потребителей, нагрузку на ресурсы заданий, задержку доставки и несанкционированный доступ. В следующих разделах приведены конкретные сигналы, шаблоны работы с CLI/консолью и критерии принятия решений для эксплуатации и исправления производственных потоков данных.

Метрики и оповещения CloudWatch для сервисов данных

CloudWatch — это основная плоскость телеметрии: создавайте фильтры метрик, дашборды и оповещения для ключевых метрик сервисов и интегрируйте оповещения с SNS, EventBridge или Systems Manager для автоматического исправления. Используйте

undefined

для программного создания оповещений; типичные флаги включают

undefined

(или

undefined

. Для дашбордов отправляйте пользовательские метрики (например, из метаданных заданий Glue) с помощью

undefined

с пространством имен, таким как «MyCompany/DataPipeline».

Сосредоточьтесь на следующих действенных метриках и шаблонах:

Glue: отслеживайте BytesRead, BytesWritten, RecordsProcessed и DPUHrs для обнаружения изменений в объеме данных, их перекоса (skew) и стоимости. Оповещения: внезапное падение RecordsProcessed или скачки DPUHrs на одну запись.
Kinesis: отслеживайте GetRecords.IteratorAgeMilliseconds для выявления отставания потребителей и IncomingBytes/IncomingRecords для оценки нагрузки на источник.
Firehose: отслеживайте DeliveryToS3.DataFreshness и DeliveryToS3.Records для выявления задержек доставки и потерь данных.
DMS: отслеживайте FullLoadRows, CDCLatencyMilliseconds и AppliedChanges для контроля состояния репликации.

Критерии принятия решений для оповещений:

Используйте составные оповещения (CloudWatch composite alarms) для уменьшения шума: комбинируйте IteratorAgeMilliseconds > X для 3 точек данных И частота ошибок потребителя > Y.
Для выбора пороговых значений определяйте базовые уровни на основе исторических данных за 7–14 дней и устанавливайте динамические пороги с помощью моделей обнаружения аномалий (PutAnomalyDetector), когда рабочие нагрузки носят сезонный характер.

Мониторинг и обработка ошибок в заданиях Glue

Glue отправляет метрики в CloudWatch и записывает логи в /aws-glue/jobs/output (журналы выполнения заданий) и /aws-glue/jobs/error (ошибки). Используйте CloudWatch Logs Insights для запроса данных о запусках заданий: выполняйте запросы через консоль или с помощью

undefined

со строкой запроса, такой как

undefined

. Отслеживайте BytesRead, BytesWritten, RecordsProcessed и DPUHrs из метрик выполнения заданий Glue — DPUHrs напрямую коррелирует со стоимостью и параллелизмом задания.

Распространенные сбои в Glue и способы их устранения:

OutOfMemory (OOM) или Executor lost: увеличьте тип/количество DPU для воркеров, переключитесь на тип воркера G.2X для задач с большим потреблением памяти или оптимизируйте партиционирование Spark (repartition/coalesce) и используйте pushdown-предикаты для уменьшения объема входных данных.
Перекос данных (data skew), вызывающий «отстающих» (stragglers): используйте ключи партиционирования для перебалансировки, увеличьте параллелизм или используйте split/resolve choices в Glue DynamicFrame, где это уместно.
Зависание задания или долгий запуск: включите закладки заданий (job bookmarks) и отслеживайте в Glue JobMetrics метрику «TimeWaitingForResources» для выявления конкуренции за ресурсы.

Компромиссы при принятии решений:

Увеличивайте DPU, когда узким местом являются CPU/память и важна предсказуемость времени выполнения; отдавайте предпочтение оптимизации кода (партиционирование, кэширование только при необходимости), если необходимо контролировать затраты.
Используйте потоковую обработку Glue (Glue streaming) для преобразований в режиме, близком к реальному времени; используйте пакетную обработку Glue ETL для сложных преобразований Spark и более крупных рабочих нагрузок, подходящих для спотовых инстансов.

Мониторинг Kinesis и Firehose

Отставание потребителей Kinesis (Consumer Lag): используйте GetRecords.IteratorAgeMilliseconds для определения, насколько сильно отстают потребители. Если GetRecords.IteratorAgeMilliseconds постоянно высок:

Масштабируйте, увеличивая количество шардов (reshard/scale), или
Улучшайте производительность потребителя за счет пакетной обработки, использования enhanced fan-out (для пропускной способности до 2 МБ/с на одного потребителя) или Kinesis Client Library (KCL) v2 с улучшенным механизмом контрольных точек (checkpointing).

Используйте

undefined

для проверки количества шардов и

undefined

для IteratorAgeMilliseconds. При сравнении вариантов исправления учитывайте:

Добавление шардов: увеличивает пропускную способность на запись и чтение; требует перешардирования и перебалансировки.
Enhanced fan-out: позволяет избежать разделения пропускной способности на чтение, но увеличивает стоимость на каждого потребителя.
Оптимизация потребителя: снижает потребность в дополнительных шардах и затраты, но требует инженерных усилий.

Метрики доставки Firehose: DeliveryToS3.DataFreshness количественно определяет задержку доставки; типичные настройки buffering_delay составляют 60–900 секунд и будут удерживать записи до тех пор, пока не будет достигнут bufferSize или bufferInterval. Если DeliveryToS3.DataFreshness высок:

Проверьте подсказки буферизации Firehose (BufferIntervalInSeconds, BufferSizeInMBs) в консоли или через

undefined

Проверьте ошибки в CloudWatch (DeliveryToS3.RecordsFailed) и разрешения бакета S3 (ошибки KMS, если используется шифрование).

Помните о семантике буферизации Firehose: сервис намеренно создает задержку до buffer interval; уменьшите buffer interval, чтобы снизить задержку за счет более частых записей в S3.

CloudTrail и аудит доступа к данным

CloudTrail предоставляет данные об активности API и, опционально, события данных для S3 и Lambda, которые не включены по умолчанию. Чтобы собирать события S3 на уровне объектов, необходимо явно включить события данных в CloudTrail через консоль или с помощью команды

undefined

и добавить ресурсы данных S3. Без включения событий данных S3 вы не увидите GetObject/PutObject в CloudTrail, что является частым пробелом при расследованиях.

Используйте логи CloudTrail в сочетании с CloudWatch Logs Insights для корреляции операционных метрик (например, логов заданий Glue) с событиями доступа. Шаблоны запросов:

CloudWatch Logs Insights:

undefined

Используйте правила EventBridge для реагирования на определённые вызовы API (например, PutBucketAcl) и перенаправляйте их в SNS для быстрых оповещений.

Задачи репликации DMS также публикуют метрики в CloudWatch: отслеживайте FullLoadRows для проверки завершённости первоначального копирования, CDCLatencyMilliseconds для обнаружения задержки репликации и AppliedChanges, чтобы убедиться, что транзакции применяются на целевой системе. Настройте оповещение (Alarm) на превышение CDCLatencyMilliseconds бизнес-SLA и на низкое значение AppliedChanges после увеличения количества строк полной загрузки.

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

Высокое значение IteratorAgeMilliseconds в Kinesis ошибочно принимают за проблемы с источником — правильный подход: проверить сохранение контрольных точек (checkpointing) и время обработки потребителя; масштабировать добавлением шардов или использовать enhanced fan-out только после профилирования CPU/IO потребителя.
Ошибки OOM (Out of Memory) в задании Glue решаются слепым увеличением DPU — правильный подход: профилировать этапы Spark, оптимизировать партиционирование и фильтрацию данных; увеличивать DPU или тип воркера только после подтверждения нехватки ресурсов.
Задержка буферизации Firehose, воспринимаемая как потеря данных — правильный подход: проверить BufferIntervalInSeconds и BufferSizeInMBs; уменьшить интервал для задач с низкой задержкой, принимая более высокую интенсивность записи/стоимость.
Предположение, что CloudTrail по умолчанию записывает операции чтения объектов S3 — правильный подход: включить события данных S3 в CloudTrail для сбора GetObject/PutObject для криминалистического аудита.
Отсутствие оповещений (alarms) о задержке CDC в DMS — правильный подход: создать оповещения CloudWatch для CDCLatencyMilliseconds и сравнивать AppliedChanges с FullLoadRows; расследовать проблемы с сетью или очередью транзакций при росте задержки.
Избыточные оповещения о временных всплесках — правильный подход: использовать evaluation-periods, datapoint-to-alarm или anomaly detection для уменьшения шума и использовать составные оповещения (composite alarms) для связанных условий.

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

Компания Acme Analytics выполняет приём потока кликов (clickstream) в реальном времени через Kinesis, обогащает события с помощью заданий Glue ETL, сохраняет устаревшие пакеты данных через Firehose в S3 и реплицирует устаревшие БД с помощью DMS. Они наблюдают сквозные задержки: отставание потребителей в Kinesis, ошибки OOM в заданиях Glue и большое значение метрики DeliveryToS3.DataFreshness в Firehose.

Профилировать потребителей Kinesis: получить метрику GetRecords.IteratorAgeMilliseconds, проанализировать логи потребителей и провести анализ затрат на Kinesis enhanced fan-out в сравнении с масштабированием шардов.
Изучить метрики CloudWatch и Logs Insights для заданий Glue на предмет стектрейсов OOM; протестировать перераспределение партиций (repartitioning) + pushdown predicate локально или на меньшем задании; только после этого при необходимости увеличивать DPU/тип воркера.
Проверить настройки буфера Firehose (BufferIntervalInSeconds) и метрику DeliveryToS3.DataFreshness; уменьшить интервал буферизации для критически важных SLO и проверить права на запись в S3/KMS.
Настроить составные оповещения (composite alarms) в CloudWatch, объединяющие IteratorAgeMilliseconds, частоту ошибок заданий Glue и DataFreshness в Firehose; доставлять оповещения в топик SNS для дежурной команды и запускать runbook через EventBridge.
Включить события данных S3 в CloudTrail и сопоставить события GetObject/PutObject со временем запуска заданий Glue и применёнными изменениями DMS для обнаружения несанкционированного или задержанного доступа.

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

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

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