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