Выберите сервис Kinesis для потокового приема данных.
→Обработка данных за доли секунды, управляемая потребителем → Kinesis Data Streams. Полностью управляемая доставка в S3/Redshift/OpenSearch с опциональной конвертацией формата → Kinesis Data Firehose.
Почему: KDS хранит записи (от 24 часов до 365 дней) и поддерживает нескольких потребителей. Firehose не имеет возможности повторного воспроизведения; он обменивает повторное воспроизведение на доставку без операций.
Источник↗
Поток сталкивается с ошибками ProvisionedThroughputExceeded в пиковые нагрузки.
→Решардирование. Каждый шард поддерживает прием 1 МБ/с или 1000 записей/с, исходящий трафик 2 МБ/с. Используйте равномерные ключи партиционирования; включите Enhanced Fan-Out для скорости >2 МБ/с на потребителя.
Почему: Горячие ключи партиционирования концентрируют трафик на одном шарде. Случайные или хеш-основанные ключи распределяют нагрузку.
Источник↗
Потоковая нагрузка нестабильна и непредсказуема; ручное решардирование вызывает операционные трудности.
→Kinesis Data Streams в режиме емкости по запросу. Автоматически масштабируется до 200 МБ/с по умолчанию; оплата за объем данных.
Источник↗
Несколько потребителей, читающих один и тот же поток, достигают лимита чтения 2 МБ/с/шард.
→Enhanced Fan-Out. Каждый потребитель получает выделенные 2 МБ/с/шард через push-модель HTTP/2 SubscribeToShard.
Источник↗
Максимизировать пропускную способность приема данных из приложения на стороне производителя.
→Kinesis Producer Library (KPL) с агрегацией + коллекцией. Объединяет несколько пользовательских записей в одну запись Kinesis размером до 1 МБ; снижает стоимость PUT-запросов.
Почему: PutRecord для одной записи имеет ограничение по скорости и является дорогим при 50 тыс. событий/с. KPL агрегирует данные на стороне клиента.
Источник↗
Разместить JSON-кликстрим в S3 в формате Parquet, секционированный по времени события.
→Firehose с конвертацией формата записей (JSON → Parquet) с использованием таблицы Glue Data Catalog + динамическое партиционирование по временной метке события.
Почему: Parquet + партиционирование значительно снижает стоимость сканирования в Athena. Динамическое партиционирование избегает отдельного шага ETL.
Источник↗
Некоторые записи не проходят трансформацию или доставку в Firehose; необходимо их сохранить для повторного воспроизведения.
→Настройте резервное копирование S3 с `AllData` или `FailedDataOnly`. Сбойные записи попадают в настроенный префикс с метаданными об ошибках.
Источник↗
Обеспечьте отсутствие потери данных в MSK, если сбойнет AZ брокера.
→Фактор репликации ≥ 3 в 3-х AZ и `min.insync.replicas=2` с `acks=all` для производителя. Включите Multi-AZ через KRaft без ZooKeeper или размещение брокеров в 3-х AZ.
Источник↗
Потоковая передача данных из MSK в S3, OpenSearch или RDS без управления кластером Kafka Connect.
→MSK Connect с управляемым коннектором (Confluent S3 Sink, Debezium для CDC). Автоматически масштабирует воркеры по WCU.
Источник↗
Топик хранит последнюю версию записи по каждому ключу; старые версии могут быть отброшены.
→Установите `cleanup.policy=compact` для топика. Kafka сохраняет самое последнее значение для каждого ключа; более старые записи с тем же ключом подлежат компактированию.
Источник↗
Регулярная еженедельная передача 10 ТБ данных из локальной NFS в S3 через Direct Connect.
→AWS DataSync с локальным агентом + запланированная задача. Проверяет целостность данных, поддерживает инкрементальную передачу, параллельную работу.
Почему: DataSync быстрее, чем aws-cli sync, и нативно обрабатывает регулирование пропускной способности, повторные попытки и верификацию.
Источник↗
Извлекать данные из SaaS API (Salesforce, ServiceNow, Zendesk) в S3 по расписанию.
→AWS AppFlow. Управляемые коннекторы, обработка OAuth, запуск по расписанию или по событию, запись Parquet в S3.
Источник↗
Реплицировать текущие изменения из локального SQL Server в Aurora MySQL с минимальным временем простоя.
→AWS DMS с задачей полной загрузки + CDC. Используйте Schema Conversion Tool (SCT) для преобразования гетерогенных схем/кода перед DMS.
Источник↗
Экземпляр репликации DMS выходит из строя — репликация прерывается.
→Включите Multi-AZ на экземпляре репликации. Синхронный резервный экземпляр в другой AZ; автоматическое переключение.
Источник↗
Требуется аналитика почти в реальном времени по данным OLTP Aurora без конвейера ETL.
→Интеграция Aurora zero-ETL с Redshift. Непрерывная репликация данных Aurora в Redshift; запросы видят новые данные в течение секунд.
Почему: Устраняет необходимость в конвейерах DMS / Glue / кастомных CDC для сценариев OLTP-в-хранилище.
Источник↗
Переместить 100 ТБ исторического архива из локального хранилища в S3; пропускная способность ограничена.
→AWS Snowball Edge Storage Optimized. Физическое устройство доставляется на место; данные копируются; устройство отправляется обратно.
Источник↗
Исходный JSON содержит вложенные массивы; последующему реляционному анализу требуются плоские строки.
→Преобразование `Relationalize` в Glue PySpark (или `explode()` в DataFrame) преобразует вложенные массивы в отдельные строки/таблицы.
Источник↗
Glue Crawler определяет неоднозначные типы (`choice<int,string>`) из неструктурированных CSV-данных.
→Примените преобразование `ResolveChoice` — приведите к определенному типу или спроецируйте в структуру. Или исправьте в источнике, принудительно задав схему.
Источник↗
Задача Glue ETL запускается ежечасно на растущих данных S3; необходимо обрабатывать только новые файлы.
→Включите закладки задач Glue. Glue отслеживает обработанные файлы/партиции и пропускает их при повторных запусках.
Почему: Позволяет избежать повторной обработки всего набора данных. Требуется для инкрементальных ETL-конвейеров.
Источник↗
Задача Glue Spark завершается с ошибкой OutOfMemoryError на драйвере во время крупных агрегаций.
→Переключитесь на воркеры G.2X или G.4X (больше памяти драйвера) или включите предикаты push-down `--enable-glue-datacatalog` для уменьшения объема перемешиваемых данных.
Источник↗
Запустить непрерывный Spark Structured Streaming против источника Kinesis с управляемой инфраструктурой.
→Потоковая задача AWS Glue ETL. Под капотом Spark Structured Streaming; контрольные точки в S3.
Источник↗
Бизнес-аналитику необходимо очищать и преобразовывать данные без написания кода.
→AWS Glue DataBrew. Визуальные преобразования на основе рецептов (более 250), профилирование, lineage. Вывод в S3, Redshift, RDS.
Источник↗
Запускать задачу Glue ETL только после успешного обновления Glue Data Catalog краулером.
→Рабочий процесс Glue с условными триггерами. Успех краулера → запустить задачу ETL. Сбой → пропустить / оповестить.
Источник↗
Краулер определяет все столбцы CSV как `string` — нужны типы даты и числа.
→Добавьте пользовательский классификатор Glue (шаблон Grok или подсказка столбца) перед сканированием. В качестве альтернативы предварительно запишите строку заголовка с явными типами.
Источник↗
Нескольким производителям/потребителям в Kafka требуется эволюция схемы без нарушения совместимости друг с другом.
→AWS Glue Schema Registry с правилами совместимости (BACKWARD/FORWARD/FULL). Производители регистрируют схему; потребители получают + проверяют.
Источник↗
Выберите между EMR и Glue для Spark ETL.
→Длительно работающий кастомный Spark с глубокой настройкой, несколько фреймворков (Hive, Presto, Flink) → EMR. Бессерверный ETL с оплатой за задание и интеграцией с Glue Data Catalog → Glue. Нестабильный/непредсказуемый Spark → EMR Serverless.
Источник↗
Периодические задачи Spark/Hive; требуется отсутствие операций с кластером и холостого простоя вычислений.
→EMR Serverless. Предварительно инициализированные пулы емкости для запусков с низкой задержкой; масштабируется для каждого задания; оплата за vCPU-час.
Источник↗
Сочетание узлов core по запросу и узлов task в режиме Spot для экономичной оптимизации EMR.
→Парки инстансов (Instance Fleets) с целевой емкостью по типу. Парк core узлов по запросу для стабильности HDFS; парк task узлов в режиме Spot с разнообразными типами инстансов.
Источник↗
Стандартизировать на Kubernetes; нужно, чтобы задачи EMR Spark использовали кластер совместно с другими нагрузками.
→EMR on EKS. Spark работает как поды на существующем кластере EKS; инфраструктура и роли IAM используются совместно через IRSA.
Источник↗
Потоковая обработка с сохранением состояния, агрегацией по окнам и семантикой "точно один раз".
→Kinesis Data Analytics для Apache Flink. Управляемая среда выполнения Flink; контрольные точки в S3; автоматическое масштабирование.
Источник↗
Легковесное преобразование каждой записи в потоке Kinesis (<1 мс каждая).
→Lambda с Event Source Mapping на KDS. Настройте `BatchSize`, `MaximumBatchingWindowInSeconds` и `ParallelizationFactor`.
Почему: Lambda дешевле, чем KCL/Glue Streaming, для небольших порекордных задач.
Источник↗
Шаг Step Functions иногда завершается сбоем из-за временного регулирования; повторная попытка, затем оповещение.
→Добавьте блок `Retry` с `ErrorEquals: ["Lambda.ThrottlingException", "States.TaskFailed"]`, `IntervalSeconds`, `MaxAttempts`, `BackoffRate=2`. А также `Catch` для состояния уведомления.
Источник↗
Параллельная обработка 500 000 JSON-файлов с помощью преобразования Lambda.
→Распределенное состояние Map в Step Functions с `MaxConcurrency` и ItemReader из S3. Распараллеливание на тысячи параллельных вызовов Lambda.
Источник↗
Сложный DAG с межсервисными зависимостями (Glue + Redshift COPY + Lambda + email) и требованиями к lineage.
→Amazon MWAA (Managed Workflows for Apache Airflow). Нативные операторы Airflow для сервисов AWS; синхронизация DAG через Git.
Источник↗
Необходимо откатить изменения DAG, если развертывание вызывает сбои.
→Храните DAG в версионированном бакете S3 + синхронизация через версионирование S3. Или поддерживайте репозиторий DAG в Git с одной средой на ветку + синхронизация S3 через CI.
Источник↗