В последнее время специализированные издания
В последнее время специализированные издания переполнены новостями о революции «кластерных вычислений». Эта парадигма состоит в использовании большого числа (низкопроизводительных) процессоров, работающих в параллель для решения вычислительной проблемы. По существу, предлагается построение центра данных путем объединения большого числа низкопроизводительных серверов вместо использования меньшего числа высокопроизводительных серверов. Рост интереса к кластерам способствует распространению средств их программирования. Одним из первых и наиболее известных подобных средств является MapReduce (MR) . Подход MapReduce привлекателен тем, что обеспечивает простую модель, на основе которой пользователи могут выражать сравнительно сложные распределенные программы, что порождает значительные интерес в образовательном сообществе. Например, IBM и Google обнародовали планы по обеспечению доступности 1000-процессорного кластера MapReduce для обучения студентов распределенному программированию.
При наличии этого интереса к MapReduce естественно задать вопрос: «А почему бы вместо этого не использовать какую-нибудь параллельную СУБД?». Параллельные системы баз данных (которые все основаны на общих архитектурных принципах) коммерчески доступны уже почти двадцать лет, и на рынке их около десятка, включая Teradata, Aster Data, Netezza, DATAllegro (и, следовательно, вскоре Microsoft SQL Server через посредство проекта Madison), Dataupia, Vertica, ParAccel, Neoview, Greenplum, DB2 (посредством Database Partitioning Feature) и Oracle (посредством Exadata). Это надежные, высокопроизводительные вычислительные платформы. Подобно MapReduce, они обеспечивают среду высокоуровневого программирования и полную распараллеливаемость. Хотя может показаться, что MR и параллельные системы баз данных нацелены на разную публику, на самом деле, можно написать почти любую задачу параллельной обработки либо в виде некоторого набора запросов к базе данных (возможно, с использованием определяемых пользователями функций и агрегатов для фильтрации и комбинирования данных), либо в виде набора заданий MapReduce.
Вдохновляемые этим вопросом, авторы задались целью понять, в чем состоят различия подходов MapReduce и параллельных систем баз данных при выполнении крупномасштабного анализа данных. Эти два класса систем расходятся в нескольких ключевых аспектах. Например, для всех СУБД требуются данные, соответствующие строго определенной схеме, в то время как MR допускает использование данных, представленных в любом произвольном формате. К числу других отличий относятся способы оптимизации на основе индексации и сжатия данных, модели программирования, методы распределения данных и стратегии выполнения запросов.
Цель статьи состоит в том, чтобы проанализировать эти отличия и их последствия. Второй раздел статьи начинается с краткого обзора этих двух альтернативных классов систем, после чего в разделе 3 обсуждается их архитектурные особенности. Затем в разделе 4 описывается эталонный тестовый набор, состоящий из разнообразных задач, одна из которых взята из статьи про MR , а прочие являются более трудными. Кроме того, приводятся результаты прогонов этого тестового набора на 100-узловом кластере. В испытаниях участвовали публично доступная версия MapReduce с открытыми кодами Hadoop , а также две параллельных SQL-ориентированных СУБД – Vertica и система одного из основных поставщиков реляционных СУБД. Также приводятся данные о временных затратах на загрузку и проверку данных, и неформально описываются процедуры, потребовавшиеся для установки и настройки программного обеспечения для каждой задачи.
В большинстве случаев SQL-ориентированные СУБД оказались существенно более быстрыми, и при их использовании потребовалось меньше кода для реализации каждой задачи, но больше времени для настройки и загрузки данных. На основе полученных результатов в заключении статьи обсуждаются причины различий между рассматриваемыми подходами, и приводятся рекомендации по поводу оптимальных методов для любого средства крупномасштабного анализа данных.
Некоторые читатели могут счесть, что эксперименты, проводимые с использованием 100 узлов, не являются интересными или представительными с точки зрения реальных систем обработки данных.
Авторы не согласны с этим предположением в двух отношениях. Во-первых, как демонстрируется в разд. 4, на 100 узлах две параллельные СУБД справляются с разными аналитическими задачами в 3,1-6,5 раз быстрее, чем MapReduce. Хотя, конечно, MR может масштабироваться до тысяч узлов, из-за исключительной эффективности современных СУБД такая массивная аппаратура не требуется даже при наличии наборов данных в 1-2 петабайта (1000 узлов с двухтерабайтной дисковой памятью на узел обладают общей дисковой емкостью в 2 петабайта). Например, в конфигурации Teradata в eBay используются всего 72 узла (в каждом узле два четырехъядерных процессора, 32 гигабайта основной памяти и 104 300-гигабайтных диска) для управления реляционными данными объемом около 2,4 петабайт. В качестве другого примера, хранилище данных Fox Interactive Media реализуется с использованием СУБД Greenplum на 40 узлах. Каждый узел представляет собой машину Sun X4500 с двумя двухъядерными процессорами, дисками общей емкостью в 48500 гигабайт и 16 гигабайтами основной памяти (1 петабайт общей дисковой памяти) . Поскольку петабайтного размера в мире достигают лишь немногие наборы данных, совсем непонятно, скольким пользователям MR на самом деле требуется 1000 узлов.
