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