Data Lake: как устроено озеро данных и зачем оно бизнесу
Data Lake, или озеро данных — централизованное хранилище больших объёмов структурированной, полуструктурированной и неструктурированной информации. Данные поступают туда из разных источников и могут сохраняться в исходном формате. Их структуру определяют позже — при подготовке к конкретному анализу, отчёту или модели. Озеро данных используют как основу для аналитики, машинного обучения и обмена информацией между корпоративными системами.
Какие данные хранят в Data Lake
В традиционной базе сведения заранее распределяют по таблицам и полям. Data Lake принимает разные типы информации без приведения к единой табличной структуре:
- записи о заказах и платежах;
- события с сайтов и из мобильных приложений;
- логи серверов и корпоративных систем;
- данные CRM, рекламных платформ и сервисов рассылок;
- CSV-, JSON- и XML-файлы;
- документы, изображения, аудио и видео;
- показания датчиков и подключённых устройств.
В одном озере могут находиться исходные файлы, очищенные наборы и данные, подготовленные для конкретных отчётов. Поэтому Data Lake — не отдельный формат данных или тип базы, а хранилище и архитектурный подход к работе с разнородной информацией.
Ключевой принцип — schema-on-read, «схема при чтении». Система не требует заранее приводить все поступающие сведения к одной модели. Структуру определяют, когда данные извлекают для отчёта, исследования или обучения модели. В классическом хранилище чаще используется схема при записи: формат и состав данных определяют до загрузки.
Как устроено озеро данных
Типовая архитектура Data Lake включает несколько уровней:
- Источники. Информация поступает из бизнес-приложений, сайтов, CRM, кассовых систем, рекламных кабинетов, мобильных приложений и других платформ.
- Загрузка. Пакетные процессы передают накопленные сведения по расписанию, а потоковые — по мере появления событий.
- Сырой слой. Данные сохраняются максимально близко к исходному виду. Он нужен для аудита, повторной обработки и проверки преобразований.
- Стандартизированный слой. Форматы, названия полей и единицы измерения приводят к согласованным правилам, проверяют типы, выявляют и исправляют технические ошибки.
- Подготовленный слой. Формируются наборы для отчётности, сегментации, исследований и моделей машинного обучения.
- Каталог и управление доступом. Метаданные описывают происхождение, владельца, формат и назначение наборов. Политики определяют, кто может читать, изменять и выгружать информацию.
Деление на сырой, преобразованный и подготовленный слои сохраняет исходные данные и отделяет их от наборов, которым уже можно доверять в бизнес-процессах. Такую многоуровневую организацию рекомендуют, в частности, AWS и Microsoft.
Загрузить файлы в единое хранилище недостаточно. Без каталога, владельцев наборов, правил качества и контроля доступа Data Lake превращается в data swamp — «болото данных», где сложно найти актуальную версию информации и понять её происхождение.
Data Lake, хранилище данных, Lakehouse и CDP: в чём разница
Эти системы могут работать в одной архитектуре, но решают разные задачи.
| Система | Какие данные хранит | Основная задача | Основные пользователи |
|---|---|---|---|
| Data Lake | Сырые и обработанные данные разных форматов | Сохранение информации для будущей обработки, исследований и ML | Инженеры данных, аналитики, Data Scientists |
| Data Warehouse | Преимущественно очищенные и структурированные данные | Регулярная отчётность и BI-аналитика | Аналитики, руководители |
| Data Lakehouse | Данные разных форматов с дополнительным табличным и транзакционным слоем | Совместить гибкость озера с управляемостью и аналитическими возможностями хранилища | Аналитики, инженеры данных, Data Scientists |
| CDP | Данные, связанные с конкретными клиентскими профилями | Сегментация, персонализация и управление маркетинговыми коммуникациями | Маркетологи |
Data Warehouse обычно создают под известные показатели и отчёты. До загрузки данные очищают и приводят к установленной модели, поэтому бизнес-пользователям проще строить повторяемые запросы.
Data Lake сохраняет больше исходного контекста. Например, компания может оставить полную историю действий в приложении, даже если сейчас использует для отчётности только несколько типов событий.
Lakehouse дополняет озеро функциями управления данными, характерными для хранилища: контролем схем, версиями данных и транзакционной обработкой. Такая архитектура рассчитана на выполнение BI-, Data Science- и ML-задач поверх общего слоя хранения.
CDP работает ближе к маркетинговому применению данных. Она связывает контакты, покупки, подписки и поведенческие события с профилями клиентов, после чего маркетолог создаёт сегменты и запускает коммуникации.
Зачем Data Lake маркетологу
Маркетолог редко работает с сырым слоем напрямую. Ценность озера раскрывается, когда команда данных превращает накопленную информацию в понятные признаки, аудитории и показатели.
Основные сценарии:
- Сквозная аналитика. В одном контуре сопоставляют расходы на рекламу, посещения сайта, покупки, возвраты и повторные заказы.
- Расширенная сегментация. В выборках учитывают историю покупок, поведение на цифровых площадках, использование продукта и реакцию на коммуникации.
- Прогнозирование. На исторических данных обучают модели оттока, спроса, вероятности покупки и следующего подходящего предложения.
- Сохранение истории. Исходные события остаются доступными, даже если отчёты, модели или правила сегментации со временем изменились.
- Обмен данными между системами. Подготовленные наборы передают в BI-платформы, CDP, сервисы персонализации (например MoodRec), и другие прикладные системы.
Так, интернет-магазин может хранить в озере просмотры товаров, поисковые запросы, корзины, заказы и возвраты. Аналитики рассчитывают на их основе дату последней покупки, любимую категорию и вероятность повторного заказа. В CDP передаются уже готовые признаки, по которым CRM-маркетолог формирует аудиторию для рассылок.
Когда бизнесу нужен Data Lake
Озеро данных оправдано, если компания собирает большой объём разнородной информации и не хочет ограничивать её использование заранее определёнными отчётами.
Признаки подходящей задачи:
- данные поступают из десятков систем и в разных форматах;
- требуется хранить подробную историю событий;
- часть информации пока не используется, но может понадобиться для новых исследований;
- аналитики и Data Scientists регулярно создают новые наборы и модели;
- объёмы делают хранение всей информации в прикладных системах нерациональным;
- нескольким подразделениям нужен доступ к общим данным при разных правилах их обработки.
Если компания работает с несколькими небольшими таблицами и строит стабильный набор отчётов, отдельное озеро может усложнить архитектуру. В таком случае может быть достаточно операционной базы или Data Warehouse.
Какие риски нужно учитывать
Гибкая загрузка не отменяет требований к управлению данными. Основные риски Data Lake связаны не с хранением как таковым, а с отсутствием понятных правил:
- Неизвестное происхождение. Пользователь видит набор, но не знает, из какой системы он получен и какие преобразования прошёл.
- Дубликаты и противоречия. Один показатель рассчитывается несколькими способами, а идентификаторы одного клиента не связаны между собой.
- Устаревшие данные. Набор продолжает использоваться после остановки загрузки или изменения источника.
- Избыточный доступ. Сотрудники получают сведения, которые не нужны им для работы.
- Рост затрат. Компания сохраняет всё без сроков хранения, контроля объёма и понимания будущей ценности.
- Низкая пригодность для бизнеса. Сырые события доступны инженерам, но маркетологи и аналитики не получают подготовленных показателей.
До загрузки стоит назначить владельцев данных, определить сроки хранения и правила доступа, договориться о названиях ключевых показателей и вести каталог наборов. Качество следует проверять на пути от источника до прикладной системы, а не только в финальном отчёте.
Как Data Lake связан с Altcraft
Data Lake хранит и подготавливает широкие массивы корпоративной информации, а CDP Altcraft переводит клиентские данные в прикладную работу маркетинга: профили, сегменты, автоматические сценарии и коммуникации.
Подготовленные в озере сведения можно передавать в Altcraft через файлы, API или внешние SQL-базы. Например, импорт по расписанию обновляет поля клиентских профилей по данным из SQL-таблиц. После этого маркетолог использует эти сведения в сегментации и коммуникациях.
Например, продуктовая аналитика в Data Lake показывает, что клиент с активной подпиской не пользовался сервисом последние 30 дней. Эти признаки передаются в профиль Altcraft, после чего маркетолог выделяет таких клиентов в сегмент и запускает реактивационный сценарий.
Не все данные обязательно копировать в профиль. При сегментации по внешним данным Altcraft может обращаться к внешней SQL-базе или API непосредственно при построении аудитории. Такой вариант подходит для сведений, которые нужны для конкретной выборки, но не должны постоянно храниться в CDP.
Изучите работу с профилями, данными, сегментами и автоматизацией на практическом курсе Altcraft.
Заключение
Data Lake — хранилище и архитектурный подход для централизованной работы с разнородными данными в исходном и обработанном виде. Озеро сохраняет подробную историю, на основе которой создают отчёты, аналитические наборы, клиентские признаки и модели машинного обучения.
Само наличие большого хранилища не делает данные полезными. Нужны каталог, контроль качества, разграничение доступа и понятный путь от сырого события до бизнес-показателя. В маркетинговой архитектуре Data Lake часто служит источником подготовленных данных, которые затем используются в CDP для формирования клиентских сегментов и управления коммуникациями.
Читайте по теме
