Платформы для Больших Данных

В идеале платформа, полноценно решающая проблему Больших Данных, должна обеспечивать возможность работы с данными всех типов, представленных в произвольных форматах, а для этого она должна включать:

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

Сегодня пока нет таких полнофункциональных платформ, и под платформами для Больших Данных понимают самые обычные традиционные компьютерные платформы, адаптированные для работы с большими объемами данных.

Представление о платформе как отдельной сущности сложилось в середине 90-х годов одновременно с появлением «прикладного программного интерфейса» (Application Programming Interface, API), .NET и Java. На самом же деле какая-то платформа, пусть и в упрощенном виде, существовала всегда. Сначала это были коммутационные доски, на которых набирали программы проводами-перемычками, затем машинные коды, первые языки программирования и операционные системы. Важнейший шаг по направлению к платформам был сделан в 70-е годы, когда появились первые независимые от оборудования операционные системы, прежде всего Unix. В середине 90-х возникли платформы, независимые уже и от ОС, с этого момента стало возможным говорить об автономном развитии платформ. Сегодня разработка и эксплуатация ПО невозможны без развитой платформы — среды, в которой работает ПО и под которую оно создается. Обычно платформа предоставляет свои ресурсы в виде модулей, имеющих интерфейсы, или в виде каких-то сервисов. С появлением облаков и сервисов PaaS (Platform as a Service) представление о платформах существенно расширилось, и сегодня можно говорить о различных категориях облачных платформ, а среди них есть и ориентированные на работу с Большими Данными.

Большие Данные и сервисы

Большие Данные и облачные технологии — две взаимодополняющие сущности, развивающиеся параллельно; для обработки больших массивов данных требуются большие кластеры, состоящие из серверов, а глобальные облака в состоянии их предоставить. Вопрос в том — в какой форме? Что предпочесть: IaaS (Infrastructure as a Sevice) или PaaS? В первом случае провайдер (Amazon EC2, Rackspace Cloud, Google Compute Engine или RightScale) предоставляет все необходимые ресурсы: виртуальные машины, блочные или файловые системы хранения данных, защитные экраны, балансировщики нагрузок, IP-адреса, виртуальные локальные сети и необходимые пакеты ПО, а пользователь сам устанавливает на эти ресурсы свои операционные системы и приложения. Для универсализации доступа к этим ресурсам созданы такие средства, как OpenStack и Eucalyptus. Опора на IaaS дает широкое пространство для выбора поставщиков услуг, глобального или частного облака, поскольку использование ресурсов остается под полным контролем пользователя, но он же накладывает дополнительные обязательства, связанные с развертыванием ПО и управлением кластером.

Во втором случае провайдер (Amazon Elastic Beanstalk, Heroku, EngineYard, Mendix, Google App Engine и Microsoft Azure) предоставляет всю платформу полностью, включая все ее основные компоненты: операционную систему, языки программирования, среду выполнения, базы данных и Web-серверы. Степень автоматизации в части предоставления ресурсов варьируется в зависимости от избранного провайдера. Выбор PaaS освобождает от ряда служебных нагрузок, но ограничивает возможности тем функционалом, который в состоянии предоставить тот или иной провайдер, что может стать ограничением.

Создание платформ для поддержки Больших Данных BDAP (Big Data Application Platform) постепенно становится естественной частью бизнеса крупных провайдеров облачных услуг. Еще в 2009 году Amazon запустила сервисы Elastic Map Reduce, обеспечивающие работу с Hadoop, и, в дополнение к ним, сервисы Simple Queue Service, поддерживающие координацию распределенных вычислений с реляционными СУБД. Сервисы EMR программируются обычными для Hadoop способами на языках Pig, Hive или других, добавляя к ним сервисы хранения данных Amazon S3. Для доступа к EMR могут быть использованы стандартные для Amazon инструменты и графические интерфейсы других компаний. По затратам использование EMR выгоднее, чем EC2 с самостоятельной установкой Hadoop.

