Системы для Больших Данных: конвергенция архитектур

Происходящий последние десять лет экспоненциальный рост объемов данных привел к появлению нового класса систем, их обрабатывающих [1], а на переднем крае здесь оказались онлайн-компании, такие как Google и Amazon, работающие с огромными репозиториями данных. Благодаря проектам этих и других разработчиков появился ряд открытых и коммерческих технологий управления данными, с помощью которых любые организации могут создавать и эксплуатировать широко масштабируемые репозитории высокой готовности [2, 3]. Однако построение систем, связанных с обработкой Больших Данных, требует тщательно продуманных компромиссов, учитывающих специфику различных архитектур, а также дополнения знаний о проектировании традиционных программных архитектур сведениями об особенностях сильной связности, характерной для расширяемых систем. Масштаб проекта, обусловленный консолидацией функционала, уже не позволяет по отдельности рассматривать особенности архитектур распределения, данных и развертывания, что можно проиллюстрировать на примере медицинской информационной системы.

Сложности проектирования систем Больших Данных

Системы, работающие с большими объемами данных, традиционно строились на реляционных СУБД, которые по мере роста нагрузки и потребностей в хранении масштабируются в основном вертикально за счет более быстрых процессоров и накопителей. В связи с присущими таким базам ограничениями вертикального масштабирования появились новые продукты, нестрого выполняющие фундаментальные требования к СУБД. Жестко заданные модели данных, обеспечивающие надежные гарантии консистентности данных (требование, согласно которому все клиенты при считывании получают одни и те же данные) и строгое следование стандарту SQL, уступили место моделям, лишенным жестких схем и преднамеренно денормализованным, со слабой консистентностью и с проприетарным API. Такие NoSQL-системы (Cassandra, Riak, MongoDB и др.) предоставили программистам доступ к внутренним механизмам управления данными и обычно рассчитаны на горизонтальное масштабирование посредством кластеров из недорогих серверов умеренной производительности. В таких системах высокое быстродействие, эластичность хранения и доступность обеспечиваются за счет секционирования и тиражирования срезов данных в пределах кластера.

Распределенные базы данных имеют фундаментальные ограничения с точки зрения качества обслуживания, определяемые теоремой CAP Эрика Брюера о консистентности, доступности (на каждый запрос возвращается отклик об успешном выполнении либо отказе) и устойчивости к разделению. Когда происходит разделение сети, вызывающее потерю связи между узлами кластера, система должна принести консистентность в жертву доступности. Дэниел Абади предлагает PACELC — практическую интерпретацию теоремы CAP: если происходит разделение (P), система обязана принести доступность (A) в жертву консистентности (C). Иначе (E) в обычной ситуации отсутствия разделения система обязана принести в жертву задержку (L) в пользу консистентности (C).

Трудности проектирования масштабируемых систем обработки больших объемов данных обусловлены тремя проблемами. Во-первых, достижение высокой масштабируемости и доступности требует наличия сильно распределенных систем на всех уровнях, от ферм веб-серверов и систем кэширования до систем хранения данных. Во-вторых, при большом масштабе трудно с помощью SQL-подобного языка запросов обеспечить абстрактную репрезентацию системы как единого целого — с транзакционными операциями записи и консистентным считыванием. Приложения должны: «знать» о существовании копий данных; компенсировать несоответствия, возникающие при конфликтующих обновлениях копий; продолжать работу, несмотря на неизбежные сбои процессоров, сетей и программных систем. В-третьих, при использовании любой NoSQL-системы приходится идти на определенные компромиссы, обычно выбирая между быстродействием, масштабируемостью, надежностью и консистентностью. Архитекторы должны тщательно оценивать имеющиеся технологии баз данных и выбирать те из них, которые в наибольшей степени подходят для конкретного приложения. Нередко прибегают к использованию разных технологий для хранения различных срезов данных в пределах одной и той же системы, чтобы удовлетворить соответствующие требования к атрибутам качества.

Базы данных NoSQL

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

Четыре основные модели данных NoSQL: 1 — документоориентированная; 2 — ключ-значение; 3 — поколоночная; 4 — графовая

 

Документоориентированные базы (1), например MongoDB и CouchDB, хранят коллекции объектов, обычно закодированных с помощью нотации JSON или XML. Документы снабжены ключами, можно создавать вторичные индексы или неключевые поля. Форматы документов описывают себя сами, причем в коллекцию могут входить документы разных форматов.

Базы «ключ-значение» (2), например Riak и DynamoDB, реализуют распределенные хеш-таблицы. Доступ к записям происходит главным образом путем поиска по ключам, а значение, ассоциированное с каждым ключом, рассматривается как не имеющее определенного типа и требует интерпретации считывающей системой. Эта несложная модель способствует сегментированию и тиражированию, позволяя создавать высокомасштабируемые системы высокой доступности.

