Достаточен ли MapReduce: где пакетная модель начинает тормозить бизнес
Некоторые бизнес-сценарии уже требуют другого темпа вычисления. Не потому что пакетная модель плоха, а потому что задержка стала слишком дорогой.
MapReduce решил реальную проблему. Когда Google описал эту модель в 2004 году, а Hadoop воплотил её в открытом коде, появился способ обрабатывать терабайты данных на кластере обычных машин. Это был не академический прорыв - это было практическое решение, которое изменило то, как компании думают о больших данных.
В 2013 году Hadoop стал стандартным элементом аналитической архитектуры у тех, кто работает с серьёзными объёмами. И в большинстве случаев он по-прежнему справляется.
Но у ряда компаний появляются задачи, которые пакетная модель обслуживает плохо - не потому что данных стало больше, а потому что задержка стала слишком дорогой.
Что именно означает "пакетная модель"
MapReduce и построенные на его основе системы работают так: данные накапливаются, запускается задача, через некоторое время - минуты или часы - получается результат. Этот результат отражает состояние мира на момент начала задачи - фундаментальный предел пакетной модели в сравнении с более быстрыми вычислениями и её потоковой альтернативой.
Для большинства аналитических задач это нормально. Отчёт за прошлый месяц, когортный анализ, расчёт скоринга - всё это спокойно ждёт пакетного цикла.
Задержка начинает стоить денег, когда решение нужно принять до следующего пакетного цикла.
Где задержка уже стоит денег
Несколько реальных классов задач, где это проявляется:
Обнаружение мошенничества. Если транзакция помечается как подозрительная через два часа после того, как деньги ушли - информация есть, но момент действия упущен. Задержка в несколько секунд меняет ситуацию кардинально.
Рекомендации в реальном времени. Если пользователь смотрит товар прямо сейчас, а рекомендательная система обновляется раз в ночь - она не знает о его текущем поведении. Релевантность падает именно в тот момент, когда пользователь активен.
Операционный мониторинг. Если аномалия в системе обнаруживается по результатам ночного отчёта, а не в момент возникновения - стоимость инцидента растёт пропорционально задержке.
Динамическое ценообразование. Если цена пересчитывается раз в сутки, а рыночная ситуация меняется быстрее - компания либо переплачивает, либо недополучает при каждом обновлении.
Что появилось в ответ
Рынок инструментов отреагировал. В 2011 году появился Storm от Twitter, предназначенный именно для потоковой обработки событий. LinkedIn выпустил Kafka как инфраструктуру для потоков данных с высокой пропускной способностью.
Это не замена MapReduce. Это другой инструмент для другого класса задач.
Потоковая обработка решает другую задачу: обработать событие сразу или с минимальной задержкой. Это сложнее технически - нет финального момента, когда все данные гарантированно присутствуют, сложнее обеспечить гарантии доставки и порядка. Но для задач, где задержка дороже сложности, - это правильная модель.
Как думать о выборе
Не нужно заменять Hadoop на потоковую систему, если задержка не является проблемой. Это был бы неоправданно сложный и дорогой выбор.
Правильный вопрос звучит иначе: есть ли у нас задачи, где решение нужно принять раньше, чем пакетный цикл его предоставит? И если есть - что именно стоит эта задержка в деньгах или упущенных возможностях?
Если ответ "ничего значимого" - пакетная модель справляется, менять ничего не нужно. Если ответ "несколько процентов конверсии" или "часть мошеннических транзакций пропускается" - стоит смотреть на гибридный подход.
Большинство зрелых аналитических архитектур в итоге сочетают оба слоя: пакетный для исторического анализа и потоковый для оперативных решений. Выбор не "или-или", а "для чего что".