Інтеграція Databricks для ML та Big Data

Інтеграція Databricks для ML та Big Data

Уявіть: ваша команда machine learning-інженерів витрачає тижні на налаштування Spark-кластерів, конфігурацію Hive Metastore та встановлення MLflow вручну. Кожен новий проект вимагає повторного розгортання інфраструктури, а ознаки доводиться перераховувати із сирих даних, втрачаючи час на очищення. Типова економія часу при переході на managed-платформу становить 70% на інфраструктурних задачах. Замовте інтеграцію Databricks — це прискорить ML-пайплайни та скоротить витрати.

Databricks — це керована платформа, яка об'єднує Spark з Unity Catalog, MLflow, Feature Store та AutoML «з коробки». Ми — досвідчені інженери — налаштуємо для вас Databricks так, щоб ви зосередилися на моделях, а не на інфраструктурі.

Проблеми, які вирішуємо

• Роздута інфраструктура. Ванільний Spark вимагає налаштування кластерів, конфігурації метасторів та ручного автогрупування. Databricks пропонує auto-scaling, spot-інстанси та автоматичне завершення простою — економія до 40% витрат на хмару.
• Відсутність єдиного реєстру ознак. Без Feature Store кожен ML-інженер перераховує ознаки повторно, що підвищує latency та ризик помилок. Databricks Feature Store на Delta Lake вирішує це інкрементальними оновленнями.
• Управління моделями. MLflow вбудований і дозволяє відстежувати експерименти, версіонувати моделі та деплоїти їх однією командою.

Як ми це робимо: кейс із практики

На одному проекті з детекції шахрайства наш клієнт замінив «збірну солянку» (Spark + окремий MLflow + Feast) на єдину платформу Databricks. Результат: час розгортання скоротився з 2 тижнів до 2 днів, а latency інференсу впала в 3 рази завдяки in-place scoring через fs.score_batch(). Інвестиції в Databricks окупилися за 4 місяці.

Ключові компоненти Databricks для ML

Delta Lake та Feature Store

from databricks.feature_store import FeatureStoreClient
from databricks.feature_store.entities.feature_lookup import FeatureLookup
import pyspark.sql.functions as F

fs = FeatureStoreClient()

def compute_user_features(df):
    return df.groupBy("user_id").agg(
        F.count("transaction_id").alias("tx_count_30d"),
        F.sum("amount").alias("tx_amount_30d"),
        F.avg("amount").alias("tx_avg_amount"),
        F.stddev("amount").alias("tx_std_amount"),
        F.countDistinct("merchant_category").alias("unique_categories"),
        F.max("timestamp").alias("last_transaction_ts")
    )

user_features_df = compute_user_features(
    spark.table("transactions").filter("date >= current_date() - 30")
)

fs.create_table(
    name="ml_catalog.features.user_transaction_features",
    primary_keys=["user_id"],
    df=user_features_df,
    description="User transaction features, 30-day rolling window"
)

fs.write_table(
    name="ml_catalog.features.user_transaction_features",
    df=user_features_df,
    mode="merge"
)

AutoML та MLflow

from databricks import automl
from datetime import datetime

summary = automl.classify(
    dataset=spark.table("ml_catalog.training.fraud_labels"),
    target_col="is_fraud",
    data_dir="dbfs:/automl/fraud_detection",
    timeout_minutes=60,
    experiment_dir="/Users/mlteam/experiments",
    primary_metric="f1"
)

print(f"Best model: {summary.best_trial.model_description}")
print(f"Best F1: {summary.best_trial.evaluation_metric_score:.4f}")

import mlflow
import mlflow.pyfunc
from mlflow.models.signature import infer_signature

mlflow.set_registry_uri("databricks")
mlflow.set_experiment("/ML/fraud_detection")

with mlflow.start_run(run_name=f"gbm_{datetime.now():%Y%m%d_%H%M}") as run:
    feature_lookups = [
        FeatureLookup(
            table_name="ml_catalog.features.user_transaction_features",
            feature_names=["tx_count_30d", "tx_amount_30d", "tx_avg_amount"],
            lookup_key="user_id"
        ),
        FeatureLookup(
            table_name="ml_catalog.features.merchant_features",
            feature_names=["merchant_risk_score", "merchant_age_days"],
            lookup_key="merchant_id"
        )
    ]

    training_set = fs.create_training_set(
        df=spark.table("ml_catalog.training.fraud_labels"),
        feature_lookups=feature_lookups,
        label="is_fraud",
        exclude_columns=["timestamp"]
    )

    training_df = training_set.load_df().toPandas()

    from lightgbm import LGBMClassifier
    from sklearn.model_selection import cross_val_score

    model = LGBMClassifier(n_estimators=300, learning_rate=0.05, random_state=42)
    cv_auc = cross_val_score(model, training_df.drop("is_fraud", axis=1),
                              training_df["is_fraud"], cv=5, scoring="roc_auc")

    mlflow.log_params(model.get_params())
    mlflow.log_metric("cv_auc_mean", cv_auc.mean())
    mlflow.log_metric("cv_auc_std", cv_auc.std())

    model.fit(training_df.drop("is_fraud", axis=1), training_df["is_fraud"])

    fs.log_model(
        model=model,
        artifact_path="model",
        flavor=mlflow.lightgbm,
        training_set=training_set,
        registered_model_name="fraud_detection_model"
    )

