Hadoop на трёх виртуалках: честные впечатления

Клиент занимается промышленным оборудованием - несколько производственных площадок, на каждой куча устройств пишет логи: температура, давление, обороты, статусы. За три года это превратилось в весомый объём данных, который лежал в SQL Server 2008 и всё хуже себя чувствовал при аналитических запросах.

«Хотим смотреть корреляции отказов за три года по всем площадкам» - сказал клиент. Попробовали. SQL Server думал двенадцать минут и отдавал результат, который у аналитика к тому времени уже вызывал сомнения в актуальности. Подняли индексы где могли, разбили таблицы на партиции - стало терпимее, но ненамного. База разрослась до размера, при котором операционные запросы начали мешать аналитическим даже при репликации.

Hadoop обсуждают активно, на конференциях появились доклады про корпоративное применение. Решили посмотреть своими глазами - на тестовом стенде, без риска для боевых данных.

Как устроен стенд

Три виртуалки на ESXi: одна NameNode, две DataNode. По 4 ГБ RAM каждая, по два виртуальных диска. Hadoop 1.2.1 - последняя стабильная версия ветки 1.x, вторую (YARN) решили отложить: изучать две архитектуры одновременно смысла нет.

Данные - выгрузка части логов за один год, примерно 80 ГБ в CSV. Не весь объём, но репрезентативная часть для теста.

Настройка заняла день. Основные точки трения:

• Java везде. Hadoop написан на Java, это очевидно, но надо привыкнуть что настройка - это XML-файлы с Java-специфичными именами свойств. core-site.xml, hdfs-site.xml, mapred-site.xml - три файла только для базовой конфигурации кластера.
• SSH без паролей между нодами. NameNode должна ходить на DataNode по SSH для управления. Не сложно настроить, но документация это упоминает вскользь, и час потеряли именно здесь.
• HDFS - не POSIX. Файловая система распределённая, данные загружаются через hadoop fs -put, работать с ними привычными утилитами не выйдет. Психологически сдвиг небольшой, но реальный.

Что мы гоняли

Первый тест - простой: COUNT и GROUP BY по типу события за весь год. На SQL Server этот запрос шёл около минуты. На Hadoop через Hive (он превращает SQL-подобные запросы в MapReduce-задачи) - три с половиной минуты. Разочарование.

Но дальше интереснее. Запрос с несколькими JOIN-ами и агрегацией по площадкам, который в SQL Server уходил в никуда на 8+ минут - Hive посчитал за пять с половиной. Разница не в разы, но на этих объёмах - уже показательно.

Второй тест - загрузка данных. CSV в HDFS кладётся быстро, схема у Hive определяется поверх уже лежащего файла. Это приятная деталь: не нужно создавать схему и потом грузить, можно сначала положить данные и потом разобраться с типами. Для разведочного анализа очень удобно.

Честные минусы

Latency плохая на малых запросах. MapReduce запускает Java-процессы под каждую задачу, и накладные расходы ощутимы. Запрос, который SQL Server вернул бы за секунду - Hive считает 30-40 секунд просто на инициализацию. Для интерактивной работы это больно.

Три виртуалки - не показатель. Мы отдаём себе отчёт, что тестируем не то, что предполагает архитектура Hadoop. Он проектировался на десятки и сотни физических нод с локальным хранилищем. Наш стенд демонстрирует концепцию, но не реальную производительность.

Hive не SQL. Синтаксис похож, однако отличий достаточно: не все подзапросы поддерживаются, оконные функции только в свежих версиях, некоторые типовые конструкции не работают или работают иначе. Аналитику придётся переучиваться.

Операционная сложность. Мониторинг, репликация метаданных NameNode, HA для неё - всё это нужно думать отдельно. В SQL Server это коробочные функции. Здесь - ручная сборка.

Что из этого следует

Для клиентского сценария - исторический анализ больших объёмов без онлайн-транзакций - направление выглядит рабочим. Но не как замена SQL Server, а как отдельный слой для аналитики. Оперативные данные остаются в реляционной базе, в Hadoop идёт то, что уже «остыло» и нужно считать пачками.

Это типовой паттерн, который сейчас обсуждают под названием lambda-архитектура: разделить горячий и холодный пути обработки. Для промышленных журналов звучит логично.

Конкретное решение для этого клиента мы ещё не приняли - тест продолжается, смотрим на Hive 0.10 с оконными функциями и думаем про схему данных. Подробнее о том, как мы строим аналитические хранилища в целом - в описании нашего направления по DWH и BI.

Вывод на сейчас: Hadoop не волшебная кнопка, но для определённого класса задач - реальная альтернатива, которую имеет смысл рассматривать. Главное не путать хайп вокруг Big Data с реальными потребностями конкретного клиента.