МОГучие способности: новые приемы анализа больших данных

Джеффри Коэн, Брайен Долэн, Марк Данлэп, Джозеф Хеллерстейн, Кейлэб Велтон.
Перевод: Сергей Кузнецов

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

6. МОГучая СУБД

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

6.1. Загрузка и выгрузка

Важность высокоскоростной загрузки и выгрузки данных для крупных параллельных СУБД подчеркивалась более десяти лет тому назад [1], и сегодня эти аспекты еще более важны. Аналитики часто загружают новые данные, и нередко им нравится "размазывать" наборы данных между системами (например, между СУБД и кластером Hadoop) для решения конкретных задач. Поскольку аналитики очищают данные и повышают их качество, а также используют их в процессах разработки аналитических методов, эти данные часто применяются при решении разных задач. Если время загрузки данных измеряется в днях, поток работ аналитиков качественно меняется. Задержки такого рода отталкивают данные от хранилища данных.

Кроме обеспечения быстрой загрузки данных в базу данных, СУБД, хорошо подходящая для MAD-аналитики, должна позволять пользователям базы данных выполнять запросы прямо над внешними таблицами: строки подаются из файлов или от сервисов, к которым происходит доступ по требованию во время обработки запросов. За счет непосредственного и параллельного доступа к внешним данным правильно организованная СУБД может устранить накладные расходы на загрузку данных и поддержку их актуального состояния. Внешние таблицы ("обертки", "wrapper") обычно обсуждаются в контексте интеграции данных [18]. Но в контексте МОГучего хранилища данных главным является массивно-параллельный доступ к файловым данным, располагающимся в локальной высокоскоростной сети.

В Greenplum полностью параллельный доступ при загрузке данных и обработке запросов над внешними таблицами реализуется на основе метода потоковой передачи данных с их рассеиванием и сбором (Scatter/Gather Streaming). Эта идея напоминает идею внутренней организации традиционных баз данных без общих ресурсов (sharing-nothing) [7], но в данном случае требуется координация с внешними процессами, чтобы параллельно "подпитывать" данными все узлы СУБД. Когда в систему поступает поток данных, эти данные могут размещаться в таблицах базы данных для последующего доступа или использоваться непосредственно как данные внешней таблицы с параллельным вводом-выводом. При использовании этой технологии заказчики Greenplum достигают скорости загрузки полностью зеркалируемой производственной базы данных в четыре терабайта в час при незначительном влиянии на операции, одновременно выполняемые над той же базой данных.

6.1.1. ETL и ELT

Для поддержки традиционных хранилищ данных используются специальные инструментальные средства, выполняющие задачу извлечения-преобразования-загрузки (Extract-Transform-Load, ETL) данных. В последние годы наблюдается расширяющаяся тенденция к переносу работы по преобразованию данных в СУБД, чтобы обеспечить возможность ее параллельного выполнения на основе использования трансформационных SQL-скриптов. Этот подход получил название ELT, поскольку преобразование данных производится после их загрузки. Подход ELT становится еще более естественным при использовании внешних таблиц. Трансформационные запросы можно написать по отношению к внешним таблицам, что устраняет потребность в загрузке непреобразованных данных. Это может существенно ускорить цикл разработки преобразований – в особенности, в сочетании с использованием при отладке преобразований раздела SQL LIMIT как "средства онлайновой агрегации для бедных" [11].

В дополнение к преобразованиям, представляемым на SQL, в Greenplum поддерживаются скрипты MapReduce внутри СУБД; они могут запускаться над внешними данными на основе Scatter/Gather или же над таблицами базы данных (подраздел 6.3). Это позволяет программистам писать трансформационные скрипты в стиле программирования потоков данных, используемом во многих средствах ETL, и выполнять их в требуемом масштабе на основе средств распараллеливания, которые поддерживаются в СУБД.

6.2. Эволюция данных: хранение и разделение

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

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

