Trade-off Analysis для Data Systems
Нет «лучших» инструментов — есть подходящие
Главная ошибка junior data engineers — выбирать инструменты по популярности. «Kafka, потому что все используют Kafka.» «Spark, потому что это стандарт.» Правильный подход — анализ trade-offs для конкретных requirements.
Trade-off 1: Batch vs Stream Processing
Batch Processing
Stream Processing
Когда что выбирать
| Сценарий | Выбор | Почему |
|---|---|---|
| Daily revenue report | Batch | Freshness часы — достаточно. Batch дешевле |
| Fraud detection | Stream | Freshness секунды — критична. Fraud window < 1 мин |
| ML feature computation | Batch + Stream | Batch для training features, stream для serving |
| BI dashboards | Micro-batch | 5-15 мин freshness — компромисс цена/скорость |
Trade-off 2: Warehouse vs Lakehouse
| Аспект | Data Warehouse | Data Lakehouse |
|---|---|---|
| Стоимость storage | Высокая (proprietary format) | Низкая (Parquet on S3) |
| Query performance | Отличная (оптимизирован) | Хорошая (зависит от engine) |
| Data types | Структурированные | Все (struct, semi-struct, unstructured) |
| ML workloads | Плохо (нужен export) | Хорошо (прямой доступ) |
| Vendor lock-in | Высокий (Snowflake, Redshift) | Низкий (open formats) |
| ACID transactions | Встроены | Через table format (Delta/Iceberg) |
TIP
Тренд: Lakehouse побеждает
Большинство новых проектов выбирают lakehouse architecture. Snowflake и Databricks конвергируют: Snowflake добавил Iceberg support, Databricks продвигает Delta Lake. Если у вас greenfield проект — lakehouse по умолчанию, warehouse только для specific use cases (high-concurrency BI).
Trade-off 3: ETL vs ELT
ETL (Extract → Transform → Load)
Extract
Transform
Load
Transform до load — данные чистые сразу
ELT (Extract → Load → Transform)
Extract
Load
Transform
Transform после load — используем мощность DWH
Когда ETL, когда ELT
| ETL (transform first) | ELT (load first) |
|---|---|
| Data quality критична до загрузки | Raw data нужна для exploration |
| Legacy DWH с ограниченным compute | Modern DWH/Lakehouse с мощным compute |
| Compliance: PII нельзя загружать в raw виде | Дешёвый storage (S3) — храним всё |
| On-premise infrastructure | Cloud infrastructure |
Trade-off 4: Orchestrator Selection
| Airflow | Dagster | Prefect | |
|---|---|---|---|
| Модель | DAG-centric | Asset-centric | Flow-centric |
| Paradigm | Tasks & dependencies | Software-defined assets | Decorators on functions |
| Learning curve | Средняя | Высокая | Низкая |
| Community | Огромное | Растущее | Среднее |
| Testing | Сложно | Встроено | Хорошо |
| UI | Функциональное | Отличное | Хорошее |
| Когда | Legacy, большая команда | Greenfield, data mesh | Небольшие команды, быстрый старт |
Framework для принятия решений
Для каждого technology choice:
- Определите criteria — что важно для ВАШЕГО проекта (не в целом)
- Оцените 2-3 варианта по каждому критерию
- Документируйте решение — ADR (Architecture Decision Record)
- Назначьте trigger для пересмотра — «пересмотреть, когда volume > 100 TB/день»
## ADR-001: Orchestrator Selection
Status: Accepted
Context: Greenfield project, 3 DE, 20 pipelines, growing to 100+
Decision: Dagster (asset-centric model)
Alternatives considered: Airflow (established but DAG-centric), Prefect (simpler but less structure)
Consequences:
[OK] Asset lineage out-of-the-box
[OK] Built-in testing framework
[OK] Clean separation of IO and compute
[NO] Smaller community than Airflow
[NO] Team needs to learn asset-centric paradigm
Revisit trigger: If team grows to 10+ and Airflow expertise dominates