Дата-інжиніринг та побудова ML-пайплайнів

Data Engineering для ML: Pipeline'и, Анотування та Якість Даних

"У нас багато даних" — фраза, що часто означає "у нас багато сирих логів в S3, що ніхто не чіпав два роки". Перш ніж учити модель, потрібно зрозуміти, що взагалі є: яка структура, є ли дублі, як часто змінюється схема, наскільки репрезентативна вибірка.

Data Engineering для ML — не просто ETL. Це побудова відтворюваної інфраструктури даних, яка робить навчання моделей надійним, а переучування — передбачуваним.

ETL-Pipeline'и для ML: Специфіка Порівняно з BI

ETL для аналітики та ETL для ML — різні задачі. В аналітиці важлива агрегація, в ML — індивідуальні записи з історією. В аналітиці train/val/test split не потрібен, в ML — критичний. В аналітиці skew даних заважає інтерпретації, в ML — прямо впливає на якість.

Інструменти. Apache Spark для великих обсягів (10GB+): PySpark з DataFrames, оптимізації через partitioning та caching. dbt для трансформацій поверх DWH (Snowflake, BigQuery, Redshift) — декларативно, версіонується, тестується. Pandas + Polars для обсягів до кількох GB — Polars в 5-10x швидше Pandas на типових трансформаціях.

Temporal splits. Для ML важливо, що split по часу, а не випадковий. Якщо дані часові (транзакції, события користувачів), випадковий split дає data leakage: модель бачить "майбутні" дані при навчанні. Правило: train на періоді T1-T2, validation на T2-T3 (з gap для запобігання утечці), test на T3-T4.

Інкрементальні pipeline'и. Модель переучується щотижня на нових даних. Потрібен pipeline, що інкрементально додає нові записи до навчальної вибірки, не перезавантажуючи все заново. Delta Lake або Apache Iceberg — формати з ACID-трансакціями, Change Data Capture, time travel. Зберігаються в S3/GCS, читаються через Spark або DuckDB.

Feature Engineering та Feature Store

Feature Store розв'язує проблему training-serving skew. Найпідступніша помилка в ML-інфраструктурі — feature рахується по-різному при навчанні та в production. Модель учиться на "правильних" даних, а інференс отримує інші.

Feast (open source) — offline store на Parquet/Delta в S3 для навчання, online store на Redis для low-latency інференса (<10ms). Feature definitions як Python-код:

from feast import FeatureView, Field
from feast.types import Float32, Int64

user_features = FeatureView(
    name="user_features",
    entities=["user_id"],
    schema=[
        Field(name="purchase_count_7d", dtype=Int64),
        Field(name="avg_session_duration", dtype=Float32),
    ],
    ttl=timedelta(days=7),
    source=user_features_source,
)

Один definition, використовується скрізь. Немає розхождень.

Потокові features. Коли feature повинен оновлюватись в реальному часі (кількість транзакцій за останні 10 хвилин), потрібна потокова обробка. Apache Kafka + Apache Flink або Kafka Streams для обчислення features в реальному часі → запис в online store. Складніше, дорожче, потрібно тільки коли staleness features критичен для якості.

Анотування Даних

Анотування — найтрудомістка та недооцінена частина ML-проекту. Погано розміченні дані не виправить ніяка архітектура.

Label Studio — open source, підтримує анотування зображень (bounding box, polygon, segmentation), тексту (NER, класифікація), аудіо, відео. Піднімається за 10 хвилин через Docker. Для малих команд — перший вибір.

Оцінка якості анотування. Inter-annotator agreement — наскільки згодні анотатори між собою. Cohen's Kappa > 0.8 — добре, 0.6-0.8 — приймально, < 0.6 — задача неоднозначна або інструкція погана. Перетинання анотацій (10-20% прикладів розмічають два незалежних аннотатори) — обов'язкова практика.

Active learning. Не розмічати випадкові приклади, а вибирати ті, на яких модель найбільш неуверена (low confidence, high uncertainty). Цикл: учимо baseline → знаходимо неуверені приклади → розмічаємо їх → переучуємо. Дозволяє добитись тієї ж якості при 50-70% обсягу анотування. Modals, Prodigy, Label Studio підтримують active learning workflows.

Синтетичні дані. Коли реальних даних мало або отримувати їх дорого. Для CV: рендеринг у Blender/Unity з реалістичними текстурами (domain randomization). Для NLP: перефразування через LLM, backtranslation. Ризик: модель учиться на distribution синтетичних даних, а не реальних — потрібна обережність та перевірка на реальному holdout.

Якість Даних: Валідація та Моніторинг

Great Expectations — de facto стандарт для data validation в ML-pipeline'ах. Expectations — декларативні утвердження про дані: "колонка age містить значення від 0 до 120", "колонка user_id не містить null", "розподіл amount не відхиляється більше ніж на 20% від baseline". Запускається в pipeline, при провалі блокує прохідження.

Pandera — більш Pythonic альтернатива для pandas/polars DataFrames. Schema-based валідація з type hints:

import pandera as pa

schema = pa.DataFrameSchema({
    "user_id": pa.Column(int, nullable=False),
    "score": pa.Column(float, pa.Check.between(0, 1)),
    "label": pa.Column(str, pa.Check.isin(["positive", "negative", "neutral"])),
})

Data freshness. Модель очікує дані за останні N днів. ETL впав, дані не обновилися — модель використовує застарілі features. Моніторинг свіжості даних: timestamp останнього запису в кожній таблиці, alert при затримці > порога.

Дедупліка. Дублікати в навчальній вибірці завишують метрики (одні й ті ж приклади в train та val) та спотворюють ваги моделі. MinHash LSH для приблизної дедупліц на великих датасетах. Для точної — хеш по нормалізованому контенту.

Сховища та Формати

Для більшості ML-проектів на старті: Parquet в S3 + DVC для версіонування. Delta Lake або Iceberg — коли з'являється потреба в інкрементальних обновленнях або time travel.

Етапи Роботи

Аудит існуючих даних. Профілювання: ydata-profiling генерує HTML-репорт зі статистиками, дистрибуціями, кореляціями, missing values за хвилини. Перший крок у будь-якому проекті.

Проектування pipeline. Визначаємо джерела даних, частоту обновлення, вимоги до latency features, обсяги. Вибираємо інструменти під задачу.

Реалізація та тестування. Unit-тести на трансформації, integration-тести на pipeline, data validation через Great Expectations.

Моніторинг у production. Alert'и на freshness, quality checks, аномалії в обсягах даних.

Простий ETL-pipeline з валідацією: 2-3 тижні. Повнофункціональна data platform з Feature Store та моніторингом: 2-3 місяці. Аудит існуючих pipeline'ів та розробка roadmap: 1 тиждень.