Данные: data lake, версии, feature store

Зачем отдельное хранилище

Рабочая база вроде Postgres хранит текущее состояние: заказы, клиентов, остатки. Обучать модель прямо на ней неудобно. Тяжёлые запросы на миллионы строк мешают сервису, а старые значения после UPDATE пропадают.

Поэтому данные для аналитики и ML копируют в отдельное место. Таких мест два типа.

Data warehouse (хранилище данных) — аналитическая база, в которую данные попадают уже очищенными, в таблицы с заранее заданной схемой. Примеры: ClickHouse, Greenplum, BigQuery, Snowflake. К ним пишут SQL-запросы для отчётов.

Data lake (озеро данных) — объектное хранилище, куда данные кладут в исходном виде: выгрузки таблиц, логи, картинки, JSON. Обычно это S3 или MinIO, S3-совместимое хранилище, которое ставят на свои серверы. Схему данных задают при чтении, а не при записи.

Parquet

Таблицы в data lake обычно хранят в формате Parquet. Это колоночный формат: значения одной колонки лежат рядом.

Для обучения это удобно. Модели churn нужны 10 колонок из 200, и Parquet позволяет прочитать только эти 10. CSV пришлось бы прочитать целиком.

Пути в data lake могут выглядеть так:

s3://lake/raw/orders/date=2026-10-19/part-0001.parquet
s3://lake/raw/orders/date=2026-10-20/part-0001.parquet

Папку date= называют partition. Запрос за последнюю неделю читает только семь таких папок, а не всю историю.

Iceberg и lakehouse

У data lake из одних Parquet-файлов есть проблема с изменениями. Таблица состоит из сотен файлов. Пока выгрузка переписывает часть из них, читатель может увидеть половину старых файлов и половину новых. Посмотреть таблицу в виде на прошлую неделю тоже нельзя.

Эту проблему решают табличные форматы Apache Iceberg и Delta Lake. Рядом с Parquet-файлами они хранят метаданные: какие файлы составляют каждую версию таблицы. Изменение таблицы становится транзакцией: читатель видит либо старую версию, либо новую. Появляется time travel, чтение таблицы в том виде, в каком она была на заданный момент.

Data lake с табличным форматом называют lakehouse. Запросы к нему выполняют движки вроде Spark и Trino. Для ML time travel полезен тем, что модель можно переобучить ровно на тех данных, что были при первом обучении.

Версии датасетов

В метаданных запуска должна быть версия данных. Для таблицы в Iceberg это её снимок. Для датасетов в виде файлов есть отдельные инструменты.

DVC (Data Version Control) работает вместе с Git. Сам файл с данными уходит в S3, а в Git коммитится маленький файл-указатель:

dvc init
dvc add data/train.csv              # создаёт указатель data/train.csv.dvc
git add data/train.csv.dvc data/.gitignore
git commit -m "датасет v1"
dvc remote add -d storage s3://ml-data/dvc
dvc push                            # отправляет сам файл в S3

Чтобы получить датасет нужной версии, переключаешься на её коммит и выполняешь dvc pull.

lakeFS добавляет ветки и коммиты как в Git ко всему бакету S3, без копирования данных при создании ветки. На ветке можно подготовить новый датасет, проверить его и слить в main.

В ноябре 2025 года lakeFS взял на себя развитие DVC. По их объявлению DVC остаётся отдельным инструментом для небольших датасетов, а lakeFS рассчитан на крупные.

Feature store

Training-serving skew из первого урока появляется, когда feature для обучения и для прода считают разным кодом. Feature store хранит feature в одном месте для обоих случаев.

• Offline store отдаёт историю значений feature для обучения.
• Online store быстро отдаёт свежие значения для запроса в проде.

Один из open source feature store называется Feast. Сервис получает в нём feature клиента так:

from feast import FeatureStore

store = FeatureStore(repo_path=".")
features = store.get_online_features(
    features=["user_stats:orders_30d", "user_stats:avg_check"],
    entity_rows=[{"user_id": 42}],   # для какого клиента
).to_dict()

В статье Google feature store отмечен как дополнительный компонент уровня 1. Без него та же цель достигается общей функцией расчёта feature, которую вызывают и при обучении, и в сервисе.

Что важно запомнить

Данные для ML копируют из рабочей базы в data warehouse или data lake. Data lake обычно стоит на S3 или MinIO, таблицы в нём хранят в Parquet и делят на partition.

Iceberg и Delta Lake добавляют к data lake транзакции и time travel. Такой data lake называют lakehouse.

Версии датасетов ведут через DVC или lakeFS. Feature store отдаёт одни и те же feature обучению и проду и защищает от training-serving skew.