У компании Google подход иной — пользователь ничего не знает о виртуализации, а все, что ему доступно, — это API и сервисы, что в какой-то степени и удобнее, но действовать разработчик может только в жестких пределах. Сервис AppEngine предлагает функциональность родной для Google технологии MapReduce и возможности параллельной работы с данными. Его потенциал превосходит потребности аналитических задач и задач, связанных с машинным обучением. Для них достаточно аналитической базы данных BigQuery и инструмента для работы с заранее обученными моделями Prediction API, доступных посредством REST API.

Аналитическая база данных BigQuery позволяет работать в интерактивном режиме с объемом данных порядка 1 Тбайт, поддерживает SQL и по своим возможностям близка к Apache Hive, но работает быстрее. Данные могут быть непосредственно загружены в BigQuery или импортированы из системы Google Cloud Storage, что можно считать ограничением по сравнению с Amazon S3, куда можно просто прислать свой диск для импорта данных или обеспечить потоковую передачу. Тем, кто занимается машинным обучением, классификацией и генерацией рекомендаций, может быть полезен продукт Google, известный как Prediction API, созданный специально для работы с заранее обученными моделями (previously trained model). Несмотря на обещания, эти предложения Google пока находятся на начальной стадии, что можно сказать и о решении Microsoft Hadoop — оно еще не вышло на рынок.

Когда говорят и пишут о проблеме Больших Данных на корпоративном уровне, дискуссии часто сводятся к принятию или непринятию NoSQL, однако дело не в отрицании SQL, а, скорее, в стремлении создавать базы, лучше адаптированные к распределенным архитектурам, такие, которые могут эффективно работать с большими объемами данных без заметных потерь производительности и без роста затрат, пусть с какими-то отступлениями по части строгости. Но одними базами, даже самыми совершенными, всесторонне проблема Больших Данных не решается — нужны еще и некоторые конструкции (framework), упрощающие разработку прикладного ПО и освобождающие разработчика от необходимости обеспечивать такие качества, как безопасность, масштабируемость и мобильность. Эти решения берут реализацию данных качеств на себя, позволяя разработчику сосредоточиться на бизнес-составляющей приложения. Таким образом, можно определить предназначение платформ класса BDAP — это платформы, обеспечивающие распараллеливание обработки и поддерживающие новые архитектуры хранения данных и методы работы с ними.

Прообразы BDAP — хорошо известные платформы, такие как Java EE или Ruby on Rails, создававшиеся в расчете на централизованные СУБД и, как следствие, не соответствующие требованиям мира Big Data. Но других адекватных готовых решений пока нет, а имеющиеся, основанные на использовании Hadoop, еще слишком сложны — один из важнейших вопросов, связанных с Большими Данными, состоит в том, какой должна быть разумная модель разработки? Практически все, кто высказывается на эту тему, согласны с тем, что для большинства разработчиков прямая работа с Hadoop недоступна — требуется новая когорта программистов, способных понять то, каким образом можно разделить решаемую ими задачу на такие компоненты, которые бы сделали возможным использование архитектуры типа Hadoop. Если мы хотим, чтобы новые подходы работы с Большими Данными были приняты, то нужны альтернативные модели разработки, доступные широкому сообществу специалистов.

Создание новых платформ класса BDAP осложняется тем, что меняются общие представления о накоплении и хранении данных. Мы привыкли думать о данных как о некотором упорядоченном складе (data warehouse), но растущие объемы вызывают другое представление — об озерах или, точнее, водохранилищах данных (data lake). Склад предполагает распределение входных потоков и их разумное размещение, но если данные поступают в больших количествах и в реальном времени, такой возможности нет — их нужно просто каким-то образом собрать, а уж потом решать проблемы доступа. На складе хранятся в основном полезные и востребованные вещи, а в озеро сливается все, в том числе и то, что вообще никогда и никому не понадобится. В этом смысле метафора «озеро» более информативна, но для озер данных нужны адекватные технологии извлечения полезной составляющей. Среди них система Data Rush компании Pervasive, различные реализации систем обработки сложных событий (Complex Event Processing, CEP), поиска, средства data mining и text mining и др. Всего этого так много и все так быстро развивается, что сориентироваться в происходящем чрезвычайно сложно — это и есть задача BDAP.

