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.

Оптимизация затрат для рабочих нагрузок с данными гарантирует, что хранилища, вычислительные ресурсы и конвейеры обработки данных приносят пользу без неконтролируемого роста расходов. Инженеры данных должны находить баланс между производительностью запросов, долговечностью и доступностью данных с одной стороны, и моделями ценообразования, которые варьируются в зависимости от сервиса и характера использования, с другой. Эта область требует знания классов хранения и политик жизненного цикла, элементов управления на уровне запросов и кластеров, спотовых и зарезервированных мощностей, а также компромиссов между бессерверными и выделенными ресурсами.

Оптимизация затрат на хранение в S3

S3 Intelligent-Tiering — это рекомендуемый по умолчанию вариант для наборов данных с непредсказуемыми шаблонами доступа: включайте Intelligent-Tiering через консоль или AWS CLI, когда частоту доступа к объектам невозможно надежно спрогнозировать. Настраивайте Intelligent-Tiering, учитывая плату за мониторинг/автоматизацию (взимается небольшая ежемесячная плата за мониторинг каждого объекта) и выбирая правильное минимальное количество дней для автоматических переходов между уровнями (30 дней для перехода с уровня частого доступа на уровень нечастого). Используйте теги объектов и правила жизненного цикла, чтобы исключить небольшие, часто запрашиваемые объекты, для которых плата за мониторинг превысит экономию.

Используйте следующие операционные подходы для сокращения расходов на S3:

Запускайте S3 Storage Class Analysis (в консоли: Management > Analytics или через

undefined

), чтобы выявить шаблоны доступа на уровне префиксов/тегов перед созданием правил жизненного цикла.

Переводите большие исторические наборы данных в архивные классы (Glacier Flexible Retrieval или Glacier Deep Archive) с помощью переходов жизненного цикла; устанавливайте время перехода в соответствии с бизнес-SLA и избегайте частого использования ускоренного извлечения (Expedited retrievals).
Объединяйте множество мелких объектов (проблема мелких файлов) в более крупные объекты (контейнерные файлы Parquet) для аналитических нагрузок, чтобы сократить затраты на каждый запрос и каждую операцию GET.

Критерии принятия решений:

Используйте Intelligent-Tiering для наборов данных с непредсказуемым, умеренным доступом, где время извлечения не является критичным.
Используйте Standard-IA или One Zone-IA для данных с нечастым доступом, которые должны быть доступны для быстрого извлечения с предсказуемой частотой.
Используйте Glacier Standard/Bulk/Deep Archive для долгосрочного хранения, когда извлечения редки и допустима задержка от нескольких минут до нескольких часов; предпочитайте извлечение типа Bulk/Standard вместо Expedited, чтобы избежать высоких затрат.

Управление затратами в Athena и Redshift

Стоимость Athena зависит от объема сканированных байт. Применяйте элементы управления рабочими группами (в консоли или через

undefined

), чтобы внедрить лимиты на объем сканируемых данных для одного запроса и месячные бюджеты для каждой рабочей группы; включите опцию “Enforce workgroup settings”, чтобы запросы, превышающие лимит данных на запрос, завершались с ошибкой, а не выполнялись. Сокращайте объем сканируемых байт, преобразуя исходные файлы в колоночные сжатые форматы (Parquet/ORC), выполняя партиционирование по дате или часто используемым для фильтрации столбцам, применяя проталкивание предикатов (predicate pushdown) и используя CTAS или CREATE TABLE AS для материализации оптимизированных наборов данных. Используйте повторное использование результатов запросов и изоляцию рабочих нагрузок в отдельные рабочие группы, чтобы избежать перетекания затрат между командами.

Решения о затратах на Redshift зависят от предсказуемости рабочей нагрузки и выбора хранилища. Для стабильного, предсказуемого использования вычислительных ресурсов хранилища данных приобретайте зарезервированные узлы (Reserved Nodes) (на один или три года, с частичной/полной предоплатой), чтобы зафиксировать скидки по сравнению с тарифами по требованию. Для переменных рабочих нагрузок:

