Amazon SAA-C03: Аналитика, озера данных, ML и специализированные рабочие нагрузки — Руководство по подготовке

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Часть AWS SAA-C03 — Полное руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Основы озера данных: Lake Formation и Glue Data Catalog

Ключевым элементом аналитики в AWS является AWS Glue Data Catalog — хранилище метаданных, совместимое с Hive Metastore, которое используют Athena, Redshift Spectrum, EMR и Glue ETL. Здесь хранятся все определения таблиц, партиции, типы столбцов и конфигурации SerDe, и все последующие сервисы считывают данные из него. Если два пути загрузки данных (скажем, краулер Glue и ручная команда CREATE EXTERNAL TABLE) расходятся в определении схемы для одного и того же префикса S3, запросы молча возвращают неверные результаты или завершаются с ошибкой. Правильный подход — назначить единый источник истины для каждой таблицы: либо краулер отвечает за схему, либо ваше ETL-задание записывает данные с помощью glueContext.write_dynamic_frame.from_catalog, но никогда оба одновременно без стратегии слияния. Когда пакетные ETL-задания, конвертация в Parquet через Firehose и ручные DDL-операции одновременно записывают данные в одну и ту же таблицу, расхождение в каталоге (catalog drift) становится скрытой, но серьезной проблемой. Закрепите за каждой таблицей одного владельца, используйте Glue Schema Registry для потоковых источников данных и запускайте краулеры в режиме LOG (а не UPDATE_IN_DATABASE) для таблиц, управляемых ETL-заданиями, чтобы они выявляли расхождения, не перезаписывая тщательно подготовленные схемы.

AWS Lake Formation находится над Data Catalog и заменяет крупнозернистую модель политик IAM/S3 на уровень разрешений в стиле баз данных. Вместо предоставления права s3:GetObject на префикс, вы выполняете GRANT SELECT ON customers.orders TO role/AnalystRole, и Lake Formation прозрачно выдает временные учетные данные, когда Athena или Redshift Spectrum обращаются к базовым объектам. Его настоящая ценность — в тонкой настройке авторизации: фильтрация на уровне столбцов, безопасность на уровне строк через фильтры данных и контроль доступа на основе тегов (LF-Tags), который масштабируется на тысячи таблиц. Розничная платформа с персональными данными (PII) в таблице customers может предоставить аналитикам доступ к customer_id, region, signup_date, заблокировав при этом email и ssn — это применяется во время выполнения запроса и не требует создания множества представлений (view).

Каноническая схема управляемого озера данных:

1. Register S3 locations with Lake Formation (removes IAMAllowedPrincipals default).
2. Create databases and let Glue crawlers populate tables.
3. Define LF-Tags (e.g., Classification=PII, Domain=Sales).
4. Grant tag-based permissions to IAM principals.
5. Point Athena/Redshift/QuickSight at the catalog — permissions flow through.

Blueprints в Lake Formation — это готовые шаблоны рабочих процессов, которые объединяют краулеры, задания и триггеры для загрузки данных из источников JDBC или S3 в подготовленное озеро данных, превращая то, что потребовало бы настройки десятков ресурсов Glue вручную, в процесс, управляемый мастером настройки.

Частая ошибка — пытаться реализовать ограничения на уровне столбцов только в QuickSight. В QuickSight есть безопасность на уровне строк и столбцов, привязанная к наборам данных, но она защищает только интерфейс QuickSight — любой, у кого есть прямой доступ к Athena или S3, может ее обойти. Контроль на уровне столбцов должен применяться на уровне данных (через права в Lake Formation или физическое разделение столбцов во время ETL), а QuickSight наследует эти ограничения через свою IAM-роль.

Athena: бессерверный SQL поверх S3

Athena — это бессерверный движок на базе Presto/Trino с оплатой за запрос, который читает данные напрямую из Amazon S3. Не нужно выделять кластер, не требуется этап ETL перед выполнением запросов, и нет затрат во время простоя — вы платите только за объем отсканированных данных (обычно $5 за ТБ). Это делает Athena стандартным выбором для ad-hoc анализа файлов, уже находящихся в S3, будь то JSON-логи приложений, CSV-экспорты или таблицы фактов в формате Parquet. Athena требует наличия схемы и структуры партиций, которые хранятся в AWS Glue Data Catalog.

