Data lake до data lake: когда оправдан сырьевой слой и как не превратить его в болото
Складывать всё в одно место - не стратегия. Нужны каталоги, владельцы и метаданные, иначе получается не озеро, а трясина.
Идея складывать все сырые данные в одно место привлекательна логически: никогда не знаешь, что пригодится, хранение дешевеет, а обрабатывать можно потом. Компании разного размера рано или поздно приходят к этой мысли и начинают копить - логи, события, выгрузки, файлы, снапшоты баз данных.
Проходит год-два, и выясняется, что копить умели, а пользоваться - нет. Никто не знает, что именно лежит, в каком формате, актуально ли это. Данные есть, но получить из них что-то полезное сложнее, чем кажется.
Это не провал идеи сырьевого слоя. Это провал реализации без нужных элементов. Экономика того, почему "хранить всё" - это не стратегия, - и каковы реальные скрытые издержки недисциплинированного архива - важна до добавления новых источников.
Когда сырьевой слой действительно оправдан
Хранить данные до их обработки имеет смысл при нескольких условиях.
Данные изменяются или исчезают у источника. Если источник - внешняя система, API или партнёр, который не гарантирует историю, сырая копия даёт вам контроль над историей.
Требования к обработке ещё не определены. Иногда бизнес не знает точно, что именно будет анализироваться. Сохранить сырой слой и обработать позже - разумно, если это осознанное решение, а не откладывание.
Нужен аудит или воспроизводимость. В регулируемых отраслях или при работе с финансовыми данными важно уметь воспроизвести расчёт по исходным данным. Для этого нужны неизменяемые сырые копии.
Во всех остальных случаях "давайте сначала всё сохраним, а потом разберёмся" - это не стратегия. Это откладывание проблемы с процентами.
Три вещи, без которых сырьевой слой превращается в болото
Каталог. Список того, что лежит в хранилище: источник, формат, период, частота обновления, последнее обновление. Без каталога хранилище непрозрачно для новых людей и становится непрозрачным даже для создателей через полгода.
Владелец. У каждого набора данных должен быть конкретный человек или команда, которая отвечает за его актуальность и корректность. "Владеет всей командой" означает не владеет никто. Когда данные протухают или что-то ломается, должно быть понятно, кому это починить.
Метаданные о качестве. Данные бывают неполными, частично сломанными, с пропусками. Это нормально - если это задокументировано. Потребитель данных должен знать, что он получает, включая известные ограничения. Иначе он узнает об этом в самый неудобный момент.
Как организовать слои внутри сырьевого хранилища
Даже если всё хранится в одном месте, внутренняя структура помогает.
Минимальная схема:
- raw / landing - данные как пришли, без обработки;
- validated - прошли базовую проверку схемы и полноты;
- curated - очищены, приведены к единому формату, готовы к анализу.
Переход между слоями - это явный процесс, а не случайный. Если данные не прошли валидацию - они остаются в raw и не попадают дальше. Это предотвращает ситуацию, когда некорректные данные тихо уходят в аналитику.
Признаки того, что болото уже начинается
Несколько сигналов, которые я видел в разных компаниях:
- никто не может ответить, что именно лежит в каком каталоге;
- один и тот же источник данных загружается несколько раз разными командами, потому что никто не знал, что он уже есть;
- аналитик тратит больше времени на выяснение того, что это за данные, чем на сам анализ;
- "данные за прошлый год" существуют в нескольких экземплярах с разными значениями.
Ни одна из этих проблем не решается добавлением места на диске.
Вопрос для проверки
Если у вас есть сырьевое хранилище данных, возьмите любой набор данных из него и задайте три вопроса: что это, кто за это отвечает, когда последний раз проверялась актуальность?
Если на все три вопроса есть ответы - хорошо. Если нет - это точка, с которой нужно начинать наводить порядок. Не с добавления новых источников, а с описания тех, что уже есть.