Представьте: у бизнеса есть CRM, рекламные кабинеты, телефония, 1С, файлы менеджеров и ещё одна таблица, которую никто не трогает, потому что «там всё важное». Команда хочет собрать данные в одном месте. И тут появляются два красивых термина — Data Lake и DWH.
Звучит так, будто нужно выбрать победителя. На практике вопрос другой: какие данные мы складываем, в каком виде и для какого решения? Если ответить на него, половина архитектуры собирается без магии (а вторая половина хотя бы перестаёт пугать).
Что это такое простыми словами
Data Lake, или озеро данных, хранит большие объёмы данных в исходном или близком к исходному виде. Туда можно положить таблицы, события сайта, JSON, логи, записи датчиков и другие форматы. Структуру часто уточняют уже в момент обработки — это называют schema-on-read.
DWH, или корпоративное хранилище данных, хранит подготовленные и согласованные данные для анализа. До загрузки или в процессе загрузки команда задаёт структуру, правила показателей и связи. Поэтому отчёт быстрее получает понятные сущности: клиент, заказ, товар, канал, выручка.
Озеро похоже на большой склад сырья. DWH — на цех, где сырьё уже разобрано, проверено и уложено так, чтобы им можно было пользоваться каждый день. Склад не хуже цеха. Просто задачи разные.
Зачем это бизнесу
Data Lake полезен, когда источников много, форматы меняются, а будущие сценарии ещё не определены. Можно сохранить историю событий, не выбрасывая поля, которые сегодня кажутся лишними. Это удобно для исследований, машинного обучения и повторной обработки.
DWH полезен, когда руководителю каждое утро нужен одинаково посчитанный отчёт. Здесь важны стабильные правила, скорость запросов и единые определения. Если маркетинг и финансы по-разному понимают выручку, одно озеро ситуацию не вылечит — правила всё равно придётся договорить.
Часто работает связка: сырые данные попадают в озеро, затем проходят очистку и превращаются в подготовленные витрины или таблицы DWH. Но связка нужна не «потому что так делают взрослые», а когда есть объём, история и несколько реальных потребителей данных.
Как сделать: пошаговый порядок
- Запишите одно решение, ради которого собираете данные. Например: каждую неделю перераспределять рекламный бюджет по маржинальной прибыли.
- Перечислите источники и форматы. Отдельно отметьте файлы, события, документы и справочники, которые меняются без предупреждения.
- Определите, нужна ли исходная история. Если расчёт придётся пересобирать, сохраняйте сырой слой, а не только итоговую таблицу.
- Согласуйте бизнес-термины: что считается заказом, оплатой, возвратом, новым клиентом и рекламным расходом.
- Соберите один путь от источника до отчёта. Проверьте полноту, дубли, опоздавшие записи и скорость обновления.
- Только после пилота решайте, расширять DWH, добавлять озеро или оставить более простую схему.
Формула или логика расчёта
Универсальной формулы выбора нет. Я использую простую оценку из пяти вопросов: разнообразие форматов, объём истории, частота изменений, требования к повторной обработке и число регулярных отчётов. Чем больше сырого и меняющегося — тем полезнее Data Lake. Чем больше согласованной ежедневной отчётности — тем важнее DWH.
Подробный пример с числами
Возьмём интернет-магазин. В месяц он получает 600 тысяч событий сайта, 18 тысяч заказов и данные из пяти рекламных систем. Руководству нужен ежедневный отчёт по марже, а продуктовой команде — возможность исследовать путь пользователя.
Если загрузить в DWH только итоговые заказы и расходы, управленческий отчёт заработает быстро. Но продуктовая команда не увидит последовательность событий и не сможет проверить новую гипотезу. Если сложить всё только в озеро без правил, исследователи обрадуются, а ежедневный отчёт начнёт каждый раз собираться заново.
Рабочая схема такая: сырые события и выгрузки сохраняем в озере; очищенные заказы, оплаты, товары и расходы собираем в DWH; сверху делаем витрину маржинальной прибыли. Из 18 тысяч заказов 430 оказались дублями, ещё 210 оплат приехали на следующий день. После правил дедупликации и дат отчёт стал сходиться с финансами.
Результат здесь не «мы внедрили озеро». Результат — маркетолог видит прибыль по каналу утром, а аналитик может вернуться к исходным событиям и проверить новую гипотезу.
Как проверить архитектуру до большого проекта
Начните с таблицы решений, а не с перечня технологий. Для каждого сценария запишите потребителя, допустимую задержку, глубину истории и нужную детализацию. Ежедневный отчёт по оплатам может требовать строгой витрины DWH, а исследование поведения на сайте — сырого событийного слоя. Когда сценарии лежат рядом, становится видно, где один слой действительно обслуживает несколько задач, а где мы строим отдельный дворец для одного графика.
Отдельно проверьте восстановление. Представьте, что формулу маржи изменили через полгода. Есть ли исходные цены, скидки, возвраты и себестоимость, чтобы пересчитать историю? Если сохранился только готовый итог, любой новый вопрос упрётся в старую выгрузку. Сырой слой ценен не объёмом сам по себе, а возможностью честно повторить расчёт.
Следующий вопрос — качество на входе и выходе. В озере допустимы разные форматы, но недопустима неизвестность: откуда файл, за какой период, кто владелец и можно ли ему доверять. В DWH требования жёстче: ключи должны быть уникальны, связи — проверены, итог — сверен с источником. У каждого слоя своя дисциплина.
Посчитайте эксплуатацию. Сколько времени занимает загрузка, сколько стоит хранение, кто реагирует на сбой и как пользователь узнает, что отчёт устарел? Архитектура без мониторинга работает ровно до первого тихого пропуска данных. Потом отчёт открывается, цифры выглядят прилично, а вчерашний день просто не приехал.
Наконец, договоритесь о критерии расширения. Например: добавляем отдельное озеро, когда появляются три нестандартных источника, нужна повторная обработка истории и текущий DWH перестаёт удобно принимать сырой формат. Такой порог защищает и от преждевременной сложности, и от бесконечного ожидания.
Короткий чек-лист
- одно решение и его пользователь
- перечень источников и форматов
- срок хранения сырой истории
- правила качества по слоям
- стоимость загрузки и вычислений
- владелец сбоя и сценарий восстановления
Как превратить расчёт в решение
Есть ещё один полезный тест: кто будет пользоваться каждым слоем. Озеро обычно обслуживает инженеров, аналитиков и исследователей. DWH — повторяемую отчётность и подготовленные наборы. Если единственный пользователь хочет раз в неделю увидеть пять показателей, сложная двухслойная платформа может не окупиться.
С другой стороны, не считайте только сегодняшние графики. Если компания регулярно добавляет источники и пересчитывает историю, отсутствие сырого слоя создаёт долг. Каждое новое правило начинает требовать повторной выгрузки, а источник не всегда хранит нужную глубину.
Для пилота достаточно одного месяца и одного сложного случая: возврат, изменение заказа или поздняя оплата. Проведите его через весь путь и убедитесь, что итог воспроизводим. После этого увеличивайте период и число источников.
Критерий готовности простой: пользователь получает нужную цифру вовремя, команда может объяснить её происхождение, а повторный расчёт не требует ручного подвига. Если один пункт не выполняется, технология ещё не стала системой.
Что должно быть зафиксировано
- потребители каждого слоя
- рост источников на год
- один сложный тестовый случай
- воспроизводимость расчёта
- время готовности отчёта
Ограничения и типичные ошибки
- Озеро без каталога, владельцев и правил качества быстро превращается в место, где данные есть, но никто не знает какие.
- DWH не обязан хранить вообще всё. Лишняя детализация увеличивает стоимость и усложняет поддержку.
- Не сравнивайте решения только по цене хранения. Считайте разработку, вычисления, мониторинг, доступы и время команды.
- Не начинайте с переноса всех систем. Один законченный сценарий полезнее двадцати подключённых источников без результата.
- Не путайте технологию с определениями. Формулу маржи и дату выручки всё равно согласует бизнес.
Как мы используем это в работе
В работе я сначала спрашиваю собственника: какое решение должно стать быстрее или точнее? Затем мы берём один отчёт и идём назад — от цифры до поля в источнике. На этом маршруте становится видно, где нужен сырой архив, а где достаточно подготовленной таблицы.
После пилота маркетингу отдаём согласованную витрину расходов и результата. Финансам — правила выручки, возвратов и себестоимости. Технической команде — список источников, частоту обновления и проверки качества. Получается не спор «озеро или хранилище», а понятная схема ответственности.
Если у вас данные уже разъехались по системам, можно начать с одного управленческого вопроса. Кнопка ниже — чтобы обсудить его со мной и не строить космодром ради еженедельной таблицы.
Что сделать прямо сейчас
Выберите один отчёт, который команда собирает дольше всего. Нарисуйте путь трёх его главных цифр до источников и отметьте, где нужна исходная история, а где — согласованная структура. Это и будет первая версия архитектуры.
