Когда data lake превращается в болото
Почему хранилища данных часто перестают работать через год-два после запуска и что с этим делать.
Data lake - одна из тех идей, которые звучат убедительно на этапе обсуждения. Собираем все данные компании в одном месте, в едином хранилище. Аналитики берут что нужно. ИИ-проекты получают сырьё. Всё связано, всё доступно.
Через полтора-два года я часто вижу другое. Хранилище есть, данных в нём много, но никто точно не знает что там что. Новые потоки добавляются без документации. Старые не удаляются. Запросы к нему занимают непредсказуемое время. Аналитики дублируют слои, потому что не доверяют тому, что уже лежит.
Это и называется data swamp - болото вместо озера.
Почему это происходит
Причина почти всегда одна и та же: data lake создаётся как техническая инфраструктура без одновременного создания организационной инфраструктуры вокруг неё.
Техническая часть решается относительно быстро: выбрать платформу, настроить потоки, запустить загрузку. Организационная часть - нет. Кто отвечает за качество конкретного набора данных? Кто решает, что устарело и может быть удалено? Как новый аналитик узнаёт, что уже есть и в каком состоянии? Как обновляется документация?
Без ответов на эти вопросы хранилище растёт в размере и падает в ценности.
Три симптома, по которым легко диагностировать
Первый - дублирование. Когда разные команды создают похожие таблицы или датасеты, потому что не нашли существующего или не поверили в его актуальность. Это видно по структуре хранилища и по тому, как аналитики отвечают на вопрос "откуда данные".
Второй - страх удалять. Когда никто не берёт ответственность за очистку, потому что непонятно, кто использует старые данные. В результате в хранилище живут данные трёхлетней давности, которые никто не трогает, но и не трогает.
Третий - ответ "надо уточнить". Когда на простой вопрос об источнике конкретного показателя нет быстрого ответа - нужно спрашивать конкретного человека, который "это делал".
Что помогает, а что нет
Не помогает смена платформы. Болото переезжает вместе с данными. Не помогает и разовая "уборка" без изменения процессов - через полгода всё возвращается.
Помогает назначение ответственных за конкретные домены данных. Не технических администраторов, а бизнес-владельцев, которым важна конкретная часть данных. Они принимают решения об актуальности, структуре и качестве.
Помогает минимальный data catalog - реестр того, что лежит, откуда пришло и кто отвечает. Не обязательно дорогой инструмент. Иногда достаточно структурированного внутреннего Wiki, если он поддерживается живым.
Помогает политика: данные без документации и ответственного через определённый срок помечаются как устаревшие и не используются в отчётности.
Практический тест
Попросите любого аналитика в вашей команде объяснить за пять минут: откуда берётся конкретный ключевой показатель в дашборде, какой датасет его питает, кто отвечает за его актуальность.
Если это занимает больше пяти минут или требует обращения к конкретному человеку - у вас есть признаки болота, независимо от того, насколько современная платформа под ним.
Data lake сам по себе не решает проблему данных. Он создаёт новую инфраструктуру, которая требует такого же управления, как и любая другая.