Data Pipeline для ML: як побудувати надійний конвеєр даних

## Чому pipeline важливіший за модель У більшості ML-проєктів 70-80% часу витрачається не на побудову моделей, а на роботу з даними. Але про pipeline говорять значно менше, ніж про алгоритми. Насправді добре спроектований data pipeline — це конкурентна перевага: він дозволяє швидко перенавчати моделі, виявляти проблеми з якістю до того, як вони вплинуть на результат, і масштабуватись без переписування всього коду. ## Архітектура ML Data Pipeline Типовий pipeline для ML складається з кількох рівнів. Рівень збору даних (Ingestion Layer) відповідає за отримання даних з різних джерел: бази даних (PostgreSQL, MySQL), REST API, потокові джерела (Kafka, Kinesis), файлові сховища (S3, GCS). На цьому рівні дані зберігаються у сирому вигляді без трансформацій — принцип "зберігай все, фільтруй пізніше" дозволяє відтворити будь-яку трансформацію при необхідності. Рівень трансформацій (Transform Layer) реалізує ETL: очищення (видалення дублікатів, обробка пропусків), нормалізацію, агрегацію та формування фіч для навчання. Apache Spark — стандарт для великих обсягів. dbt (data build tool) — зручний варіант для SQL-орієнтованих трансформацій із версіонуванням і тестами. Feature Store — централізоване сховище готових фіч, що вирішує проблему "training-serving skew": гарантує, що в момент inference використовуються ті самі фічі, що й при навчанні. Популярні рішення: Feast (open source), Tecton, Vertex AI Feature Store. ## Валідація якості даних Без автоматичної валідації якість даних деградує непомітно. Great Expectations — найпопулярніша бібліотека Python для написання декларативних тестів на дані: "у колонці age немає значень нижче 0 або вище 120", "відсоток пропусків у полі email не перевищує 5%", "розподіл нового тижня статистично схожий на попередній". Валідація запускається при кожному завантаженні нових даних. При порушенні будь-якого правила pipeline зупиняється і надсилає сповіщення — замість того, щоб мовчки передати смітник у модель. ## Оркестрація з Apache Airflow Airflow дозволяє описати весь pipeline як DAG (спрямований ациклічний граф залежностей): завдання A запускається щодня о 02:00, завдання B — після успішного завершення A, завдання C і D — паралельно після B. Веб-інтерфейс показує статус кожного завдання, логи та історію запусків. Альтернативи для менших команд: Prefect (простіший синтаксис, хмарна версія), Dagster (краща інтеграція з типізацією даних), GitHub Actions (для простих pipeline без складних залежностей). ## Моніторинг дрейфу даних Після деплою pipeline потребує постійного моніторингу. Data drift (зміна розподілу вхідних даних) — основна причина деградації ML-моделей у production. Evidentlyai — open source бібліотека для автоматичного виявлення дрейфу: вона порівнює розподіл нових даних з референсним набором і генерує звіт про статистично значущі зміни. Рекомендований мінімум моніторингу: щотижневий звіт про розподіл ключових фіч, алерт при перевищенні порогу PSI (Population Stability Index) для критичних змінних, порівняння метрик якості моделі на нових даних з baseline. ## Практичні рекомендації Версіонуйте все. Код pipeline у Git, дані через DVC або Delta Lake, трансформації у dbt з тегами версій. Через пів року ви повинні мати можливість точно відтворити стан системи на будь-яку минулу дату. Ідемпотентність. Кожен крок pipeline має давати однаковий результат при повторному запуску з тими самими вхідними даними. Це критично для налагодження і перезапуску після помилок. Починайте просто. Для першого проєкту достатньо Python-скрипту + cron + S3 + Great Expectations. Не додавайте Airflow та Spark до того, як відчуєте реальну потребу в їхній складності.