Используйте Redshift Serverless или узлы RA3 с управляемым хранилищем, чтобы разделить вычислительные ресурсы и хранилище.
Используйте масштабирование параллелизма (concurrency scaling) экономно (оно влечет за собой дополнительные расходы, но обеспечивает автоматическое масштабирование) и отслеживайте кредиты.

Ключевые моменты для сравнения:

Reserved Nodes: лучший вариант для стабильных, долгосрочных кластеров; требует обязательств, но дает значительную скидку.
On-demand: гибкий вариант для непредсказуемых или краткосрочных проектов; более высокая почасовая стоимость.
Serverless/RA3 со Spectrum: перенесите хранилище в S3 и платите за вычислительные ресурсы только во время их активности, чтобы избежать крупных обязательств по резервированию.

Стратегии управления затратами в Glue и EMR

AWS Glue предоставляет бессерверный ETL с несколькими рычагами управления затратами. Для пакетных заданий, не чувствительных к задержкам, используйте гибкое выполнение Glue (задания Glue Flex), что может сократить затраты до ~34% по сравнению со стандартным выполнением Glue. Настраивайте параметры заданий Glue в Glue Studio или через CLI (

undefined

), чтобы выбрать тип воркера и максимальное количество DPU, установите разумный верхний предел DPU для предотвращения неограниченного автомасштабирования и используйте закладки заданий (job bookmarks), чтобы избежать полной повторной обработки. Для интерактивных или чувствительных к задержкам рабочих нагрузок выбирайте типы воркеров (Standard/G.1X/G.2X) и ответственно настраивайте параллелизм.

Сокращение затрат на EMR основано на использовании спотовых инстансов (Spot Instances) для узлов задач (task nodes), в то время как главный узел (master node) и основные узлы (core nodes) работают в режиме On-Demand (настройте парки инстансов (instance fleets) или группы инстансов (instance groups) в консоли или через

undefined

). Используйте Spot только для узлов задач, выберите стратегию распределения, оптимизированную по емкости, и установите соответствующую ставку/максимальную цену, если используете Spot с торгами. Обеспечьте сохранность состояния кластера и отказоустойчивость заданий следующим образом:

Храните постоянные данные в S3 (используя EMRFS), а не в HDFS, при использовании спотовых узлов задач.
Используйте автоматические повторные попытки и пошаговые рабочие процессы, чтобы справляться с прерываниями спотовых инстансов.
Применяйте управляемое масштабирование EMR (EMR Managed Scaling) для подбора оптимального размера кластеров; отслеживайте политики масштабирования, чтобы избежать колебаний (oscillation).

Критерии принятия решений:

Используйте Glue Flex для низкоприоритетных, чувствительных к затратам ETL-процессов с допустимостью более длительного времени запуска; установите максимальный предел DPU.
Используйте EMR со спотовыми узлами задач для крупномасштабной временной обработки (например, ночной пакетной обработки), но держите главный/основные узлы в режиме On-Demand или используйте Instance Fleets со смешанным распределением.

Зарезервированные мощности и Savings Plans для сервисов данных

Зарезервированные мощности и Savings Plans применяются к различным сервисам данных по-разному. Для сервисов на базе EC2 (EMR, самостоятельно управляемый HBase, кастомный Hadoop) используйте EC2 Savings Plans или Reserved Instances для покрытия расходов на вычисления; выбирайте региональные или зональные опции в зависимости от требований к мобильности. Redshift поддерживает покупку зарезервированных узлов для подготовленных кластеров, чтобы снизить почасовые затраты для предсказуемых нагрузок хранилища данных. Бессерверные сервисы (Glue, Athena) не имеют резервирования ресурсов; вместо этого оптимизируйте их через планирование рабочих нагрузок и изменение форматов данных.

Практические рекомендации по покупке:

