6 миллиардов общего рынка программного
Рынок аналитических баз данных в настоящее время составляет $3,98 миллиардов , т.е. 27% от оцениваемого в $14, 6 миллиардов общего рынка программного обеспечения баз данных , и его объем ежегодно увеличивается на 10,3% . Поскольку передовые методы управления бизнесом все чаще основываются на принятии решений на основе данных и неопровержимых фактов, а не на основе интуиции и предположений, у компаний возрастает интерес к системам, которые способны управлять данными, обрабатывать их и анализировать на разных уровнях детализации. Эта тенденция хорошо известна венчурным компаниям, которые в последние годы финасировали не менее десятка новых компаний, создающих специализированное программное обеспечения для аналитического управления данными (например, Netezza, Vertica, DATAllegro, Greenplum, Aster Data, Infobright, Kickfire, Dataupia, ParAccel и Exasol), и продолжают их финансировать несмотря на трудную экономическую ситуацию.
В то же время взрывообразно возрастает объем данных, которые требуется сохранять и обрабатывать в системах аналитических баз данных. Частично это происходит из-за возрастающего уровня автоматизации производства данных (компьютеризуется все большее число бизнес-процессов), увеличения числа датчиков и других устройств, генерирующих данные, перехода на использование Web-технологий при взаимодействиях с заказчиками и нормативных требований со стороны государства, для удовлетворения которых приходится сохранять в режиме онлайн большее число исторических, пригодных для анализа данных. Нередко приходится слышать о компаниях, ежедневно загружающих в свои аналитические системы баз данных более терабайта структурированных данных и обладающих более чем петабайтными хранилищами данных .
Принимая во внимание проблему взрывообразного роста объема данных, почти все упомянутые выше начинающие компании основывают свои СУБД на архитектуре без совместно используемых ресурсов (sharing-nothing) – наборе независимых, возможно, виртуальных машин с собственными локальными дисками и основной памятью, соединенных высокоскоростной сетью. Широко распространено мнение, что такая архитектура масштабируется наилучшим образом , особенно, если принимать во внимание стоимость аппаратных средств. Кроме того, рабочие нагрузки анализа данных обычно содержат много крупных операций сканирования, многомерной агрегации и соединений со звездообразной схемой, которые сравнительно просто распараллеливаются по узлам сети без совместно используемых ресурсов. Лидер поставщиков аналитических СУБД – компания Teradata использует архитектуру без общих ресурсов. Oracle и Microsoft недавно анонсировали аналитические СУБД без общих ресурсов, созданные в проектах Exadata и Madison соответственно. В этой статье мы будем называть аналитические СУБД, основанные на архитектуре без использования общих ресурсов, параллельными системами баз данных.
Параллельные системы баз данных демонстрируют реальную масштабируемость до десятков узлов (нередко эта масштабируемость близка к линейной). Однако известно очень небольшое число установок таких систем, включающих более сотни узлов, и, насколько нам известно, ни в одной публикации не упоминались установки с тысячами узлов. Имеется ряд причин, по которым параллельные системы баз данных не масштабируются должным образом до сотен узлов. Во-первых, при возрастании числа узлов более часто возникают отказы, а параллельные системы баз данных обычно разрабатываются в том предположении, что отказы случаются редко. Во-вторых, параллельные системы баз данных обычно рассчитываются на однородные массивы машин, а при масштабировании почти невозможно добиться полной однородности. В-третьих, до настоящего времени имелось очень небольшое число приложений, для достижения требуемой производительности которых требовались установки с более чем несколькими десятками узлов. Поэтому параллельные системы баз данных просто не тестировались на установках большего масштаба, и на пути дальнейшего масштабирования могут встретиться непредвиденные инженерные трудности.
Поскольку объем данных, требующих анализа, продолжает расти, умножается и число приложений, для эффективного выполнения которых требуется более сотни узлов. Некоторые специалисты утверждают, что для выполнения анализа такого масштаба лучше всего подходят системы, основанные на MapReduce , поскольку они разрабатывались с самого начала в расчете на масштабирование до тысяч узлов в архитектуре без совместно используемых ресурсов и прордемонстрировали свои возможности при поддержке внутренних операций Google и при испытаниях на тестовом наборе TeraSort . Несмотря на свою исходную ориентацию на поддержку совсем других приложений (обработка неструктурированных текстовых данных), MapReduce (и его публично доступная инкарнация – система с открытыми исходными текстами Hadoop ) может использоваться для обработки структурированных данных и способна производить эту обработку в огромном масштабе. Например, Hadoop используется для управления 2,5-петабайтным хранилищем данных Facebook .
Однако, как отмечали Девитт (DeWitt) и Стоунбрейкер (Stonebraker) , в MapReduce отсутствуют многие характеристики, являющиеся бесценными при обработке рабочих нагрузок над стуктурированными данными, (в основном, из-за того, что изначально MapReduce не предназначался для выполнения анализа структурированных данных) и парадигма "прямой отдачи" (immediate gratification), на которой основаны системы MapReduce, препятствует получению дологовременных преимуществ от моделирования и загрузки данных до их обработки. Эти недостатки приводят к тому, что системы MapReduce в ряде случаев демонстрируют производительность, на порядок уступающую производительности параллельных систем баз данных .
В идеальном случае преимущества MapReduce в масштабируемости можно было бы объединить с преимуществами параллельных систем баз данных в проризводительности и эффективности, чтобы получить гибридную систему, которая хорошо подходила бы для рынка аналитических СУБД и отвечала бы потребностям будущих приложений аналитической обработки больших объемов данных. В этой статье мы описываем свою реализацию и экспериментальное использование HadoopDB, которая замышлялась именно как подобная гибридная система. Основная идея HadoopDB состоит в использовании MapReduce в качестве коммуникационного слоя над несколькими узлами, в которых выполяются экземпляры одноузловой СУБД. Запросы представляются на языке SQL, транслируются в MapReduce расширенными существующими средствами, и как можно большая часть работы передается в высокопроизводительные одноузловые СУБД.
Одним из не упоминавшихся ранее преимуществ MapReduce над параллельными системами баз данных является стоимость. Имеется версия MapReduce с открытыми кодами (Hadoop), которую можно получить и использовать бесплатно. При этом у всех упоминавшихся параллельных систем баз данных имеется совсем не маленькая цена, часто составляющая семизначное число для крупных установок. Поскольку наша цель состояла в объединении в гибридной системе всех преимуществ обоих подходов к анализу данных, мы решили основывать свой протитип исключительно на компонентах с открытыми исходными текстами, чтобы добиться еще и преимущества в стоимости. Поэтому мы используем PostgreSQL на уровне управления базами данных, Hadoop – на уровне коммуникаций, Hive – на уровне компиляции. Мы открываем также и весь свой собственный код .
Одним из побочных эффектов такой разработки является версия PostgreSQL без совместно используемых ресурсов. Мы с оптимизмом относимся к тому, что наш подход может потенциально содействовать преобразованию любой одноузловой СУБД в параллельную систему баз данных без общих ресурсов.
Поскольку мы стремимся к обеспечению дешевого крупномасштабного анализа данных, нашей целевой платформой являются виртуализованные публичные или частные среды "облачных вычислений" ("cloud computing"), такие как Elastic Compute Cloud (EC2) компании Amazon или частные среды, построенные на основе Cloud OS компании VMware. Установка системы в подобной среде позволяет существенно сократить начальные капитальные вложения, снизить расходы на эксплуатацию системы, предоставление ее услуг и развитие аппаратных средств (за счет максимального использования доступной аппаратуры). Использование публичных облачных сред, подобных EC2, также позволяет добиться существенной экономии при росте масштабов системы , и эта экономия частично распространяется на заказчиков. Все эксперименты, описываемые в этой статье, выполнялись в среде Amazon EC2; однако наши методы применимы и в вычислительных кластерных средах, в которых не применяется виртуализация.
Вкратце, основным вкладом нашей работы является следующее:
Мы развили предыдущие исследования , показывающие превосходство производительности параллельных систем баз данных над производительностью Hadoop. В то время как в этих предыдущих исследованиях изучалась производительность систем в идеальных условиях, мы проводили эксперименты с отказоустойчивостью и неоднородностью узлов, чтобы продемонстрировать некоторые проблемы масштабирования параллельных систем баз данных.
Мы разработали гибридную систему, обладающую преимуществами и параллельных систем баз данных, и MapReduce. Эту систему можно также использовать для выполнения одноузловых систем баз данных в среде без совместно используемых ресурсов.
Мы провели испытания этой гибридной системы на ранее опубликованном тестовом наборе, чтобы определить, насколько она близка к параллельным системам баз данных по производительности и к Hadoop – по масштабируемости.
