m@ksim.pro
К списку статей
Данные 3 мин чтения

Spark, Hadoop или MPP: выбирать нужно тип нагрузки, а не бренд

Под разные задачи нужны разные режимы вычисления и хранения. Ошибка в выборе платформы стоит дороже, чем кажется на старте.

В разговорах про большие данные часто звучит один и тот же вопрос: "А вы на Hadoop или нет?" Или: "Нам нужен Hadoop, мы слышали, что это для больших данных."

Это примерно так же, как спросить у врача: "Нам нужны антибиотики, мы слышали, что они лечат." Возможно. Зависит от диагноза.

Hadoop, MPP-базы данных и in-memory движки вроде Spark - это разные инструменты с разными характеристиками. Правильный выбор определяется нагрузкой, а не тем, что написано в статье про лидеров рынка. Вопрос о том, где оправдан кластер, а где достаточно нормального DWH, - отправная точка; этот материал развивает тот аргумент с появлением Spark и более детальной классификацией нагрузок.

Три класса нагрузки, три режима работы

Прежде чем говорить об инструментах, стоит классифицировать задачу.

Пакетная обработка больших объёмов - задачи, где нужно обработать терабайты или петабайты данных, скорость ответа измеряется часами, но важна надёжность и масштабируемость. Исторические расчёты, переработка сырых логов, трансформация данных для хранилищ. Здесь Hadoop MapReduce был разработан именно для этого - дешёвое горизонтальное масштабирование на commodity-железе с отказоустойчивостью через репликацию.

Интерактивная аналитика - запросы, на которые аналитик ждёт ответа секунды или минуты. Срезы по большим таблицам, агрегации, ad-hoc анализ. Здесь MPP-архитектура (Massively Parallel Processing) - например, Teradata, Greenplum, Vertica - работает принципиально иначе: данные хранятся колоночно, запросы распараллеливаются по узлам. Скорость интерактивного ответа несравнимо выше, чем у MapReduce - следствие колоночного хранения и нового темпа аналитики, который оно обеспечивает.

Итеративные вычисления - машинное обучение, графовые алгоритмы, задачи, где одни и те же данные нужно читать многократно в рамках одного вычисления. MapReduce здесь катастрофически неэффективен: каждая итерация пишет результаты на диск и читает с диска. Spark решает это иначе - держа промежуточные результаты в памяти. На задачах машинного обучения разница в скорости может быть на порядок.

Почему одна платформа не закрывает все задачи

Попытка использовать один инструмент для всех трёх классов нагрузки - дорогая ошибка. Не потому что инструмент плохой, а потому что он не проектировался для всего одновременно.

Hadoop с MapReduce - медленный для интерактивной аналитики. Аналитик, ждущий ответа двадцать минут вместо двадцати секунд, делает меньше исследований. Это прямые потери производительности.

MPP-база - отличная для аналитических запросов, но дорогая для хранения сырых неструктурированных логов в большом объёме. Хранить терабайты сырых данных в Teradata - это либо очень дорого, либо вынуждает делать агрессивную фильтрацию до загрузки, теряя детальность.

Обе платформы неэффективны для итеративных ML-задач по причинам, описанным выше.

Реальные архитектуры зрелых data-платформ используют разные инструменты для разных слоёв: дешёвое хранилище сырых данных, MPP для аналитики, специализированные вычисления для ML. Разделение ODS, витрин и DWH - структурное выражение этого принципа.

Что спросить перед выбором платформы

Правильное обсуждение начинается не с "какую платформу выбрать", а с описания нагрузки. Несколько вопросов, которые помогают:

  1. Каков объём данных сейчас и какова динамика роста? Терабайты или сотни гигабайт - разные решения.
  2. Какой допустимый latency для аналитических запросов? Секунды, минуты или часы - принципиально разные требования.
  3. Что за задачи - разовые batch-расчёты, регулярная аналитика или итеративные алгоритмы?
  4. Каков бюджет на железо и лицензии? Некоторые MPP-решения стоят столько, что оправданы только при определённом масштабе.
  5. Есть ли в команде экспертиза по конкретной платформе? Стоимость обучения и найма - часть стоимости решения.

Один практический ориентир

Если компания только начинает строить аналитическую инфраструктуру и объёмы данных не превышают нескольких терабайт - вероятно, ни Hadoop, ни дорогой MPP не нужны прямо сейчас. Правильно выбранная реляционная база с продуманной схемой закрывает большинство аналитических задач малого и среднего бизнеса.

Hadoop и специализированные платформы имеют смысл, когда объём данных или требования к скорости/гибкости действительно выталкивают за пределы стандартных решений. Не раньше.

Выбор платформы "потому что у конкурентов" или "потому что все говорят" - это не архитектурное решение. Это следование моде за счёт бюджета.

К списку статей
Контакт

Если эта статья отозвалась - напишите. Я отвечаю лично.

Telegram