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

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

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

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

В этом разделе мы оцениваем систему HadoopDB, сравниваем ее с реализацией MapReduce и двумя реализациями параллельных систем баз данных, используя тестовый набор, впервые представленный в [23]⁴. Этот тестовый набор состоит из пяти задач. Первая из них взята прямо из исходной статьи про MapReduce [8], авторы которой называют ее характерным представителем распространенных задач MR. Следующие четыре задачи являются аналитическими запросами, представляющими характерную рабочую нагрузку анализа структурированных данных, на поддержку которой ориентируется HadoopDB.

Мы проводили свои эксперименты на "крупных" экземплярах Amazon EC2 (зона us-east-1b). В каждом экземпляре имелось 7,5 гигабайт основной памяти, 4 вычислительных блока EC2 (2 виртуальных ядра), 850 гигабайт дисковой памяти (2 × 420 гигабайт плюс 10-гигабайтный корневой раздел). В качестве операционной системы использовалась 64-битная Linux Fedora 8.

Поначалу производительность дискового ввода-вывода в узлах EC2 была довольно низкой (25 мегабайт в секунду). Впоследствии мы инициализировали в каждом узле некоторое дополнительное дисковое пространство, чтобы это исходное замедление не сказывалось на скорости записи промежуточных файлов и результатов задач. После инициализации этого дискового пространства последующие операции записи выполнялись гораздо быстрее (86 мегабайт в секунду). Скорость сети составляла примерно 100-110 мегабайт в секунду. Каждая задача выполнялась по три раза, и фиксировались средние результаты. Окончательные результаты запросов, выполняемых в параллельных системах баз данных, отправлялись из команды shell в файл через программный канал (pipe). Hadoop и HadoopDB сохраняли результаты в HDFS. В этом разделе мы приводим результаты только тех прогонов, в которых все узлы были доступными, работали корректно, и во время выполнения тестов отсутствовали одновременно выполняемые задачи (в разд. 7 мы отказываемся от этих требований). Для каждой задачи производительность измерялась на кластерах из 10, 50 и 100 узлов.

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

В наших экспериментах сравнивалась производительность Hadoop, HadoopDB (с PostgreSQL⁵ в качестве основой СУБД) и две коммерческие параллельные СУБД.

6.1.1. Hadoop

Hadoop – это версия с открытыми кодами среды MapReduce, реализованная под непосредственным влиянием идей исходной статьи про MapReduce и используемая сегодня в десятках компаний для выполнения анализа данных [1]. В описываемых в данной статье экспериментах мы использовали систему Hadoop версии 0.19.1, выполняемую в среде Java 1.6.0. Мы устанавливали систему с несколькими изменениями в конфигурационных установках, используемых по умолчанию. Данные в HDFS сохранялись в блоках размером 256 мегабайт вместо размера в 64 мегабайта, принимаемого по умолчанию. Каждый исполнитель MR работал с кучей максимального размера в 1024 мегабайта. В каждом узле допускалось одновременное выполнение двух экземпляров Map и одного экземпляра Reduce. Мы также расширили буферное пространство для операций чтения-записи файлов и увеличили буфер сортировок до 200 мегабайт (со ста параллельными потоками для слияния). В дополнение к этому, мы изменили число параллельных пересылок, выполняемых функцией Reduce на фазе "перетасовки" (shuffle), и число рабочих потоков управления для каждого HTTP-сервера компонента TaskTracker до 50. Эти настройки соответствуют принципам организации высокопроизводительных кластеров Hadoop [13]. Кроме того, мы допустили повторное использование JVM (Java Virtual Machine).

Для каждого прогона мы сохраняли все входные данные и результаты в HDFS без репликации (в разд. 7 мы добавляем репликацию). После прогона тестов на кластере конкретного размера мы удаляли во всех узлах каталоги данных, заново форматировали и загружали HDFS, чтобы обеспечить равномерное распределение данных между всеми узлами.