В Greenplum обеспечивается несколько механизмов хранения данных. Развитые средства спецификации разделения данных языка SQL позволяют применять эти механизмы к таблицам целиком или их частям. Как отмечалось ранее, в Greenplum поддерживаются внешние таблицы. Также обеспечивается формат хранения вида "кучи" для часто обновляемых данных и возможность хранения таблиц в сильно сжатой форме, оптимизированной для выполнения операций добавления данных ("append-only", AO), для которых не предполагаются операции обновления. Оба эти механизма хранения данных интегрированы в транзакционную инфраструктуру. Для единиц хранения типа AO допускаются различные режимы сжатия. В одном крайнем случае, когда сжатие отключается, очень быстро выполняется загрузка массивных данных. При другой крайности используются наиболее действенные режимы сжатия, позволяющие расходовать как можно меньше пространства области хранения. Имеются и компромиссные режимы "среднего" сжатия, обеспечивающие эффективный просмотр таблиц для счет небольшого замедления загрузки. В последней версии Greenplum также появилось идейно близкое [20] "поколоночное" разделение таблиц, ориентированных на добавление данных. Это способствует повышению уровня сжатия и гарантирует, что при выполнении запросов над крупными архивными таблицами из внешней памяти будут считываться только требуемые столбцы.

Администратор базы данных может гибким образом специфицировать требуемый механизм хранения. В Greenplum поддерживается много способов разделения таблиц с целью повышения производительности выполнения запросов и загрузки данных, а также содействия управлению крупными наборами данных. Самым верхним уровнем разделения является политика распределения (distribution policy), специфицируемая в разделе DISTRIBUTED BY оператора CREATE TABLE и определяющая, каким образом строки таблицы распределяются по отдельным узлам кластера Greenplum. В то время, как у всех таблиц имеется политика распределения, пользователь опционально может специфицировать для таблицы политику разделения (partitioning policy), которая разъединяет данные таблицы в разделы по диапазону или по списку. Политика разделения по диапазону позволяет пользователю специфицировать упорядоченный набор неперекрывающихся разделов для столбца разделения. У каждого раздела имеются начальное (START) и конечное (END) значения. Политика разделения по списку позволяет пользователю специфицировать набор разделов для некоторой совокупности столбцов, причем каждый раздел соответствует некоторому конкретному значению. Например, таблица sales может быть хэш-распределена по узлам по sales_id. Кроме того, в каждом узле строки могут быть разъединены по диапазону в разделы по месяцам, а строки в каждом из этих разделов могут быть дополнительно разъединены по трем регионам продаж. Заметим, что структура разделения полностью поддается изменениям: в любой момент времени пользователь может добавлять новые разделы или удалять существующие разделы или подразделы.

Разделение таблиц важно по ряду причин. Во-первых, оптимизатор запросов осведомлен о структуре разделения и может анализировать предикаты с целью исключения разделов (partition exclusion): сканировать только некоторый поднабор разделов, а не таблицу целиком. Во-вторых, у каждого раздела таблицы может иметься свой формат хранения в соответствии с ожидаемой рабочей нагрузкой. Типичная схема состоит в разделении таблицы по полю временной метки и хранении старых разделов в сильно сжатом формате, ориентированном только на добавление данных, а более новых ("более горячих") разделов – в формате, в большей степени допускающем обновления данных. В-третьих, становится возможным атомарный обмен разделами (atomic partition exchange). Вместо того, чтобы вставлять в таблицу по одной строке за раз, пользователь может воспользоваться ETL или ELT для размещения своих данных в некоторой временной таблице. После того, как данные очищены и преобразованы, можно воспользоваться командой ALTER TABLE ... EXCHANGE PARTITION для привязки этой временной таблицы в качестве раздела существующей таблицы путем выполнения быстрой атомарной операции. Эта возможность делает разделение особенно полезным для организаций, которые выполняют ежедневные, еженедельные или ежемесячные массивные загрузки данных, и в особенности в тех случаях, когда они удаляют или архивируют старые данные для поддержки в хранилище данных в оперативном режиме некоторого окна данных фиксированного размера. Та же идея позволяет пользователям осуществлять физическую миграцию таблиц и модифицировать форматы хранения, ограждая производственные таблицы от накладных расходов загрузки и преобразования данных.

6.3. МОГучее программирование