Поскольку счета за Athena выставляются за отсканированные терабайты, формат хранения оказывает огромное влияние на стоимость и задержку. Два главных рычага влияния — это формат и партиционирование:

• Колоночные форматы (Parquet, ORC) позволяют Athena отсекать ненужные столбцы и группы строк. Запрос вида SELECT sum(amount) FROM orders WHERE region='us-east-1' к данным в Parquet прочитает только два указанных столбца; при работе с CSV он прочитает каждый байт каждой строки.
• Партиционирование по столбцам с высокой селективностью (например, dt=2024-03-11/) превращает полное сканирование таблицы в целевое чтение. Для многотерабайтных логов (CloudFront, ALB, VPC Flow Logs) это разница между запросом стоимостью $0.15 и запросом за $30.

Конвертация сырых JSON или CSV в партиционированный Parquet со сжатием Snappy — это почти всегда первый шаг для оптимизации затрат. В сочетании с проталкиванием предиката LIMIT (pushdown), Athena покрывает большинство потребностей в аналитике поверх S3 без какой-либо инфраструктуры.

Экономически эффективный паттерн для таблицы “readings”, хранящейся в виде партиционированного Parquet:

CREATE EXTERNAL TABLE readings (
  station_id string,
  reading_ts timestamp,
  temp_c    double
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://weather-lake/readings/'
TBLPROPERTIES ('has_encrypted_data'='true');

SELECT station_id, AVG(temp_c) OVER (
         PARTITION BY station_id
         ORDER BY reading_ts
         ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS moving_avg
FROM readings
WHERE dt = '2024-03-11';

Пропускать запуск краулера — частая ошибка. Без записи в каталоге вам придется либо вручную писать DDL-команды CREATE EXTERNAL TABLE (что ненадежно при изменении схем), либо использовать трюки со схемой на чтении (schema-on-read), которые сканируют каждый файл. Хуже того, без MSCK REPAIR TABLE или проецирования партиций (partition projection) Athena будет сканировать весь префикс при каждом запросе. Краулеры Glue обнаруживают новые партиции по расписанию и атомарно обновляют каталог.

Athena и зашифрованные данные в S3. Athena поддерживает SSE-S3, SSE-KMS и CSE-KMS, но только если у вызывающей стороны есть нужные права KMS, а рабочая группа или клиент настроены на используемый режим шифрования. В случае CSE-KMS файл шифруется на стороне клиента перед загрузкой; субъекту IAM, выполняющему запрос, необходимы права kms:Decrypt и kms:GenerateDataKey для ключа CMK, а политика ключа должна предоставлять ответные разрешения. Типичный сценарий сбоя: загрузка Parquet, зашифрованного с помощью CSE-KMS, предоставление роли Athena только прав на чтение из S3, и последующее получение непонятных ошибок AccessDenied или HIVE_CANNOT_OPEN_SPLIT — объект доступен для чтения, но зашифрованный текст не может быть расшифрован. Другая частая ошибка — регистрация таблицы с неверным режимом шифрования (указание SSE-KMS в свойствах таблицы, когда объекты были записаны с помощью CSE-KMS); Athena пытается выполнить расшифровку на стороне сервера во время операции GetObject, и в результате получает необработанный зашифрованный текст, который не проходит проверку “магического числа” Parquet.

Федеративные запросы Athena позволяют объединять данные из S3 с операционными хранилищами (DynamoDB, RDS) без перемещения данных. Используйте Athena для ad-hoc аналитики, ориентированной на чтение; для планового формирования подготовленных зон используйте задания Glue.

Краулеры Glue, ETL-задания и закладки заданий

Краулеры Glue сканируют пути в S3, определяют схему (включая ключи разделов из структуры каталогов, например year=2024/month=01/) и регистрируют или обновляют таблицы в каталоге. Это решение с минимумом кода для задачи «мы загружаем файлы в S3 и делаем их доступными для запросов». Запланируйте ежечасный запуск краулера для целевого бакета, и Athena немедленно увидит новые разделы.

aws glue create-crawler \
  --name logs-crawler \
  --role AWSGlueServiceRole-Logs \
  --database-name analytics_db \
  --targets '{"S3Targets":[{"Path":"s3://acme-logs/app/"}]}' \
  --schedule "cron(0 * * * ? *)"

ETL-задания Glue (Spark, оболочка Python или Ray) отвечают за часть, связанную с преобразованием. Glue — это бессерверный сервис: вы платите за DPU-час с минимумом в одну минуту, а среда выполнения автоматически масштабирует воркеры. Основной паттерн: CSV/JSON на входе, партиционированный Parquet на выходе:

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext

glueContext = GlueContext(SparkContext.getOrCreate())
df = glueContext.create_dynamic_frame.from_catalog(
    database="raw", table_name="reports_csv")
glueContext.write_dynamic_frame.from_options(
    frame=df,
    connection_type="s3",
    connection_options={"path": "s3://curated/reports/",
                        "partitionKeys": ["report_date"]},
    format="parquet",
    format_options={"compression": "snappy"})

Критически важной операционной функцией является закладка задания (job bookmark): Glue сохраняет состояние о том, какие файлы или разделы уже были обработаны, поэтому последующие запуски считывают только новые данные. Если забыть включить закладки, каждый запуск будет заново обрабатывать весь набор данных с самого начала, что линейно увеличит стоимость и время выполнения и часто будет приводить к дублированию выходных данных. Закладки включаются для каждого задания и должны использоваться с источниками, которые их поддерживают (источники S3 через ридер Glue DynamicFrame поддерживают; произвольные чтения Spark — нет). Для работы закладок требуется аргумент transformation_ctx у каждого источника и обрамление кода вызовами job.init(...) / job.commit():

job = Job(glueContext)
job.init(args['JOB_NAME'], args)   # bookmark state loaded

datasource = glueContext.create_dynamic_frame.from_catalog(
    database="analytics_db",
    table_name="app_logs",
    transformation_ctx="datasource"   # required for bookmarking
)
# ... transforms ...
job.commit()                          # bookmark state persisted

Для чистого преобразования формата без какой-либо логики вариантом с наименьшими усилиями часто является краулер Glue для необработанных данных плюс задание Glue, созданное в визуальном редакторе (или рецепт DataBrew) — код Spark не требуется. Пользовательские кластеры EMR или конвертеры на Lambda добавляют операционную нагрузку, которую устраняет бессерверная модель Glue.

Типичное ежедневное задание, которое подготавливает данные в S3 и загружает их в Redshift Serverless:

# Glue 4.0 PySpark: S3 raw -> curated -> Redshift Serverless
df = glueContext.create_dynamic_frame.from_catalog(
        database="raw", table_name="orders").toDF()
df = df.filter("order_status <> 'CANCELLED'") \
       .withColumn("order_date", to_date("order_ts"))

glueContext.write_dynamic_frame.from_jdbc_conf(
    frame       = DynamicFrame.fromDF(df, glueContext, "out"),
    catalog_connection = "redshift-serverless-conn",
    connection_options = {"dbtable": "fact_orders", "database": "analytics"},
    redshift_tmp_dir   = "s3://stg/redshift-tmp/")

Конфигурации безопасности Glue и мультитенантный ETL

Краулеры и задания Glue требуют такого же подхода к шифрованию, как и Athena. Конфигурации безопасности (security configurations) Glue — это именованные наборы, определяющие, как шифруются целевые объекты S3, логи CloudWatch и закладки заданий, включая CSE-KMS с конкретным CMK. Задание, к которому присоединена конфигурация безопасности, прозрачно расшифровывает входные данные CSE-KMS и шифрует выходные данные тем же способом, при условии, что IAM-роль задания имеет разрешения KMS для используемых ключей.

Для мультитенантного ETL — когда SaaS-платформа обрабатывает данные каждого клиента с помощью CMK этого клиента — правильным паттерном является одна конфигурация безопасности на клиента (или параметр задания, выбирающий CMK) плюс IAM-роль с доступом только к этому CMK. Обработка данных всех клиентов в одном задании с одним общим ключом сводит на нет гарантию изоляции, которую должен обеспечивать CSE-KMS.

Связанная с этим практика: рабочие аналитические таблицы не должны быть прямой целью для исследовательских заданий или ноутбуков Glue. Экспортируйте снимок в S3 с префиксом «analytics» и направляйте Athena или Spark на эту копию. Выполнение экспериментальных преобразований над «живой» таблицей создает риск перезаписи на уровне разделов, повреждения закладок и конфликтов блокировок, а также размывает границу аудита между операционными данными и аналитическими производными.

AWS Glue DataBrew

DataBrew — это аналог Glue с минимумом кода для пользователей, которые не могут или не должны писать код на Spark. Он предлагает интерфейс в стиле электронных таблиц с более чем 250 готовыми преобразованиями (заполнение пропусков, маскирование PII, группировка выбросов, разбор дат). Его отличительными чертами являются общие рецепты (shared recipes) — версионируемые JSON-артефакты, которые можно публиковать и повторно применять в разных проектах, — и визуализация происхождения данных (data lineage), которая отслеживает столбцы от исходных наборов данных через рецепты и задания до мест вывода. Выбирайте DataBrew, когда за логику преобразования отвечают аналитики; выбирайте Glue Studio/скрипты, когда за нее отвечают инженеры, и конвейеру требуется кастомный код, потоковая обработка или сложные соединения.

Amazon EMR: распределенная пакетная обработка и роли времени выполнения

Amazon EMR — это управляемая кластерная платформа для запуска Spark, Hadoop, Hive, Presto, HBase и Flink. Его сильная сторона — это большие, распараллеливаемые пакетные или интерактивные рабочие нагрузки, которые считывают петабайтные наборы данных из S3 и соединяют их с другой системой записи (часто Redshift) для обогащения. EMR может запускать краткосрочные кластеры (запуск, выполнение, завершение) или долгоживущие, а также смешивать инстансы On-Demand, Spot и Reserved с помощью флотилий инстансов (instance fleets).

Канонический паттерн: задание Spark читает Parquet из S3, выгружает таблицы измерений из Redshift через UNLOAD в S3, соединяет их на разных исполнителях (executors) и записывает обогащенный результат обратно в S3:

# Spark on EMR: enrich S3 events with Redshift dimensions
df_events = spark.read.parquet("s3://raw/events/dt=2024-11-01/")
df_dims = (spark.read
    .format("io.github.spark_redshift_community.spark.redshift")
    .option("url", "jdbc:redshift://cluster:5439/analytics")
    .option("dbtable", "public.customer_dim")
    .option("tempdir", "s3://staging/redshift-unload/")
    .load())

enriched = df_events.join(df_dims, "customer_id", "left")
enriched.write.mode("overwrite").partitionBy("region").parquet("s3://curated/events/")

EMR здесь выигрывает, потому что Spark распределяет соединение между десятками узлов, а промежуточное хранение в S3 позволяет избежать узкого места однопоточного JDBC-соединения. Ловушка заключается в том, чтобы рефлекторно использовать EMR всякий раз, когда нужно выполнить запрос к данным в S3. Для ad-hoc SQL-запросов к десяткам или сотням гигабайт данных предоставление и настройка кластера Spark — это чистые операционные издержки: определение размера кластера, конфигурация YARN, автомасштабирование, ротация логов, установка патчей. EMR оправдывает себя только тогда, когда это обосновано объемом данных, необходимостью кастомного кода или гибкостью движка выполнения.

Роли времени выполнения (runtime roles) в EMR. Исторически все шаги на кластере наследовали профиль инстанса EC2 — одну роль, прикрепленную к базовым узлам, — что означало, что каждая команда, использующая общий кластер, имела объединение всех разрешений, необходимых любой из команд. Роли времени выполнения решают эту проблему: когда пользователь отправляет шаг, он передает --execution-role-arn, и EMR принимает эту роль на время выполнения шага. Команда А может быть ограничена доступом к s3://team-a/*, а команда Б — к s3://team-b/*. Профиль инстанса становится минимальной ролью для начальной загрузки, которая только извлекает артефакты кластера.

Роли времени выполнения также являются механизмом для блокировки доступа к IMDS. Когда эта функция включена (EMR 6.7+ со Spark/Hive на YARN), пользовательский код не может получить доступ к сервису метаданных инстанса — включая IMDSv2 — потому что платформа перехватывает эти вызовы. Это закрывает путь для эскалации привилегий, при котором задание могло бы вызвать http://169.254.169.254/latest/api/token и принять мощный профиль инстанса EC2.

aws emr create-cluster \
  --release-label emr-6.15.0 \
  --applications Name=Spark Name=Hive \
  --security-configuration team-isolation-sc \
  --service-role EMR_DefaultRole \
  --ec2-attributes InstanceProfile=EMR_EC2_MinimalRole,...

aws emr add-steps --cluster-id j-XXXX \
  --steps Type=Spark,Name="TeamA-ETL",\
ActionOnFailure=CONTINUE,\
Jar=command-runner.jar,\
Args=[spark-submit,s3://team-a/jobs/etl.py] \
  --execution-role-arn arn:aws:iam::111122223333:role/TeamA-EMRRuntime

Именно конфигурация безопасности включает принудительное применение ролей времени выполнения и блокировку IMDS. Без нее предположение, что рабочие нагрузки EMR «автоматически используют роли с наименьшими привилегиями», неверно — по умолчанию они используют общий профиль инстанса, и IMDS доступен из пользовательского кода.

Amazon Redshift и Redshift ML

Redshift — это колоночное MPP-хранилище данных для устойчивых аналитических нагрузок, требующих отрисовки дашбордов менее чем за секунду, выполнения сложных соединений миллиардов строк и стабильной задержки при одновременной работе BI-пользователей. Узлы RA3 отделяют вычислительные ресурсы от управляемого хранилища; Redshift Serverless тарифицируется в RPU-секундах на основе настроенной базовой мощности, масштабируется под нагрузкой и приостанавливается в простое, устраняя традиционную проблему подбора размера кластера.

Redshift участвует в аналитических конвейерах в двух режимах обогащения:

• Как источник: Spark на EMR извлекает измерения через UNLOAD в S3, или Glue читает через Redshift Data API.
• Как целевое хранилище: Firehose или задание Glue копирует обогащенные данные с помощью COPY.

Redshift Spectrum расширяет эту возможность, позволяя выполнять SQL-запросы из Redshift напрямую к S3 через Glue Data Catalog — тот же каталог, который использует Athena, — что и делает возможным реализацию паттерна lake-house. Идеально, когда у вас уже есть кластер Redshift и вы хотите соединять фактические данные из хранилища с «холодной» историей в S3 без перемещения данных.

Пакетные загрузки используют COPY из S3 с распараллеливанием по вычислительным узлам; для параллелизма файлы следует разбивать на примерно равные части (количество которых кратно числу срезов (slice)):

COPY events FROM 's3://acme-lake/events/dt=2024-05-12/'
IAM_ROLE 'arn:aws:iam::111:role/RedshiftLoader'
FORMAT AS PARQUET;

Потоковая загрузка обычно проходит через Firehose (буферизованный COPY) для доставки, не требующей операционного вмешательства (zero-ops).

Redshift ML позволяет SQL-пользователям создавать, обучать и вызывать модели с помощью CREATE MODEL:

CREATE MODEL churn_predictor
FROM (SELECT tenure, plan, monthly_spend, churned FROM customers)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'redshift-ml-artifacts');

SELECT customer_id, predict_churn(tenure, plan, monthly_spend)
FROM customers_current;

Под капотом Redshift экспортирует обучающий набор данных в S3, вызывает SageMaker Autopilot (или указанный алгоритм, например XGBoost) и импортирует скомпилированную модель для выполнения логического вывода (inference) внутри базы данных. Это мощный инструмент, когда аналитики уже работают в SQL, но он не заменяет полноценную ML-платформу: перемещение данных в S3 и вычислительные ресурсы для обучения в SageMaker оплачиваются отдельно, большие обучающие наборы могут привести к значительным расходам на исходящий трафик и время работы Autopilot, и отсутствует встроенный рабочий процесс для хранилищ признаков (feature stores), отслеживания экспериментов или A/B-развертывания. Рассматривайте Redshift ML как демократизированный инструмент для логического вывода над данными в Redshift, а не как универсальное средство для обучения моделей.

Выбор между Athena и Redshift

Потоковая загрузка данных: Kinesis Data Streams, Firehose и MSK

Эти три потоковых сервиса AWS решают пересекающиеся задачи, но с существенно разными гарантиями:

Kinesis Data Streams использует шарды (или режим on-demand); записи с одинаковым ключом партиции попадают в один и тот же шард и потребляются по порядку. Потребители используют классический GetRecords или Enhanced Fan-Out (выделенные 2 МБ/с на каждого потребителя). Lambda-функция, подключенная как источник событий, вызывается с пакетами данных для каждого шарда, сохраняя порядок. Это правильный выбор, когда последующая логика нетривиальна, когда несколько независимых потребителей должны иметь возможность повторно считывать историю, или когда объемы кликстрима огромны — например, сайт, генерирующий 30 ТБ/день, будет направлять данные через KDS в Firehose для сохранения в S3 и последующего анализа с помощью Athena/Spectrum.

Kinesis Data Firehose — это управляемая доставка по принципу «отправил и забыл»: он буферизует данные по размеру или времени (например, 5 МБ / 300 секунд), опционально вызывает Lambda для преобразования, опционально конвертирует JSON в Parquet/ORC, используя схему таблицы Glue, и записывает в S3, Redshift (через S3 + COPY), OpenSearch или Splunk. Включение преобразования в Parquet в Firehose — это простой способ сохранять потоковые данные в оптимизированном для запросов формате без необходимости в последующем задании Glue:

Firehose delivery stream → 
  Record transformation: Lambda (optional, for enrichment) →
  Format conversion: enabled, schema from Glue table "events.raw" →
  Destination: s3://lake/events/ partitioned by !{timestamp:yyyy/MM/dd}

Firehose не гарантирует сквозной порядок доставки, не поддерживает нескольких потребителей с возможностью повторного чтения, а его назначения — это фиксированный набор приемников. Выбор Firehose, когда требование гласит «обрабатывать каждую запись по порядку» или «несколько независимых потребителей», неверен в обоих случаях. Аналогично, ожидать, что один лишь Firehose будет выполнять сложные преобразования — это ловушка; его единственный хук для трансформации — это Lambda, вызываемая для каждого буферизованного пакета. Все, что связано с внешним обогащением, агрегацией нескольких записей или условной маршрутизацией, должно быть реализовано в этой Lambda или перенесено выше по потоку в Managed Service for Apache Flink.

Amazon MSK — это управляемый Apache Kafka. Выбирайте его, если у вас уже есть производители/потребители Kafka, вам нужны специфичные для Kafka функции (уплотненные топики, транзакции, Kafka Streams, Connect) или требуется пропускная способность, превышающая ту, что может комфортно обеспечить Kinesis на основе шардов.

Использование SQS или EventBridge в качестве пути для приема аналитических данных — это ошибка: SQS не обеспечивает порядок в рамках потока и не имеет функции повторного чтения; EventBridge оптимизирован для маршрутизации событий, а не для постоянного приема данных со скоростью в несколько МБ/с.

Поиск в реальном времени: KDS + Firehose + OpenSearch + QuickSight

Каноническая замена для локального стека Elasticsearch+Logstash:

Firehose буферизует записи потока и доставляет их напрямую в домен OpenSearch, обеспечивая повторные попытки, резервное копирование в S3 и опциональное преобразование с помощью Lambda. OpenSearch Dashboards встроены и бесплатны при использовании домена и подходят для операторов, отслеживающих потоки в реальном времени. QuickSight дополняет эту схему, предоставляя аналитику для бизнеса — он напрямую запрашивает данные из Athena, Redshift, RDS и OpenSearch, а его колоночный движок SPICE, работающий в памяти, кэширует обработанные наборы данных для обеспечения производительности панелей мониторинга на уровне долей секунды.

Типичное разделение: OpenSearch Dashboards для операторов; QuickSight для руководителей, использующих агрегированные, подготовленные наборы данных из озера данных на базе Athena/Glue. Обоим сервисам должен быть предоставлен IAM-доступ на чтение и, где это применимо, разрешение Decrypt в KMS для CMK, защищающих базовое хранилище — в противном случае уровень визуализации отображает пустые панели с ошибками разрешений, скрытыми в логах запросов.

Управление доступом в QuickSight

В QuickSight создаются наборы данных (логические запросы плюс вычисляемые поля и безопасность на уровне строк), затем на их основе — анализы, а после этого публикуются панели мониторинга (представления только для чтения, доступные для совместного использования). Управление доступом является многоуровневым и должно применяться на правильном уровне. Ловушка заключается в предоставлении широкого доступа на уровне панели мониторинга — например, предоставление доступа группе всей организации, когда только часть пользователей должна видеть базовые данные.

Принцип наименьших привилегий в QuickSight означает:

• Предоставлять доступ к набору данных только тем пользователям/группам, которым он необходим.
• Применять безопасность на уровне строк с помощью набора данных разрешений, который фильтрует строки по имени пользователя или группе.
• Применять безопасность на уровне столбцов для скрытия конфиденциальных полей.
• Предоставлять доступ к панелям мониторинга конкретным пользователям, группам или (для встроенной аналитики) пространствам имён.

Предоставление публичного доступа к панели мониторинга или доступа в рамках всего аккаунта обходит замысел контроля на уровне набора данных, поскольку пользователи, просматривающие панель мониторинга, наследуют доступ на чтение к визуализируемым данным независимо от разрешений на доступ к исходным данным. Помните, что безопасность на уровне столбцов в QuickSight защищает только интерфейс QuickSight; любой, у кого есть прямой доступ к Athena или S3, обходит её, поэтому критически важные элементы управления должны находиться в Lake Formation или ETL, а не только в QuickSight.

Роли QuickSight — Admin, Author, Reader — контролируют, что пользователь может делать, в отличие от разрешений на совместное использование, которые контролируют, что он может видеть. Пользователь с ролью Reader потребляет ресурсы по более низкой цене за сессию, чем лицензия Author, поэтому группы пользователей-зрителей по умолчанию должны иметь роль Reader, а доступ должен предоставляться через членство в группах, а не через индивидуальные назначения.

Amazon Neptune для графовых рабочих нагрузок

Neptune — это управляемая графовая база данных, поддерживающая модель графа свойств (Gremlin, openCypher) и RDF (SPARQL). Она специально создана для работы с данными с высокой степенью связности — социальные связи, мошеннические сети, графы знаний, рекомендательные системы — где рекурсивные соединения в реляционной базе данных становятся непомерно затратными. Социальная платформа с пользователями, подписками, лайками и постами естественным образом отображается на вершины и рёбра, и Neptune отвечает на запросы обхода графа с несколькими переходами («друзья друзей, которым понравилось X») за миллисекунды.

Neptune Streams предоставляет упорядоченный по времени лог каждого изменения в графе. Lambda или приложение, опрашивающее этот поток, может реагировать на изменения — пересчитывать рекомендации, обновлять поисковый индекс, запускать оповещения о мошенничестве — без необходимости создавать специализированный конвейер захвата изменений данных (CDC). Воспроизведение этого на Aurora или DynamoDB требует обхода графа на уровне приложения плюс отдельной инфраструктуры для CDC. Когда в постановке задачи присутствуют как «анализ взаимосвязей», так и «мониторинг изменений», Neptune со Streams является прямым решением.

SageMaker: комплексное пользовательское машинное обучение

SageMaker обеспечивает полный жизненный цикл: ноутбуки Studio, управляемые задания обучения (с поддержкой спотовых инстансов), Model Registry, конечные точки реального времени и бессерверные, пакетное преобразование и Pipelines для MLOps. Типичный процесс включает загрузку обучающих данных в S3, запуск задания обучения с указанием встроенного алгоритма или пользовательского контейнера, после чего SageMaker выделяет эфемерные инстансы, передаёт логи в CloudWatch и записывает артефакт модели обратно в S3. Развёртывание выполняется одним вызовом API:

from sagemaker.estimator import Estimator
est = Estimator(image_uri=xgb_image, role=role,
                instance_count=2, instance_type="ml.m5.xlarge",
                output_path="s3://models/xgb/")
est.fit({"train": "s3://data/train/", "validation": "s3://data/val/"})
predictor = est.deploy(initial_instance_count=1, instance_type="ml.m5.large")

Не нужно управлять Kubernetes, драйверами GPU или сервером моделей. Для команд, чьё требование — «обучить и предоставить доступ к модели», SageMaker почти всегда является решением с наименьшими накладными расходами по сравнению с самостоятельным развёртыванием инференса на ECS/EC2.

SageMaker Savings Plans предполагают обязательство по расходам в долларах в час на соответствующие компоненты (Studio, обучение, обработка, инференс в реальном времени) на 1 или 3 года, что даёт скидку до 64% от цен по требованию. Они гибкие в отношении семейства инстансов, размера, региона и компонента, но не покрывают Ground Truth, хранилище или передачу данных. Используйте Savings Plans, когда базовое использование ML предсказуемо; оставляйте пиковые нагрузки по обучению на спотовых инстансах для увеличения экономии.

Управляемые сервисы ИИ в сравнении с пользовательским ML

Сервисы Amazon Rekognition (изображения/видео: распознавание объектов и сцен, анализ лиц, модерация), Textract (OCR, а также извлечение данных из форм и таблиц) и Comprehend (NLP: распознавание сущностей, анализ тональности, обнаружение PII, пользовательская классификация) предоставляют доступ к предварительно обученным моделям через простые API. Вызов DetectEntities в Comprehend возвращает типизированные сущности, включая категорию COMMERCIAL_ITEM, что идеально подходит для извлечения названий ингредиентов из текста рецепта и их передачи в DynamoDB для поиска — и всё это без обучающих данных, без хостинга и с оплатой по факту использования:

aws comprehend detect-entities \
    --language-code en \
    --text "Combine 2 cups flour, 1 tsp salt, and 3 eggs..."

Распространенная ошибка — избыточное усложнение (over-engineering): запуск заданий обучения в SageMaker, разметка данных с помощью Ground Truth и развертывание эндпоинтов, в то время как управляемый сервис уже решает эту задачу за малую долю операционных затрат. Пользовательский ML оправдан только тогда, когда точность на специфичных для домена данных оказывается существенно выше, когда требуемые типы сущностей не соответствуют схеме управляемого сервиса (при этом Comprehend Custom Classification/Entity Recognition все равно дешевле, чем «сырой» SageMaker), или когда требования к задержке и местоположению данных (data residency) требуют использования частной модели.

Хранилища и сети для HPC: FSx for Lustre и EFA

Сильно связанные (tightly coupled) HPC-нагрузки — CFD, молекулярная динамика, сейсмическая визуализация, крупномасштабное обучение — имеют два непреложных требования: межсоединение узлов с крайне низкой задержкой и общее хранилище с высокой пропускной способностью.

Elastic Fabric Adapter (EFA) — это сетевой интерфейс, доступный для определенных семейств EC2 (hpc7a, hpc6id, c6in, p4d/p5 и других). Он обходит стек TCP/IP ядра с помощью технологии OS-bypass через Libfabric, позволяя MPI и NCCL достигать задержек на уровне микросекунд при работе на сотнях узлов. Для работы EFA требуется, чтобы инстансы находились в одной зоне доступности (Availability Zone) и, для максимальной пропускной способности, в кластерной группе размещения (cluster placement group).

FSx for Lustre — это управляемая параллельная файловая система, обеспечивающая пропускную способность в сотни ГБ/с и задержку менее миллисекунды. Сервис нативно интегрируется с S3: файловую систему FSx можно связать с бакетом, чтобы объекты отображались как POSIX-файлы, а результаты, записанные в Lustre, можно было экспортировать обратно в S3. Развертывания типа Persistent SSD подходят для долгоживущих временных данных (scratch); тип Scratch2 дешевле для эфемерных данных заданий.

Неправильный паттерн — использование EFS для HPC. EFS основан на NFS и настроен на множество небольших клиентов, выполняющих файловый ввод-вывод общего назначения; он не может поддерживать совокупную пропускную способность или количество IOPS для метаданных, которые требуются для MPI-задания на 500 узлов, а его архитектура с поддержкой нескольких AZ добавляет задержку. Использование стандартного ENA вместо EFA ограничивает MPI задержками на уровне TCP, что в несколько раз увеличивает время выполнения операций, интенсивно использующих allreduce. Правильная комбинация — это инстансы с поддержкой EFA в кластерной группе размещения, монтирующие FSx for Lustre, где S3 используется в качестве долговечного холодного хранилища, связанного с файловой системой.

← Базы данных и кеширование · Все домены · Интеграция приложений →

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

Просмотреть Amazon →