System Design для Data Engineering
Почему DE SD ≠ Backend SD
Backend System Design фокусируется на request-response: как обработать HTTP-запрос от пользователя, масштабировать API, кэшировать ответы. Data Engineering System Design фокусируется на data flow: как данные попадают в систему, как трансформируются, где хранятся и как потребляются.
Backend System Design
Data Engineering SD
Ключевые отличия
| Аспект | Backend SD | Data Engineering SD |
|---|---|---|
| Основная модель | Request-Response | Data Flow (pipeline) |
| Латентность | Миллисекунды | Минуты → часы (batch), секунды (stream) |
| Объём данных | KB per request | GB → TB per batch |
| Тип нагрузки | Много маленьких запросов | Мало больших batch jobs |
| Ключевая метрика | P99 latency | Data freshness, SLA, quality |
| Failure mode | 500 error → retry | Pipeline failed → stale data |
| Cost driver | Compute (серверы) | Storage + Compute (часто storage доминирует) |
6-Layer Framework для Data Systems
Любая data-система состоит из 6 слоёв:
Как использовать этот framework
В каждом system design упражнении или на собеседовании проговаривайте все 6 слоёв. Не обязательно в порядке сверху-вниз — можно начать с consumers (что нужно бизнесу?) и идти вверх к sources. Но каждый слой должен быть затронут.
Что делает Data Engineer «System Designer»
Data Engineer принимает решения на каждом слое:
| Слой | Решения |
|---|---|
| Sources | Какие источники? Batch или CDC? Как валидировать на входе? |
| Processing | Spark или Flink? Batch или stream? Как обрабатывать late data? |
| Storage | Warehouse или Lakehouse? Какой table format? Как партиционировать? |
| ML/AI | Нужен ли feature store? Online или offline? |
| Consumers | SQL доступ? API? Pre-aggregated views? |
| Tools | Airflow или Dagster? Как мониторить? Как обеспечить quality? |
Три главных вопроса DE System Design
Перед каждым проектом задайте себе:
1. Как данные приходят и как быстро нужна реакция?
Это определяет processing model:
- Данные приходят раз в день → Batch processing (Spark, AWS Glue)
- Данные приходят постоянно и нужны через минуты → Micro-batch (Spark Structured Streaming)
- Данные нужны в секунды → Real-time streaming (Kafka + Flink)
2. Кто потребляет данные и для чего?
Это определяет storage и data model:
- Аналитики пишут SQL-запросы → Data Warehouse с star schema
- Data Scientists тренируют модели → Lakehouse с raw данными + feature store
- Сервисы читают через API → Low-latency serving layer (Redis, RocksDB)
3. Сколько данных и какой бюджет?
Это определяет tool choice и architecture:
- 10 GB/день, бюджет минимален → PostgreSQL + dbt + cron
- 1 TB/день, средний бюджет → Lakehouse + Spark + Airflow
- 100 TB/день, enterprise → Multi-engine (Spark + Flink + Trino) + Data Mesh
Правило: «The best data systems aren’t the most complex — they’re the ones that are simple enough to maintain, fast enough to deliver, and flexible enough to grow.»
Не overengineer. Если PostgreSQL + dbt достаточно — используйте их. Spark не нужен для 10 GB/день.