Нужны такие платформы приложений, которые объединили бы в себе многообразие методов и средств для работы с огромными потоками данных и представили бы их в форме, доступной специалисту средней квалификации. Рынок готовых решений класса BDAP еще далек от зрелости, и сейчас можно говорить лишь о двух направлениях: одно ориентируется на Hadoop/MapReduce, другое — на In Memory Data Grid. Деление на два направления является совершенно естественным, поскольку эти направления дополняют друг друга. Оба преследуют своей целью адаптацию распределенных аппаратных ресурсов к работе с большими объемами данных; в какой-то мере их можно сравнить с двумя подходами к высокопроизводительным вычислениям, где есть кластерные суперкомпьютеры с распределенной памятью и многопроцессорные системы с общей памятью. Сходство между кластерами для высокопроизводительных вычислений (HPC) и кластерами Hadoop/MapReduce в том, что общую задачу необходимо каким-то образом разбить на фрагменты и обеспечить их выполнение в независимых друг от друга узлах, чтобы потом собрать все воедино. На компьютерах с общей памятью и на конфигурациях типа In Memory Data Grid проблемы разбиения и сборки нет.

Платформы Hadoop/MapReduce

Технология Hadoop/MapReduce распространяется как небольшими компаниями, так и грандами индустрии наподобие IBM и EMC, принята практически всеми компаниями, занятыми в этой сфере, и обладает рядом достоинств.

• Низкая стоимость. Hadoop — результат проекта Apache в открытых кодах, и его может бесплатно загрузить любой, к тому же он работает на простейших недорогих серверах.
• Быстродействие. Для работы с терабайтами требуются минуты, а с петабайтами — часы.
• Масштабируемость по ресурсам хранения. Если не хватает объема, достаточно нарастить дисковое пространства в узлах или увеличить число узлов в кластере.
• Масштабируемость по производительности. Производительность растет линейно в зависимости от мощности отдельного узла и числа узлов, при необходимости можно выбрать их любое сочетание.
• Толерантность к типам данных. Технологию можно применять со структурированными, квазиструктурированными и неструктурированными данными.
• Гибкость по отношению к языкам программирования. Hadoop в оригинале был написан на Java, но доступ к данным может осуществляться с использованием языка Apache Hive, созданного по мотивам SQL, для целей аналитики подходит Apache Pig, а для написания собственных аналитических инструментов можно использовать Java, C/C++, Ruby, Python, C#, QBASIC.

Вместе с тем у «Hadoop в чистом виде» есть свои слабые места.

• Сложность настройки. Без достаточной квалификации настроить систему чрезвычайно сложно, а найти специалиста по Hadoop еще сложнее.
• Трудность в управлении. Отсутствуют инструменты для управления с удобным интерфейсом.
• Невысокая надежность. В Hadoop имеются точки без резервирования, что вызывает потери данных при сбое.
• Низкая безопасность. Файлы не защищены и открыты для разрушения или хищения.
• Отсутствие оптимизации к оборудованию. Hadoop полностью не использует все аппаратные ресурсы.

На рынке имеются проекты с открытыми кодами, а также коммерческие продукты на их основе, компенсирующие перечисленные слабости Plain Hadoop, но ни один из них нельзя рассматривать как совершенную платформу BDAP, а некоторые еще пребывают на начальной стадии реализации.

Платформы с открытыми кодами

Проект Apache Ambari потенциально может стать основой для платформы BDAP с открытым кодом. Средствами Apache Ambari можно упростить выполнение следующих функций для Hadoop Cluster.

