HadoopDB архитектурный гибрид технологий

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


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

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

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

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


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

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

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

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

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

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


Содержание раздела