Базы с поколоночным размещением данных (3), например HBase и Cassandra, расширяют модель ключ-значение, размещая записи с ключами в столбцах, каждый из которых представляет собой пару ключ-значение. Ключ становится названием столбца, а значение — это данные произвольного типа (например, документ JSON или изображение в двоичном формате). Коллекция может содержать записи с различным количеством столбцов.

Графовые базы (4), например Neo4j и GraphBase, организуют данные в виде структуры с большим количеством внутренних связей — обычно это ориентированный граф. Такие базы способны обеспечивать исключительно высокое быстродействие для задач, связанных с обходом графа и поиском подграфов. Поскольку эффективное разбиение графа — это NP-сложная задача, такие базы обычно в меньшей степени рассчитаны на горизонтальное масштабирование и, как правило, отвечают требованиям ACID для транзакций, обеспечивая высокую консистентность.

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

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

Особенности приложений для работы с Большими Данными

Приложения работы с Большими Данными проникают во многие области, и одна из них — аэронавигация. Современные коммерческие авиалайнеры генерируют по 500 Гбайт операционных данных за рейс, необходимых для диагностики неполадок в реальном времени, оптимизации расходов топлива и прогнозирования потребностей в ремонтно-техническом обслуживании. Для повышения безопасности и снижения затрат авиакомпаниям необходимо создавать масштабируемые системы с целью регистрации данных, их анализа и управления ими.

Еще одна область — здравоохранение, где, по некоторым оценкам, средства анализа Больших Данных могли бы принести экономию 450 млрд долл. (данные для США. — Прим. перев.). Анализ петабайтов данных по пациентам, накапливаемых в страховых компаниях, медицинских учреждениях и клинических исследованиях, поможет снизить затраты за счет повышения результативности лечения. Кроме того, аналитические системы позволят получать новые знания, помогающие в лечении и предотвращении заболеваний.

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

Во-первых, системы Больших Данных, от сайтов социальных СМИ до датчиков в энергосетях, должны справляться с большим объемом операций записи [1]. Поскольку запись затратнее, чем считывание, можно пользоваться сегментированием данных (секционированием и распределением), чтобы разделять операции записи между накопителями, а для обеспечения высокой доступности можно прибегать к тиражированию. Однако операции сегментирования и тиражирования создают проблемы с доступностью и консистентностью, которые надо как-то компенсировать.

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

Третье требование — возможность выполнения аналитики с большим объемом вычислений. Большинство систем Больших Данных должны справляться с комбинированными рабочими задачами, когда часть запросов требует быстрого ответа, а часть выполняется подолгу в связи со сложным анализом крупных срезов данных. Чтобы удовлетворить это требование, архитектуру ПО и данных специально оптимизируют с расчетом на то, что время обработки запросов будет варьироваться. Один из передовых образцов — система выдачи рекомендаций Netflix, которая способна параллельно выполнять быстрые запросы и сложный анализ больших коллекций данных, непрерывно улучшая качество генерируемых персональных советов.

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

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

Подобная конвергенция архитектур, необходимая для обеспечения требуемого качества, типична для приложений, работающих с Большими Данными. Этот подход можно описать как архитектурную модель «4+1» с сильносвязанными процессным, логическим и физическим представлениями.

Масштаб имеет значение

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

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

Во-вторых, архитектурные компоненты должны быть «без сохранения состояния», тиражируемыми и терпимыми к сбоям в зависимых от них сервисах. Например, используя шаблон проектирования «выключатель-автомат» (circuit breaker — программный механизм распознавания сбоев и предотвращения их влияния на работу системы) и возвращая кэшированные или стандартные результаты при сбоях, архитектура ограничивает влияние неполадок и выигрывает время на восстановление.

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

Еще один подход — оптимизация инструментария разработки, направленная на повышение продуктивности труда программистов и снижение загрузки ресурсов. В Facebook, например, разработали HipHop — систему трансляции кода, написанного на PHP, в код на С++, которая позволила вдвое уменьшить нагрузку на процессоры при выдаче веб-страниц. Учитывая гигантские масштабы систем Facebook, подобные оптимизации обеспечивают значительное снижение операционных издержек. Можно также принимать меры по снижению затрат на лицензирование ПО, которые при соответствующих масштабах могут быть непозволительно большими. Чтобы избежать их, в некоторых компаниях создают собственные базы данных и пакеты связующего ПО, нередко выпуская их в открытых кодах. Широко известные примеры открытых технологий для систем Больших Данных созданы в компаниях Netflix и LinkedIn.

Масштаб также влияет на тестирование и диагностику сбоев. Из-за огромных размеров самих систем и срезов данных, с которыми они работают, провести полную аттестацию кода перед вводом в рабочую эксплуатацию практически нереально. Примеры современных средств для тестирования масштабных решений — Canary Testing (метод экспресс-тестирования ключевых функций системы) и инструментарий верификации облачных сред Netflix Simian Army. Для быстрой диагностики проблем во время рабочей эксплуатации нужны развитые средства мониторинга и протоколирования — в крупномасштабных системах процессы ведения и анализа журналов сами по себе становятся задачами обработки Больших Данных, поэтому необходимы масштабируемые инфраструктуры протоколирования, характеризующиеся низкими накладными расходами, например Blitz4j.

