Второе рождение гридов

В прогнозе на 2013 год аналитики Gartner включили вычисления в памяти (In-Memory Computing, IMC) в десятку наиболее «горячих» технологий, аргументируя свой выбор тем, что распространение IMC позволит заметно усовершенствовать работу с Большими Данными в реальном времени и даст возможность обрабатывать множество одновременно происходящих событий. Эти аргументы в пользу преимуществ работы в памяти не новость, но тем не менее до сих пор широкое распространение решений IMC сдерживала дороговизна памяти DRAM. Однако ситуация меняется, память становится доступнее, что делает IMC привлекательнее, а получающие все более широкое распространение флэш-накопители пока не могут составить конкуренцию DRAM по быстродействию. В 2013 году бизнес, так или иначе связанный с IMC, оценивается в 2 млрд долл., а далее прогнозируется среднегодовой рост около 40%.

Во всей полноте разнообразие подходов к IMC можно, например, представить в виде стека (рис. 1), но здесь мы ограничимся одной, возможно наиболее перспективной и наиболее новой из областей IMC — гридами данных в памяти (In-Memory Data Grid, IMDG) и вычислительными гридами в памяти (In-Memory Compute Grid, IMCG), а также их связью между собой и с СУБД в памяти (In-Memory Database, IMDB). Следует отметить, что во многих случаях сложно провести грань между различными ипостасями гридов в памяти, то есть определить, является ли данный грид вычислительным или гридом данных. Более того, часто говорят вообще о полной интеграции этих двух типов гридов.

Рис. 1. In-Memory Computing — от приложений до оборудования

Гриды данных

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

Гриды появились в восьмидесятые годы, когда казалось, что они смогут решить насущную на тот момент проблему использования ресурсов временно простаивающих компьютеров, но постепенно актуальность этой задачи сошла на нет, а само ее решение оказалось намного сложнее, чем предполагалось. В итоге кластеры потеснили гриды. Нынешняя реинкарнация гридов объясняется органической способностью их архитектуры удовлетворить требованию «трех V» для средств работы с Большими Данными: velocity — высокая скорость работы в памяти, variability — способность хранить в гридах самые разнообразные данные, volumes — объемы хранения данных в гридах теоретически бесконечны. IMDG оказались подходящим средством для хранения Больших Данных, причем удешевление памяти можно назвать необходимым условием появления IMDG, а к числу достаточных можно отнести массовое распространение 64-разрядной адресации и многоядерной процессорной архитектуры. Движение в сторону IMDG началось с появления кэшей данных в памяти, которые постепенно эволюционировали в полноценные гриды памяти. Способность непрерывно анализировать большие объемы данных, выделяя скрытые образы и тенденции, позволяет создавать системы, приближенные к живым организмам, и серьезная роль здесь принадлежит IMDG, способным работать с данными на скорости, измеряемой терабайтами в секунду.

In Memory Data Grid — это не реляционная СУБД и даже не СУБД, резидентная в памяти (IMDB), но и не СУБД типа NoSQL. Это готовый к использованию продукт, обладающий следующими качествами:

• модель данных построена по принципу «ничего общего» (shared nothing) и предполагает распределение данных между множеством физически разнесенных серверов;
• модель данных может быть объектной или с хранением по ключам (key-value);
• все серверы равнозначны, а все данные хранятся в их оперативной памяти;
• для изменения размеров оперативной памяти серверы могут подключаться или отключаться без нарушения работы инфраструктуры грида;
• поддерживаются приложения на .NET или Java;
• конструкция грида является отказоустойчивой с возможностью автоматического обнаружения вышедших из строя серверов.

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

С программной точки зрения IMDG можно рассматривать как распределенное хранилище объектов с интерфейсом, похожим на интерфейс с согласованной неблокирующей структурой данных (Concurrent HashMap) в Java. В хранилище содержатся объекты с ключами, причем объекты могут быть любыми, а не только массивами байтов или строками, что дает гибкость — можно хранить точно те объекты, которые требует бизнес-логика. Способность работы с объектами отличает IMDG от IMDB, от СУБД NoSQL и NewSQL, а IMDG вообще отличает возможность распределения по множеству серверов. По существу, IMDG можно рассматривать как карты хэша, при котором каждый ключ кэшируется на определенном узле, и чем больше узлов, тем больше размер кэша. Задача состоит в том, чтобы разместить данные по узлам таким образом, чтобы локализовать данные — исключить в процессе обработки обмен данными между узлами. В идеале IMDG вообще исключает миграцию данных и обладает стабильной топологией. По надежности хранения IMDG не уступают реляционным базам: поддерживаются требования ACID (Atomicy — «атомарность», Consistency — «согласованность», Isolation — «изолированность», Durability — долговечность) и, в отличие от NoSQL, данные всегда непротиворечивы.

