Ни одно корпоративное ИТ-решение не идеально; для каждого достоинства, которым обладает продукт, обычно существует тот или иной компромисс. Хотя в целом ряде отраслей средства пакетной аналитики Hadoop оказались ценным ресурсом для бизнеса, стали налицо и их ограничения. Вначале эта сторона дела может показаться мелочью, но из-за нее скоро могут появиться проблемы. Так, ряд самых распространенных операционных трудностей при использовании Hadoop могут создавать серьезные и затратные помехи для бизнеса. Син Сачтер, сооснователь и CEO компании Pepperdata, создающей ПО оптимизации кластеров в реальном времени, как человек, управлявший первым коммерческим опытом внедрения Hadoop во времена своей работы в команде Yahoo, прекрасно знаком с технологическими недостатками Hadoop, влияющими на бизнес. Для оптимизации использования Hadoop компании должны быть заранее хорошо знакомы с его наиболее распространенными изъянами, многие из которых влияют на надежность, предсказуемость и обозримость. Ниже на базе информации от Сачтера мы исследуем главные причины, почему Hadoop может не давать ожидаемой отдачи.
Задания заканчиваются отказом или сильно тормозят
Развертывание Hadoop часто начинается в среде «песочницы». Со временем рабочие нагрузки возрастают, и на кластер все больше ложатся функции поддержки продуктивных приложений, управляемой соглашениями об уровне услуг. Сиюминутные запросы и другие низкоприоритетные задания конкурируют за системные ресурсы с бизнес-критическими приложениями, и в результате высокоприоритетные задания выполняются с неприемлемыми задержками.
Невозможность отслеживать производительность кластера в реальном времени
Диагностические средства Hadoop статичны, и их лог-файлы дают информацию о выполнении заданий на кластере лишь по их завершении. Hadoop не позволяет отслеживать на достаточно гранулярном уровне, что происходит, когда выполняется много заданий. В итоге трудно и зачастую невозможно предпринимать коррективные действия, предотвращающие операционные проблемы до момента их возникновения.
Недостаток макроуровневой видимости и контроля над кластером
Различные диагностические средства Hadoop предоставляют возможность анализировать статистику индивидуальных заданий и исследовать активность отдельных узлов кластера. Кроме того, разработчики могут подстраивать свой код под оптимальную производительность индивидуальных заданий. Чего однако нет, так это возможности отслеживать, анализировать и контролировать, что происходит со всеми пользователями, заданиями и задачами в масштабе целого кластера, включая использование каждого аппаратного ресурса.
Недостаточная возможность устанавливать и обеспечивать приоритеты заданий
Хотя планировщики заданий и диспетчеры ресурсов предоставляют базовые возможности, например, организацию последовательности заданий, планирование по времени и событиям и выделение узлов, они недостаточны для обеспечения максимально эффективного использования ресурсов кластера при выполнении заданий.
Недоиспользуемые и растрачиваемые ресурсы
Организации обычно подбирают размер своих кластеров под максимальные пиковые нагрузки. Редко задействуемые ресурсы зачастую стоят больших денег и реально не нужны.
Недостаточная возможность контролировать выделение ресурсов кластера в реальном времени
Когда исполняемые на кластере нестандартные задания, неэффективные или ресурсозатратные запросы или другие процессы неблагоприятно влияют на производительность, операторы Hadoop зачастую не успевают предпринять нужные корректирующие меры для предотвращения срыва соглашений об уровне услуг.
Отсутствие гранулярного обзора использования ресурсов кластера
Когда задания завершаются отказом или с большой задержкой, операторам и администраторам Hadoop трудно диагностировать проблемы производительности. Hadoop не дает способов мониторинга и анализа производительности кластера с достаточным контекстом и детальностью. Например, невозможно изолировать проблемы по пользователю, заданию или задаче и идентифицировать узкие места, связанные с сетью, ОЗУ или диском.
Невозможность предсказать, когда кластер исчерпает возможности
Дополнительные и более многообразные задания, расширяющиеся объемы и разнообразие типов данных, усложнение запросов и многие другие факторы со временем все больше нагружают ресурсы кластера. И зачастую нужду в добавочных кластерных ресурсах осознают лишь после аварии (скажем, перестает работать сайт для клиентов или не создается критически важный отчет). Итогом могут стать разочарование клиентов, упущенные бизнес-возможности, незапланированные нужды в капитальных затратах и т. д.
Конкуренция HBase и MapReduce
На общую производительность может сильно влиять конкуренция за системные ресурсы заданий HBase и MapReduce. Невозможность оптимизировать использование ресурсов, когда одновременно задействуются разные типы рабочих нагрузок, заставляет многие организации идти на затраты и развертывать отдельные выделенные кластеры.
Отсутствие важных визуальных панелей
Интерактивное исследование и быстрый диагноз проблем производительности в кластере остаются нерешенными вопросами. Статические отчеты и подробные лог-файлы, формируемые планировщиками и диспетчерами ресурсов, не годятся для простого и быстрого диагноза проблем. На просеивание огромных массивов данных в поиске причин неполадок могут уходить часы, а то и дни. Операторам Hadoop требуется возможность быстро визуализировать, анализировать и определять причины проблем производительности и находить возможности оптимизации использования ресурсов.
