Когда для Apache Hadoop и Spark обеспечена хорошая аппаратная поддержка, аналитики имеют возможность эффективно исследовать глубинные закономерности данных, предлагать ценные управленческие решения и решать тактические задачи бизнес-планирования. Однако какой должна быть аппаратная поддержка, чтобы ее можно было назвать «хорошей»? Поиск ответа начинают с вопроса, где лучше размещать систему — в облаке или на базе собственного ЦОДа? Генеральный директор компании Altiscale Рами Стата проанализировал на ресурсе DataInformed причины, которые следует принимать во внимание при выборе.

Сразу следует оговориться: Стата старался убедить читателей в приоритетном выборе именно облачного решения взамен корпоративного ЦОДа. Его главный аргумент: компании должны заниматься исследованием больших данных, а не инфраструктурой. Этот подход более характерен для массового заказчика, для которого Стата искал наиболее быстрый способ выхода на рынок BI.

Есть ли смысл самостоятельно развертывать и управлять ИТ-инфраструктурой для Spark и Hadoop?

Если компания собирается разворачивать Spark и Hadoop в собственном ЦОДе, то ей придется вложить для этого немало денег. Они пойдут в том числе на оплату консультационных услуг, подбор оборудования и выбор поставщика.

Как показывает практика, вариант собственного ЦОДа отнимает также немало времени. Развертывание узлового кластера, прокладка сети, настройка системного ПО — все это потребует новых знаний и времени.

О вот инфраструктура готова. Можно начинать работать? «Рано делать выдох, — считает Стата. — Это только начало „борьбы“ с отстроенной инфраструктурой». После перехода от пилотных проектов к производственным заданиям появляется новая проблема: в компаниях начинают понимать, что такое реальная нагрузка и как она реализуется на существующей инфраструктуре. В результате часто приходится переходить на новую аппаратную конфигурацию.

Операционная поддержка проектов больших данных

Если в компаниях привыкли вкладывать крупные средства в приобретение новых технологий и затем постепенно внедрять их в повседневную практику, то переход на технологии больших данных станет для них несколько новым явлением. Им придется столкнуться с проблемой нарастания масштабов собираемых данных. Чтобы решить ее, потребуется повышать квалификацию сотрудников или искать их на рынке.

Выбор облачного варианта Spark+Hadoop позволяет избежать трудностей внедрения в корпоративном ЦОДе. В этом случае управление изменениями, выбор направлений для развития, обеспечение надежной, высокопроизводительной работы — это задача облачного вендора.

«Однако не все облачные провайдеры одинаково подходят, — считает Стата. — Среди них есть „умельцы, сделавшие сами себя“. Часто они предлагают только Spark и Hadoop на облачной инфраструктуре. Поддержку всех остальных функций — мониторинг заданий, тонкая настройка, обновление ПО — они возлагают на клиента. Но именно эти операции требуют наиболее кропотливого внимания».

При отсутствии опыта Стата советует выбрать вариант облачной услуги Spark-as-a-Service, которая предусматривает полный цикл управления. Пользователь получает готовую среду для работы с большими данными, сопровождение операций, техническую поддержку, консультативные услуги. Этот выбор освобождает от необходимости вникать в особенности внутренней структуры Spark+Hadoop, перекладывая эту задачу на плечи облачного провайдера.

Поддержка экосистемы Spark и Hadoop

Нынешнее развитие технологий больших данных и экосистемы Hadoop и Spark идет в направлении создания новых механизмов для анализа данных, размещаемых в оперативной памяти, и создания высокопроизводительного механизма SQL for Hadoop. Одновременно на рынке появляется много новых инструментов, связанных с планированием вычислительной нагрузки, управления потоками и хранения данных. Эти новшества требует постоянного обновления Hadoop, Spark, Hive и Pig, причем это необходимо делать с высокой периодичностью, как правило, несколько раз в год. Наиболее частые изменения сейчас происходят на платформе Spark.

При выборе облачного размещения работы по такой поддержке берет на себя провайдер. Это гарантирует клиенту получение наиболее полной версии окружения со всеми установленными обновлениями и инновациями. Выбор собственного ЦОДа в качестве варианта для размещения систем не дает такой гарантии.

Большинство облачных решений поддерживают разработки сторонних компаний, такие как система машинного обучения компании H2O, платформа совместных аналитических расчетов компании Alation, BI-решение компании AtScale и другие.