Хотя в подходе MAD предпочтение отдается быстрому импорту и частому использованию данных, а не их тщательному моделированию, это не означает отказа от структурированных баз данных как таковых. Как отмечалось в разд. 4, средства СУБД управления структурированными данными могут быть очень полезны для организации экспериментальных данных, пробных наборов данных и экспериментальных потоков работ. На самом деле, на предприятиях, в которых используются инструменты типа Hadoop, обычно имеются также СУБД, и/или развертываются легкие системы баз данных типа Hive. Но в том же разд. 4 отмечалась и полезность унификации структурированной среды и предпочитаемыми аналитиками средами программирования.

Аналитиками данных становятся люди разных профессий. Некоторые из них являются экспертами по SQL, но многие – нет. Аналитики с научной или математической подготовкой обычно хорошо знакомы со статистическими пакетами, такими как R, SAS или Matlab. Эти пакеты работают с данными в основной памяти на настольных компьютерах, но они поддерживают удобные абстракции математического программирования и обеспечивают доступ к библиотекам, содержащим сотни статистических процедур. Для других аналитиков привычны традиционные языки программирования типа Java, Perl и Python, но обычно им не по душе написание параллельного или ориентированного на оптимизацию ввода-вывода кода.

Способ расширения функциональных возможностей системы баз данных, впервые примененный в Postgres [19], теперь не является экзотикой в СУБД – это опора современной аналитики, позволяющая выполнять код поблизости от данных. Чтобы привлечь различных программистов, в интерфейсе правильно организованной расширяемой СУБД должно поддерживаться несколько языков. В этом отношении достаточно мощной стала PostgreSQL: в этой СУБД поддерживается множество языков программирования расширений, включая R, Python и Perl. В Greenplum перенимаются эти интерфейсы, и обеспечивается возможность выполнения получаемых программ на кластере параллельно по данным. Конечно, автоматический параллелизм не обеспечивается: разработчикам приходится думать о том, как их код будет выполняться в папаллельной по данным среде (как мы поступали по отношению к примерам из разд. 5).

У разработчиков, в дополнение к работе по реализации статистических методов на расширяемом SQL (подобных тем, которые описывались в разд. 5), имеется энтузиазм к реализации методов с использованием парадигмы программирования MapReduce, популяризируемой Google [4] и Hadoop. С точки зрения разработки языков программирования в MapReduce и современном SQL применяются очень похожие подходы к параллелизму: в обеих случаях используются модели программирования с распараллеиванием по данным для архитектур без совместно используемых ресурсов; обеспечивается возможность восходящих вызовов (upcall) расширений для обработки отдельных кортежей или наборов кортежей в потоке данных. Но, как явление культуры, MapReduce привлекает внимание многих разработчиков, заинтересованных в выполнении крупномасштабного анализа над большими данными, и широко распространено мнение, что эта среда программирования более привлекательна, чем SQL. МОГучее хранилище данных должно привлекать и этих программистов, позволяя им программировать в любимом ими стиле MapReduce в контексте, интегрирующем оба эти подхода с общими корпоративными данными, и обеспечивая более сложные средства управления продуктами данных.

В Greenplum эта проблема решается путем реализации интерфейса программирования MapReduce, механизмом поддержки времени выполнения которого является тот же самый исполнитель запросов, который используется для поддержки SQL [9]. Пользователи пишут функции Map и Reduce на знакомых языках типа Python, Perl или R и связывают их со скриптами MapReduce посредством простого конфигурационного файла. Затем они могут выполнить эти скрипты через интерфейс командной строки, передающий конфигурацию и код MapReduce в СУБД, которая возвращает получаемые результаты в конфигурируемое место назначения: командную строку, файлы или таблицы СУБД. Для взаимодействия с СУБД требуется указать только ее IP-адрес и свои аутентификационные данные (пользователь/пароль, ключи PGP и т.д.). Следовательно, разработчики, применяющие традиционные инструментальные средства с открытыми кодами, продолжают использовать свои любимые редакторы текстов, системы управления исходным кодом и интерфейсы shell; им ничего не нужно знать об утилитах базы данных, синтаксисе SQL, проектировании схемы и т.д.

