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

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

Оригинал: Azza Abouzeid, Kamil Bajda-Pawlikowski, Daniel Abadi, Avi Silberschatz, Alexander Rasin. HadoopDB: An Architectural Hybrid of MapReduce and DBMS Technologies for Analytical Workloads. Proceedings of the 35th VLDB Conference, August 24-28, 2009, Lyon, France

Содержание

От переводчика: параллельная СУБД для бедных или путь в будущее?

Аннотация

1. Введение

2. Родственные работы

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

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

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

4.2. MapReduce

5. HadoopDB

5.1. История реализации Hadoop

5.2. Компоненты HadoopDB

5.3. Резюме

6. Тестовые испытания

6.1. Испытываемые системы

6.2. Тестовые испытания для сравнения производительности и масштабируемости

6.3. Сводка описанных результатов

7. Отказоустойчивость и неоднородная среда

7.1. Обсуждение

8. Заключение

9. Благодарности

10. Литература

От переводчика: параллельная СУБД для бедных или путь в будущее?

Зародившаяся в недрах Google технология MapReduce не дает покоя сообществу баз данных. Действительно, обидно. С несравненно меньшими усилиями, чем те, которые были затрачены в течение десятилетий сотнями исследований на разработку архитектурных и технологических приемов построения параллельных СУБД (имеются в виду СУБД категории sharing nothing), в MapReduce удалось элегантно решить проблемы масштабируемости и отказоустойчивости.

Первая реакция авторитетных представителей сообщества баз данных состояла в (достаточно убедительных) попытках показать, что MapReduce не может конкурировать с параллельными СУБД по производительности. В статье Майкла Стоунбрейкера (Michael Stonebraker) и др. Сравнение подходов к крупномасштабному анализу данных определялся тестовый набор и описывались результаты экспериментов, показывающие, что при решении простых, но типичных аналитических задач параллельные системы баз данных демонстрируют производительность, на порядок превышающую производительность Hadoop – свободно доступной реализации MapReduce.

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

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

Этим идеям не противоречат работы, описываемые в статьях Джо Хеллерстейна и др. МОГучие способности: новые приемы анализа больших данных и Эрика Фридмана и др. SQL/MapReduce: практический подход к поддержке самоописываемых, полиморфных и параллелизуемых функций, определяемых пользователями, в которых, фактически, говорится о применении технологии MapReduce для поддержки массивно распараллеливаемых функций, определяемых пользователями. В продуктах компаний Greenplum и Asterdata на первом месте стоят технологии параллельных СУБД, а MapReduce носит вспомогательный характер, затыкая те "дыры", которые остаются при использовании SQL (может быть, по этому поводу стоит вглянуть на мою заметку про Asterdata SQL и MapReduce: новые возможности или латание старых дыр?).

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

Поэтому в проекте HadoopDB в прототипе будущей параллельной системы управления аналитическими данными в качестве основы используется реализация MapReduce с открытыми кодами Hadoop, которая обеспечивает масштабируемость и отказоустойчивость. Эффективность системы, свойственная существующим параллельным СУБД, обеспечивается за счет использования в узлах кластера СУБД PostgreSQL, а традиционный SQL-ориентированный доступ к данным, управляемым системой, поддерживается компонентом SMS, сделанным на основе свободно доступного компилятора SQL для Hadoop Hive.

Описываемый подход, безуловно, является интересным и перспективным, что подтвержается результатами экспериментов, выполненных авторами. Особенно привлекает то, что весь проект HadoopDB выполняется на основе подхода open source в среде Amazon Elastic Compute Cloud (EC2), что позволяет каждому желающему повторить или выполнить собственные эксперименты с системой, а при желании что-то в ней изменить и/или добавить.

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

Сергей Кузнецов

Аннотация

Производственная среда аналитических приложений управления данными быстро изменяется. Многие предприятия отказываются от размещения своих аналитических баз данных на дорогостоящих проприетарных машинах и переходят к использованию более дешевой аппаратуры массового спроса, которая обычно организуется на основе массивно-параллельной архитектуры (MPP) без совместно используемых ресурсов (sharing-nothing) и часто применяется в публичной или частной "облачной" среде виртуализации. В то же время, объемы данных, нуждающихся в анализе, взрывообразно возрастают, и для выполнения анализа требуются сотни тысяч машин, работающих параллельно.

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

