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

Эндрю Павло, Эрик Паулсон, Александр Разин, Дэниэль Абади, Дэвид Девитт, Сэмюэль Мэдден, Майкл Стоунбрейкер
Пересказ: Сергей Кузнецов
Оригинал: 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

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

6. Заключение

На основе результатов, представленных в этой статье, можно сделать ряд интересных выводов. Во-первых, в масштабе выполненных экспериментов обе параллельные системы продемонстрировали существенное превосходство в производительности над Hadoop при выполнении ряда тестовых задач анализа данных большого объема. В среднем для всех пяти задач на кластере из 100 узлов СУБД-X оказалась в 3.2 раза быстрее MR, а Vertica – в 2.3 раза быстрее СУБД-X. Хотя авторы не могут проверить это утверждение, они полагают, что те же относительные показатели производительности сохранились бы и на кластере с 1000 узлов (самая крупная конфигурация Teradata на кластере с менее чем 100 узлами управляет данными объемом более четырех петабайт). Эти цифры можно истолковать так, что параллельные системы баз данных, обеспечивающие то же самое время отклика при использовании меньшего числа процессоров, безусловно, будут потреблять намного меньше энергии; модель MapReduce на кластере с несколькими тысячами узлов является решением грубой силы, растрачивающим огромные объемы энергии. Хотя ходят слухи, что версия MR от Google быстрее версии Hadoop, у авторов статьи не было доступа к этому коду, и поэтому они не могли его протестировать. Однако они сомневаются, что эти две версии MR показали бы существенную разницу в производительности, поскольку MR вынуждает всегда начинать выполнение запроса с просмотра всего входного файла.

Это преимущество в производительности, свойственное обеим системам баз данных, является результатом применения ряда технологий, разработанных в последние 25 лет, включая (1) индексы в виде B-деревьев, ускоряющие выполнение операций выборки, (2) новые механизмы хранения данных (например, поколоночное хранение), (3) эффективные методы сжатия данных с возможностью выполнять операции прямо над сжатыми данными, (4) сложные параллельные алгоритмы для выполнения запросов над большими объемами реляционных данных. В случае применения поколоночных систем баз данных, подобных Vertica, с диска считываются только те столбцы, которые требуются для выполнения запроса. Кроме того, поколоночное хранение позволяет добиться лучших показателей сжатия данных (в Vertica они сжимаются примерно в 2.0 раза, в СУБД-X – в 1.8 раз, а в Hadoop – в 1.25 раз). Это тоже способствует сокращению объема дискового ввода-вывода при выполнении запросов.

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

Еще одной областью, в которой во время тестирования систем баз данных были обнаружены недостатки, является расширяемость. Идее расширения СУБД определяемыми пользователями типами и функциями уже 25 лет [16]. Тем не менее, ни одна из тестируемых параллельных систем не смогла хорошо справиться с задачей агрегации с применением UDF, заставив авторов искаться обходные пути при обнаружении ограничений (например, в Vertica) или ошибок (например, в СУБД-X).

Хотя системы баз данных устойчивы к разнообразным программным сбоям, нет никаких сомнений, что MR лучше справляется с минимизацией потерь уже выполненной работы при возникновении аппаратных сбоев. Однако эта возможность потенциально сопровождается крупным ухудшением производительности из-за расходов на материализацию промежуточных файлов между фазами Map и Reduce. Пока неясно, насколько существенно это ухудшение. К сожалению, для должного исследования этого вопроса требуется реализация в одной среде стратегий с материализацией и без нее, а такая работа не предусматривалась в исследованиях, которым посвящена данная статья. Несмотря на очевидное преимущество Hadoop в этой области, не совсем ясно, насколько существенна устойчивость систем к аппаратным сбоям при их реальном практическом использовании. Кроме того, если для системы MR требуется 1000 узлов для достижения производительности параллельной системы баз данных, работающей на ста узлах, то для первой системы вероятность отказа узла при обработке запроса в десять раз больше, чем для второй. Тем не менее, от улучшенной устойчивости не отказался бы ни один пользователь баз данных.

Многие люди считают, что SQL поначалу трудно использовать. Частично это связано с тем, что при решении проблем с использованием SQL требуется несколько иной стиль мышления, и с тем, что SQL превратился в сложный язык, который существенно отличается от исходной разработки, выполненной Доном Чемберлином (Don Chamberlin) в 1970-х гг. Хотя большинство языков со временем усложняется, SQL особенно плох, поскольку многие его средства разрабатывались конкурирующими компаниями-поставщиками СУБД, каждая из которых стремилась включить в язык собственные проприетарные расширения.

Несмотря на свои недостатки, SQL по-прежнему является мощным инструментом. Рассмотрим запрос для генерации списка служащих, упорядоченного по заработной плате, причем для каждого служащего должен указываться еще и уровень его зарплаты (уровень зарплаты служащих, получающих максимальную зарплату, равен единице). На SQL этот запрос можно сформулировать следующим образом:

SELECT Emp.name, Emp.salary,
       RANK() OVER (ORDER BY Emp.salary)
FROM Employees AS Emp

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

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

По мнению авторов, для обоих видов систем можно еще многое сделать. Наиболее важны появление над базисным уровнем MR интерфейсов более высокого уровня, таких как Pig [15] и Hive [2], а также разработка инструментов, близких по духу к MR, но более выразительных, таких как Dryad [13] и Scope [5]. Это упростит кодирование сложных задач в MR-подобных системах и устранит одно из больших преимуществ SQL-ориентированных систем – меньшие трудозатраты на кодирование задач. Что касается параллельных систем баз данных, как коммерческих, так и с открытыми исходными текстами, авторы полагают, что в них будет существенно усовершенствован параллелизм функций, определяемых пользователями. Таким образом, API обеих классов систем, очевидно, сближаются. Первыми признаками этого являются решения по интеграции SQL и MR от компаний Greenplum и Asterdata.

7. Благодарности

Авторы хотели бы поблагодарить Лакшмиканта Шриниваса (Lakshmikant Shrinivas) на помощь в приведении СУБД-X в работоспособное состояние, а также Криса Олстона (Chris Olston) и рецензентов за их глубокие комментарии и обратную связь. Эта работа частично поддерживалась грантом NSF CluE - 0844013/0844480.

8. Литература

1. Hadoop. http://hadoop.apache.org/.
2. Hive. http://hadoop.apache.org/hive/.
3. Vertica. http://www.vertica.com/.
4. Y. Amir and J. Stanton. The Spread Wide Area Group Communication System. Technical report, 1998.
5. R. Chaiken, B. Jenkins, P.-A. Larson, B. Ramsey, D. Shakib, S. Weaver, and J. Zhou. Scope: easy and efficient parallel processing of massive data sets. Proc. VLDB Endow., 1(2):1265–1276, 2008.
6. Cisco Systems. Cisco Catalyst 3750-E Series Switches Data Sheet, June 2008.
7. J. Cohen, B. Dolan, M. Dunlap, J. M. Hellerstein, and C. Welton. MAD Skills: New Analysis Practices for Big Data. Under Submission, March 2009.
8. J. Dean and S. Ghemawat. MapReduce: Simplified Data Processing on Large Clusters. In OSDI ’04, pages 10–10, 2004.
9. D. J. DeWitt and R. H. Gerber. Multiprocessor Hash-based Join Algorithms. In VLDB ’85, pages 151–164, 1985.
10. D. J. DeWitt, R. H. Gerber, G. Graefe, M. L. Heytens, K. B. Kumar, and M. Muralikrishna. GAMMA - A High Performance Dataflow Database Machine. In VLDB ’86, pages 228–237, 1986.
11. S. Fushimi, M. Kitsuregawa, and H. Tanaka. An Overview of The System Software of A Parallel Relational Database Machine. In VLDB ’86, pages 209–219, 1986.
12. S. Ghemawat, H. Gobioff, and S.-T. Leung. The Google File System. SIGOPS Oper. Syst. Rev., 37(5):29–43, 2003.
13. M. Isard, M. Budiu, Y. Yu, A. Birrell, and D. Fetterly. Dryad: Distributed Data-parallel Programs from Sequential Building Blocks. In EuroSys ’07, pages 59–72, 2007.
14. E. Meijer, B. Beckman, and G. Bierman. LINQ: reconciling object, relations and XML in the .NET framework. In SIGMOD ’06, pages 706–706, 2006.
15. C. Olston, B. Reed, U. Srivastava, R. Kumar, and A. Tomkins. Pig Latin: A Not-So-Foreign Language for Data Processing. In SIGMOD ’08, pages 1099–1110, 2008.
16. J. Ong, D. Fogg, and M. Stonebraker. Implementation of data abstraction in the relational database system ingres. SIGMOD Rec., 14(1):1–14, 1983.
17. D. A. Patterson. Technical Perspective: The Data Center is the Computer. Commun. ACM, 51(1):105–105, 2008.
18. R. Rustin, editor. ACM-SIGMOD Workshop on Data Description, Access and Control, May 1974.
19. M. Stonebraker. The Case for Shared Nothing. Database Engineering, 9:4–9, 1986.
20. M. Stonebraker and J. Hellerstein. What Goes Around Comes Around. In Readings in Database Systems, pages 2–41. The MIT Press, 4th edition, 2005.
21. D. Thomas, D. Hansson, L. Breedt, M. Clark, J. D. Davidson, J. Gehtland, and A. Schwarz. Agile Web Development with Rails. Pragmatic Bookshelf, 2006.

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