Массивно-параллельные системы обработки (massively parallel processing, MPP) данных существовали на протяжении десятилетий.

Хотя архитектуры отдельных поставщиков могут варьироваться, массивно-параллельная обработка — наиболее развитой, проверенный и широко используемый механизм хранения и анализа больших объемов данных. Так что же собой представляет массивно-параллельная архитектура и что в ней особенного?

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

Рис. 4.3. Массивно-параллельная система обработки данных

В чем преимущество такой архитектуры? Представьте себе движение по шестиполосному шоссе. Если эти шесть полос сойдутся в одну, пусть даже на коротком участке дороги, движение будет сильно затруднено. Если шесть полос остаются открытыми на всем протяжении пути от отправной точки до места назначения, то поездка будет гораздо более комфортной. В часы пик на дороге могут возникать пробки, но они будут меньше и очень скоро рассосутся. В случае с традиционной архитектурой базы данных в процессе обработки существует по крайней мере несколько точек, в которых количество полос сокращается до одной. Одной полосы может быть достаточно, только если объем движения небольшой. Именно это делает архитектуру MPP незаменимой для анализа больших объемов данных: она позволяет всем полосам оставаться открытыми на протяжении всего процесса.

Рассмотрим пример из мира баз данных. Традиционная база данных будет опрашивать терабайтную таблицу по одной строке за раз. Однако при использовании массивно-параллельной системы с 10 обрабатывающими устройствами данные разбиваются на 10 независимых фрагментов по 100 гигабайт. Это означает, что одновременно выполняется 10 запросов. При необходимости в большей вычислительной мощности и более высокой скорости просто добавьте дополнительные обрабатывающие устройства.

Разделяйте работу!

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

Если бы система в нашем примере включала 20 обрабатывающих устройств, то вместо 10 фрагментов по 100 гигабайт одновременно обрабатывалось бы 20 независимых фрагментов по 50 гигабайт, что увеличило бы производительность. Дело несколько усложняется, когда выполнение запроса требует перемещения данных между процессорами, однако массивно-параллельные системы очень быстро справляются и с этой задачей (см. рис. 4.4).

Рис. 4.4. Сравнение традиционного и MPP-запроса

При использовании MPP-систем данные не хранятся в одном месте, что облегчает восстановление в случае выхода оборудования из строя.

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

Использование MPP-систем для подготовки данных и скоринга

Причина, по которой МРР-система может оказаться столь полезной в сфере передовой аналитики, заключается в том, что бoльшая часть неудобств, связанных с обработкой, приходится на этап подготовки данных, которая включает соединение, агрегирование, деривацию и преобразование.

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

Логика большинства задач, связанных с подготовкой данных, относительно проста. Для решения именно таких задач и предназначены реляционные базы данных и их родной язык, известный как язык структурированных запросов (structured query language — SQL).

Современный SQL может справиться с большинством, если не со всеми, задач подготовки данных, необходимыми для анализа. Именно использование SQL положило начало развитию аналитики, встроенной в базу данных, в MPP-системах. Аналитики просто поместили задачи в базу данных, написав их на SQL, вместо того чтобы писать их на аналитическом языке, что потребовало бы извлечения информации из базы данных.

Еще 10 лет назад SQL имел некоторые ограничения, когда речь шла об определенных сложных вычислениях, необходимых для поддержки передовой аналитики. Сегодня это язык гораздо более мощный. Старое правило, согласно которому при работе с конкретной строкой запрос не учитывает данные в других строках, уже не действует. Например, существуют SQL-функции, называемые «оконными» (windowed aggregates), которые при обработке конкретной строки позволяют запросу учесть данные, находящиеся в другом месте. При помощи таких функций запрос, например, может узнать, является ли данная транзакция первой или последней для клиента, и предпринимать разные действия при обработке данных. Такая функциональность позволяет SQL решать множество дополнительных сложных задач обработки, которые ставят средства передовой аналитики в процессе подготовки данных.

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

Не стоит недооценивать SQL

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

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

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

Обработка в базе данных применяется при проведении скоринга. Модели часто строятся на основе выборки, однако скоринг подразумевает работу со всеми данными. Например, модель склонности может быть построена на основе выборки клиентов, однако, когда придет время для использования модели, необходимо будет оценить каждого клиента, чтобы выбрать среди них тех, кто наберет наибольшее количество баллов, и нацелить на них маркетинговую кампанию. В таких случаях старые методы извлечения всей информации из базы данных могут быть малопригодными, а то и невозможными из-за временны' х затрат.

Рассмотрим более подробный пример. Допустим, розничный торговец построил модель склонности, чтобы выявить клиентов, которые, скорее всего, отреагируют на рекламную акцию. Такая модель часто строится на основе репрезентативной выборки, включающей несколько сотен тысяч потребителей. Те, кто отреагировал на специальное предложение в прошлом, сравниваются с теми, кто этого не сделал. Модель создает алгоритм скоринга, который будет вычислять вероятность отклика каждого клиента.

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

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