1. Введение

Рынок аналитических баз данных в настоящее время составляет $3,98 миллиардов [25], т.е. 27% от оцениваемого в $14,6 миллиардов общего рынка программного обеспечения баз данных [21], и его объем ежегодно увеличивается на 10,3% [25]. Поскольку передовые методы управления бизнесом все чаще основываются на принятии решений на основе данных и неопровержимых фактов, а не на основе интуиции и предположений, у компаний возрастает интерес к системам, которые способны управлять данными, обрабатывать их и анализировать на разных уровнях детализации. Эта тенденция хорошо известна венчурным компаниям, которые в последние годы финасировали не менее десятка новых компаний, создающих специализированное программное обеспечения для аналитического управления данными (например, Netezza, Vertica, DATAllegro, Greenplum, Aster Data, Infobright, Kickfire, Dataupia, ParAccel и Exasol), и продолжают их финансировать несмотря на трудную экономическую ситуацию.

В то же время взрывообразно возрастает объем данных, которые требуется сохранять и обрабатывать в системах аналитических баз данных. Частично это происходит из-за возрастающего уровня автоматизации производства данных (компьютеризуется все большее число бизнес-процессов), увеличения числа датчиков и других устройств, генерирующих данные, перехода на использование Web-технологий при взаимодействиях с заказчиками и нормативных требований со стороны государства, для удовлетворения которых приходится сохранять в режиме онлайн большее число исторических, пригодных для анализа данных. Нередко приходится слышать о компаниях, ежедневно загружающих в свои аналитические системы баз данных более терабайта структурированных данных и обладающих более чем петабайтными хранилищами данных [19].

Принимая во внимание проблему взрывообразного роста объема данных, почти все упомянутые выше начинающие компании основывают свои СУБД на архитектуре без совместно используемых ресурсов (sharing-nothing) – наборе независимых, возможно, виртуальных машин с собственными локальными дисками и основной памятью, соединенных высокоскоростной сетью. Широко распространено мнение, что такая архитектура масштабируется наилучшим образом [17], особенно, если принимать во внимание стоимость аппаратных средств. Кроме того, рабочие нагрузки анализа данных обычно содержат много крупных операций сканирования, многомерной агрегации и соединений со звездообразной схемой, которые сравнительно просто распараллеливаются по узлам сети без совместно используемых ресурсов. Лидер поставщиков аналитических СУБД – компания Teradata использует архитектуру без общих ресурсов. Oracle и Microsoft недавно анонсировали аналитические СУБД без общих ресурсов, созданные в проектах Exadata¹ и Madison соответственно. В этой статье мы будем называть аналитические СУБД, основанные на архитектуре без использования общих ресурсов, параллельными системами баз данных².

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

Поскольку объем данных, требующих анализа, продолжает расти, умножается и число приложений, для эффективного выполнения которых требуется более сотни узлов. Некоторые специалисты утверждают, что для выполнения анализа такого масштаба лучше всего подходят системы, основанные на MapReduce [8], поскольку они разрабатывались с самого начала в расчете на масштабирование до тысяч узлов в архитектуре без совместно используемых ресурсов и прордемонстрировали свои возможности при поддержке внутренних операций Google и при испытаниях на тестовом наборе TeraSort [7]. Несмотря на свою исходную ориентацию на поддержку совсем других приложений (обработка неструктурированных текстовых данных), MapReduce (и его публично доступная инкарнация – система с открытыми исходными текстами Hadoop [1]) может использоваться для обработки структурированных данных и способна производить эту обработку в огромном масштабе. Например, Hadoop используется для управления 2,5-петабайтным хранилищем данных Facebook [20].

