HadoopDB: архитектурный гибрид технологий MapReduce и СУБД для аналитических рабочих нагрузок

Азза Абузейд, Камил Байда-Павликовски, Дэниэль Абади, Ави Зильбершац, Александр Разин
Перевод: Сергей Кузнецов

Назад Содержание Вперёд

3. Требуемые свойства

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

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

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

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

Использование дешевых и ненадежных массовых аппаратных средств для построения кластеров без совместно используемых ресурсов позволяет сократить эксплуатационные расходы и потребление дорогостоящих ресурсов. Имеется также тенденция к использованию наиболее дешевых аппаратных средств при организации центров данных [14]. В результате быстро возрастает вероятность отказов узлов во время выполнения запросов. Эта проблема только обостряется при масштабировании аналитических систем: чем больший объем данных затрагивается при выполнении аналитических запросов, тем большее число узлов требуется для обработки этих запросов. Это еще больше повышает вероятность отказа по крайней мере одного узла во время выполнения запроса. Например, по информации Google [8], при выполнении аналитического задания в среднем возникает 1,2 отказов. Если при каждом отказе узла требуется выполнять запрос заново, то трудно довести до конца выполнение сложных запросов, для обработки которых требуется достаточно большое время.

Возможность работы в неоднородной среде. Как отмечалось выше, имеется устойчивая тенденция к увеличению числа узлов, участвующих в выполнении запросов. Почти невозможно добиться одной и той же производительности сотен или тысяч вычислительных узлов, даже если всем узлам соответствуют полностью идентичные аппаратные или виртуальные машины. При масштабировании системы все более распространенными становятся частичные отказы узлов, приводящие не к полной утрате их работоспособности, а к падению производительности. Производительность отдельных узлов может также снижаться из-за фрагментации дисковой памяти или ошибок конфигурирования программного обеспечения. На однородность производительности узлов кластера может оказывать влияние и параллельное выполнение нескольких запросов (или, в некоторых случаях, процессов). Параллельные активности, выполняемые в разных виртуальных машинах, которые базируются на одной и той же физической машине, могут приводить к отклонениям показателей производительности на 2-4% [5].

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

Гибкий интерфейс запросов. Имеются разнообразные средства интеллектуального анализа данных (business intelligence, BI), ориентированные на пользователей. Эти средства работают с программным обеспечением баз данных и поддерживают развитые возможности аналитики, генерацию запросов и визуализацию результатов. Подобные средства являются важной частью общей картины управления аналитическими данными, поскольку бизнес-аналитики часто не получают должную техническую подготовку, и им трудно взаимодействовать с программным обеспечением баз данных напрямую. Средства BI обычно подключаются к базам данных с использованием ODBC или JDBC, так что системы баз данных, для которых требуется обеспечить возможность работы с этими средствами, должны уметь обрабатывать SQL-запросы, поступающие через такие интерфейсы.

В идеале, в системах анализа данных должен также иметься надежный механизм, позволяющий пользователям писать определяемые ими функции (user-defined function, UDF), и запросы, включающие вызовы UDF, должны автоматически распараллеливаться по узлам кластера без совместного использования ресурсов. Таким образом, требуется поддержка как SQL, так и интерфейсного языка, не являющегося SQL.

4. Предпосылки и недостатки имеющихся подходов

В этом разделе мы приведем обзор подходов параллельных систем баз данных и MapReduce к выполнению анализа данных и укажем свойства из разд. 3, которыми обладает каждый из этих подходов.

4.1. Параллельные СУБД

Направление параллельных системы баз данных возникло на основе исследований, выполненных в середине 1980-х гг., и большинство современных систем выглядят подобно прототипам параллельных СУБД Gamma [10] и Grace [12]. Во всех этих системах поддерживаются стандартные реляционные таблицы и язык SQL и реализуются многие методы повышения производительности, разработанные исследовательским сообществом в последние десятилетия, включая индексацию, сжатие (операции, выполняемые без распаковки данных), материализованные представления, кэширование результатов и совместное использование ресурсов ввода-вывода. Большая часть таблиц (или даже все таблицы) разделяется по нескольким узлам кластера без совместного использования ресурсов; однако механизм разделения данных прозрачен для конечного пользователя. В параллельных системах баз данных используется оптимизатор запросов, приспособленный к распределенной рабочей нагрузке и превращающий SQL-команды в планы запросов, выполнение которых поровну разделяется между несколькими узлами.

