Data Lake: что это, отличие от DWH и пример — озеро данных хранит информацию в исходном формате и применяет структуру в момент чтения. В документации Microsoft Learn этот подход назван schema-on-read: преобразование выполняется тогда, когда данные понадобились. Хранилище данных (DWH) устроено иначе — оно задаёт структуру на входе, schema-on-write. Ниже — сравнение, ограничения и заполненный учебный маршрут записей с карантином и lineage.
Определение озера данных и schema-on-read
В материалах AWS озеро данных описано как централизованное хранилище, которое принимает структурированные и неструктурированные данные любого масштаба. Данные кладутся как есть, без предварительного структурирования, а аналитика — от дашбордов до машинного обучения — запускается поверх них. Databricks добавляет важную деталь: озеро использует плоскую архитектуру и объектное хранилище, где объект получает метаданные и уникальный идентификатор. Это упрощает поиск и извлечение данных.
Schema-on-read — это подход, при котором схема применяется в момент чтения. Microsoft Learn прямо противопоставляет его schema-on-write: хранилище задаёт структуру и преобразует данные при загрузке, а озеро хранит всё в исходном виде и трансформирует по необходимости. Ключевое уточнение: schema-on-read остаётся подходом к обработке. Он задаёт момент применения схемы и не отменяет саму схему, проверки качества и правила доступа. Озеро без описанных схем чтения и валидации превращается в свалку — AWS называет это состояние data swamp.
Практический смысл подхода: команда сначала собирает данные, а структуру и правила описывает позже, когда понятны вопросы к ним. Microsoft Learn относит к типовым сценариям озера приём и перемещение данных, обработку больших объёмов, аналитику и машинное обучение, BI-отчётность, а также архивное хранение для аудита и соответствия требованиям.
Отличие lake, DWH и lakehouse
Различие удобно смотреть по четырём осям: типы данных, стоимость, надёжность и круг пользователей. По данным Databricks, озеро и lakehouse принимают все типы — структурированные, полуструктурированные и необработанные, — тогда как хранилище работает только со структурированными данными. По стоимости озеро и lakehouse опираются на дешёвое объектное хранилище, а хранилище дорожает при масштабировании из-за вендорских издержек. По надёжности Databricks описывает традиционное озеро как источник низкого качества с риском data swamp, а lakehouse — как надёжные данные высокого качества. По пользователям озеро исторически тяготеет к дата-сайентистам, lakehouse объединяет аналитиков, дата-сайентистов и ML-инженеров, хранилище ориентировано на аналитиков.
| Критерий | Data Lake | DWH | Lakehouse |
|---|---|---|---|
| Типы данных | Все типы, включая необработанные | Только структурированные | Все типы |
| Стоимость | Низкая, объектное хранилище | Выше при росте объёма | Низкая |
| Надёжность | Риск низкого качества | Высокое качество | Высокое качество |
| Пользователи | Дата-сайентисты | Аналитики | Аналитики, дата-сайентисты, ML-инженеры |
| Формат | Открытый | Закрытый, проприетарный | Открытый |
Microsoft Learn описывает lakehouse как сосуществование озера и хранилища: сырое хранение сочетается со структурированной производительностью запросов. Databricks формулирует это как транзакционный слой поверх озера, который добавляет управление данными, похожее на хранилище, и сохраняет открытый формат. AWS замечает, что типичная организация использует и хранилище, и озеро, поскольку у них разные задачи.
Ограничения: governance, каталог, доступ, retention
AWS называет главной сложностью озера то, что сырые данные лежат без надзора за содержимым. Чтобы озеро стало пригодным, нужны механизмы каталогизации и защиты: без них данные не найти и им нельзя доверять. Для широкой аудитории требуются governance, семантическая согласованность и контроль доступа.
Microsoft Learn перечисляет свой набор ограничений. Масштаб и сложность: петабайты сырых данных требуют инфраструктуры, распределённой обработки и управления затратами. Узкие места обработки: рост объёма и разнообразия добавляет задержку. Риски целостности: без валидации и мониторинга ошибки и неполные загрузки подрывают надёжность содержимого. Качество и governance: разнородные источники усложняют единые стандарты, а управление метаданными, каталогизация и фреймворки governance становятся критичными. Безопасность и доступ: нужны продуманные права и аудит по разнородным наборам. Обнаружимость: без каталогизации озеро вырождается в data swamp, где ценная информация присутствует, но недоступна или понята неверно.
Databricks добавляет три практические проблемы: отсутствие поддержки транзакций, слабое принуждение к качеству и governance, плохая оптимизация производительности. Отдельно названы проблемы надёжности при смешивании пакетных и потоковых данных, замедление запросов при росте объёма из-за управления метаданными и неудачного партиционирования, а также сложности защиты и удаления данных для соответствия требованиям регуляторов. Ownership и retention здесь связаны напрямую: пока не назначен владелец набора и не задан срок хранения, удаление и обновление записей остаются неопределёнными.
Учебный маршрут raw → validated → curated
Ниже — условный учебный набор, который показывает путь записей по слоям. Значения взяты как пример для разбора.
Входные объекты:
raw/orders/2026-11-01.jsonl
{"order_id":"R-31","amount":"900","currency":"RUB"}
{"order_id":"R-32","amount":"bad","currency":"RUB"}
raw/support/notes.txt
R-31: просит доставку после 18:00
Правила слоя validated для этого учебного набора: поле amount приводится к decimal, единственная допустимая валюта — RUB. Запись R-31 проходит проверку и попадает в validated/orders с amount=900.00 RUB. Запись R-32 не проходит: значение «bad» не приводится к числу, поэтому запись уходит в quarantine/orders с reason=invalid_amount.
| Объект | Формат | Проверка | Выход | Lineage |
|---|---|---|---|---|
| raw/orders/2026-11-01.jsonl | JSONL | amount → decimal, currency в списке | R-31 → validated/orders (900.00 RUB); R-32 → quarantine/orders (invalid_amount) | validated/orders/R-31 ← raw/orders/2026-11-01.jsonl#R-31; quarantine/orders/R-32 ← raw/orders/2026-11-01.jsonl#R-32 |
| raw/support/notes.txt | TXT | текст не парсится, доступ ограничен | остаётся в raw/support с меткой restricted | curated/daily не ссылается на объект |
| curated/daily_total | таблица | агрегат только по validated | daily_total RUB = 900.00, count = 1 | curated/daily_total ← validated/orders/R-31 |
Слой curated собирает агрегат по validated. Итог: daily_total RUB = 900.00, count = 1. Каждая строка витрины хранит ссылку на исходный объект, поэтому происхождение числа проверяемо.
Ручной эталон результата
Эталон задаёт, что должно получиться после прогона учебного набора. Он нужен, чтобы сверять автоматический результат с ожидаемым вручную.
Ожидаемые значения: daily_total RUB = 900.00, count = 1. Запись R-32 отсутствует в validated и присутствует в quarantine с reason=invalid_amount. Исходные raw-объекты сохраняют исходное содержимое. Персональная заметка из raw/support/notes.txt не публикуется в общей витрине.
Порядок сверки:
- Открыть curated/daily_total и сравнить сумму и счётчик с эталоном.
- Проверить, что в validated/orders ровно одна запись — R-31.
- Найти R-32 в quarantine/orders и убедиться, что причина указана как invalid_amount.
- Сопоставить lineage витрины с исходным объектом raw/orders/2026-11-01.jsonl.
- Убедиться, что notes.txt остался в raw/support с меткой restricted.
Если хотя бы один пункт расходится с эталоном, разбор останавливают и правят правило.
Проверка карантина вместо нуля
Отдельная проверка касается некорректного значения. Ошибка, которую ловит эта проверка, — молчаливая подмена: сломанное значение превращается в 0 и попадает в витрину как настоящая сумма.
Правильное поведение: значение «bad» не приводится к числу, запись R-32 уходит в quarantine/orders с reason=invalid_amount. В validated/orders остаётся только R-31. Витрина curated/daily_total считает агрегат по validated, поэтому daily_total RUB = 900.00, count = 1 — без учёта битой записи.
Как проверить на своих данных:
- Добавить в raw-набор запись с заведомо некорректным числовым полем.
- Прогнать маршрут и открыть quarantine: запись должна быть там с указанной причиной.
- Проверить, что в validated этой записи нет.
- Сравнить агрегат витрины с ручным эталоном: сумма и счётчик не должны измениться от битой записи.
- Убедиться, что в витрине нет нулевых подстановок вместо отброшенных значений.
В этом наборе подмена «bad» нулём сохранит сумму 900.00 RUB, но увеличит count до 2. Проверка счётчика и карантина обнаружит такую подмену.
Сохранность raw и приватность заметок
Вторая проверка касается двух вещей сразу: исходные объекты остаются неизменными, а персональные данные не попадают в общую витрину.
Сохранность raw: файл raw/orders/2026-11-01.jsonl сохраняет исходное содержимое после прогона. Маршрут читает его и создаёт производные объекты в validated и quarantine, а исходник не перезаписывается. Это позволяет вернуться к сырым данным и пересобрать слои заново.
Приватность заметок: raw/support/notes.txt содержит персональную просьбу и остаётся в raw/support с меткой restricted. Витрина curated/daily на этот объект не ссылается. Databricks в рекомендациях по lakehouse прямо указывает маскировать данные с приватной информацией до попадания в озеро и псевдонимизировать персональные данные для соответствия требованиям.
Порядок проверки:
- Сравнить контрольную сумму raw-файла до и после прогона.
- Убедиться, что в validated и curated нет объектов, производных от notes.txt.
- Проверить метку restricted на объекте заметки.
- Просмотреть lineage витрины: в нём должен быть только raw/orders/2026-11-01.jsonl.
Частые вопросы
Что такое data lake простыми словами?
Это централизованное хранилище, которое принимает данные в исходном формате и любого масштаба. Структура применяется в момент чтения, когда данные понадобились для анализа. AWS описывает его как репозиторий для структурированных и неструктурированных данных, поверх которого запускают аналитику и машинное обучение.
Чем data lake отличается от DWH?
Хранилище данных задаёт структуру на входе и работает со структурированными данными, а озеро хранит всё как есть и применяет схему при чтении. Microsoft Learn называет эти подходы schema-on-write и schema-on-read. Хранилище даёт высокое качество и низкую задержку, озеро — гибкость и низкую стоимость хранения.
Что такое lakehouse и зачем он нужен?
Lakehouse добавляет транзакционный слой поверх озера и совмещает сырое хранение со структурированной производительностью запросов. Databricks описывает его как систему, где аналитика, data science и машинное обучение работают вместе в открытом формате. Он снижает риск data swamp за счёт управления данными.
Почему озеро данных превращается в data swamp?
Причина — сырые данные без надзора, каталога и правил доступа. AWS указывает, что без каталогизации и защиты данные не найти и им нельзя доверять. Microsoft Learn добавляет, что без каталогизации ценная информация остаётся недоступной или понятой неверно.
Как проверить, что битая запись не попала в витрину?
Нужно найти запись в quarantine с указанной причиной и убедиться, что в validated её нет. Затем сравнить агрегат витрины с ручным эталоном: сумма и счётчик не должны измениться от битой записи. В учебном наборе R-32 уходит в quarantine с reason=invalid_amount, а daily_total RUB = 900.00, count = 1.