Однако, как отмечали Девитт (DeWitt) и Стоунбрейкер (Stonebraker) [9], в MapReduce отсутствуют многие характеристики, являющиеся бесценными при обработке рабочих нагрузок над стуктурированными данными, (в основном, из-за того, что изначально MapReduce не предназначался для выполнения анализа структурированных данных) и парадигма "прямой отдачи" (immediate gratification), на которой основаны системы MapReduce, препятствует получению дологовременных преимуществ от моделирования и загрузки данных до их обработки. Эти недостатки приводят к тому, что системы MapReduce в ряде случаев демонстрируют производительность, на порядок уступающую производительности параллельных систем баз данных [23].

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

Одним из не упоминавшихся ранее преимуществ MapReduce над параллельными системами баз данных является стоимость. Имеется версия MapReduce с открытыми кодами (Hadoop), которую можно получить и использовать бесплатно. При этом у всех упоминавшихся параллельных систем баз данных имеется совсем не маленькая цена, часто составляющая семизначное число для крупных установок. Поскольку наша цель состояла в объединении в гибридной системе всех преимуществ обоих подходов к анализу данных, мы решили основывать свой протитип исключительно на компонентах с открытыми исходными текстами, чтобы добиться еще и преимущества в стоимости. Поэтому мы используем PostgreSQL на уровне управления базами данных, Hadoop – на уровне коммуникаций, Hive – на уровне компиляции. Мы открываем также и весь свой собственный код [2].

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

Поскольку мы стремимся к обеспечению дешевого крупномасштабного анализа данных, нашей целевой платформой являются виртуализованные публичные или частные среды "облачных вычислений" ("cloud computing"), такие как Elastic Compute Cloud (EC2) компании Amazon или частные среды, построенные на основе Cloud OS компании VMware. Установка системы в подобной среде позволяет существенно сократить начальные капитальные вложения, снизить расходы на эксплуатацию системы, предоставление ее услуг и развитие аппаратных средств (за счет максимального использования доступной аппаратуры). Использование публичных облачных сред, подобных EC2, также позволяет добиться существенной экономии при росте масштабов системы [14], и эта экономия частично распространяется на заказчиков. Все эксперименты, описываемые в этой статье, выполнялись в среде Amazon EC2; однако наши методы применимы и в вычислительных кластерных средах, в которых не применяется виртуализация.

Вкратце, основным вкладом нашей работы является следующее:

• Мы развили предыдущие исследования [23], показывающие превосходство производительности параллельных систем баз данных над производительностью Hadoop. В то время как в этих предыдущих исследованиях изучалась производительность систем в идеальных условиях, мы проводили эксперименты с отказоустойчивостью и неоднородностью узлов, чтобы продемонстрировать некоторые проблемы масштабирования параллельных систем баз данных.

• Мы разработали гибридную систему, обладающую преимуществами и параллельных систем баз данных, и MapReduce. Эту систему можно также использовать для выполнения одноузловых систем баз данных в среде без совместно используемых ресурсов.

• Мы провели испытания этой гибридной системы на ранее опубликованном тестовом наборе, чтобы определить, насколько она близка к параллельным системам баз данных по производительности и к Hadoop – по масштабируемости.

2. Родственные работы

В последнее время выполнялись некоторые исследовательские работы, посвященные объединению идей MapReduce и параллельных систем баз данных; однако в этих исследованиях основное внимание уделялось языковым и интерфейсным аспектам. Проекты Pig (Yahoo, [22]), SCOPE (Microsoft, [6]) и Hive (проект с открытыми исходными текстами, [11]) направлены на интеграцию в программное обеспечение MapReduce конструкций декларативных запросов, используемых в системах баз данных, с целью обеспечения большей независимости данных, повторной используемости кода и автоматической оптимизации запросов. В продуктах компаний Greenplum и Asterdata добавлена возможность определения MapReduce-функций (вместо SQL-функций или впридачу к ним) над данными, хранимыми под управлением этих продуктов [16].

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

---

¹ Более точно, Exadata является системой без совместного использования ресуров только на уровне хранения данных.

² Это определение слегка отличается от определений параллельных систем баз данных, приводимых в учебниках, где в их число иногда включаются еще и системы, основанные на архитектурах с совместно используемой общей памятью (shared memory) и совместно используемыми дисками (shared disk).

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