МОГучее программирование
Хотя в подходе MAD предпочтение отдается быстрому импорту и частому использованию данных, а не их тщательному моделированию, это не означает отказа от структурированных баз данных как таковых. Как отмечалось в разд. 4, средства СУБД управления структурированными данными могут быть очень полезны для организации экспериментальных данных, пробных наборов данных и экспериментальных потоков работ. На самом деле, на предприятиях, в которых используются инструменты типа Hadoop, обычно имеются также СУБД, и/или развертываются легкие системы баз данных типа Hive. Но в том же разд. 4 отмечалась и полезность унификации структурированной среды и предпочитаемыми аналитиками средами программирования.
Аналитиками данных становятся люди разных профессий. Некоторые из них являются экспертами по SQL, но многие – нет. Аналитики с научной или математической подготовкой обычно хорошо знакомы со статистическими пакетами, такими как R, SAS или Matlab. Эти пакеты работают с данными в основной памяти на настольных компьютерах, но они поддерживают удобные абстракции математического программирования и обеспечивают доступ к библиотекам, содержащим сотни статистических процедур. Для других аналитиков привычны традиционные языки программирования типа Java, Perl и Python, но обычно им не по душе написание параллельного или ориентированного на оптимизацию ввода-вывода кода.
Способ расширения функциональных возможностей системы баз данных, впервые примененный в Postgres , теперь не является экзотикой в СУБД – это опора современной аналитики, позволяющая выполнять код поблизости от данных. Чтобы привлечь различных программистов, в интерфейсе правильно организованной расширяемой СУБД должно поддерживаться несколько языков. В этом отношении достаточно мощной стала PostgreSQL: в этой СУБД поддерживается множество языков программирования расширений, включая R, Python и Perl. В Greenplum перенимаются эти интерфейсы, и обеспечивается возможность выполнения получаемых программ на кластере параллельно по данным.
Конечно, автоматический параллелизм не обеспечивается: разработчикам приходится думать о том, как их код будет выполняться в папаллельной по данным среде (как мы поступали по отношению к примерам из разд. 5).
У разработчиков, в дополнение к работе по реализации статистических методов на расширяемом SQL (подобных тем, которые описывались в разд. 5), имеется энтузиазм к реализации методов с использованием парадигмы программирования MapReduce, популяризируемой Google и Hadoop. С точки зрения разработки языков программирования в MapReduce и современном SQL применяются очень похожие подходы к параллелизму: в обеих случаях используются модели программирования с распараллеиванием по данным для архитектур без совместно используемых ресурсов; обеспечивается возможность восходящих вызовов (upcall) расширений для обработки отдельных кортежей или наборов кортежей в потоке данных. Но, как явление культуры, MapReduce привлекает внимание многих разработчиков, заинтересованных в выполнении крупномасштабного анализа над большими данными, и широко распространено мнение, что эта среда программирования более привлекательна, чем SQL. МОГучее хранилище данных должно привлекать и этих программистов, позволяя им программировать в любимом ими стиле MapReduce в контексте, интегрирующем оба эти подхода с общими корпоративными данными, и обеспечивая более сложные средства управления продуктами данных.
В Greenplum эта проблема решается путем реализации интерфейса программирования MapReduce, механизмом поддержки времени выполнения которого является тот же самый исполнитель запросов, который используется для поддержки SQL . Пользователи пишут функции 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, вычисление коэфициентов кластеризации и т.д.) можно компактно закодировать с исползованием "самосоединений" таблицы ссылок.
