Data Lake

Озеро данных — это централизованное хранилище, которое сохраняет данные в исходном, нативном формате: от выгрузок из баз данных и журналов JSON до изображений, видео, аудио и документов. Обычно для этого используется недорогое облачное объектное хранилище, а структура применяется только при чтении данных. Термин придумал в 2010 году Джеймс Диксон, тогдашний технический директор Pentaho, чтобы противопоставить озеро витрине данных: витрину он сравнивал с очищенной и расфасованной бутилированной водой, а озеро — с большим массивом данных в естественном состоянии, к которому могут обращаться многие пользователи. Поскольку моделировать данные заранее не нужно, озеро может хранить всё, что собирает организация. Это удобно для компьютерного зрения: обучающие данные для будущей модели часто представляют собой необработанные данные, о применении которых никто не знал на момент их сохранения.

Как работает озеро данных#

В озере данных хранение отделено от вычислений. Файлы лежат в объектном хранилище, например Amazon S3, Google Cloud Storage или Azure Data Lake Storage, а такие движки, как Spark и Trino, или процесс на Python читают их напрямую. Поэтому каждая команда может масштабировать собственные вычислительные ресурсы, не копируя данные. Табличные данные обычно хранятся в открытых колоночных форматах, например Apache Parquet, а изображения и видео остаются обычными файлами, часто рядом с манифестами JSON или Parquet, в которых содержатся их метаданные и метки.

В большинстве озёр данные распределены по зонам в зависимости от степени обработки. Databricks называет эту схему медальонной архитектурой: в необработанной (бронзовой) зоне данные хранятся точно в том виде, в каком поступили; в очищенной (серебряной) зоне находятся проверенные данные без дубликатов; а в подготовленной (золотой) зоне — таблицы и наборы данных, готовые для отчётности или обучения. Каталог метаданных, например AWS Glue Data Catalog, Hive Metastore или Unity Catalog, фиксирует содержимое каждого набора данных, его владельца и тех, кому разрешено его читать. Без такого каталога и очистки данных озеро превращается в «болото данных»: никто не может найти файлы, доверять им или безопасно удалить их.

Схема при чтении#

В озере схема применяется при чтении данных — это называется схемой при чтении. Записывать данные можно сразу после их появления, даже если два источника по-разному определяют поля; каждый читатель сам выбирает нужные столбцы и типы. В этом примере создаются два исходных файла JSON с разными полями, а затем оба читаются по одной схеме с помощью Polars:

import json
from pathlib import Path

import polars as pl

# Необработанная зона: две камеры записывают события обнаружения в виде строк JSON, каждая со своим набором полей
Path("lake/raw").mkdir(parents=True, exist_ok=True)
Path("lake/raw/dock-1.jsonl").write_text(json.dumps({"label": "forklift", "conf": 0.91}))
Path("lake/raw/dock-2.jsonl").write_text(json.dumps({"label": "person", "conf": 0.62, "lux": 120}))

# Схема при чтении: этот читатель выбирает столбцы и типы при запросе файлов
schema = {"label": pl.String, "conf": pl.Float32, "lux": pl.Int32}
events = pl.scan_ndjson("lake/raw/*.jsonl", schema=schema, include_file_paths="source")
print(events.collect())

В результате получаются две строки со столбцами label, conf, lux и source. Первая камера не записывала lux, поэтому для неё возвращается значение null, а source указывает исходный файл для каждой строки. Другое задание может прочитать те же файлы по другой схеме, не перезаписывая их.

Озеро данных, хранилище данных и lakehouse#

• Хранилище данных: хранит очищенные структурированные таблицы с фиксированной схемой, которой данные должны соответствовать при загрузке (схема при записи), обычно после этапа извлечения, преобразования и загрузки (ETL). Хранилища, например Snowflake, BigQuery и Redshift, быстро обрабатывают запросы SQL и бизнес-аналитики, но менее гибки при работе с изображениями, текстом и другими неструктурированными данными.
• Озеро данных: недорого хранит данные в любом формате и преобразует их после загрузки (ELT), что удобно для исследований, интеллектуального анализа данных и машинного обучения. В обычных файлах озера нет транзакций, поэтому при одновременной записи читатели могут получить неполные результаты.
• Lakehouse: добавляет к хранению в озере возможности хранилища данных благодаря открытым табличным форматам, таким как Apache Iceberg, Delta Lake и Apache Hudi. Они обеспечивают транзакции ACID, контроль схемы и возможность вернуться к предыдущим версиям таблицы. Исследователи Databricks описали эту архитектуру в статье 2021 года.

Озёра данных в машинном обучении#

Для команд компьютерного зрения озеро хранит каждый кадр с камеры, метаданные съёмки, его аннотации и прогнозы, которые на нём строят развёрнутые модели. Проекты автономных транспортных средств загружают журналы поездок своих автопарков и анализируют их, чтобы найти редкие ситуации, например пешехода ночью под дождём, разметить их и добавить в обучающие выборки. В здравоохранении обезличенные снимки и отчёты, собранные в одном озере, становятся источником данных для моделей анализа медицинских изображений. Возврат прогнозов из промышленной эксплуатации в озеро для проверки и повторной разметки замыкает маховик данных, а снимки таблиц или такие инструменты, как DVC, фиксируют точную версию данных, на которой обучалась каждая модель. Хранилища признаков и векторные базы данных часто строят поверх озера: они предоставляют признаки или эмбеддинги, полученные из исходных файлов.

Ultralytics Platform может превратить папку в Amazon S3, Google Cloud Storage или Azure Blob Storage в обучающий набор данных без загрузки копии: платформа индексирует на месте до 500 000 объектов за один импорт, используя учётные данные только для чтения, разбирает файлы меток YOLO .txt, расположенные рядом с изображениями, и назначает выборки train, val и test по именам папок. Для каждого проиндексированного изображения фиксируется версия объекта, поэтому Platform не допускает работу с изображением, если его файл в озере был перезаписан.