Поддержка схемы
Для параллельных СУБД требуется, чтобы данные подстраивались под реляционную парадигму строк и столбцов. В отличие от этого, в модели MR не требуется, чтобы файлы данных соответствовали какой-либо схеме, определенной с использованием реляционной модели данных. Другими словами, MR-программист свободен структурировать свои данные любым образом или даже оставить их вообще не структурированными.
Можно подумать, что отсутствие жесткой схемы автоматически делает MR предпочтительным вариантом. Например, SQL часто критикуют за то, что от программиста требуется спецификация «формы» данных на языке определения данных. С другой стороны, MR-программистам часто приходится писать свои собственные парсеры, чтобы извлечь соответствующую семантику из своих входных записей, а для этого приходится выполнить, по крайней мере, не меньший объем работы. Но при отказе от использования схемы для крупных наборов данных имеются и другие потенциальные проблемы.
Какая бы структура не существовала во вводных файлах MR, она должна быть встроена в программы Map и Reduce. В существующих реализациях MR поддерживается встроенная функциональная возможность манипулирования простыми форматами «ключ/значение», но программисты вынуждены писать явный код для поддержки более сложных структур данных, например, составных ключей. Возможно, этот подход является приемлемым, если набор данных MR не используется в нескольких приложениях. Однако если такое совместное использование данных имеет место, второму программисту придется разбираться в коде, написанном первым программистом, чтобы понять, как следует обрабатывать вводной файл. Во всех SQL-ориентированных СУБД используется более правильный подход, при котором схема отделяется от приложения и хранится в системных каталогах, к которым можно адресовать запросы.
Но даже если схему можно было бы отделить от приложения и сделать доступной нескольким MR-программам, их разработчикам потребуется достичь согласия относительно единой схемы. Для этого, очевидно, требуется следование некоторой модели данных или моделям данных, и ему должны подчиняться вводные файлы, поскольку затруднительно изменять атрибуты данных после создания файлов.
Как только программисты договорятся о структуре данных, что-то или кто- то должен гарантировать, что при любых добавлениях или обновлениях данных не нарушается целостность или другие высокоуровневые ограничения (например, зарплата служащих должна быть неотрицательной). Такие условия должны быть известны всем программистам, модифицирующим набор данных, и должны явно ими соблюдаться. В инфраструктуре MR и распределенной системе хранения данных, на которых MR основывается, отсутствует знание этих правил, и это позволяет легко повредить вводные данные. Но опять же, если отделить такие ограничения от приложения и возложить их поддержку на управляющую систему, как это делается во всех SQL-ориентированных СУБД, то целостность данных будет обеспечиваться без дополнительной работы программистов.
Таким образом, если совместное использование данных не предвидится, то парадигма MR является вполне пригодной. Однако если совместное использование данных требуется, то для программистов предпочтительнее использовать язык описания данных и выносить определения схемы и ограничения целостности из программы приложения. Эту информацию следует собирать в общих системных каталогах, доступных соответствующим пользователям и приложениям.