• Установка. Для этой цели разработана система подсказок, облегчающая процесс развертывания Hadoop, а сам процесс усовершенствован технологиями от компании Puppet Labs, известной в области автоматизации работы с ПО.
• Управление. Есть средства для запуска, остановки и переконфигурования всего кластера.
• Мониторинг. Имеются управляющие панели для отображения текущего состояния кластера и выдачи сообщений об аварийных ситуациях.

Одной из первых подобное решение предложила компания Hortonworks, специально выделенная из состава Yahoo! В комплект продуктов Hortonworks Data Platform помимо Ambari входят Hadoop MapReduce, HDFS, HBase, язык программирования Pig, хранилище данных Hive, средства управления хранением HCatalog и модуль управления Zookeeper.

Проект с открытым кодом Apache Mesos, начатый в 2009 году в университете Беркли, дополняет Ambari и служит для повышения эффектности использования аппаратных ресурсов кластера самыми разными способами, вплоть до выполнения нескольких заданий Hadoop на одном кластере. В основе проекта лежит эффективная изоляция распределяемых ресурсов. Mesos поддерживает не только Hadoop, но и такие технологии, как MPI, Hepertable и Spark. Инициация Mesos мотивирована не только стремлением повысить отдачу от оборудования, но и желанием создать общий интерфейс для нескольких интегрированных сред программирования (Apache Hama, Microsoft Dryad, Google Pregel и Caffeine), что позволит организациям использовать разные среды в соответствии с потребностями.

Zettaset

Свою платформу Zettaset Orchestrator на базе Hadoop предложила молодая компания Zettaset. Платформа поддерживает основные функции, ожидаемые от продукта этого типа, но Orchestrator упрощает работу администратора за счет предоставления ему интерфейса для наблюдения за кластером и выдачи отчетов о состоянии аппаратного и программного обеспечения, о текущей производительности и других параметрах. Администратор имеет возможность запускать необходимые сервисы, создавать резервные копии, изменять конфигурации и пр. Автоматизирован ряд критически важных функций, упрощена процедура загрузки больших файлов, а безопасность обеспечена поддержкой протокола сетевой аутентификации Kerberos. В результате процесс управления упрощается и исчезает потребность в высококвалифицированных экспертах.

Появление решений типа Zettaset Orchestrator позволяет создавать системы нового класса для работы с Большими Данными, сочетающие в себе преимущества открытого ПО с открытым подходом к проектированию аппаратного обеспечения. В 2011 году Facebook выступила с инициативой Open Compute Project, распространяющейся на все серверные компоненты и подсистемы от новой конструкции стоек до системных плат и коммутации. Одной из первых изделия, в которых воплощены принципы Open Compute, выпустила компания Hyve Solutions, производящая специализированные аналитические машины Series 8, способные конкурировать с изделиями куда более именитых производителей. Для этого она устанавливает на свои серверы ОС Red Hat Enerptise Linux и Apache Hadoop, объединяет в платформу средствами Zettaset Orchestrator и для поддержки приложений использует хранилище данных Apache Hive, язык программирования Pig, брокер к реляционным СУБД Sqoop и координатор сервисов Zookeeper. Минимальным квантом оборудования служит модуль 2U, состоящий из двух процессоров Intel 5690, 96 Гбайт оперативной памяти, 3,6 Тбайт памяти Fusion-io (новый тип распределенной памяти, занимающий промежуточное место между оперативной памятью и SSD, разработан одноименной компанией, где ведущим ученым работает Стив Возняк) и 5 Тбайт дисковой памяти. Эти модули объединяются коммутатором Arista и устанавливаются в шасси различной высоты по числу модулей. Таким образом, по принципу Лего собирается мощная аналитическая машина.

Platform Computing