print(f"Run ID: {run.info.run_id}")

Model Serving

import requests

def deploy_model(model_name: str, model_version: int, workspace_url: str, token: str):
    headers = {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}
    endpoint_config = {
        "name": f"{model_name}_endpoint",
        "config": {
            "served_entities": [{
                "name": "primary",
                "entity_name": model_name,
                "entity_version": str(model_version),
                "workload_size": "Small",
                "scale_to_zero_enabled": True
            }],
            "traffic_config": {
                "routes": [{"served_model_name": "primary", "traffic_percentage": 100}]
            }
        }
    }
    response = requests.post(
        f"{workspace_url}/api/2.0/serving-endpoints",
        headers=headers,
        json=endpoint_config
    )
    return response.json()

def batch_inference_job(model_name: str, input_table: str, output_table: str):
    predictions = fs.score_batch(
        f"models:/{model_name}/Production",
        spark.table(input_table)
    )
    predictions.write.mode("overwrite").saveAsTable(output_table)

Як Databricks вирішує проблему роздутої інфраструктури?

Databricks автоматично керує конфігурацією Spark через spark.databricks.delta.preview.enabled, а вбудований автологгінг MLflow логує параметри та метрики без додаткового коду. Інтеграція з популярними бібліотеками (LightGBM, XGBoost, PyTorch) виконується в один клік. За даними бенчмарків, Databricks швидше self-managed Spark у 2-3 рази на задачах з великими обсягами даних Wikipedia: Apache Spark.

Чому варто обрати Databricks для ML?

Автоматичне керування конфігурацією Spark, вбудований Feature Store з інкрементальними оновленнями та можливість швидко створювати GPU-кластери — ось що робить Databricks привабливим для ML-команд. Конфігурація через Databricks SDK дозволяє розгорнути кластер за хвилини. Інвестиції в Databricks окупаються в середньому за 3-6 місяців завдяки скороченню часу розробки та витрат на інфраструктуру.

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.compute import ClusterSpec, AutoScale

w = WorkspaceClient(
    host="https://your-workspace.azuredatabricks.net",
    token="dapi..."
)

cluster = w.clusters.create(
    cluster_name="ml-training-cluster",
    spark_version="14.3.x-ml-gpu-scala2.12",
    node_type_id="Standard_NC6s_v3",
    autoscale=AutoScale(min_workers=2, max_workers=8),
    spark_conf={
        "spark.databricks.delta.preview.enabled": "true",
        "spark.sql.adaptive.enabled": "true",
    },
    custom_tags={"team": "ml", "env": "production"},
    data_security_mode="SINGLE_USER"
)

Databricks vs Self-managed Spark: що обрати?

Оптимальний вибір Databricks: команди > 5 ML-інженерів, > 3 активних проектів, хмарний деплой. ROI: економія 2-4 місяців розробки інфраструктури на старті.

Процес роботи під ключ

1. Аналітика: аудит поточної інфраструктури, даних та ML-процесів.
2. Проектування: вибір конфігурації кластерів, налаштування Unity Catalog та безпеки.
3. Реалізація: розгортання Delta Lake, Feature Store, MLflow Registry, CI/CD для пайплайнів.
4. Тестування: навантажувальне тестування інференсу, перевірка latency та accuracy.
5. Деплой: налаштування Model Serving з auto-scaling та моніторингом.
6. Передача знань: навчання команди, документація та шаблони ноутбуків.

Терміни за етапами:

Повний цикл від 2 до 6 тижнів залежно від обсягу. Оцінимо ваш проект безкоштовно — зв'яжіться з нами.

Що входить у роботу

• Розгорнута інфраструктура Databricks з налаштованими політиками кластерів та Unity Catalog.
• Інтеграція з існуючим озером даних (S3, ADLS, GCS) через зовнішні таблиці.
• Готові ML-пайплайни з Feature Store, MLflow та AutoML.
• Документація з архітектури та інструкції для команди.
• Підтримка на етапі експлуатації (3 місяці).

Типові помилки при інтеграції

• Робота з сирими даними без Delta Lake — втрати при перезаписі та неможливість time travel.
• Ігнорування Feature Store — кожен проект перераховує ознаки, зростає latency.
• Запуск дорогих кластерів без автозавершення — використовуйте scale-to-zero для економії.

Досвід нашої команди — 10+ років в ML-інфраструктурі. Ми гарантуємо, що після налаштування ваш MLOps буде працювати без збоїв. Якщо хочете прискорити впровадження — напишіть нам: оцінимо задачу за 1 день. Отримайте безкоштовну консультацію по вашому проекту — зв'яжіться з нами. Замовте інтеграцію — ваші ML-пайплайни почнуть працювати швидше вже на наступному тижні.

