К свободе от проблемы Больших Данных

Сергей Кузнецов

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

Так что сегодняшний всплеск ажиотажа вокруг проблемы больших данных во многом является искусственным. С имеющимися сегодня большими данными трудно (или невозможно) работать ученым, бизнес-аналитикам и т.д., но обычно они забывают о том, что вчера им было трудно (или невозможно) работать с вчерашними большими данными, объемы или специфика которых сегодня проблему не порождают. С большой вероятностью завтра проблему не будут порождать сегодняшние большие данные, но проявится проблема завтрашних больших данных.

Вечность и призрачность проблемы вряд ли позволяет рассчитывать на ее полное и окончательное решение. Это плохо для пользователей и разработчиков приложений, но гарантирует постоянную занятость в будущем исследователей и разработчиков систем управления данными ☺. Конечно, их деятельность напоминает попытки моряков доплыть до заманчивого миража, навеянного Фата-Морганой, но в данном случае сами эти попытки весьма увлекательны и полезны, поскольку худо-бедно поддерживают общее развитие человечества. Более того, иногда удается найти решение частных, но чрезвычайно важных случаев проблемы больших данных. Речь идет о тех категориях данных, для управления которыми традиционно предназначены СУБД.

Как с большими данными справляются перспективные СУБД

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

Проблеме больших данных подвержены обе эти категории баз данных. Объемы транзакционных баз данных возрастают из-за развития оперативных потребностей пользователей, бизнеса или науки. Например, транзакционные базы данных Internet-магазинов значительно увеличиваются в объеме при внедрении технологии персонализации услуг. Объемы аналитических баз данных увеличиваются, прежде всего, из-за своей природы: данные в них всегда только накапливаются и никогда не уничтожаются. Другой серьезной причиной роста объема аналитических баз данных является потребность бизнес-аналитиков в привлечении новых источников данных (например, данных, черпаемых из открытых Internet-источников).

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

В первом десятилетии нового века исследователям во главе с одним из пионеров технологии баз данных Майклом Стоунбрейкером (Michael Stonebraker) удалось нащупать пути решений обоих частных случаев проблемы. В основе обоих решений лежат следующие общие принципы:

1. перенос вычислений как можно ближе к данным;
2. использование архитектуры без совместно используемых ресурсов (sharing nothing);
3. эффективное разделение данных по узлам вычислительной системы с возможностью их репликации в нескольких узлах.

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

Сразу стоит сказать, что все три принципа далеко не новы. Скорее всего, их появление можно датировать 80-ми годами прошлого века. Например, на принципах sharing nothing основывалась популярная и в высшей степени эффективная параллельная СУБД Teradata, которая успешно используется на протяжении нескольких десятков лет. Однако именно в наше время отмеченные три принципа удалось успешно применить при создании реально масштабируемых параллельных транзакционных и аналитических СУБД.

Применение этих принципов является необходимым, но не достаточным для реализации обеих категорий систем. В каждом случае приходится применять некоторые дополнительные идеи. В частности, транзакционные параллельные СУБД оказывается выгодно основывать на давно известных идеях управления базами данных в основной памяти, а для обеспечения надежности данных применять развитую репликацию. В аналитических же системах более выгодно применять технологию хранения табличных данных во внешней памяти по столбцам в совокупности с поддержкой разнообразных избыточных структур данных. (Идеи хранения данных по столбцам тоже совсем не новы и ранее применялись, например, в аналитической СУБД Sybase IQ.)

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

Как уже отмечалось, понятие больших данных является относительным. В частности, большие транзакционные данные по объему на несколько порядков уступают большим аналитическим данным. Из уважения к житейскому понятию слова «большой», далее я сосредоточусь на больших аналитических данных (хотя с технической и практической точек зрения транзакционные большие данные заслуживают не меньшего внимания).

Масштабируемая параллельная серверная бизнес-аналитика

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

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

Как это сделать? Единственным распространенным методом параллельного программирования в кластерной среде является использование интерфейса MPI — интерфейса передачи сообщений. В этом случае программист сам решает, как расположить отдельные параллельно выполняемые части своей программы в узлах кластеров и как обеспечить их взаимодействие для формирования окончательного результата. Известно, что программирование с использованием интерфейса MPI представляет собой большую сложность даже для профессионально подготовленных программистов. Можем ли мы сделать профессиональными программистами бизнес-аналитиков, которым гораздо ближе математическая статистика, а не методы параллельного программирования? Скорее всего, типичный аналитик, которому будет предложено приступить к решению такой задачи, предпочтет пользоваться старыми добрыми пакетами аналитических программ на своей рабочей станции, что в корне загубит всю идею горизонтальной масштабируемости систем. На первый взгляд, эта проблема кажется неразрешимой, равно как неразрешимой кажется и более общая проблема обеспечения удобных и эффективных средств параллельного программирования для программистов широкого профиля.