Приобретайте Redshift Reserved Nodes для стабильных рабочих нагрузок хранилища данных с известным уровнем использования (оцените 1-летние и 3-летние сроки, а также варианты с полной/частичной предоплатой или без предоплаты).
Используйте EC2 Savings Plans для покрытия прогнозируемых расходов на EMR/EC2 в разных семействах инстансов; Savings Plans обеспечивают гибкость при смене семейства инстансов или региона.
Не покупайте резервирования для бессерверных сервисов; вместо этого оптимизируйте шаблоны использования, планирование и структуру данных.

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

Athena сканирует всю таблицу без партиционирования — всегда партиционируйте большие таблицы временных рядов по дате или другим столбцам с высокой кардинальностью, по которым часто выполняется фильтрация, и конвертируйте их в Parquet/ORC, чтобы минимизировать объем сканируемых данных.
Автоматическое масштабирование DPU в Glue может привести к избыточному выделению ресурсов — установите максимальное количество DPU в конфигурации задания (в консоли или через

undefined

) и выберите подходящие типы воркеров, чтобы затраты оставались предсказуемыми.

Плата за извлечение данных из S3 Glacier — избегайте ускоренного извлечения (Expedited), если это не критически важно для бизнеса; планируйте стандартное (Standard) или массовое (Bulk) извлечение и настраивайте переходы жизненного цикла с реалистичными SLA.
Главные (master) и основные (core) узлы EMR не должны использовать Spot-инстансы — настройте master/core узлы как On-Demand и назначайте Spot-инстансы только для узлов задач (task nodes), избегая хранения состояния в HDFS или реплицируя его.
Множество мелких объектов в S3 увеличивают затраты на запросы и замедляют аналитику — объединяйте мелкие файлы в более крупные колоночные файлы во время загрузки данных.
Чрезмерное использование масштабирования параллелизма (concurrency scaling) или неуправляемого автомасштабирования может увеличить почасовую оплату — отслеживайте метрики масштабирования, устанавливайте лимиты и используйте зарезервированные мощности, когда рабочие нагрузки предсказуемы.

Практическая задача: снижение затрат на ночные ETL-процессы в Acme Analytics

Компания Acme Analytics выполняет ночные ETL-процессы и ежедневную ad-hoc аналитику; ежемесячные расходы на облако резко выросли из-за роста объема необработанных данных в S3 и часов работы Redshift по требованию (On-Demand). Компании необходимо сократить расходы на 35% без влияния на SLA ночных процессов.

Выполнить анализ классов хранения S3 (Storage Class Analysis) и настроить правила жизненного цикла для перемещения «холодных» необработанных файлов старше 90 дней в Glacier Flexible Retrieval (планировать массовые/стандартные извлечения).
Преобразовать необработанные CSV-файлы в партиционированный и сжатый формат Parquet и объединить мелкие файлы; хранить оптимизированные наборы данных с отдельными префиксами для Athena/Redshift Spectrum.
Создать рабочие группы (workgroups) Athena с лимитами на объем сканируемых данных для каждого запроса и принудительно применять настройки рабочих групп; включить повторное использование результатов запросов и установить ежемесячный бюджет для каждой рабочей группы.
Перенести пакетные ETL-задачи на задания Glue Flex для несрочных преобразований, установить максимальное количество DPU и запланировать их выполнение на часы с низкой нагрузкой; сохранить небольшой парк стандартных ресурсов Glue для срочных заданий.
Оптимизировать размер кластера Redshift: приобрести годовые зарезервированные узлы (Reserved Nodes) для постоянной базовой вычислительной нагрузки, переместить исторические данные в S3 и использовать Spectrum для редко выполняемых запросов, а также включать масштабирование параллелизма (concurrency scaling) только под контролем мониторинга.

Обоснование: Стратегия сочетает оптимизацию формата данных и жизненного цикла (снижая затраты на хранение и сканирование), использование более дешевых бессерверных вычислений для гибких задач (Glue Flex), управление запросами (рабочие группы Athena) и резервирование мощностей для постоянных вычислительных нагрузок, чтобы максимизировать скидки, сохраняя при этом доступность и производительность.

← Мониторинг и устранение неполадок конвейеров данных · Все домены · Качество →

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