Data Lake (озеро данных)

Data lake (озеро данных) — это централизованное хранилище, которое хранит сырые данные в их исходном формате — структурированные (выгрузки из БД), полуструктурированные (JSON, логи CSV) и неструктурированные (изображения, PDF, аудио, сырой текст) — в огромных масштабах и по низкой цене, без требования структурировать данные по заранее заданной схеме перед сохранением. Это ключевое отличие от data warehouse (хранилища данных): warehouse навязывает подход «схема при записи» (schema-on-write) — данные должны быть очищены и структурированы перед загрузкой, — тогда как data lake использует подход «схема при чтении» (schema-on-read): данные загружаются как есть, а структура и смысл применяются позже, во время запроса или обработки, тем инструментом, который их читает. Почему это важно для разработчиков AI/SaaS-продуктов: data lake стали особенно актуальны в эпоху AI, поскольку значительная часть сырого материала для AI-функций — документы, транскрипты чатов, загруженные файлы, выходные данные моделей, логи оценок (eval) — плохо укладывается в реляционные таблицы, а навязывание жёсткой схемы перед сохранением означало бы принятие решения заранее о том, как именно эти данные будут использоваться, что часто неизвестно в момент их поступления. Сохранение данных в сыром виде сначала в data lake (обычно это просто объектное хранилище вроде S3 с определённой схемой папок/партиций) сохраняет опциональность: новая AI-функция, появившаяся через полгода, сможет переобработать те же исторические сырые данные способом, который никто не предвидел на момент их первого сбора. Как это работает: data lake обычно строятся напрямую на объектном хранилище (S3, Google Cloud Storage, Azure Blob Storage) с использованием открытых форматов файлов (Parquet, Avro, JSON), организованных по схеме партиционирования (например, `s3://lake/events/year=2026/month=07/day=02/`), которая позволяет движкам запросов сканировать только релевантные партиции вместо всего датасета. Движки запросов вроде Apache Spark, Presto/Trino или AWS Athena могут выполнять SQL напрямую по файлам, лежащим в озере, без отдельного этапа загрузки, стирая границу между «data lake» и «data warehouse» — гибридный паттерн, часто называемый «lakehouse» (популяризован Databricks), добавляет к дешёвому и гибкому хранению в стиле lake транзакционные гарантии и обеспечение схемы в стиле warehouse. Практический пример: AI-SaaS логирует каждую пару сырых запрос/ответ LLM (промпт, модель, токены, задержка, вывод) как JSON-файлы в data lake на базе S3, партиционированный по дате, задолго до того, как решить, какой именно анализ понадобится проводить. Спустя месяцы, когда команда хочет построить систему регрессионной оценки промптов, сравнивающую поведение моделей между версиями, она запускает запросы Athena напрямую по историческому сырому JSON в озере — заранее строить ETL-пайплайн под сценарий использования, который на момент сбора данных ещё никто не определил, не потребовалось.