Вычислительные гриды

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

Функциональность IMCG можно разделить на  следующие  группы.

• Внедрение и контроль использования (Distributed Deployment & Provisioning). Неудобство и большие трудозатраты при выполнении этих действий всегда было слабой стороной гридов, что затрудняло их использование, а иногда делало это невозможным. Со времен первых систем гридов (Globus, Grid Engine, DataSynapse, Platform Computing) и до Hadoop в большинстве проектов внедрение и внесение серьезных изменений были связаны с большим объемом ручной работы по перестройке библиотек и повторному запуску всех сервисов. Распределенность архитектуры IMCG усиливает эту проблему, поэтому соответствующие технологии, например GridGain, включают средства, снижающие трудозатраты.
• Распределенное управление ресурсами (Distributed Resources Management). Сюда входит управление физическими устройствами, виртуальными машинами и операционными системами. В IMCG одной из важнейших функций является автоматическое поддержание топологии и обнаружение изменений. Согласованность топологии необходима для того, чтобы все узлы «видели» все изменения (выход из строя узлов, подключение новых) единообразно.
• Распределенные модели исполнения (Distributed Execution Models). Эти модели и превращают IMCG в вычислительную инфраструктуру. Таких моделей может быть несколько, и наиболее распространенная относится к классу «разветвление с объединением» (fork-join type) или MapReduce — разделение задачи на множество подзадач по какому-либо признаку, а затем их объединение в виде итогового результата. Наиболее популярна реализация MapReduce, известная как Hadoop, полностью ориентированная на работу с дисками, а MapReduce в реализации GridGain делает примерно то же самое, но в оперативной памяти. В моделях исполнения поддерживаются архитектуры с массовым параллелизмом (Massively Parallel Processing, MPP) и удаленный вызов процедур (Remote Procedure Call, RPC), а также распределенные вычисления с обменом сообщениями, потоковые вычисления и обработка сложных событий.

Общий список продуктов, прямо или условно попадающих в категорию IMDG/IMCG, насчитывает около дюжины названий: VMware Gemfire, Oracle Coherence, Alachisoft Ncache, Gigaspaces XAP Elastic Caching Edition, Hazelcast, Scaleout StateServer, IBM WebSphere eXtreme Scale, Terracotta Enterprise Suite, JBoss Infinispan и несколько продуктов GridGain. В числе наиболее успешных игроков на поле IMDM называют SAP, Oracle, IBM, Altibase, Tableau, Qliktech и Software AG (после приобретения Terracotta). В сегменте IMDG/IMCG преуспели молодые компании — например, ScaleOut Software, GigaSpaces и GridGain, основанная в 2007 году выпускником Балтийского государственного технического университета («Военмех») Никитой Ивановым.

Решение от ScaleOut

На рис. 2 представлена идеальная схема того, как в версии ScaleOut должна работать аналитическая система на базе IMDG.

Рис. 2. Данные на потоке в IMDG

Грид стоит «на потоке» (in-bound) быстроизменяющихся оперативных данных и выделяет те или иные существенные ситуации сразу при их возникновении. Это может быть, например, проверка платежных операций непосредственно по ходу их исполнения или любое другое приложение, где требуется аналитика, синхронная с потоком данных. Если такая система работает, то можно почти мгновенно обнаруживать критически важные события и предпринимать превентивные меры. Традиционная аналитика Больших Данных на это пока не способна и рассчитывает на сохранение данных в распределенной файловой системе и затем на их обработку в пакетном режиме. Даже переход на твердотельные накопители позволит уменьшить время выполнения пакета заданий, но реальное время все равно останется недостижимым. Решением может быть аналитическая машина на базе IMDG, превращающая простое распределенное по узлам кластера хранилище данных в параллельную платформу анализа данных в реальном времени. Задача собственно платформы IMDG состоит в автоматической балансировке нагрузки, в минимизации перемещения данных и организации работы с данными по месту их нахождения.

