Жизненный цикл данных
Данные не возникают из ниоткуда и не исчезают в никуда. У каждого датасета есть жизненный цикл: от рождения в системе-источнике до момента, когда человек принимает на их основе решение.
Понять lifecycle — значит видеть пайплайн целиком. На какой стадии данные сейчас, что с ними должно произойти дальше, какие инструменты используются на каждом этапе. Этот урок — карта всего следующего курса.
Шесть стадий
Если ты увидишь на картинке любую data-архитектуру в любой компании, она впишется в эту схему. Меняются только инструменты на каждом слое.
1. Source — источник
Это не часть пайплайна, а исходная точка. Источники бывают:
- Транзакционные БД — Postgres, MySQL, MongoDB. Здесь живут «горячие» данные приложения: заказы, пользователи, события.
- API сторонних сервисов — Stripe (платежи), Salesforce (CRM), Google Ads (маркетинг).
- Файлы — CSV, Excel из ERP, JSON-логи приложения.
- Событийные потоки — Kafka, Kinesis, webhooks. Сообщения в реальном времени.
- SaaS-сервисы — Zendesk (поддержка), Mixpanel (продуктовая аналитика).
DE обычно не контролирует источники — их пишут другие команды. Это политически важная точка: договариваться о схеме, частоте обновления, контракте.
2. Ingestion — извлечение
Задача: достать данные из источника и доставить в хранилище.
Главные вопросы при проектировании ingestion:
- Batch или streaming? Раз в час одной пачкой или event-by-event в реальном времени?
- Pull или push? DE-система забирает (pull, например Fivetran забирает из Salesforce) или источник отправляет (push, например webhook из Stripe).
- Full или incremental? Каждый раз грузим всё или только изменения с прошлого раза?
- Что делать с дубликатами и failures?
Инструменты: Fivetran, Airbyte, dlt, Debezium + Kafka, кастомный Python.
Подробнее — в следующем уроке 02-ingestion.
3. Storage — хранение
Куда положили данные после ingestion и где они живут долгосрочно.
Варианты:
- OLTP-БД — обычно НЕ для долгосрочного хранения данных аналитики.
- Data Warehouse (DWH) — Snowflake, BigQuery, Redshift. Структурированное хранение, оптимизированное под SQL-аналитику.
- Data Lake — S3, GCS, Azure Blob. Хранение файлов в любом формате, дёшево.
- Lakehouse — гибрид: файлы в S3 + слой метаданных (Iceberg, Delta).
В DWH обычно несколько слоёв:
Слои называются по-разному: Bronze / Silver / Gold (Databricks Medallion) или Raw / Staging / Marts (dbt). Идея одна: от сырого к готовому.
Подробнее — урок 03-storage.
4. Processing — обработка
Что делаем с данными внутри storage:
- Cleaning — убираем NULL, дубликаты, типизируем.
- Conforming — приводим разные источники к единым названиям (одинаковый
customer_idвезде). - Aggregating — считаем суммы, средние, count.
- Joining — объединяем таблицы.
- Modeling — строим star schema, dimensions, facts.
Инструменты:
- dbt — для SQL-трансформаций в DWH.
- Spark / PySpark — для тяжёлых данных и custom-логики.
- Pandas / Polars — для маленьких локальных задач.
Подробнее — урок 04-processing.
5. Serving — подача
Готовые данные нужно донести до потребителей. Каналы:
Подробнее — урок 05-serving.
6. Consumption — потребление
Финальная точка: человек или машина использует данные.
- Аналитик смотрит дашборд, отвечает на вопрос продакта.
- ML-модель предсказывает churn на основе фич.
- Продакт-менеджер принимает решение «запускать ли A/B-тест».
- Маркетолог запускает email-кампанию на сегмент клиентов.
DE формально не контролирует consumption. Но качество данных, скорость дашбордов и доступность — на нём.
Поперёк всех стадий — orchestration
Никакого хаоса быть не может. Над всеми стадиями работает оркестратор:
Оркестратор отвечает: «когда запускать ingestion», «что делать, если упало», «куда слать алерт».
Подробнее — модуль 11-orchestration-airflow. Углубление — airflow-course.
Поперёк всех стадий — data quality
И мониторинг качества. На каждой стадии — свои тесты:
- На ingestion — проверка, что данные пришли вовремя и в нужном объёме.
- На storage — schema validation, null-проверки.
- На processing — бизнес-тесты («сумма заказов = сумма payments»).
- На serving — SLA на дашборды.
Подробнее — модуль 15-data-quality.
Пример: типичный пайплайн e-commerce
Чтобы стадии стали конкретными:
Это классический MDS-пайплайн. На каждой стадии — конкретный инструмент. Орестратор (Airflow) запускает Fivetran-sync, потом dbt run, потом dbt test, потом нотификация в Slack.
Что важно про lifecycle
Когда тебя спросят на собеседовании «спроектируй пайплайн для X» — отвечай по этим шести стадиям. Это структура, в которой не запутаешься. Не надо начинать с «возьмём Airflow» — начни с «где источник, как ingest, куда грузить, как трансформировать, как serve, кто consumer».
Попробуй сам
- Возьми любой data-pipeline из твоей собственной жизни (например, как Google Maps узнаёт о пробках). Разложи его по 6 стадиям. Где источник? Кто ingest? Где storage? Как serve?
- Открой архитектурную диаграмму любой компании (Spotify Engineering Blog, Airbnb Engineering). Найди на ней все 6 стадий. Заверь себя: «понимаю, что на каждой стадии происходит».