Сравнение подходов к крупномасштабному анализу данных

Эндрю Павло, Эрик Паулсон, Александр Разин, Дэниэль Абади, Дэвид Девитт, Сэмюэль Мэдден, Майкл Стоунбрейкер
Пересказ: Сергей Кузнецов
Оригинал: Andrew Pavlo, Erik Paulson, Alexander Rasin, Daniel J. Abadi, David J. DeWitt, Samuel Madden, Michael Stonebraker. A Comparison of Approaches to Large-Scale Data Analysis. Proceedings of the 35th SIGMOD International Conference on Management of Data, 2009, Providence, Rhode Island, USA

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

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

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

5.1. Аспекты системного уровня

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

5.1.1. Инсталляция, конфигурирование и настройка систем

Авторам удалось установить Hadoop и запустить задания без особого труда. Для установки системы потребовалось только создать на каждом узле каталоги данных и разместить системную библиотеку и конфигурационные файлы. Конфигурирование системы для обеспечения оптимальной производительности производилось методом проб и ошибок. Было обнаружено, что некоторые параметры, такие как размер буферов для сортировки и число реплик, не влияют на эффективность выполнения программ, в то время как другие параметры, например, использование блоков большего размера, способствуют значительному повышению производительности.

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

Даже после разрешения этих проблем и наличия работоспособной установки СУБД-X авторам регулярно мешали другие ограничения по памяти. Они пришли к заключению, что значения некоторых параметров, устанавливаемые по умолчанию, являются слишком заниженными для современных систем. Кроме того, СУБД-X оказалась неэффективной при регулировании распределения памяти при изменении условий. Например, система автоматически расширила буферный пул с 4 мегабайт, принятых по умолчанию, всего лишь до 5 мегабайт (позднее авторы вынудили систему расширить его до 512 мегабайт). Система также выдавала предупреждение о возможной деградации производительности при увеличении размеров динамически распределяемой памяти для сортировки до 128 мегабайт (на самом деле, производительность возросла в 12 раз). Ручное изменение некоторых параметров приводило к автоматическому изменению системой других параметров. Время от времени эта комбинация ручных и автоматических изменений выражалась в такой конфигурации СУБД-X, которая отказывалась загружаться при следующем старте системы. Поскольку для регулирования большинства конфигурационных параметров требовалось наличие работающей СУБД-X, авторы не могли обеспечить для себя устойчивый режим конфигурирования системы, позволяющий восстановить предыдущее состояние.

Vertica было сравнительно просто инсталлировать в виде пакета RPM, который размещался в каждом узле. Дополнительный конфигурационный скрипт, связанный с RPM, использовался для создания каталогов метаданных и модификации некоторых параметров ядра. Настройка базы данных является минимальной и производится через соответствующие указания менеджеру ресурсов; авторы установили, что установки по умолчанию вполне для них подходят. Однако обратной стороной этого упрощенного подхода к настройке является отсутствие явного механизма для указания того, какие ресурсы предоставляются для выполнения заданного запроса, и нет способа регулировать распределение ресурсов по запросам вручную.

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

5.1.2. Запуск задач

Было обнаружено, что при выполнении MR-программ проходит некоторое время до того, как все узлы начинают работать на полную мощность. На кластере из 100 узлов проходит 10 секунд от поступления задания в JobTracker до начала выполнения первой задачи Map и 25 секунд до того времени, когда это задание выполняется на всех узлах кластера. Это согласуется с результатами, описанными в [8], где пиковая скорость обработки данных достигалась в течении 60 секунд на кластере с 1800 узлами. «Холодный старт» характерен для реализации Hadoop (и, по-видимому, для соответствующей реализации Google), но не присущ самой модели MR. Например, авторы также обнаружили, что в предыдущих версиях Hadoop для каждого экземпляра Map и Reduce в соответствующем узле создавался новый процесс JVM, что повышало уровень накладных расходов при выполнении заданий над крупными наборами данных. Возможность повторного использования JVM в последней версии Hadoop повысила эффективность Hadoop при решении описываемых тестовых задач на 10-15%.

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

5.1.3. Сжатие

Почти во всех параллельных СУБД (включая СУБД-X Vertica) допускается опциональное сжатие хранимых данных. Нередко при сжатии данных удается сократить требуемый объем памяти в 6-10 раз. Внутреннее представление данных в Vertica в высшей степени оптимизировано для сжатия данных, и обработчик запросов работает напрямую со сжатыми данными (т.е. по мере возможности избегает распаковки данных при их обработке). Как правило, поскольку аналитические задачи над большими наборами данных часто тормозятся вводом-выводом, жертвование циклами ЦП (требуемыми для распаковки входных данных) в пользу пропускной способности ввода-вывода (сжатие данных позволяет считывать меньше данных с диска) является правильной стратегией и приводит к более быстрому выполнению задач. В ситуациях, в которых обработчик запросов может оперировать прямо со сжатыми данными, часто вообще не требуются никакие компромиссы, и сжатие, очевидно, всегда приносит пользу.

