DATA LAKE И DATA WAREHOUSE: в чем разница
Data Lake или Data Warehouse?
В корпоративной инфраструктуре данные редко живут в одном месте.
Операционные системы хранят заказы, клиентов, платежи, остатки и документы. CRM содержит историю взаимодействия с клиентами. ERP отвечает за финансовый и производственный контур. Интернет-магазин собирает события пользователей. Сервисы создают логи и технические события. Внешние системы передают дополнительные данные.
Пока каждый источник решает собственную операционную задачу, это нормально.
Проблема начинается тогда, когда компании нужно ответить на вопросы, которые проходят сразу через несколько систем:
- › сколько реально заработали на определённой группе клиентов;
- › как менялась маржинальность по периодам;
- › какой канал приводит наиболее ценных клиентов;
- › почему выросло время обработки заказов;
- › где возникают потери между продажей и отгрузкой;
- › как операционные показатели связаны с финансовыми.
Для этого данные приходится собирать в отдельный аналитический контур.
И здесь появляются два понятия, которые часто используют как взаимозаменяемые: Data Lake и Data Warehouse. На самом деле это разные подходы к работе с данными.
ориентирован прежде всего на сохранение большого объёма данных в исходном или близком к исходному виде и возможность использовать их для разных задач.
— на структурированные, подготовленные и согласованные данные, с которыми удобно и предсказуемо работать в аналитике и отчётности.
Разница не сводится к тому, что одно хранилище «для сырых данных», а другое «для готовых». Вопрос глубже: на каком этапе и в каком виде компания фиксирует структуру, качество и смысл своих данных.
Сначала нужно разделить операционные и аналитические данные
Одна из фундаментальных ошибок — пытаться заставить одну систему одновременно хорошо выполнять операционную и аналитическую работу.
Допустим, ERP используется для оформления заказов. Для неё важно быстро создать заказ, изменить его статус, провести документ, проверить остаток, записать платёж. Это операционная нагрузка.
А теперь представим, что аналитик запускает тяжёлый запрос по нескольким годам истории, соединяя заказы, клиентов, товары, платежи и возвраты. Такая задача совершенно другая. Она читает огромное количество данных, выполняет агрегации и соединения и может потреблять значительные вычислительные ресурсы.
Если постоянно выполнять подобные запросы непосредственно в операционной базе, аналитика начинает конкурировать с бизнес-приложением за те же ресурсы.
> Поэтому в зрелой архитектуре данные обычно отделяют от операционного контура.
Это разделение позволяет не заставлять операционную систему быть одновременно базу для транзакций, аналитическим хранилищем, архивом и источником данных для машинного обучения.
Что такое Data Lake
Data Lake — это архитектурный подход, при котором данные собираются в централизованное хранилище в большом разнообразии форматов.
Туда могут попадать:
- › таблицы из корпоративных систем;
- › выгрузки из CRM и ERP;
- › события приложений;
- › логи;
- › JSON и XML;
- › документы;
- › данные из API;
- › файлы;
- › телеметрия;
- › исторические снимки;
- › результаты работы других систем.
Главная особенность — данные не обязательно приводятся к единой аналитической модели до момента загрузки.
Можно сохранить источник практически в исходном виде, а преобразование выполнить позже, когда появится конкретная задача.
- › Это принципиально отличается от классического подхода Data Warehouse.
Зачем вообще хранить данные в сыром виде
На первый взгляд возникает логичный вопрос:
Потому что преобразование — это тоже решение.
Когда данные сразу очищают, объединяют, агрегируют и приводят к единой модели, часть исходного контекста может исчезнуть.
Например, сегодня бизнес считает клиента по одному правилу. Через год методика изменяется.
> Если сохранился только итоговый показатель, пересчитать историю по новой логике может оказаться невозможно.
> Если же сохранены исходные данные, их можно обработать заново.
Поэтому сырой слой часто играет роль источника правды для самого контура данных: он позволяет вернуться к исходной информации и построить новые производные наборы.
Но здесь есть важное условие.
«Сырое» не должно означать «бесконтрольное».
Если компания складывает данные в озеро без каталогизации, владельцев, политики хранения, контроля качества и управления доступом, через некоторое время она получает не Data Lake, а Data Swamp — болото данных.
Data Lake — это не просто большая папка
Такое представление встречается довольно часто:
Нет.
Само хранилище не создаёт архитектуру Data Lake.
Нужны как минимум понятные правила:
- › откуда поступают данные;
- › в каком виде они сохраняются;
- › как идентифицируется источник;
- › какая версия данных актуальна;
- › как отслеживается время загрузки;
- › кто является владельцем набора;
- › какие данные считаются чувствительными;
- › кто имеет к ним доступ;
- › как контролируется качество;
- › сколько хранится конкретный набор;
- › как обнаруживаются изменения схемы;
- › каким образом данные переходят из сырого состояния в подготовленное.
> Без этих механизмов озеро быстро превращается в хранилище, где данные формально существуют, но использовать их становится всё сложнее.
Что такое Data Warehouse
Data Warehouse решает другую задачу.
Здесь данные проходят более жёсткую подготовку перед тем, как становятся частью аналитической модели.
Информация из разных источников должна быть приведена к согласованному виду.
Например, в одной системе клиент идентифицируется по customer_id, в другой — по номеру договора, а в третьей вообще хранится только адрес электронной почты.
Для аналитики недостаточно просто сложить эти три набора рядом.
Нужно определить, как они связаны, какие идентификаторы считаются основными, как обрабатываются дубли и какие правила используются для формирования единой сущности клиента.
То же самое происходит с товарами, подразделениями, заказами, датами, валютами и другими бизнес-сущностями.
Поэтому Data Warehouse — это не просто место хранения.
Это ещё и слой согласования корпоративных данных.
В Warehouse структура появляется раньше запроса
Одна из классических характеристик Data Warehouse — подход schema-on-write.
Упрощённо это означает:
сначала определяется структура и правила данных → затем данные загружаются в эту структуру → после этого ими пользуются аналитические запросы.
данные сохраняются → структура и преобразования определяются под конкретную задачу.
Это не означает, что в Data Lake структуры нет вообще.
Она есть, но часто применяется позже и может отличаться для разных сценариев использования.
Разница именно в том, когда принимается решение о структуре и правилах представления данных.
Почему нельзя просто выбрать что-то одно
Потому что у этих подходов разные задачи.
Представим, что компания получает данные из десяти источников. Часть источников имеет стабильную структуру, часть меняется. Одни данные нужны для регулярной финансовой отчётности, другие используются исследовательской командой, третьи понадобятся для обучения моделей машинного обучения.
Если всё сразу привести к одной жёсткой структуре, можно получить слишком негибкую систему.
Если всё хранить исключительно в исходном виде, аналитикам придётся постоянно самостоятельно разбираться в источниках, качестве и бизнес-логике.
Поэтому на практике часто появляется многоуровневая архитектура.
Названия слоёв могут отличаться в разных архитектурах. Смысл важнее терминологии:
по мере движения данных от источника к потребителю растёт степень их обработки, согласования и бизнес-контекста.
Что имеет смысл хранить в сыром виде
В Raw-слое обычно имеет смысл сохранять данные максимально близко к источнику.
Например, пришёл пакет данных из ERP — его можно сохранить с информацией о времени загрузки и источнике, не пытаясь сразу превратить его в идеальную аналитическую модель.
Это даёт несколько преимуществ.
- › Можно повторить обработку:
Если логика трансформации изменилась, данные можно обработать заново. - › Можно расследовать ошибки:
If итоговый показатель выглядит неправильно, можно вернуться к исходному набору и понять, на каком этапе возникло расхождение. - › Можно использовать данные для новых задач:
Сегодня набор нужен для BI, завтра его можно использовать для аналитической модели или машинного обучения. - › Можно отделить загрузку от преобразования:
Система сначала надёжно принимает данные, а затем обрабатывает их независимо.
Это особенно важно при больших объёмах и сложных интеграциях.
Но сырые данные нельзя бесконечно тащить в аналитику
Есть принципиальная причина, по которой поверх Raw-данных создаются подготовленные слои.
Бизнес-аналитик не должен каждый раз самостоятельно выяснять:
- › какой источник считается главным;
- › почему в одном наборе пять статусов заказа, а в другом семь;
- › как считать выручку;
- › как связывать клиентов между системами;
- › какие заказы считаются отменёнными;
- › как учитывать возвраты;
- › какой курс валюты использовать.
Если каждый отчёт строится на собственной интерпретации данных, компания получает несколько разных версий реальности.
И все три расчёта формально могут быть правильными относительно своих правил.
Проблема не в SQL.
> Проблема в отсутствии единой бизнес-семантики.
Именно здесь Data Warehouse особенно ценен.
Warehouse нужен не только ради скорости запросов
Производительность важна, но это далеко не единственная причина создавать аналитическое хранилище.
Главная ценность — в согласованности.
Допустим, в компании существует понятие «активный клиент». Если его определение находится только в головах аналитиков, каждый отчёт может трактовать его по-разному. В зрелой архитектуре определение закрепляется в модели данных и правилах расчёта.
То же касается:
- › выручки;
- › маржи;
- › активного заказа;
- › нового клиента;
- › возврата;
- › конверсии;
- › отгруженного заказа;
- › просроченной задолженности.
Warehouse становится местом, где технические данные связываются с бизнес-терминами и правилами их расчёта.
Data Lake и Data Warehouse решают разные проблемы
Их можно сравнить не как «старую и новую технологию», а как два разных слоя ответственности.
Но воспринимать эту таблицу как жёсткое правило не стоит.
Современные платформы стирают часть традиционных границ между Lake и Warehouse.
Поэтому сегодня важнее смотреть не на название продукта, а на архитектурные функции конкретного слоя.
А где здесь Data Lakehouse?
Появление Lakehouse как раз связано с попыткой объединить сильные стороны двух подходов.
Идея заключается в том, чтобы использовать гибкость и экономичность озёрной архитектуры, но при этом добавить управление схемами, транзакционность, качество, каталогизацию и более строгую работу с аналитическими наборами.
Это полезная архитектурная модель, но она не отменяет исходную проблему.
Даже если физически компания использует одну платформу, логически всё равно остаются разные уровни:
Поэтому вопрос «Lake или Warehouse?» иногда вообще поставлен неправильно.
Гораздо полезнее спросить:
— «где в нашей архитектуре находятся исходные данные, где происходит их обработка, где определяется корпоративная бизнес-семантика и откуда получают данные конечные потребители?»
Откуда вообще должны поступать данные
Ещё один важный вопрос — не только где хранить данные, но и как они туда попадают.
Для разных систем могут использоваться разные механизмы:
- › пакетные выгрузки;
- › API;
- › CDC — захват изменений в источнике;
- › очереди сообщений;
- › потоковая обработка;
- › файлы;
- › специализированные коннекторы.
Выбор зависит от требований к задержке.
Поэтому архитектура данных начинается не с выбора хранилища.
Она начинается с требования к скорости, полноте, историчности и качеству данных.
История данных — отдельная архитектурная задача
Операционная система часто показывает текущее состояние.
У товара сейчас определённая цена.
Заказ сейчас находится в определённом статусе.
Но аналитике может быть нужна история:
как это значение менялось во времени?
Это особенно важно для:
- › цен;
- › клиентских сегментов;
- › организационной структуры;
- › статусов;
- › договоров;
- › тарифов;
- › остатков;
- › атрибутов товаров.
Если старое значение просто перезаписывается новым, часть аналитического контекста исчезает.
Поэтому аналитическая архитектура должна заранее определить, какие изменения необходимо сохранять исторически и с какой детализацией.
Качество данных нельзя исправить одним Warehouse
Иногда Data Warehouse воспринимают как место, куда данные попадают уже «правильными».
На практике это не так.
Если CRM содержит дубли клиентов, ERP использует неоднозначные справочники, а источник регулярно присылает некорректные даты, само хранилище проблему магически не устранит.
Нужны процессы Data Quality:
- › проверки обязательных полей;
- › контроль диапазонов;
- › обнаружение дублей;
- › проверка ссылочной целостности;
- › контроль полноты загрузки;
- › отслеживание изменений схемы;
- › мониторинг аномалий;
- › контроль задержки поступления данных.
Причём ошибки должны не просто фиксироваться.
Система должна понимать, что делать с некорректной записью: отклонить, отправить в отдельный поток, принять с предупреждением или остановить загрузку.
Без управления доступом Data Lake становится риском
В Data Lake потенциально может оказаться огромное количество корпоративной информации.
Причём иногда в исходном виде — включая поля, которые не нужны большинству аналитиков.
Поэтому безопасность нельзя откладывать до момента, когда появляется первый отчёт.
Нужно заранее определить:
- › какие данные являются чувствительными;
- › кто имеет доступ к исходному слою;
- › кто может видеть подготовленные данные;
- › какие поля необходимо маскировать;
- › какие наборы можно передавать внешним сервисам;
- › как контролируется доступ к историческим данным;
- › как фиксируются обращения к чувствительной информации.
Особенно важно разделять право хранить данные и право видеть данные.
Сам факт нахождения информации в корпоративном Data Lake не означает, что любой пользователь аналитического контура должен иметь доступ ко всему набору.
Когда Data Lake действительно оправдан
Data Lake especially полезен, когда компании приходится работать с большим разнообразием данных.
Например:
- › источников много;
- › форматы постоянно меняются;
- › появляются новые типы данных;
- › нужны исторические данные;
- › есть задачи Data Science;
- › требуется сохранять события и логи;
- › аналитические сценарии ещё не определены полностью;
- › данные нужно использовать для разных будущих задач.
В такой ситуации слишком ранняя жёсткая стандартизация может ограничить развитие.
Но это не означает, что Lake автоматически нужен каждой компании.
Если у организации несколько стабильных источников, понятная отчётность и относительно простой набор аналитических задач, сложная озёрная архитектура может оказаться неоправданной.
Когда достаточно Data Warehouse
Если основной сценарий компании — регулярная управленческая аналитика, финансовая отчётность, KPI и BI, то Warehouse может закрывать значительную часть задач без отдельного полноценного Data Lake.
Особенно если:
- › источники хорошо известны;
- › данные структурированы;
- › набор аналитических показателей относительно стабилен;
- › основными потребителями являются BI и аналитики;
- › нет большого объёма неструктурированных данных;
- › не требуется постоянное исследование новых типов данных.
В таком случае архитектура может быть значительно проще.
И это важно: хорошая архитектура не та, в которой больше компонентов.
Хорошая архитектура — та, которая решает необходимые задачи с оправданной сложностью.
Самая опасная ошибка — начать с технологии
Выбор между Data Lake, Data Warehouse, Lakehouse и конкретной платформой имеет смысл только после того, как понятны требования.
Сначала нужно ответить на другие вопросы:
- › Какие источники данных есть у компании?
- › Как часто они меняются?
- › Какой объём данных поступает?
- › Нужна ли история?
- › Какая допустимая задержка?
- › Какие данные должны быть доступны в реальном времени?
- › Кто будет потребителем?
- › Какие правила качества необходимы?
- › Какие данные чувствительны?
- › Какие аналитические и ML-сценарии планируются?
- › Какие данные нужно уметь пересчитывать задним числом?
Только после этого можно выбирать архитектуру.
Иначе возникает типичная ситуация:
> компания выбирает технологию, а затем пытается подогнать под неё свои процессы.
Как выглядит зрелый контур данных
В зрелой архитектуре данные не просто перемещаются из одной системы в другую.
У них появляется жизненный цикл.
При этом вокруг всех слоёв должны существовать дополнительные механизмы:
Именно они превращают набор хранилищ в корпоративную платформу данных.
Главная разница — не в способе хранения
Data Lake и Data Warehouse часто сравнивают по формату файлов, стоимости хранения или скорости запросов. Это полезные характеристики, но они не объясняют главное.
отвечает за гибкость работы с большим разнообразием исходных данных и сохранение их контекста.
отвечает за структурирование, согласование и предсказуемое использование данных в аналитике.
Они могут существовать отдельно.
Могут быть частью одной платформы.
Могут физически использовать одну технологическую основу.
Но логически их задачи всё равно различаются.
И именно поэтому корпоративная архитектура данных должна начинаться не с вопроса:
— «Какое хранилище нам выбрать?»
А с другого:
— «Как данные проходят путь от источника до решения, которое на их основе принимает человек или система?»
Если этот путь спроектирован правильно, становится понятно, где нужно сохранить исходные данные, где их очистить, где согласовать бизнес-смысл, а где уже предоставить потребителю готовый набор для работы.
И тогда Data Lake и Data Warehouse перестают быть конкурирующими коробками.
- › Они становятся разными уровнями одной системы управления корпоративными данными.
API, Webhook или очередь сообщений?
Когда API есть, а интеграция всё равно не работает
Как соединить производство и корпоративные системы
Все инженерные материалы и экспертные статьи
Полный алфавитный справочник ИТ-терминов
🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.
Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).
Автоматизация бизнеса и ИИ-решения под ключ
Самозанятый Скопец Антон Викторович ИНН 741709260870