Data warehouse, data mart, data lake, lakehouse
Вокруг аналитических данных крутятся четыре термина, которые легко спутать: data warehouse, data mart, data lake, lakehouse. Их используют в вакансиях, в архитектурных схемах, на собеседованиях — и часто неточно. Этот урок наводит порядок: что означает каждый, какую задачу решает, как они исторически сменяли друг друга и в каких отношениях находятся сегодня.
Это завершающий урок модуля «От OLTP к OLAP». Предыдущие уроки объяснили, почему аналитике нужна отдельная система с другой моделью и другим хранением. Этот урок даёт словарь: как называются эти системы и чем они различаются. Без чёткого владения этими четырьмя словами невозможно осмысленно говорить об архитектуре данных.
Data warehouse: организованный склад
Data warehouse (хранилище данных, DWH) — центральная аналитическая база. Это система, в которую данные из многих источников собираются, очищаются, согласуются и складываются в продуманной, структурированной модели, оптимизированной под аналитические запросы.
Ключевые свойства data warehouse:
- Схема задана заранее (schema-on-write). Прежде чем данные лягут в warehouse, для них определена структура: таблицы, столбцы, типы, связи. Данные приводятся к этой схеме при загрузке.
- Данные интегрированы и согласованы. Клиент из CRM и клиент из биллинга сведены к единому представлению. Справочники согласованы между источниками.
- Модель оптимизирована под аналитику. Обычно размерная — star schema с fact- и dimension-таблицами (следующий модуль). Поколоночное хранение со сжатием.
- Данные структурированы. Таблицы со строками и столбцами. Не произвольные файлы.
Аналогия в названии точна. Data warehouse — это склад, где товар разложен по полкам с этикетками, по системе. Найти нужное легко, потому что всё каталогизировано заранее. Цена этого порядка — данные нужно разложить до того, как ими пользуются: разложить (определить схему, привести, интегрировать) дорого, зато брать (запрашивать) потом дёшево и быстро. Примеры: Snowflake, BigQuery, Redshift, Teradata.
Data mart: витрина под один отдел
Data mart (витрина данных) — это подмножество warehouse, выделенное под нужды одной предметной области или одного отдела. Не отдельный класс системы, а способ организации: меньший, сфокусированный срез.
Корпоративный warehouse покрывает всю компанию: продажи, маркетинг, финансы, логистику, поддержку. Финансовому аналитику не нужен весь этот объём — ему нужны финансовые данные. Data mart — это срез warehouse именно для финансов: только релевантные таблицы, только нужные метрики, под конкретный круг вопросов конкретного отдела.
Зачем выделять витрины:
- Простота для пользователя. Аналитику маркетинга не нужно ориентироваться в сотнях таблиц всей компании — он видит десяток таблиц своей витрины.
- Производительность. Меньший, сфокусированный набор данных — запросы быстрее.
- Разграничение доступа. Финансовая витрина доступна финансам; чувствительные данные не видны лишним.
- Независимость команд. Команда отдела развивает свою витрину, не задевая остальных.
Соотношение «warehouse и mart» — это «целое и его тематические части». Один корпоративный warehouse, внутри — несколько витрин под отделы. Важная тонкость, к которой курс вернётся в модуле про методологии: витрины разных отделов должны опираться на общие согласованные справочники (conformed dimensions) — иначе «выручка» в финансовой витрине и «выручка» в маркетинговой разойдутся, и компания получит несколько противоречащих версий одной цифры.
Data lake: озеро сырья
Data lake (озеро данных) появилось как ответ на жёсткое ограничение warehouse: warehouse требует схему заранее и принимает только структурированные данные. А мир данных шире таблиц — логи, JSON из API, изображения, видео, тексты, потоки событий, сырые выгрузки. Под warehouse-модель это всё не ложится, по крайней мере не сразу.
Data lake — это хранилище, которое принимает любые данные в любом формате как есть, без предварительной схемы. Технически это, как правило, дешёвое объектное хранилище (Amazon S3, Google Cloud Storage и подобные), куда складывают файлы: Parquet, CSV, JSON, логи, медиа — всё подряд.
Главное архитектурное различие — момент, когда определяется схема:
- Warehouse — schema-on-write: структура задаётся при записи; что не подходит под схему, не попадёт.
- Data lake — schema-on-read: данные кладутся как есть, без схемы; структура накладывается в момент чтения, тем, кто читает, и под свою задачу.
Аналогия снова в названии. Если warehouse — склад с полками и этикетками, то data lake — озеро: вода (данные) втекает свободно, без сортировки. Плюс: ничего не теряется, принять данные дёшево и быстро, можно сложить сырьё, для которого ещё нет применения. Минус — оборотная сторона: озеро легко превращается в data swamp (болото) — гигантскую свалку файлов без каталога, описаний и качества, где ничего не найти. Дёшево втекает — дорого осмысленно достаётся. Это ровно противоположный warehouse компромисс.
| Аспект | Data warehouse | Data lake |
|---|---|---|
| Схема | заранее (schema-on-write) | при чтении (schema-on-read) |
| Типы данных | структурированные таблицы | любые: файлы, логи, JSON, медиа |
| Стоимость записи | высокая (привести к схеме) | низкая (положить как есть) |
| Стоимость осмысленного чтения | низкая (всё разложено) | высокая (структуру наложить самому) |
| Главный риск | негибкость к новым данным | превращение в data swamp |
| Хранилище | специализированная аналитическая СУБД | дешёвое объектное хранилище (S3 и подобные) |
Lakehouse: попытка соединить оба
Долго warehouse и data lake существовали как две раздельные системы, и многие компании держали обе сразу: lake для сырья и нетабличных данных, warehouse для структурированной аналитики. Это означало дублирование данных, два набора инструментов, перекачку из lake в warehouse и постоянный риг рассинхронизации.
Lakehouse (озёрный склад) — архитектура, которая стремится дать одной системой и дешёвое гибкое хранение data lake, и структуру с производительностью data warehouse. Идея: хранить данные в дешёвом объектном хранилище в открытом колоночном формате (Parquet), но сверху положить табличный слой с метаданными, который придаёт этим файлам свойства warehouse — таблицы, схему, транзакции, версионирование.
Этот метаданный слой обеспечивают открытые табличные форматы: Delta Lake, Apache Iceberg, Apache Hudi. Они превращают набор Parquet-файлов в S3 в полноценную таблицу:
- Транзакции (ACID) — параллельные записи не повреждают данные.
- Эволюция схемы — столбцы можно добавлять без переписывания всего.
- Time travel — версионирование: можно запросить таблицу «по состоянию на вчера».
- Производительные запросы — поверх тех же файлов работают и SQL-движки, и движки машинного обучения.
Lakehouse — естественный дом для medallion architecture из прошлого урока: bronze/silver/gold живут слоями в одном lakehouse, каждый слой — это набор табличных форматных таблиц своей степени зрелости.
Как уложить четыре термина вместе
Соберём картину, чтобы термины перестали путаться.
Data warehouse — структурированная аналитическая база со схемой, заданной заранее; данные интегрированы; оптимизирована под аналитику. Структура и скорость ценой гибкости.
Data mart — не отдельная система, а тематический срез warehouse под один отдел; меньше, сфокусированнее, проще. Отношение к warehouse — «часть к целому».
Data lake — хранилище любых данных в любом формате без схемы заранее; схема накладывается при чтении. Гибкость и дешёвый приём ценой риска превратиться в свалку.
Lakehouse — архитектура, соединяющая дешёвое гибкое хранение lake со структурой и производительностью warehouse через открытый табличный формат поверх файлов.
Историческая логика проста: сначала появился warehouse (нужна аналитика — нужен организованный склад данных); внутри него выделили mart-ы (большому warehouse нужны тематические срезы под отделы); затем рядом возник data lake (warehouse не вмещал сырьё и нетабличное); и наконец lakehouse попытался свести lake и warehouse в одно, чтобы не держать две системы. Это не четыре конкурента, из которых надо выбрать один. Это словарь слоёв и подходов современной аналитической инфраструктуры — и владеть им вы обязаны точно.
DWH vs Data Lake vs Lakehouse: карта вариантов DE Apache Iceberg: каталог и иерархия метаданныхБыстрая проверка на собеседовании. «Чем lake отличается от warehouse?» — момент определения схемы: warehouse это schema-on-write, lake это schema-on-read. «Что такое mart?» — тематический срез warehouse под отдел, а не отдельный класс системы. «Зачем lakehouse?» — чтобы одной системой иметь и гибкость lake, и структуру warehouse, не держа обе.
Попробуй сам
Возьмите розничную компанию: интернет-магазин и сеть офлайн-точек. У неё есть production-база заказов, CRM, биллинг, выгрузки с касс, логи поведения на сайте (клики, просмотры), фотографии товаров, отзывы покупателей текстом.
Разложите эти данные по терминам урока. Что естественно ложится в structured warehouse, а что — нет, и почему? Что отправится в data lake и по какой причине именно туда? Если у компании есть отделы продаж, маркетинга и финансов — какие три data mart вы бы выделили и какие таблицы дали каждому?
Затем сформулируйте письменно: какую конкретную проблему решит для этой компании переход на lakehouse — что станет проще по сравнению с раздельным содержанием отдельного data lake и отдельного data warehouse? Ответ свяжите с дублированием данных, числом инструментов и риском рассинхронизации между двумя системами.