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