MLOps & Data Engineering

VM виртуализирует железо и запускает полноценную ОС (гипервизор → Guest OS → приложение). Контейнер использует ядро хост-системы и изолирует только процессы через namespaces и cgroups. Контейнер: секунды на старт, МБ размер, почти нативная производительность. VM: минуты на старт, ГБ размер, overhead от гипервизора. Контейнеры — для приложений, VM — когда нужна полная изоляция ОС.

В обычном CI/CD тестируем код. В ML-пайплайне добавляются: тестирование данных (schema, distributions), тестирование модели (метрики не деградировали, нет data leakage), версионирование данных и моделей (DVC, MLflow), воспроизводимость (фиксация seed, окружения). Также pipeline включает retraining trigger (по расписанию или при data drift) и A/B-тестирование перед полным rollout.

Offline store (Hive, Parquet) — для batch-генерации train-данных: нужны исторические значения фич, point-in-time correctness, большие объёмы. Online store (Redis, DynamoDB) — для real-time inference: нужны текущие значения фич с latency < 10ms. Фичи вычисляются один раз и синхронизируются между хранилищами, что гарантирует consistency между training и serving (train-serve skew).

Без логирования через 2 недели невозможно вспомнить, какие гиперпараметры дали лучший результат. Минимум: метрики (train/val/test), гиперпараметры, версия данных, git hash кода, random seed. Дополнительно: learning curves, confusion matrix, примеры ошибок, конфиг окружения. Инструменты: MLflow, W&B, Neptune. Главное — воспроизводимость: по логам можно точно восстановить эксперимент.

Batch: предсказания для всех объектов заранее, результат в хранилище. Подходит для рекомендаций (предвычислить для всех пользователей ночью), скоринга (обновлять раз в день). Online: предсказание по запросу в real-time. Нужен для fraud detection (решение за миллисекунды), dynamic pricing, персонализации в реальном времени. Batch проще, дешевле, масштабируемее; online — когда нужна свежесть и контекст запроса.

Data drift: изменилось распределение входных данных P(X) — например, сезонность, новая аудитория. Concept drift: изменилась связь P(Y|X) — то, что было спамом, стало нормой. Data drift детектируют через PSI, KS-тест на входных фичах. Concept drift — через мониторинг метрик на свежих размеченных данных. Data drift не всегда ведёт к деградации модели, concept drift — почти всегда.

Shadow mode: новая модель получает продовый трафик, но ответы не показываются пользователям — сравниваем метрики без риска. Canary: 5-10% трафика идёт на новую модель, мониторим бизнес-метрики. Full rollout: после успешного canary — 100% трафика. Поэтапность нужна, потому что офлайн-метрики не гарантируют успех в проде — latency, edge cases, взаимодействие с другими системами.

LAG(value, offset) возвращает значение из предыдущей строки внутри окна. Пример: SELECT user_id, event_date, LAG(event_date) OVER (PARTITION BY user_id ORDER BY event_date) AS prev_date FROM events — для каждого пользователя получаем дату предыдущего события. Разница event_date - prev_date = время между визитами. PARTITION BY создаёт отдельное окно для каждого user_id.

ETL: данные трансформируются ДО загрузки в хранилище (классика, on-premise). ELT: данные грузятся сырыми, трансформация — в хранилище (cloud-native, BigQuery/Snowflake). Для ML лучше ELT: сырые данные сохраняются (можно переизвлечь фичи), трансформация через SQL/Spark масштабируется, новые фичи не требуют перестройки пайплайна. ETL — когда данные нужно фильтровать/маскировать до загрузки (compliance, PII).

Data validation: schema checks (типы, nullable, диапазоны), statistical checks (среднее, распределение не отклонились), volume checks (объём данных в ожидаемом диапазоне), freshness checks (данные не старше N часов). Инструменты: Great Expectations, Deequ, dbt tests. Встраивают как gate перед обучением: если проверки не прошли — пайплайн останавливается и шлёт alert, а не обучает модель на мусоре.

Cron: нет зависимостей между задачами, нет retry-логики, нет UI для мониторинга, нет backfill. Airflow: DAG с зависимостями (задача B ждёт A), retry с backoff, UI для статуса и логов, backfill за прошлые даты, SLA-мониторинг, интеграция с облаками. Для одного скрипта раз в день cron достаточно. Для ML-пайплайна из 10+ шагов с зависимостями — оркестратор необходим.

Star Schema: одна таблица фактов + денормализованные dimension-таблицы (одна JOIN-операция). Snowflake: dimension-таблицы нормализованы (дерево JOIN-ов). Star проще и быстрее для аналитических запросов (меньше JOIN-ов), занимает больше места. Snowflake экономит место и проще обновляется (нормализация). На практике Star Schema — стандарт для DWH/OLAP, потому что скорость запросов важнее экономии места.

Lazy evaluation: трансформации (map, filter, join) не выполняются сразу, а строят план (DAG). Выполнение запускается только action-ом (collect, count, write). Это позволяет Spark оптимизировать план: объединять операции, переупорядочивать, eliminировать лишнее. Shuffle — перераспределение данных между нодами (при groupBy, join) — самая дорогая операция, требует сетевой передачи. Минимизация shuffle — ключ к производительности.