Исполнитель Greenplum обеспечивает доступ к файлам для заданий MapReduce с использованием того же метода Scatter/Gather, который применяется для доступа к внешним таблицам в SQL. Кроме того, в Greenplum скрипты MapReduce могут взаимодействовать со всеми средствами базы данных и наоборот. В качестве входных данных скриптов MapReduce могут использоваться таблицы и представления, а результаты работы скриптов могут сохраняться в виде таблиц базы данных, к которым можно напрямую обращаться из среды SQL. Поэтому можно организовывать сложные конвейеры, некоторые фазы которых представлены на SQL, а некоторые – в синтаксисе MapReduce. Выполнение этих фаз может производиться полностью по требованию (при запуске фаз SQL и MapReduce в конвейере) или при материализации их результатов внутри или вне базы данных. Разные скрипты могут взаимодействовать на основе обычных интерфейсов: через таблицы и представления базы данных или входные потоки MapReduce. Для написания функций Map и Reduce, а также функций, расширяющих SQL, можно использовать разнообразные языки программирования.

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

При работе с разнообразными заказчиками Greenplum мы обнаружили, что разработчики, равно комфортно чувствующие себя при использовании и SQL, и MapReduce, гибко выбирают наилучший подход при решении разных задач. Например, подход MapReduce оказывается более удобным при написании ETL-скриптов для файлов, в которых известен порядок данных, и этот порядок может использоваться при преобразовании данных. MapReduce также облегчает спецификацию преобразований, в которых имеется одной входной поток данных и производится много выходных потоков, – это также распространено в средах ENL, в которых "измельчаются" входные записи, и производятся потоки результирующих таблиц со смешанными форматами. Как не странно, SQL оказывается более удобным, чем MapReduce, для задач, связанных с графовыми данными, такими как ссылки в Web или социальные сети, поскольку большую часть алгоритмов в этой сфере (PageRank, вычисление коэфициентов кластеризации и т.д.) можно компактно закодировать с исползованием "самосоединений" таблицы ссылок.

7. Направления и размышления

Работа, описываемая в этой статье, является результатом довольно быстрых интерактивных обсуждений с людьми разных профессий и с разной подготовкой, основной интерес для которых представляют данные. Структура статьи заранее не планировалась; вместо этого мы применили МОГучий подход: собрали много данных, организовали быстрые обсуждения с несколькими заинтересованными сторонами и постарались поглубже вникнуть в детали.

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

Управление пакетами и повторное использование: Во многих случаях аналитику требуется всего лишь увязать и параметризовать готовые методы из учебников типа линейной регрессии повторного взятия образцов. Для поддержки этого имеется настоятельная потребность (в средах и SQL, и MapReduce) в некотором решении для управления пакетов и в репозитории наподобие репозитория CRAN для R, чтобы обеспечить очень простое повторное использование кода. Помимо прочего, для этого требуется стандартизовать словарь таких объектов, как векторы, матрицы, функции и функционалы.

Совместная оптимизация методов хранения и запросов для линейной алгебры: Имеется много вариантов размещения матриц в узлах кластера [2]. Мы полагаем, что во всех случаях для хранения матрицы могут использоваться записи, к которым применяются методы, написанные в синтаксисе SQL или MapReduce. Следующим шагом является усложнение оптимизатора запросов, которое позволит ему (a) учитывать наличие нескольких одновременно используемых способов хранения матриц и (b) выбирать из числа эквивалентных библиотечных процедур линейной алгебры те процедуры, которые настраиваются к разным способам хранения.

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

Оперативная обработка запросов для MAD-аналитики: Быстрота аналитики зависит от того, насколько часто аналитик сможет выполнять свои задачи. Методы, подобные онлайновой агрегации (Online Aggregation [11]), могут радикально ускорить этот процесс, но для этого их нужно значительно расширить, чтобы обеспечить обсуждаемую здесь основательную аналитику. Требуются методы получения полезных скользящих оценок (running estimates) для более сложных вычислений, включая эпизодический код наподобие программ MapReduce. Нужны также методы приоритизации данных, позволяющие учитывать данные на "хвостах" распределений.

7.1. Когда наступит будущее?

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

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

Благодарим Ноэля Сио (Noelle Sio) и Дэвида Хаббарда (David Hubbard) из FAN за их вклад в эту работу и Джеймса Марка (James Marca) из университета Южной Калифорнии в Ирвине за помощь в организации наших обсуждений.

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