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