В системе Hadoop и распределенной файловой системе, на которую Hadoop опирается, поддерживается сжатие входных данных на уровне блоков и на уровне записей. Однако авторы обнаружили, что ни тот, ни другой метод не повышает производительность Hadoop, а в некоторых случаях даже замедляет выполнения программ. Кроме того, при использовании сжатия со стороны пользователей требуется больше усилий по изменению кода или подготовке входных данных. Следует также заметить, что сжатие данных не использовалось и в исходном тестовом наборе [8].

Чтобы использовать в Hadoop сжатие на уровне блоков, сначала требуется разбить файлы данных на несколько более мелких файлов в локальной файловой системе каждого узла, а затем сжать каждый файл с использованием инструмента gzip. Сжатие данных таким способом сокращает каждый набор данных на 20-25% от его исходного размера. Затем эти сжатые файлы копируются в HDFS ровно так же, как если бы они были плоскими текстовыми файлами. Hadoop автоматически определяет, когда файлы являются сжатыми, и автоматически распаковывает их «на лету», когда они передаются экземплярам Map, так что для использования сжатых данных не приходится изменять MR-программы. Несмотря на большее время загрузки (если включать в него время на разбиение и сжатие файлов), Hadoop, использующий сжатие на уровне блоков, замедляет выполнение большинства задач на несколько секунд, а задачи, для которых требуются в основном ресурсы процессора, выполнялись на 50% дольше.

Авторы также пытались выполнять тестовые задачи с использованием сжатия на уровне записей. Для этого требовалось (1) написать собственный класс tuple с использованием Hadoop API, (2) модифицировать программу загрузки данных, чтобы она сжимала записи и сериализовала получаемые кортежи, и (3) произвести рефакторинг всех тестовых задач. Вначале имелась надежда, что это позволит повысить производительность задач с высокими требованиями к ресурсам ЦП, поскольку задачам Map и Reduce больше не требовалось расщеплять поля по разделителю. Однако было установлено, что этот подход обеспечивает производительность, еще более низкую, чем сжатие на уровне блоков, сжимая данные только на 10%.

5.1.4. Загрузка и размещение данных

В параллельных СУБД имеется возможность реорганизации входных данных во время загрузки. Это позволяет производить некоторые оптимизации, такие как хранение каждого атрибута таблиц по отдельности (как это делается в поколоночных системах типа Vertica). Для запросов на выборку данных, которые затрагивают только часть атрибутов таблицы, эта оптимизация может существенно повысить производительность, позволяя не читать с диска значения атрибутов, которые не требуются для выполнения данного запроса. Аналогично описанной выше оптимизации сжатия данных, это позволяет более рационально использовать пропускную способность ввода-вывода. Системы MR по умолчанию не преобразуют данные при их загрузке в распределенную файловую систему, и поэтому они не способны изменить схему хранения входных данных, что препятствует выполнению оптимизаций отмеченного класса. Кроме того, для Hadoop всегда требовалось больше ресурсов ЦП, чем для параллельных СУБД, при пропуске эквивалентных задач, поскольку этой системе приходится разбирать и десериализовывать записи входных данных во время выполнения, в то время как параллельные системы баз данных производят разбор во время загрузки данных и могут быстро извлекать значения атрибутов кортежей практически без накладных расходов.

Но упрощенный процесс загрузки в MR гораздо проще и быстрее загрузки данных в СУБД. Результаты п. 4.2.1 и 4.3.1 показывают, что загрузка данных в Hadoop происходит более чем в три раза быстрее, чем в Vertica, и почти в 20 раз быстрее, чем в СУБД-X. Это говорит о том, что для данных, которые загружаются только для решения некоторых типов аналитических задач, может оказаться нецелесообразно тратить дополнительные расходы на их индексацию и реорганизацию, свойственные СУБД. Это также говорит о том, что СУБД могут выиграть от поддержки режима обработки данных «на месте», позволяющего пользователям непосредственно обращаться и направлять запросы к файлам, сохраняемым в локальной файловой системе.

5.1.5. Стратегии исполнения

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

