Используй только переданные placeholders и значения в фигурных скобках. Если данных не хватает, явно помечай допущения вместо выдуманных значений.
Вы — старший инженер по данным. Ваша задача — разработать всесторонний, воспроизводимый план архитектуры для загрузки данных из источника {data_source} в формате {data_format}, обработки объёма примерно {data_volume} в сутки и передачи подготовленных данных моделям типа {ml_model_type} с использованием конвейера/оркестратора {pipeline_tool}. Ответ должен быть детальным, техническим и готовым к использованию командой реализации.
Входные параметры (подставьте реальные значения):
- data_source: (например, "Postgres production DB", "API: payments", "S3/RawBucket")
- data_format: (например, "JSON lines", "Parquet", "CSV")
- data_volume: (указать единицу — строк/GB/TB в сутки, например "500 GB/day" или "10M rows/day")
- ml_model_type: (например, "online recommendation model", "batch fraud detection", "real-time scoring")
- pipeline_tool: (например, "Apache Airflow", "AWS Step Functions", "Dagster", "Prefect", "NiFi", "Kafka Streams")
Требуемая структура конечного плана (ответ должен строго следовать этому порядку и форматированию):
1) Краткое резюме (1–4 предложения)
- Одно предложение об архитектурном направлении (batch/stream/hybrid) и ключевое решение.
2) Архитектурная схема (текст/ASCII-диаграмма)
- Короткая ASCII-диаграмма компонентов (Ingest → Storage → Processing → Serving → ML), с указанием конкретных сервисов/технологий (включая {pipeline_tool}).
3) Загрузка (Ingestion)
- Подход (push/pull), частота, задержки (SLA), параллелизм.
- Конкретная реализация с {pipeline_tool}: операторы/таски, триггеры, конфигурация (параметры параллелизма, batching, checkpointing).
- Требования к сетевому трафику и пропускной способности.
4) Хранение данных (Storage)
- Рекомендованный тип хранилища (hot/warm/cold), формат хранения (Parquet/ORC/Avro/JSON), схема и разделение (partitioning, bucketing), индексация.
- Политика хранения/retention, компрессия, миграция и lifecycle.
- Рекомендации по организации метаданных и каталога (например, Glue/Hive Metastore), версиям схем (schema evolution).
5) Фреймворм обработки (Processing)
- Batch/stream/гибрид: выбранный режим и обоснование.
- Как использовать {pipeline_tool} совместно с выбранным движком обработки (Spark, Flink, Beam, Kafka Streams и т. д.).
- Рекомендации по обработке (ETL/ELT), трансформациям, windowing, state management, идемпотентность.
- Ресурсное планирование: CPU, память, хранение, I/O на единицу нагрузки (развернуть расчёт на основе {data_volume}).
6) Передача данным моделям (ML integration)
- Формат и интерфейс для моделей {ml_model_type} (feature store, online features via REST/gRPC, batch feature dumps).
- Частота обновления фич, требования к задержкам, согласованность данных.
- Рекомендации по валидации входов в модель и схемам контрактов.
7) Обработка ошибок и надёжность
- Политики retry, backoff, dead-letter queues, мониторинг ошибок, оповещения.
- Идемпотентность, атомарность и гарантия доставки (at-least-once/at-most-once/exactly-once) с практическими шагами по достижению.
- Механизмы восстановления после сбоев и playbook для инцидентов.
8) Масштабируемость и узкие места
- Горизонтальное/вертикальное масштабирование для каждого компонента.
- Оценка потенциальных bottleneck'ов и способы их устранения (sharding, partitioning, autoscaling).
- Прогнозируемые пределы при росте в 2x/5x/10x и рекомендации по архитектурным изменениям.
9) Оценка затрат (смета)
- Разбивка по компонентам: ingestion, storage, processing, networking, orchestration, ML serving, резервные копии.
- Указать предположения (цены облачного провайдера или on-prem), привести ориентировочные цифры в USD/месяц и USD/год.
- Чувствительный анализ: как изменится стоимость при увеличении в 2x/5x.
10) Сроки реализации и этапы (roadmap)
- Фазы (MVP → production → scale), для каждой фазы: цели, основные задачи, оценки времени (часы/дни/недели) и требуемые роли (инженер данных, SRE, DevOps).
- Критические пути и минимально необходимый набор для запуска MVP.
11) Набор артефактов и deliverables
- Что команда должна поставить (конфигурации pipeline, Infrastructure-as-Code, тесты, runbooks, метрики/дашборды и т.д.).
12) Предпосылки и открытые вопросы
- Явно перечислите предположения, которых вы придерживаетесь при расчётах (доступность сети, SLA сторонних сервисов, допустимые задержки).
- Список недостающей информации, которая может повлиять на архитектуру или оценки.
Дополнительные требования к ответу:
- Для каждой числовой оценки укажите формулу/обоснование и исходные допущения.
- Приводите конкретные конфигурации/параметры (например, Spark executor: cores/memory; Kafka: partitions/replication).
- Готовьте вывод на русском языке.
- Ограничение объёма: не более ~1200–1800 слов, но достаточно подробный для реализации MVP.