На сегодняшний день существует не менее четырех основных способов проведения подготовки данных и скоринга в базе данных: 1) модель проталкивания SQL; 2) функции, определенные пользователем (UDF); 3) встроенные процессы и 4) язык разметки для прогнозного моделирования (PMML).

Модель проталкивания SQL

SQL — родной язык для MPP-системы, и он отвечает широкому спектру требований. Это особенно касается агрегирования, соединения и преобразования данных. Многие основные задачи, связанные с подготовкой данных, могут быть переведены на язык SQL пользователем. Либо аналитический инструмент может генерировать SQL-код от имени пользователя и «протолкнуть» его в базу данных. Код SQL также легко генерируется многими аналитическими алгоритмами, обладающими довольно простой логикой. К этой категории относятся линейная регрессия, логистическая регрессия и деревья решений. Аналитические инструменты часто переводят логику модели на язык SQL. Иногда пользователи самостоятельно пишут SQL-сценарий после создания модели. В любом случае подготовка данных или процессы скоринга в конечном счете выполняются только с использованием SQL.

Функции, определенные пользователем

Функции, определенные пользователем (UDF), — относительно новая особенность реляционных баз данных. Возможности UDF выходят за рамки возможностей языка SQL. Определенные пользователем функции расширяют функциональность языка SQL, позволяя пользователю определить логику задачи, которая выполняется так же, как и родная SQL-функция.

Запрос общего объема продаж по каждому потребителю может быть записан следующим образом:

«Select Customer, Sum(Sales)...»

При использовании определенных пользователем функций запрос на проведение скоринга потерь может быть записан так:

«SelectCustomer, Attrition_Score...»

В последнем примере «Attrition_Score» — определенная пользователем функция, имеющаяся в системе базы данных. UDF применяет к данным необходимую логику, и эта логика может быть значительно более сложной, чем в случае использования только языка SQL.

Функции, определенные пользователем, пишутся на таких языках, как C++ или Java. В результате в них могут быть встроены некоторые процедурные возможности языка. Это расширяет ядро SQL, которое не имеет таких возможностей. Сложность заключается в том, что многие профессиональные аналитики не умеют писать программы на этих языках. И тогда на помощь приходят аналитические инструменты, которые автоматически генерируют соответствующие определенные пользователем функции и загружают их в базу данных, подготавливая к использованию.

Встроенные процессы

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

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

Язык разметки для прогнозного моделирования

Язык разметки для прогнозного моделирования (рredictive modeling markup language, PMML) — способ передачи результатов моделирования от одного инструмента другому. Концептуально он вмещает минимальное количество информации, необходимой для создания фрагмента кода в целях скоринга. Информация, включаемая в PMML-поток, содержит тип модели, имена переменных и их форматы, а также значения параметров. Язык PMML позволяет аналитикам использовать любой из PMML-совместимых инструментов для построения модели. Если инструмент PMML-совместим, а для проведения скоринга предполагается использование другого PMML-совместимого инструмента, просто передайте код PMML от первого инструмента второму, и второй инструмент автоматически сгенерирует процесс скоринга.

Один из недостатков PMML проявляется не сразу. В системе, где применяется код PMML, должны присутствовать такие же переменные в том же формате, как и в системе, где была построена модель и сгенерирован PMML-код. Предположим, что в разработанной модели применялась входная переменная «SumOfSales», содержавшая общий объем продаж по каждому клиенту в числовом формате. Переменная «SumOfSales» также должна присутствовать в виде числовой переменной в системе, где будет использоваться код PMML. Для этого в данной системе ее необходимо воссоздать.

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

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

Технологию PMML следует понимать правильно

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

Более поздние версии языка PMML дают возможность решить некоторые задачи подготовки данных с его помощью, однако на то, чтобы решить все изложенные здесь проблемы, уйдет еще много времени. Из-за его ограничений язык PMML останется наименее часто используемым вариантом.

Итоги

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

Любой организации, которая стремится улучшить масштабируемость аналитической системы, следует обратить внимание на сферу MPP. В связи с увеличением объема данных перемещать их в процессе анализа нецелесообразно, за исключением тех случаев, когда это абсолютно необходимо. Дополнительная масштабируемость также значительно увеличивает широту и объем аналитических процессов, которые организация может использовать. Эти дополнительные процессы применимы к традиционным данным, большим данным или к их комбинации.

Перед тем как завершить этот раздел, мы должны остановиться на следующем. Хотя мы касались в основном корпоративных хранилищ данных, большинство поставщиков MPP-систем сегодня предлагают «устройства», которые представляют собой уменьшенные версии их систем корпоративного класса. Они предназначены для специальных целей, например для команды аналитиков, которым необходимо обрабатывать огромные объемы данных. Устройства часто бывают созданы для обработки одного или двух рабочих потоков, а корпоративное хранилище данных поддерживает многопоточность.

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

Укрощение больших данных: как извлекать знания из массивов информации
с помощью глубокой аналитики / Билл Фрэнкс. - М.: Манн, Иванов и Фербер, 2014.
Опубликовано с разрешения издательства