Помимо этого, в последнее время наблюдается всплеск разработок, выстраиваемых поверх Hadoop. Эти решения также требуют поддержки при установке, эксплуатации и обслуживании, которую бывает затруднительно получить в рамках корпоративного ЦОДа. Облачные провайдеры берут решение этих проблем на себя.

Скачкообразный рост нагрузки, масштабирование ресурсов, «непредсказуемость» Spark при работе с кластерами...

По мере накопления данных и появления новых приложений кластер Hadoop начинает разрастаться в размерах. У вычислительной нагрузки появляются скачкообразные всплески. Они вызывают избыточное выделение аппаратных ресурсов для поддержки обработки потоков данных в устойчивом состоянии при нехватке ресурсов. При ведении интенсивной параллельной обработки возникают скачки производительности у системы в целом.

Если обработка больших данных ведется в полноценном облаке, то функция поддержки в условиях неоднородной нагрузки предусмотрена изначально. Эти системы справляются и с массированным наплывом данных в условиях, когда поставлены жесткие ограничения на время максимальной задержки при получении результата. Они также адаптируются под динамически собираемые данные, поступление которых часто сопровождается скачкообразными всплесками и поэтому требует быстрого масштабирования привлекаемых ресурсов.

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

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

Добавление Spark усложняет процесс еще более. Spark может отнимать ресурсы при работе со сложными заданиями.

Полноценная защита прикладной системы

Для многих выбор между размещением в облаке или собственным ЦОДом лежит через ответ на вопрос о безопасности. Принято считать, что более надежную защиту можно получить при размещении на собственной ИТ-инфраструктуре. Однако есть ряд аргументов, когда уровень безопасности, предоставляемый облачным вендором, не уступает «домашнему» решению.

Внимание к мелочам. Строительство системы безопасности для корпоративного ЦОДа часто выстроено на универсальном подходе, ориентированном на защиту от широкого набора угроз.

Облачные провайдеры чаще всего реализуют специализированный вариант защиты, где все детали прорабатываются индивидуально. При этом облачные вендоры обычно вкладывают более крупные финансовые средства на развитие системы безопасности, потому что с их точки зрения эта функция является конкурентным преимуществом.

Современные технологии. Комплектация корпоративного ЦОДа часто содержит оборудование нескольких поколений. Часть ранее созданной инфраструктуры может оказаться недостаточно защищенной. Причина кроется в том, что разработка ее систем безопасности велась до появления новейших угроз. Поэтому при «зоопарке» технологий вероятность возникновения брешей для внедрения эксплойтов выше.

Облачные системы защиты, как правило, оснащены с учетом всех последних изменений. В распоряжении провайдеров находятся системы, практически не отягощенные устаревшими технологиями. Это облегчает их контроль с точки зрения безопасности.

Экспертиза мирового уровня. Одна из проблем при строительстве собственного ЦОДа — привлечение высококлассных специалистов в области безопасности. В настоящее время на рынке наблюдается их дефицит. Поскольку облачные провайдеры готовы тратить на безопасность более крупные средства, чем рядовые компании, они имеют больше шансов привлечь экспертов мирового класса.

Работа с данными

Задания для обработки больших данных на Spark и Hadoop, создаваемые аналитиками компаний, сильно отличаются от типовых задач, которые решаются в производственных целях. Аналитик пишет специальный программный код, который будет исполняться один или два раза за жизненный цикл. Запуск таких программ и их отладка требуют много времени, а также привлечения системных инженеров службы эксплуатации ЦОДа для учета особенностей реального размещения данных в кластере. По мере роста числа заданий, работающих в корпоративном ЦОДе, получать такие консультации будет все сложней и сложней.

Некоторые исследователи пытаются решить эту проблему сами. Они начинают изучать незнакомые инструменты командной строки и API, пытаясь самостоятельно решить проблемы при работе с Hadoop и Spark. Другие выстраиваются в очередь к инженерам по данным, что ведет к задержкам в работе над проектами.

При корпоративном ЦОДе для исследователей часто выстраивают специальные кластеры Hadoop. Их поддержка ведется отдельно от основной работы ИТ-отдела.

Трудности, возникающие при организации таких BI-проектов, ведут к тому, что «живые» данные часто заменяют на заранее подготовленные выборки. Результаты получаются менее точными. В облачной среде такие задачи решаются проще.