Хранилище данных или data lake: как не ошибиться с выбором
Разбор двух архитектурных подходов к хранению корпоративных данных и критерии выбора для компаний среднего размера.
На рынке сейчас активно продвигают два образа будущего для корпоративных данных. Первый - классическое хранилище данных (data warehouse): структурированные таблицы, строгая схема, SQL-запросы. Второй - data lake: всё складывается как есть, в исходном формате, а структуру добавляют потом при чтении.
Я регулярно вижу, как компании выбирают между этими подходами по маркетинговым брошюрам, а не по реальным потребностям. Обе архитектуры работают - но каждая в своём контексте.
Что такое хранилище данных на практике
Data warehouse - это инфраструктура, в которую данные попадают уже очищенными и приведёнными к единой схеме. Трансформация происходит до записи, а не после. Запросы работают быстро, потому что структура предсказуема.
Главное ограничение: схема должна быть определена заранее. Если бизнес-правила меняются или появляется новый источник данных с другой структурой - нужна миграция. Это не катастрофа, но это работа.
Warehouse хорошо подходит для аналитики с устоявшимися вопросами: продажи по регионам, воронки, финансовая отчётность. Там, где вопросы известны и повторяются.
Что такое data lake на практике
Data lake - это хранилище сырых данных. Логи, события, файлы, JSON, таблицы - всё в одном месте в исходном виде. Схема определяется в момент чтения, а не записи.
Главный плюс - гибкость. Можно добавить новый источник данных без изменения существующей структуры. Можно задать вопрос, который не был предусмотрен при проектировании.
Главный минус, о котором редко говорят: data lake без управления быстро превращается в data swamp. Никто не знает, что где лежит, данные не документированы, качество неизвестно. Это не технический дефект архитектуры - это организационный дефект. Но он встречается очень часто.
Где ломается логика выбора
Компании среднего размера часто переоценивают гибкость lake и недооценивают стоимость управления им. Утверждение "сначала соберём всё, потом разберёмся" работает только если есть команда, которая разбирается.
Обратная ошибка тоже бывает: компании с действительно разнородными и непредсказуемыми данными строят rigid warehouse и потом мучаются с каждым изменением схемы.
Ни одна из этих ошибок не про технологию. Обе - про несоответствие архитектуры реальной ситуации.
Как принять решение
Несколько вопросов, которые помогают прояснить картину:
- Насколько хорошо вы понимаете, какие вопросы будете задавать данным? Если вопросы устоявшиеся - warehouse. Если постоянно новые - lake или гибрид.
- Есть ли в компании люди, которые будут активно поддерживать метаданные и документацию по данным? Без этого lake деградирует.
- Сколько источников данных у вас сейчас и как часто появляются новые? При высокой частоте изменений lake даёт меньше трения.
- Какова цена задержки ответа на аналитический вопрос? Warehouse обычно быстрее для предсказуемых запросов.
- Есть ли у вас задачи машинного обучения, которым нужны сырые данные в исходном виде? Это аргумент в пользу lake или как минимум гибридного подхода.
Правильного ответа, одинакового для всех, нет. Но правильный ответ для конкретной компании обычно становится очевидным после честных ответов на эти вопросы.