Компания Platform Computing, недавно вошедшая в состав IBM, приобрела известность в качестве поставщика инструментов для управления кластерами. Ее продукт Platform MapReduce ориентирован на открытые коды и на Hadoop, а использование MapReduce в названии указывает на модель, реализованную в нем, а не на ее реализацию в Google. На рис. 1 показана общая архитектура Platform MapReduce, где средний уровень занимает собственно платформа, в свою очередь разделенная на три уровня. На рис. 2 представлены компоненты этой платформы. Перечень функций, выполняемых каждым компонентом, позволяет понять на этом примере содержательный смысл платформы Больших Данных.

Рис. 1. Архитектура Platform MapReduce

Рис. 2. Компоненты платформы Platform Computing

• Консоль управления, подсистема генерации отчетов. Первая производит активный мониторинг кластера в целом и его отдельных узлов, работы механизма MapReduce, оркестровки ресурсов и управления сессиями, а вторая служит для подготовки отчетов, которые могут быть в последующем проанализированы с целью улучшения качества работы и повышения качества обслуживания, оговоренного в SLA.
• API приложений и сервисов. Интерфейс интеграции и исполнения приложений, упрощающий работу программистов за счет избавления их от сложностей адаптации приложений к Hadoop.
• Оптимизация размещения данных. Разумная стратегия планирования баланса размещения данных по узлам Hadoop играет существенную роль в повышении производительности.
• Оркестровщик ресурсов. Оптимизация отображения физической кластерной инфраструктуры в логическую, которая должна в максимальной степени соответствовать фрагментации задачи в Hadoop. От того, насколько точно виртуальная серверная инфраструктура согласуется с разбиением задачи по условиям работы MapReduce, зависит эффективность работы системы.
• Менеджер сессий и сервисов, менеджер управления экземплярами. Обеспечение надежности системы.

Rock+

Платформа Rock+ (рис. 3), или StackIQ Enterprise Data, состоит из продуктов двух компаний — StackIQ и Hortonworks. Решение Hortonworks Data Platform включает в себя наиболее популярные компоненты Apache Hadoop: файловую систему Hadoop Distributed File System (HDFS), блок MapReduce, базу данных HBase и модуль управления Zookeeper. Продукты StackIQ Cluster Manager и StackIQ Data Manager служат для управления кластерами и данными на кластерах. Платформа Rock+ унаследовала многие черты от системы управления HPC-кластерами с тех времен, когда компания называлась Clustercorp. Платформа Rock+ содержит в себе все необходимое для установки Hadoop на «голое железо» кластера.

Рис. 3. Платформа Rock+

In-Memory Data Grid

Грид In-Memory Data Grid (IMDG) объединяет в один ресурс память всех компьютеров, входящих в серверные фермы (рис. 4). В основе IMDG лежит идея объектного хранения данных, поддерживаемая объектными языками программирования, в первую очередь Java и C#. Программное обеспеение IMDG хранит данные как наборы объектов, доступные либо по заданным идентификационным ключам либо посредством поиска по атрибутам объектов. Основная функция IMDG состоит в распределении данных по серверам, на которых размещается грид, и в балансировке нагрузки. IMDG позволяет приложениям более эффективно использовать потенциал серверных ферм.

Рис. 4. Пример реализации In-Memory Data Grid

Платформы на базе IMDG и Hadoop/MapReduce

