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 поддерживают крупномасштабный прием данных, долговечное архивирование, производительность запросов и безопасное управление в современных платформах данных. Инженеры данных должны находить баланс между стоимостью, задержкой доступа, долговечностью и гранулярным контролем доступа при интеграции таких сервисов, как S3, Lake Formation, Redshift и DynamoDB, в конвейеры. Понимание компромиссов между классами хранения, автоматизации жизненного цикла, различий между управляемым и локальным хранилищем, а также шаблонов секционирования помогает избежать неожиданных проблем с производительностью и затратами в производственной среде.

Классы хранения и политики жизненного цикла Amazon S3

S3 предлагает несколько классов хранения и средств управления жизненным циклом для оптимизации затрат и шаблонов доступа. Класс хранения можно настроить при загрузке (в консоли или через CLI: aws s3 cp file s3://bucket/key –storage-class INTELLIGENT_TIERING) или с помощью правил жизненного цикла бакета (aws s3api put-bucket-lifecycle-configuration –bucket my-bucket –lifecycle-configuration file://lifecycle.json). Intelligent-Tiering автоматически перемещает объекты между уровнями для частого и редкого доступа и взимает небольшую плату за мониторинг; включайте его для неизвестных или меняющихся шаблонов доступа. Используйте правила жизненного цикла для перемещения объектов в GLACIER или DEEP_ARCHIVE для долгосрочного хранения, а также для удаления старых версий по истечении срока их действия.

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

Intelligent-Tiering: низкие операционные издержки при переменном доступе, ежемесячная плата за мониторинг каждого объекта; лучше всего подходит, когда шаблон доступа непредсказуем.
Glacier и Glacier Deep Archive: Glacier предлагает более быстрые стандартные и ускоренные варианты извлечения при более высокой стоимости хранения; Deep Archive — самый дешевый вариант для многолетнего хранения с временем извлечения (массового/стандартного) в несколько часов.
Standard-IA и Intelligent-Tiering: для Standard-IA действует минимальная 30-дневная плата и плата за извлечение — избегайте его использования для часто запрашиваемых данных или краткоживущих объектов.

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

Включите версионирование (aws s3api put-bucket-versioning –bucket my-bucket –versioning-configuration Status=Enabled) и блокировку объектов (aws s3api put-object-lock-configuration –bucket my-bucket –object-lock-configuration file://lock.json) для обеспечения неизменяемости; включение MFA Delete требует специальных операций CLI и учетной записи владельца бакета с настроенной MFA.
Переходы жизненного цикла применяются к версиям объектов и могут быть ограничены по префиксу/тегам; используйте правило abort-incomplete-multipart-upload, чтобы избежать утечек хранилища из-за незавершенных многосоставных загрузок.

Проектирование озера данных с помощью S3 и Lake Formation

Проектируйте озеро данных, используя S3 в качестве центрального объектного хранилища и Lake Formation для централизованного контроля доступа и каталогизации. Зарегистрируйте расположения S3 как ресурсы Lake Formation, настройте AWS Glue Data Catalog и используйте разрешения Lake Formation для баз данных/таблиц (aws lakeformation grant-permissions –principal arn:aws:iam::123456789012:user/analyst –permissions SELECT –resource ‘{…}’). Lake Formation может применять гранулярный контроль: на уровне столбцов, на уровне строк (с помощью выражений фильтрации) и маскирование на уровне ячеек, используя LF-теги и фильтры данных, применяемые к запросам Glue/Athena.

Ключевые шаблоны конфигурации и управления:

Регистрация расположения: используйте консоль Lake Formation, чтобы зарегистрировать s3://bucket/path и прикрепить IAM-роль, которая позволяет Lake Formation сканировать/читать данные.
Гранулярные политики: определите LF-теги и прикрепите их к таблицам/столбцам; предоставляйте разрешения с указанием списка столбцов (column-list) для их ограничения и используйте выражения фильтрации строк (row-filter expressions), чтобы ограничить строки, возвращаемые для субъекта.
Помните, что разрешения Lake Formation могут переопределять или блокировать разрешения IAM для S3 при доступе через Glue/Athena — при необходимости предоставляйте доступ как на уровне Lake Formation, так и на уровне S3.

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

Используйте Lake Formation, когда вам нужна централизованная каталогизация, LF-теги и гранулярное применение политик для нескольких аналитических движков.
Для простого контроля доступа или доступа внешних инструментов рассмотрите политики бакетов S3 и IAM, но будьте осторожны: аналитические движки, управляемые Lake Formation, могут игнорировать разрешения, выданные только через IAM.

Архитектура и хранилище Amazon Redshift

Redshift разделяет вычислительные ресурсы и управляемое хранилище на узлах типа RA3 в противовес узлам DS2 с локальными SSD-дисками. Узлы RA3 используют Redshift Managed Storage (RMS), где данные хранятся в Amazon S3 под управлением кластера; выбирайте RA3 для масштабируемого хранилища со стабильной производительностью запросов и возможностью платить за вычисления отдельно. Узлы DS2 хранят данные на локальных дисках инстанса, что требует тщательного определения размера и его изменения по мере роста данных.

Детали конфигурации и эксплуатации:

Создайте кластер RA3 через консоль или CLI: aws redshift create-cluster –cluster-identifier my-cluster –node-type ra3.xlplus –number-of-nodes 2 –master-username admin –master-user-password Passw0rd.
Команда COPY: должна выполняться в кластере с прикрепленной IAM-ролью, предоставляющей доступ на чтение из S3. Прикрепите роль при создании кластера или измените кластер, чтобы добавить iam roles; ARN роли (arn:aws:iam::acct:role/RedshiftS3Role) указывается в команде COPY как credentials ‘aws_iam_role=arn:…’.
Отслеживайте очереди WLM, ускорение коротких запросов (short query acceleration), автоматическую очистку (automatic vacuuming) и используйте SORT/ENCODE для оптимизации хранения и производительности.

Сравнение (RA3 и DS2):

RA3: разделенное хранилище, автоматическое распределение данных по уровням в S3, меньше усилий по управлению хранилищем, лучше всего подходит для растущих наборов данных.
DS2: локальное SSD-хранилище, меньшая задержка для локальных данных, но ограниченная емкость и сложность в масштабировании.

DynamoDB и выбор специализированных баз данных

Выбирайте DynamoDB для высокомасштабируемых рабочих нагрузок типа «ключ-значение» и документных баз данных, требующих задержки в пределах нескольких миллисекунд. Проектирование таблицы зависит от выбора ключа раздела (и опционального ключа сортировки): используйте ключи с высокой кардинальностью и хорошим распределением, чтобы избежать «горячих» партиций. Для последовательных ключей или ключей на основе временных меток реализуйте случайные префиксы (шардирование) или используйте UUID для распределения операций записи. Используйте режим «по требованию» (on-demand), чтобы избежать выделения ресурсов, но рассмотрите подготовленную пропускную способность (provisioned capacity) с автомасштабированием для предсказуемых нагрузок и для использования адаптивной пропускной способности (adaptive capacity) на «горячих» партициях.

Примечания по практической настройке:

CLI для создания таблицы:

undefined

Используйте GSI для альтернативных сценариев доступа, включите TTL для автоматического удаления устаревших данных и используйте DynamoDB Streams + Lambda для реализации паттернов отслеживания изменений данных (change-data-capture).
Для кэширования нагрузок с интенсивным чтением добавьте DAX; для сложных запросов или реляционных задач выбирайте Aurora или Redshift Spectrum в зависимости от сложности запросов и требований к согласованности данных.

Критерии выбора движка:

Используйте DynamoDB для предсказуемых сценариев доступа к одной таблице и для массового масштабирования с низкой задержкой.
Используйте Redshift для сложной аналитики и крупномасштабных OLAP-систем.
Используйте Aurora для транзакционных реляционных рабочих нагрузок.

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

Использование S3 Standard-IA для часто используемых данных — у Standard-IA есть минимальный 30-дневный период оплаты; используйте Standard или Intelligent-Tiering для недолговечных или часто используемых объектов.
Игнорирование того, что разрешения Lake Formation переопределяют разрешения IAM S3 для Glue/Athena — предоставляйте доступ и в Lake Formation, и в S3 при использовании Glue/Athena, и проверяйте действующие разрешения в консоли Lake Formation.
Команда COPY в Redshift требует IAM-роли, прикрепленной к кластеру, а не только разрешений пользователя — прикрепите IAM-роль с доступом к S3 к кластеру и ссылайтесь на ее ARN в операциях COPY.
«Горячие» партиции в DynamoDB из-за последовательных ключей — избегайте монотонных ключей; используйте хэшированные ключи, случайные префиксы или UUID и рассмотрите использование режима «по требованию» или автомасштабируемой подготовленной пропускной способности.
Неправильное включение S3 Object Lock и MFA Delete — для Object Lock требуется включенное версионирование и соответствующие разрешения; MFA Delete можно включить/отключить только через CLI с использованием MFA, и для этого есть строгие требования к владельцу бакета.
Неправильные переходы в жизненном цикле без тестирования стоимости и времени извлечения — тестируйте процессы извлечения для классов Glacier, чтобы избежать неожиданных задержек и счетов за извлечение.

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

Компания Acme Media должна хранить 50 ТБ необработанных видеоданных, предоставлять аналитикам доступ к преобразованным метаданным через запросы и обеспечивать доступ на уровне строк и столбцов для различных бизнес-подразделений, минимизируя при этом затраты на хранение.

Загружать необработанное видео в S3 с помощью многочастной загрузки (multipart upload), тегировать объекты по дате загрузки и набору данных, использовать Intelligent-Tiering для начальных, неизвестных сценариев доступа.
Настроить правила жизненного цикла для перемещения медиафайлов в GLACIER или DEEP_ARCHIVE по истечении настраиваемого периода хранения (убедитесь, что он соответствует 30+ дням, если рассматривается Standard-IA).
Зарегистрировать расположения S3 в Lake Formation, создать краулеры Glue для заполнения Data Catalog и предоставить бизнес-подразделениям разрешения на уровне строк и столбцов на основе тегов Lake Formation.
Хранить обработанные метаданные в Redshift RA3 для аналитики; прикрепить IAM-роль к кластеру для выполнения операций COPY из S3 и использовать операции VACUUM/ANALYZE в окнах обслуживания.
Использовать DynamoDB с хэшированными ключами UUID для высокопроизводительной справочной таблицы манифестов видео и включить режим «по требованию» для поглощения всплесков трафика.

Обоснование: Такой подход изолирует затраты на холодное хранилище с помощью классов Glacier, использует Intelligent-Tiering для неизвестных сценариев доступа, применяет Lake Formation для безопасного, гранулярного контроля доступа в аналитических системах и выбирает RA3 для масштабируемого аналитического хранилища, в то время как DynamoDB обеспечивает операционные поиски с низкой задержкой.

← Приём и сбор данных · Все домены · Каталогизация данных и управление метаданными →

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