Что касается требуемых свойств рабочих нагрузок крупномасштабного анализа данных, описанных в разд. 3, то в параллельных системах баз данных лучше всего поддерживается "свойство производительности", поскольку именно это свойство больше всего требуется для успешной конкуренции на открытом рынке. Достижению высокой производительности способствует использование ряда хитроумных приемов, придуманных на протяжении десятилетий в сообществе баз данных. Особенно высокой производительности параллельные системы баз данных достигают при наличии высококвалифицированного администратора баз данных (database administrator, DBA), который может тщательно спроектировать базу данных, правильно установить и настроить систему и должным образом ее поддерживать. Однако современные достижения в области автоматизации таких задач и расширяющаяся тенденция к использованию заранее настроенных и сконфигурированных специализированных аппаратно-программных систем (appliance) позволяют многим параллельным системам баз данных демонстрировать высокую производительность без специальных действий DBA.

В параллельных системах баз данных хорошо поддерживается и свойство гибкого интерфейса запросов. Поддержка SQL и ODBC обычно сама собой разумеется, и во многих параллельных системах баз данных допускается определение и использование UDF (хотя возможности планировщика и оптимизатора запросов по распараллеливанию выполнения UDF по узлам кластера без общих ресурсов различаются в разных реализациях).

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

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

4.2. MapReduce

Концепция MapReduce была введена Дином (Jeffrey Dean) и Гемаватом (Sanjay Ghemawat) в 2004 г. [8]. Для понимания нашей статьи не требуется знание всех деталей работы MapReduce. Коротко говоря, MapReduce обрабатывает данные, распределенные (и реплицированные) между узлами кластера без общих ресурсов на основе трех базовых операций. Во-первых, параллельно выполняется некоторый набор задач Map (по одной задаче на узел) без каких-либо коммуникаций между узлами. Далее данные заново разделяются между узлами кластера. Наконец, параллельно выполняется некоторый набор задач Reduce (по одной задаче в каждом узле, получившем раздел данных). За этим может следовать произвольное число циклов Map-repartition-Reduce, если это требуется. В системе MapReduce не создается какой-либо детальный план выполнения запроса, в котором заранее указывалось бы, какие узлы должны выполнять соответствующие задачи; это определяется во время выполнения. Такой подход позволяет системам MapReduce "на лету" подстраиваться к отказам узлов и медленным узлам путем назначения большего числа задач более быстрым узлам и переназначения задач, которые были назначены для отказавших узлов. Кроме того, в MapReduce на локальный диск сбрасываются результаты каждой задачи Map, чтобы минимизировать объем работы, которую придется повторно выполнить после возникновения отказа.

Что касается требуемых свойств рабочих нагрузок крупномасштабного анализа данных, то MapReduce наилучшим образом поддерживает свойства отказоустойчивости и возможности функционировать в разнородных средах. Отказоустойчивость достигается за счет выявления и переназначения другим узлам задач отказавших узлов (предпочтение отдается узлам, содержащим реплики входных данных Map). Возможность функционирования в неоднородных средах обеспечивается за счет выполнения избыточных задач. Задачи, выполнение которых занимает долгое время в медленных узлах, избыточным образом выполняются на узлах, завершивших выполнение назначенных им задач. Время выполнения подобной задачи становится равным времени выполнения в самом быстром узле назначенной ему избыточной задачи. Если делать задачи достаточно мелкими, то можно минимизировать влияние отказов и "отстающих" узлов.

В MapReduce имеется гибкий интерфейс запросов; функции Map и Reduce представляют собой всего лишь произвольные вычисления, закодированные на некотором языке общего назначения. Поэтому каждая задача может делать со своими входными данными все, что угодно, лишь бы только она производила результирующие данные в соответствии с соглашениями модели. В большинстве систем, основанных на MapReduce, (в том числе, и в системе Hadoop, в которой напрямую реализованы детали системного уровня, описанные в статье про MapReduce) не поддерживается декларативный SQL. Однако имеются некоторые исключения (например, Hive).

Как было показано в предыдущем исследовании, самой большой проблемой MapReduce является производительность [23]. Поскольку от пользователей не требуется моделирование и загрузка данных до их обработки, использование многих упомянутых выше средств повышения производительности, применяемых в системах баз данных, в данном случае оказывается невозможным.

В идеальном случае отказоустойчивость и возможность функционировать в неоднородных средах MapReduce можно было бы объединить с производительностью параллельных систем баз данных. В следующих разделах мы опишем свою попытку построить такую гибридную систему.

Назад Содержание Вперёд