Нередко все проблемы работы с Большими Данными сводят к Hadoop/MapReduce, упуская из виду, что Hadoop/MapReduce и сопровождающие технологии Pig, Hive, HBase и др. создавались без расчета на актуальные сегодня требования: реальное время и потоковые данные. Создателями Hadoop/MapReduce решалась актуальная на тот момент задача обеспечения работы с данными, хранящимися в распределенных файловых системах Google File System (GFS) и Hadoop Distributed File System (HDFS), а для этой цели вполне достаточно пакетного режима для запуска совместно выполняемых работ. Организация вычислений в пакетном режиме возникла на мэйнфреймах, каждое задание сопровождалось описанием на языке Job Control Language, однако и в современных условиях пакетный режим сохранился в тех случаях, когда всю вычислительную мощность системы приходится отдавать одному заданию и тогда его ставят в очередь на выполнение, — именно так дело обстоит с Hadoop/MapReduce. Но в пакетном режиме невозможно оперативно анализировать данные, вот почему уже сейчас раздаются голоса, предвещающие конец Hadoop/MapReduce, что глубоко ошибочно: компьютерные технологии не умирают, а преображаются — например, к Hadoop/MapReduce в качестве дополнения, минимизирующего негативное влияние batch-processing и приближающего к реальному времени, можно применить технологию IMDG.

Почему же именно на IMDG возлагаются надежды как на ускорителя аналитики? Согласно первоначальному замыслу, кэширующая, по существу, технология IMDG разрабатывалась для ускорения задач HPC, но, как выяснилось позже, она же с успехом может быть применена и для создания аналитических платформ, работающих с Большими Данными, выступая уже в совершенно ином качестве. Если в HPC технология IMDG позволяет агрегировать память узлов и тем самым приблизить возможности кластеров с распределенной памятью к системам с общей памятью, то в случае платформ для Больших Данных IMDG помогает создавать аналитические системы, работающие с данными в режиме реального времени. Для применения IMDG есть два пути, поскольку все множество задач, связанных с Большими Данными, можно разделить на два подмножества. В одно попадают задачи, в которых требуется доступ к гигантским объемам данных, распределенных на тысячах серверов, и время здесь не столь критично. В другое относят задачи, для которых важна именно оперативность работы, но с меньшими объемами данных — это аналитика в реальном времени. Вот почему первый путь предполагает адаптацию Hadoop/MapReduce к требованиям оперативной аналитики, что возможно, поскольку средства IMDG помогают ускорить работу систем, построенных на принципах Hadoop/MapReduce, за счет кэширования данных из дисков в оперативной памяти. Это далеко не единственный метод ускорения, еще есть такие подходы, как Continuous Map/Reduce Micro-batch in Map/Reduce.

Рис. 5. Выполнение Map/Reduce на архитектуре IMDG

На рис. 5 дана иллюстрация идеи замены серверной фермы, на которой работает Hadoop/MapReduce, — дисковое пространство просто заменяется пространством оперативной памяти, однако далеко не просто воплотить эту идею на практике. Одна из наиболее удачных реализаций IMDG (рис. 6) принадлежит израильской компании GigaSpaces. Оперативная память отдельных серверов объединяется в общее пространство для хранения данных, доступ к которым обеспечивается средствами различных API. В результате получается сочетание быстрых операций чтения и записи, характерных для оперативной памяти, с надежностью, свойственной кластерным системам.

Рис. 6. Варианты топологий стека GigaSpaces

Преимущества решения GigaSpaces IMDG:

• необходимая для работы в реальном времени низкая задержка, поскольку все данные содержатся в оперативной памяти;
• эластичность и масштабируемость — кластер легко и просто может быть уменьшен или увеличен;
• уменьшение нагрузки на серверы СУБД — количество обращений заметно сокращается;
• высокая готовность — по желанию можно выбрать различные схемы резервирования.

Решение от GigaSpaces может стать основой для создания высокопроизводительных и масштабируемых систем с архитектурой Space-Based Architecture. Для ускорения аналитики могут применяться и более традиционные продукты, не ориентированные на Hadoop/MapReduce, но способные работать с Большими Данными, используя IMDG. В первую очередь это поддерживающие Java системы VMware Gemfire, Oracle Coherence, Hazelcast и Gigaspaces XAP Elastic Caching Edition, а также cистемы .Net Alachisoft NCache и Scaleout StateServer, к которым по своим возможностям приближаются IBM eXtreme Scale, Terracotta Enterprise Suit и Jboss Infinispan.