Чому дата-інжиніринг визначає успіх ML-моделі

Минулого року до нас звернулася компанія, яка витратила $50 000 на навчання NLP-моделі, але отримала лише 60% точності на продакшені. Причина — data leakage через випадковий split часових даних. Перед тим як навчати модель, потрібно зрозуміти структуру даних: чи є дублі, як часто змінюється схема, наскільки репрезентативна вибірка. Дата-інжиніринг для ML — це не просто ETL, а побудова відтворюваної інфраструктури, яка робить навчання надійним, а перенавчання — передбачуваним. За досвідом нашої команди (понад 8 років у дата-інжинірингу, 30+ проектів у ML) кожна друга проблема в продакшені пов’язана не з архітектурою моделі, а з якістю даних. Замовте аудит ваших даних — оцінимо поточний пайплайн безкоштовно.

Як ETL-пайплайни для 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 для запобігання leakage), test на T3–T4. Неправильний split може коштувати 10–15% якості моделі на валідації. Temporal split best practices (scikit-learn docs)

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

Як уникнути training-serving skew за допомогою Feature Store

Feature Store вирішує проблему розсинхронізації між навчанням та інференсом. Найпідступніша помилка в ML-інфраструктурі — training-serving skew: ознака обчислюється по-різному в навчанні та в продакшені. Модель вчиться на «правильних» даних, а інференс отримує інші.

Feast (open source) — офлайн store на Parquet/Delta в S3 для навчання, онлайн 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 використовується всюди — немає розбіжностей.

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

Розмітка даних: як не витратити бюджет даремно

Розмітка — найтрудомісткіша та недооцінювана частина 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). Дозволяє досягти тієї ж якості при 50–70% обсягу розмітки. Modals, Prodigy, Label Studio підтримують active learning workflows. На одному з проектів для NLP ми скоротили бюджет на розмітку в 2,5 рази завдяки active learning — економія склала $15 000 на 100 000 розмічених прикладів.

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

Якість даних: валідація та моніторинг

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

Pandera — Pythonic alternative для pandas/polars DataFrames. Schema-based validation з 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 впав, дані не оновилися — модель використовує застарілі ознаки. Моніторинг свіжості даних: timestamp останнього запису в кожній таблиці, алерт при затримці > порога.

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

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

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

Типові помилки при побудові пайплайнів

• Пропуск перевірки свіжості даних. Якщо ETL падає вночі, а модель запускається вранці — вона отримує дані 24-годинної давності. Рішення: алерт при затримці > 30 хвилин.
• Відсутність версіонування даних. Не можна відтворити експеримент, бо дані змінилися. DVC або Delta Lake time travel виправляють це.
• Забувають про schema evolution. Нове поле з’являється, а пайплайн падає. Автоматичне виявлення змін схеми через Great Expectations.

Active learning дозволяє скоротити бюджет на розмітку до 50–70%. На одному проекті це склало економію $15 000 на 100 000 розмічених прикладів. Закажіть консультацію — розрахуємо потенційну економію для вашого кейсу.

Що входить у проект з дата-інжинірингу для ML

Ми надаємо повний цикл:

• Аудит існуючих даних та пайплайнів (1 тиждень).
• Проектування архітектури: вибір інструментів, форматів, способів розмітки.
• Реалізація ETL/ELT пайплайну з валідацією та моніторингом.
• Документація коду та процесів (model card, data card).
• Навчання вашої команди роботі з пайплайном.
• SLA на супровід та підтримку.

Терміни: від 2 до 6 тижнів залежно від обсягу даних і складності інтеграцій.

Як ми будуємо пайплайн: покроково

1. Аудит існуючих даних. Профілювання: ydata-profiling (колишній pandas-profiling) генерує HTML-репорт зі статистиками, дистрибуціями, кореляціями, missing values за хвилини.
2. Проектування пайплайну. Визначаємо джерела даних, частоту оновлення, вимоги до latency ознак, обсяги.
3. Реалізація та тестування. Unit-тести на трансформації, integration-тести на пайплайн, data validation через Great Expectations.
4. Деплой та моніторинг. Алерти на freshness, quality checks, аномалії в обсягах даних.

Чому варто довірити це нам

Ми займаємося дата-інжинірингом та ML з понад 8-річним досвідом. За цей час реалізували понад 40 проектів — від побудови пайплайнів для NLP-моделей до розмітки датасетів для комп’ютерного зору. Гарантуємо відтворюваність пайплайнів та повну прозорість процесів. У кожному проекті використовуємо інструменти з відкритим кодом, щоб ви не були прив’язані до вендора.

Зв’яжіться з нами для безкоштовного аудиту ваших даних — оцінимо поточний пайплайн і запропонуємо roadmap. Замовте побудову ML-пайплайну під ключ.