Мы представляем результаты как для Hadoop с кодированием вручную, так и для Hadoop с использованием Hive (т.е. планы Hadoop генерировались автоматически на основе SQL-интерфейса Hive). Эти результаты для Hadoop на диаграммах показаны путем разделения соответствующих столбцов на две части. В нижней части показано время, затраченное Hadoop при выполнении заданий, которые кодировались вручную, а верхняя часть демонстрирует дополнительные накладные расходы, затраченные на автоматическую генерацию плана системой Hive, а также на вызовы функций и динамическое разрешение типов данных через Java Reflection API при обработке каждого кортежа в задании, код которого получен путем использования Hive.

6.1.2. HadoopDB

Система Hadoop, используемая внутри HadoopDB, конфигурировалась точно так же, как описывалось в предыдущем пункте, за исключением того, что в узлах не допускалось одновременное выполнение нескольких задач map. Кроме того, в каждом рабочем узле инсталлировалась СУБД PostreSQL 8.2.5. Объем основной памяти, используемой для разделяемых буферов, был увеличен до 512 мегабайт, а объем рабочей памяти – до 1 гигабайта. Сжатие данных в PostreSQL не применялось.

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

6.1.3. Vertica

Vertica – это относительно новая параллельная система баз данных (первый выпуск вышел в 2005 г.) [3], основанная на исследовательском проекте C-Store [24]. Vertica является поколоночным хранилищем данных (column-store), т.е. каждый атрибут каждой таблицы хранится (и к нему обеспечивается доступ) по отдельности. Было показано, что этот метод позволяет повысить производительность системы на рабочих назрузках, содержащих, главным образом, запросы на выборку данных.

У системы Vertica имеется "облачная" редакция, которую мы и использовали в экспериментах, описываемых в этой статье. Vertica использовалась для сравнения производительности систем и в предыдущем исследовании [23] на том же тестовом наборе, поэтому мы конфигуривали эту систему таким же образом, как и раньше ⁶. Таким образом, у Vertica имелась следующая конфигурация. Все данные были сжаты, и Vertica работала прямо со сжатыми данными. Первичные индексы реализовывались путем сортировки таблиц по индексному атрибуту. Параметры конфигурирования Vertica, используемые по умолчанию, не изменялись.

6.1.4. СУБД-X

СУБД-X – это та же самая коммерческая система баз данных с хранением данных по строкам, которая использовалась для экспериментов в [23]. Поскольку ко времени представления этой статьи на конференцию VLDB облачной редакции этой СУБД не было, мы не могли экспериментировать с ней в среде EC2. Однако, поскольку наши эксперименты с СУБД Vertica в среде EC2 показали снижение ее производительности на 10-15% по сравнению с аналогичными экспериментами на Висконсинском кластере, описанными в [23]⁷, (этого следовало ожидать, поскольку известно, что уровень виртуализации приводит к образованию накладных расходов), в своих цифрах мы воспроизводим показатели СУБД-X из [23], считая их оценкой сверху производительности СУБД-X, если бы она работала в среде EC2.

---

⁴ Нам известно правило для авторов, запрещающее использовать ссылки на литературу в качестве имен существительных. Однако для экономиии места здесь мы используем [23] не как ссылку, а как сокращенную форму выражения "статья Павло и др. из трудов конференции SIGMOD 2009".

⁵ Сначала мы экспериментировали с MySQL (уровень хранения MyISAM). Однако мы обнаружили, что хотя простые сканирования таблиц выполнялись на 30% быстрее, более сложные запросы обрабатывались намного медленнее из-за отсутствия кластеризованных индексов и слабых алгоритмов соединения.

⁶ На самом деле, мы попросили того же человека, который пропускал запросы на Vertica в предыдущем исследовании, пропустить те же запросы в среде EC2.

⁷ В своих экспериментах мы использовали более позднюю версию Vertica, чем в [23]. Замедление в среде EC2 по-преднему сохранилось в пределах 10-15%.

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