Аналитический сервер ScaleOut Analytics Server представляет собой типичный пример IMDG, совмещенный с машиной для анализа данных (рис. 3). Данные в машину поступают из двух типов источников, различающихся по требованиям к задержке: если задержка должна быть минимальной, то работающее приложение динамически непрерывно обновляет грид в темпе поступления данных; если требования не столь жестки, то данные могут задержаться в системе хранения. В любом случае IMDG удерживает данные, для надежности создает их реплики и распределяет по серверам. ScaleOut Analytics Server позволяет создавать спецификацию запросов либо с использованием фильтров на Java, либо на языке интегрированных запросов Microsoft LINQ, если используется C#. Эти спецификации позволяют выбирать анализируемые данные по тем или иным признакам.

Рис. 3. Аналитическая машина MapReduce IMDG Scaleout

В ScaleOut Analytics Server принятые в Hadoop методы анализа и слияния (analysis и merge) могут быть написаны либо на Java, либо на C#. Поскольку IMDG хранит эти анализируемые и сливаемые объекты в оперативной памяти, то эти методы могут быть написаны без использования прикладного интерфейса API к гриду. В таком случае аналитический метод специфицирует логику анализа в приложении к одному объекту, выбираемому спецификацией запроса. Например, в случае биржи это может быть обработка показателей одной компании, а слияние дает обобщенные показатели по группе объектов. В дополнение к ScaleOut Analytics Server есть специальный API, называемый «вызов» (invoke), и дополнительная спецификация запросов для методов анализа и слияния, позволяющая запускать модель вычисления, называемую «параллельный метод вызова» (Parallel Method Invocation, PMI). В таком случае IMDG автоматически выполняет запросы, анализ и слияние параллельно на всех своих серверах, образуя машину мультипотокового вычисления. Таким образом ScaleOut Analytics Server позволяет избежать перехода в пакетный режим и приблизиться к реальному времени.

Описанная выше схема упрощает трудоемкий процесс программирования Hadoop, при котором даже опытному программисту требуется несколько недель на освоение специфических приемов. Использование функций ScaleOut Analytics Server открывает возможность для разработки аналитических приложений специалистам, которые являются профессионалами в прикладных областях.

На рис. 4 приведено сравнение производительности различных реализаций аналитической системы на базе IMDG.

Рис. 4. Сравнение производительности

Решения от GridGain

Одну из своих презентаций технический директор и сооснователь GridGain Дмитрий Сетракян назвал «Почему слоны не умеют танцевать?», понимая под слонами сложные системы Hadoop MapReduce, работающие с устаревшими данными в пакетном режиме.

В наиболее общей форме подход к IMDG, которого придерживаются в компании GridGain, иллюстрирует рис. 5. Конфигурация состоит из множества серверов, работающих в памяти и передающих данные и коды другим серверам. При масштабировании число серверов, входящих в грид, может превышать тысячу. При необходимости грид может получать данные и коды из традиционных баз данных, NAS и SAN. В целом платформа от GridGain сочетает в себе ПО связующего слоя, высокоскоростную реализацию MapReduce и включает поддержку вычислительных гридов (GridGain Compute), гридов данных (Data Grid) и Больших Данных (за счет интеграции файловой системы Hadoop Distributed File System и СУБД HBase). На базе платформы создается три группы продуктов: In-memory HPC, In-memory Streaming и In-memory Database, а также ускорители Accelerator for Hadoop и Accelerator for Mango DB. При этом In-memory HPC поддерживает четыре модели исполнения: MapReduce Processing, RPC Processing, MPP Processing и MPI-Style Processing. Решения из группы In-memory Streaming предназначаются для обработки потоков, иначе называемой обработкой сложных событий.

Рис. 5. Архитектура IMDG от GridGain

GridGain IMDB представляет собой основанное на Java объектное хранилище данных с доступом по ключам, которое можно представить в виде совокупности одного или нескольких кэшей, называемых картами или словарями. Каждый кэш есть не что иное, как распределенный набор пар ключ-значение представления объектов любого определенного пользователем типа.

