[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive]
Свободные мысли о свободном софте
[an error occurred while processing this directive]
Logo CitForum CITForum на CD Форумы Газета Море(!) аналитической информации!
[an error occurred while processing this directive]
[an error occurred while processing this directive]
[an error occurred while processing this directive]
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]

15.10.2018

Google
WWW CITForum.ru
[an error occurred while processing this directive]

Новости мира IT:

Архив новостей

[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive]
Пятнадцатая техническая конференция «Корпоративные базы данных-2010»
Москва, 22–23 апреля
С Новым годом!

Генеральный спонсор
Техническая конференция
Корпоративные базы данных – 2008
Москва, 24–25 апреля
При поддержке РФФИ

Спонсор
[an error occurred while processing this directive] [an error occurred while processing this directive]
На правах рекламы
2010 г.

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 недавно анонсировали аналитические СУБД без общих ресурсов, созданные в проектах Exadata1 и Madison соответственно. В этой статье мы будем называть аналитические СУБД, основанные на архитектуре без использования общих ресурсов, параллельными системами баз данных2.

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

Поскольку объем данных, требующих анализа, продолжает расти, умножается и число приложений, для эффективного выполнения которых требуется более сотни узлов. Некоторые специалисты утверждают, что для выполнения анализа такого масштаба лучше всего подходят системы, основанные на 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].

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


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

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

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

[an error occurred while processing this directive]
[an error occurred while processing this directive]
[an error occurred while processing this directive] [an error occurred while processing this directive]

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

[an error occurred while processing this directive]
[an error occurred while processing this directive]
[an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]

Размещение рекламы — тел. +7 495 6608306, ICQ 232284597

[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]

Редакция рекомендует:

Последние комментарии:

Что мы знаем об iPhone 4G? (7)
16 июля, 20:25

Подписка на новости CITForum.ru

Новые публикации:

7 июля

  • Управление параллелизмом с низкими накладными расходами для разделенных баз данных в основной памяти

  • Рекурсивные запросы в Oracle

  • Жесткий диск WD10EARS с сектором 4 КБ. Подготовка к эксплуатации в Linux.

    Обзоры журнала Computer:

    Газета:

  • Московские пробки - исследование IBM

  • От Osborne до iPad: эволюция портативных компьютеров

    19 мая

  • Прозрачный механизм удаленного обслуживания системных вызовов

  • Система моделирования Grid: реализация и возможности применения

    Газета:

    Майкл Стоунбрейкер:

  • Ошибки в системах баз данных, согласованность "в конечном счете" и теорема CAP

  • Дискуссия по поводу "NoSQL" не имеет никакого отношения к SQL

    29 апреля

  • Материалы конференции "Корпоративные Базы Данных-2010"

  • Разные облики технологии баз данных (отчет о конференции)

    14 апреля

  • MapReduce: внутри, снаружи или сбоку от параллельных СУБД?

  • Научные вызовы технологиям СУБД

    Обзоры журнала Computer:

    31 марта

  • Рационализация согласованности в "облаках": не платите за то, что вам не требуется

  • Взаимные блокировки в Oracle

  • Архитектура среды тестирования на основе моделей, построенная на базе компонентных технологий

  • Объектное представление XML-документов

    Газета:

  • Microsoft для российских разработчиков: практика с элементами фундаментальности

    10 марта

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

  • Классификация OLAP-систем вида xOLAP

  • BGP. Три внешних канала. Балансировка исходящего и входящего трафиков

    Газета:

  • Что мы знаем об iPhone 4G?

    17 февраля

  • MapReduce и параллельные СУБД: друзья или враги?

  • Объектно-ориентированное программирование в ограничениях: новый подход на основе декларативных языков моделирования данных

  • Системологический подход к декомпозиции в объектно-ориентированном анализе и проектировании программного обеспечения

    Газета:

  • Эволюция Wine

    3 февраля

  • Дом на песке

  • Реальное переосмысление "формальных методов"

  • Интервью с Найджелом Пендзом

    Газета:

  • iPad. Первый взгляд на долгожданный планшет от Apple

  • Я не верю в iPad [an error occurred while processing this directive]

    20 января

  • SQL/MapReduce: практический подход к поддержке самоописываемых, полиморфных и параллелизуемых функций, определяемых пользователями

  • Данные на лету: как технология потокового SQL помогает преодолеть кризис

    Обзоры журнала Computer:

    2 декабря

  • Сергей Кузнецов. Год эпохи перемен в технологии баз данных

    18 ноября

  • Генерация тестовых программ для подсистемы управления памятью микропроцессора

  • Сравнительный анализ современных технологий разработки тестов для моделей аппаратного обеспечения

    Все публикации >>>


    [an error occurred while processing this directive]
  • [an error occurred while processing this directive] [an error occurred while processing this directive]
    Купить сотовые телефоны в М.Видео
    Отличные цены на сотовые телефоны. Бесплатная доставка. Заказ в интернет-магазине и по телефону (495) 644-28-51
    www.mvideo.ru [an error occurred while processing this directive]

    Регистрация доменов в зонах .ru, .com, .net. Компания Rusonyx.

    IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    [an error occurred while processing this directive]
    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 6608306, ICQ 232284597 Пресс-релизы — pr@citforum.ru
    Послать комментарий
    Информация для авторов

    Редакция раздаёт котят!

    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2009 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...
    [an error occurred while processing this directive]


    [an error occurred while processing this directive] [an error occurred while processing this directive] реклама:
    Производство и продажа серверов | забронировать гостиницу Санкт Петербурга | платный хостинг | IBM Rational. Аналитика и инструменты
    [an error occurred while processing this directive] [an error occurred while processing this directive]