Однако не так давно удалось найти подход и к решению этой проблемы, по крайней мере, первой ее части (здесь следует отметить заслуги разработчиков параллельных СУБД Greenplum и Asterdata). Это решение основывается на применении технологии MapReduce.

Напомним, что технология MapReduce появилась в недрах компании Google в качестве замены аналитическим параллельным СУБД для решения собственных аналитических задач. Технология быстро обрела популярность среди многих практиков, особенно молодежи, и поначалу вызвала глубокое возмущение в сообществе баз данных. Авторитетные специалисты из этой области утверждали, что MapReduce — это возврат к доисторическому времени, когда для решения проблем управления данными требовалось явное программирование, и упрекали сторонников MapReduce в невежестве и неразумном отрицании серьезных результатов прошлых лет. Скорее всего, эти доводы были и остаются правильными. Технология MapReduce не может и не должна заменить технологию баз данных. Но оказалось, что эта технология может быть чрезвычайно полезной, если ее применить внутри самой параллельной аналитической СУБД для поддержки параллельного программирования и выполнения аналитических функций, поставляемых пользователями.

MapReduce концептуально несравненно проще, чем MPI. Программисту нужно понимать только одну идею — что данные надо сначала распределить по узлам кластера, а потом обработать. Результат обработки можно снова распределить по узлам кластера и снова обработать и т.д. От программистов приложений требуется всего лишь обеспечить программный код двух функций — функции map, обеспечивающей разделение данных по узлам кластера, и функции reduce, обеспечивающей обработку данных в полученных разделах. Конечно, такая парадигма программирования гораздо проще для непрофессиональных программистов, чем MPI, но, что еще более важно, она должна быть понятийно близка аналитикам.

Традиционная аналитика или то, что мы привыкли называть аналитикой, имеет дело с данными, явно или неявно представляемыми в виде многомерного куба. Первый и, по видимому, революционный шаг на пути к обеспечению аналитической обработки табличных SQL-ориентированных данных, в свое время обеспечивала работа незабвенного Джима Грея (Jim Gray), в которой он предложил оператор roll up, позволяющий динамически построить многомерный куб в реляционной базе данных. Именно Джим Грей, во-первых, понял, что традиционный оператор group by позволяет получить грань многомерного куба, а общая процедура построения многомерного куба сводится к повторному выполнению оператора group by до тех пор, пока не будет получено нужное число измерений. Во-вторых, Джим Грей первым понял, что для выполнения операции roll up требуется столько же усилий, сколько и для выполнения простого group by. Что же такое тогда аналитика в контексте SQL-ориентированной СУБД? Грубо говоря, она сводится к применению различных агрегатных аналитических функций к граням куба.

Заметим, что операцию group by можно было бы с успехом считать операцией «партиционирования» таблицы в соответствии со значениями заданного столбца группировки. После этого можно было бы легко обрабатывать полученные группы параллельно. Можно считать, что функция map в программе MapReduce — это обобщенный оператор group by, обеспечивающий разделение исходных данных по некоторым явно запрограммированным пользователем правилам. Функцию reduce можно считать обобщением агрегатной фунции в SQL. Получается, что аналитик при написании новой аналитической функции не обязан выходить за пределы того набора понятий, к которому он привык, работая с традиционной аналитической СУБД.

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

И в этом месте хочется сделать одно крамольное замечание. Фактически, в новом поколении аналитических параллельных СУБД обеспечивается возможность параллельного программирования аналитических приложений, которое проще и понятней для неподготовленных специалистов, чем традиционный интерфейс MPI. Т.е. фактически частично решается более общая проблема — проблема параллельного программирования для суперкомпьютеров. Встает вопрос, а не заслуживает ли этот подход более широкого использования, чем расширение аналитического параллельного сервера баз данных? Не стоит ли попытаться применять технологию MapReduce для программирования параллельных задач, требующих обработки больших объемов данных? Как я уже сказал, это замечание крамольно, но меня не оставляет мысль, что как большие данные почти всегда бессмысленны без больших вычислений, так и большие вычисления чаще всего невозможны без поддержки эффективного доступа к большим данным. Не стоит ли об этом задуматься?