Каждый кэш должен быть заранее сконфигурирован — «на лету» сделать это невозможно из-за необходимости сохранять согласованность распределенных семантик. При работе с GridGain IMDB во встроенном режиме кэши и их проекции служат основными входными точками API. Хотя каждый кэш имеет множество конфигурационных опций, все кэши разделяются только на три типа или режима: локальный, реплицируемый и делящийся на разделы. В локальном режиме все данные хранятся без какого-либо распределения, требующего организации обмена в памяти. При репликации по всем узлам кластера обеспечивается высокий уровень готовности и надежности, что приводит к излишним затратам ресурсов памяти. Третий режим отличается тем, что в каждом из узлов хранится небольшая порция общих данных, поэтому обеспечивается наибольшее быстродействие. Возможность комбинации всех трех режимов для каждого узла не ограничивает пользователя какой-то одной моделью хранения и делает GridGain IMDB удобным распределенным хранилищем данных. GridGain IMDB хранит данные на четырех системных уровнях (по возрастанию времени задержки): в памяти — JVM on-heap, в памяти вне кучи — JVM off-heap, в пространстве подкачки локального диска или в дополнительном кэше. Термином heap, буквально «куча», обозначают область памяти для динамического размещения объектов (кэша грида и других компонентов) — в случае Java heap объекты сохраняются в «куче», а в случае off-heap — вне ее. При размещении данных за пределами кучи JVM об этом не знает — следовательно, не замедляется.

Существенная отличительная особенность GridGain IMDB заключается в том, что изначально разрабатывалась высококачественная распределенная масштабируемая среда, которой позже придали черты полноценной СУБД. Обычно бывает иначе — готовые базы данных адаптируют к возможности распределения. GridGain IMDB основывается на технологии HyperClustering, позволяющей масштабировать систему вплоть до1000 узлов в одной транзакционной топологии. Кластеризация GridGain IMDB построена по одноранговой топологии, а управление транзакциями поддерживается механизмом MVCC (MultiVersion Concurrency Control — «управление конкурентным доступом с помощью многоверсионности»).

Еще одним достоинством GridGain IMDB является интеграция с In-Memory HPC на уровне ядра СУБД. Большинство традиционных реляционных и No/NewSQL СУБД в конечном счете служат для обеспечения адресации к хранимым данным и обладают заурядными способностями их обработки, поэтому данные нужно извлекать и перемещать к месту обработки, что вызывает задержки и связано со многими сложностями, ограничивающими масштабирование. В отличие от них GridGain IMDB была изначально спроектирована в расчете на минимизацию перемещения данных, поэтому для нее интеграция с HPC является органичной. Такой подход обеспечивает параллельную обработку в ее «чистом» виде, поскольку вся задача разбивается на подзадачи, которые распределяются по узлам для обработки именно тех данных, которые на них хранятся. GridGain IMDB поддерживает MapReduce, распределенный SQL, MPP, MPI, RPC и API к файловым системам. Для программирования и создания запросов предлагается несколько возможных путей. Во внешнем контексте можно использовать драйверы Java, C++ и C#. Кроме того, GridGain IMDB поддерживает протоколы REST и Memcached. Во встроенном режиме используются SQL и JDBC, а также технология текстового поиска и индексирования Lucene, текстовые и полноэкранные запросы. Для сложных процессов обработки данных можно использовать In-memory MapReduce, MPP, RPC и MPI. Кроме того, GridGain IMDB предлагает файловую систему GGFS (GridGain File System) и поддержку протокола MongoDB Document API.

В отличие от реляционных, NewSQL и NoSQL баз данных, GridGain IMDB позволяет легко программировать во встроенном режиме — обычный режим работы с базами является внешним, то есть база реализуется отдельно от приложений, а данные передаются из базы в приложение по определенному сетевому протоколу. Такой подход плохо подходит к решению задач HPC и обработке больших массивов данных в реальном времени. GridGain IMDB отличается тем, что поддерживает встроенный режим (embedded mode), в котором логика обработки данных встраивается непосредственно в базу.

В GridGain IMDB каждый кэш может быть сконфигурирован так, чтобы имелась одна или более активных резервных копий, обеспечивающих надежность в случае выхода из строя какого-то узла. Наличие таких копий может помочь повысить производительность на операциях, где доминирует чтение. При изменении топологии, то есть при подключении или отключении узлов, специальные средства осуществят синхронное или асинхронное перераспределение данных по разделам, с тем чтобы обеспечить целостность и готовность. На случай, если в результате ошибки синхронизации происходит сегментация сети (split-brain — расщепление мозга) и образуются два ее сегмента с частично общим содержанием, причем каждый сегмент считает себя единственным, в GridGain IMDB имеются подключаемые средства, исключающие ошибочные операции чтения и записи.

GridGain IMDB гарантирует соблюдение требований ACID при выполнении распределенных транзакций.

***

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