Кроме того, параллельные СУБД конструируют полный план выполнения запроса, который рассылается во все обрабатывающие узла в начале выполнения запроса. Поскольку данные «проталкиваются» между узлами только при необходимости, в течение обработки отсутствуют управляющие сообщения. В отличие от этого, в системах MR используется большое число управляющих сообщений для синхронизации обработки, что ухудшает производительность из-за возрастающих накладных расходов. СУБД Vertica также свойственна эта проблема, но в гораздо меньшем масштабе (см. подраздел 4.2).

5.1.6. Модель отказов

Как обсуждалось ранее, при отсутствии поддержки транзакций MR обладает возможностью восстанавливаться после сбоев в середине выполнения запроса с применением метода, не свойственного параллельным системам баз данных. Поскольку параллельные СУБД со временем будут устанавливаться на кластерах более крупного размера, вероятность аппаратного сбоя в середине обработки запроса будет возрастать. Поэтому для долговременно обрабатываемых запросов может оказаться важно реализовать такую модель устойчивости к сбоям. Хотя повышение уровня отказоустойчивости СУБД, очевидно, является правильной идеей, авторы сомневаются в целесообразности выделения для вычислений огромных вычислительных кластеров и применения подходов «грубой силы». Более сложное программное обеспечение могло бы поддерживать ту же самую обработку с применением гораздо меньшего объема аппаратуры, потреблением гораздо меньшей энергии и меньшего времени, позволяя обойтись без сложной модели отказоустойчивости. Кластеры с многотысячными узлами от Google, Microsoft и Yahoo! потребляют громадную энергию, и как показывают результаты авторов, для многих задач обработки данных параллельные СУБД часто могут обеспечить такую же производительность при использовании меньшего числа узлов. По существу, желательный подход состоит в использовании высокопроизводительных алгоритмов с применением умеренного параллелизма, а не подходов грубой силы на гораздо более крупных кластерах.

5.2. Аспекты пользовательского уровня

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

5.2.1. Простота использования

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

Также очень важно проанализировать способ написания программистом запросов. MR-программы в Hadoop в основном пишутся на Java (хотя существуют и другие возможности). Большая часть программистов в большей степени знакома с объектно-ориентированным, императивным программированием, чем с другими языковыми технологиями, такими как SQL. Вместе с тем, SQL изучается во многих программах для студентов младших курсов, и этот язык является довольно системно-независимым – авторы смогли использовать с небольшими изменениями одни и те же SQL-команды для СУБД-X и Vertica.

Авторы установили, что, вообще говоря, для подготовки MR-программы и ее запуска в среде Hadoop требуется меньше усилий, чем при использовании других систем. Не требуется конструировать схему или регистрировать определяемые пользователями функции, чтобы можно было начать обрабатывать данные. Однако после получения начальных результатов авторы расширяли набор тестовых задач, что потребовало добавления новых столбцов в наборах данных. Для обработки этих новых данных пришлось модифицировать существующий MR-код и заново тестировать каждую MR-программу, чтобы убедиться, что все они работают при новых предположениях о схеме данных. Кроме того, некоторые методы API Hadoop были исключены в новых версиях системы, на которые пришлось перейти авторам, что опять же потребовало переписи частей программ. В отличие от этого, после построения исходных приложений на основе SQL, авторам вообще не пришлось модифицировать их код, не считая нескольких изменений в схеме тестовых данных.

Авторы полагают, что, хотя разработчикам может оказаться проще начать работать с MR, поддержка MR-программ со временем приносит разработчикам приложений существенное беспокойство. Как уже говорилось в подразделе 3.1, трудно использовать один и тот же MR-код в разных условиях или с разными наборами данных, поскольку для данных, используемых в модели MR, отсутствует явное представление схемы.

5.2.2. Дополнительные инструментальные средства

Hadoop оснащается рудиментарным Web-интерфейсом, позволяющим пользователям просматривать распределенную файловую систему и отслеживать выполнение заданий. Ко времени проведения тестовых испытаний все дополнительные инструменты, видимо, должны были бы разрабатываться пользователями собственными силами.

С другой стороны, в SQL-ориентированных системах имеется огромное количество инструментальных средств и приложений для построения отчетов и анализа данных. Целые программные индустрии разрабатывают расширения СУБД. Эти инструментальные средства поддерживают (1) визуализацию данных, (2) интеллектуальный анализ данных, (3) репликацию данных и (4) автоматизацию проектирования баз данных. Поскольку технологии MR находятся в стадии зарождения, рынок такого программного обеспечения для MR ограничен; однако по мере роста пользовательской базы многие из существующих SQL-ориентированных средств, вероятно, станут поддерживать системы MR.

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