Пример объединения функциональностей

В Институте программной инженерии при Университете Карнеги — Меллона создается система агрегации данных из множества баз медицинских карт, емкостью в десятки петабайт каждая. Чтобы обеспечить высокую масштабируемость и доступность с малыми затратами, изучается возможность использовать для агрегации базы NoSQL. Для повышения доступности и сокращения задержки при обработке запросов от пользователей, находящихся в разных странах, применяются географически распределенные ЦОД.

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

В рамках этого проекта созданы прототипы решения на основе нескольких СУБД NoSQL, в том числе MongoDB, на примере которой можно проиллюстрировать, чем обусловливаются те или иные архитектурные предложения. Данные в системе делятся на три сегмента и тиражируются между двумя ЦОД (рис. 1).

Рис. 1. Прототип системы управления медицинскими данными на основе СУБД MongoDB. Географически распределенные ЦОД повышают доступность и снижают задержку обработки запросов от пользователей, находящихся в разных странах мира

СУБД MongoDB требует использования архитектуры «главный-подчиненный» — у каждой коллекции данных есть главная копия, которая обслуживает все запросы на запись и распространяет изменения на другие копии. Поскольку для считывания клиенты могут обращаться к любой копии, появляется вероятность неконсистентности в периоды между записями в мастер-копию и считываниями из других копий. Данная СУБД позволяет выбирать между консистентностью и величиной задержки путем установки параметров для каждой операции записи и считывания. В результате может либо отсутствовать гарантия надежности при малой задержке, либо обеспечиваться надежность на мастер-копии и других копиях, но при большой задержке. Для выполнения считывания можно выбрать один из следующих вариантов: с предпочтением ближайшей копии (потенциальная неконсистентность, но низкая задержка), обязательно с мастер-копии (консистентность, но нет устойчивости к разделению) или потребовать, чтобы большинство копий согласовали считываемое значение (консистентность, устойчивость к разделению).

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

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

Данное приложение пока работает поверх SQL-базы, которая маскирует для разработчиков физическую модель данных и топологию развертывания. Система абстрактно представлена в виде единого образа — обеспечивается четкое разделение функциональности между приложением и базой данных, а детали распределения данных между процессорами, хранением и сетями маскируются транзакционным интерфейсом чтения/записи. С переходом в среду NoSQL приложению придется самостоятельно обрабатывать сбои, связанные с физическим распределением данных (сегментированием и тиражированием) и количеством копий и серверов. Таким образом, в логике приложения необходимо учитывать низкоуровневые инфраструктурные особенности, традиционно скрываемые за интерфейсом базы данных.

Архитектурная тактика

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

Рис. 2. Тактика оптимизации быстродействия в системах Больших Данных. Инженерные решения затрагивают архитектуры данных, распределение и развертывание

Рис. 2 и 3 иллюстрируют стандартную тактику повышения быстродействия и доступности в системах Больших Данных, на рис. 4 показана тактика улучшения масштабируемости с учетом возможности увеличенных нагрузок. Видно, что проектные решения затрагивают архитектуры данных, распределения и развертывания. В частности, достижение доступности требует маскировки неизбежных в распределенной системе сбоев. На уровне данных важным приемом для обхода разделений сети будет тиражирование элементов данных. Когда приложение не может получить доступ ни к одной из секций базы данных, еще одним тактическим приемом для повышения готовности будет проектирование модели данных таким образом, чтобы возвращались какие-то осмысленные стандартные значения. На уровне распределенного ПО реализация этой тактики осуществляется с помощью кэширования. На уровне развертывания тактика обеспечения доступности состоит в тиражировании данных по разным географическим регионам и использовании распределенных уровней прикладного ПО для защиты от сбоев электроэнергии и сети. На рис. 3 дан общий обзор тактических приемов, позволяющих проектировать системы высокой доступности.

Рис. 3. Архитектурные приемы, позволяющие проектировать системы Больших Данных высокой доступности

Рис. 4. Тактика обеспечения масштабируемости для систем Больших Данных с учетом возможности скачков нагрузки

***

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

Литература

1. D. Agrawal, S. Das, A. El Abbadi. Big Data and Cloud Computing: Current State and Future Opportunities // Proc.14th Int’l Conf. Extending Database Technology (EDBT/ICDT 11). — 2011. — P. 530–533.
2. W. Vogels. Amazon DynamoDB — a Fast and Scalable NoSQL Database Service Designed for Internet Scale Applications. Blog, 18 Jan. 2012. URL: http://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html (дата обращения: 01.09.2015).
3. F. Chang et al. Bigtable: A Distributed Storage System for Structured Data. ACM Trans // Computing Systems. — 2008. Vol. 26, № 2 (article 4).

Иэн Гортон (igorton@sei.cmu.edu) — научный сотрудник, Джон Клейн (jklein@sei.cmu.edu) — старший научный сотрудник, Институт программной инженерии Университета Карнеги — Меллона.