Требуемые свойства
В этом разделе мы описываемым требуемые свойства системы, разрабатываемой для анализа данных петабайтного масштаба (который скоро станет более распространенным). В следующем разделе мы обсуждаем, по каким причинам системы параллельных баз данных и системы MapReduce по отдельности не удовлетворяют некоторым из этих свойств.
Производительность. Производительность – это основная характеристика, которая используется производителями коммерческих систем баз для проведения различия между своими системами и другими решениями. В маркетинговой литературе часто встречаются утверждения о том, что некоторое решение во много раз быстрее своих конкурентов. Десятикратное различие в производительности может серьезно повлиять на объем, качество и глубину анализа, который может произвести система.
Высокопроизводительные системы иногда могут способствовать экономии расходов. Переход к использованию более быстрого программного продукта может позволить отложить дорогостоящую модернизацию аппаратных средств или избежать приобретения дополнительных вычислительных узлов при росте масштаба приложения. При использовании публичных платформ облачных вычислений ценообразование устроено таким образом, что человек платит только за то, что он реально использует, так что цена продукта от поставщика линейно возрастает в зависимости от требуемых ресурсов процессоров, дисковой памяти и пропускной способности сети. Следовательно, если при выполнениия одной и той же задачи для некоторого программного продукта анализа данных A требуется на порядок больше вычислительных ресурсов, чем для некоторого программного продукта анализа данных B, то продукт A будет стоить (приблизительно) на порядок дороже продукта B. Эффективность программного обеспечения оказывает непосредственное воздействие на его реальную стоимость.
Отказоустойчивость. Отказоусточивость в контексте рабочих нагрузок анализа данных оценивается не так, как в контексте транзакционных рабочих нагрузок. Для транзакционных рабочих нагрузок отказоустойчивая СУБД может восстановиться после отказа без потери каких-либо данных или обновлений, внесенных зафиксированными транзакциями, и в контексте распределенных баз данных такая система может успешно фиксировать транзакции и продвигать выполнение рабочей нагрузки даже при отказах рабочих узлов. В аналитических рабочих нагрузках присутствуют только запросы на выборку данных, отсутствует потребность в фиксации транзакций, изменяющих базу данных, и отказы узлов не могут привести к потере данных. Поэтому отказоустойчивой аналитической СУБД является такая система, которая не вынуждена выполнять какой-либо запрос заново при отказе узла, участвующего в выполнении этого запроса.
Использование дешевых и ненадежных массовых аппаратных средств для построения кластеров без совместно используемых ресурсов позволяет сократить эксплуатационные расходы и потребление дорогостоящих ресурсов. Имеется также тенденция к использованию наиболее дешевых аппаратных средств при организации центров данных . В результате быстро возрастает вероятность отказов узлов во время выполнения запросов. Эта проблема только обостряется при масштабировании аналитических систем: чем больший объем данных затрагивается при выполнении аналитических запросов, тем большее число узлов требуется для обработки этих запросов. Это еще больше повышает вероятность отказа по крайней мере одного узла во время выполнения запроса. Например, по информации Google , при выполнении аналитического задания в среднем возникает 1,2 отказов. Если при каждом отказе узла требуется выполнять запрос заново, то трудно довести до конца выполнение сложных запросов, для обработки которых требуется достаточно большое время.
Возможность работы в неоднородной среде. Как отмечалось выше, имеется устойчивая тенденция к увеличению числа узлов, участвующих в выполнении запросов. Почти невозможно добиться одной и той же производительности сотен или тысяч вычислительных узлов, даже если всем узлам соответствуют полностью идентичные аппаратные или виртуальные машины. При масштабировании системы все более распространенными становятся частичные отказы узлов, приводящие не к полной утрате их работоспособности, а к падению производительности. Производительность отдельных узлов может также снижаться из-за фрагментации дисковой памяти или ошибок конфигурирования программного обеспечения. На однородность производительности узлов кластера может оказывать влияние и параллельное выполнение нескольких запросов (или, в некоторых случаях, процессов). Параллельные активности, выполняемые в разных виртуальных машинах, которые базируются на одной и той же физической машине, могут приводить к отклонениям показателей производительности на 2-4% .
Если объем работы, требуемой для выполнения запроса, поровну распределяется между узлами кластера без совместно используемых ресурсов, то имеется опасность, что время полного выполнения запроса будет примерно равно времени выполнения своей части работы самым медленным вычислительным узлом. Таким образом, узел с вырожденной производительностью может оказывать несоразмерное влияние на общее время выполнения запроса. В системе, разрабатываемой для использования в неоднородной среде, должны приниматься меры для предотвращения таких ситуаций.
Гибкий интерфейс запросов. Имеются разнообразные средства интеллектуального анализа данных (business intelligence, BI), ориентированные на пользователей. Эти средства работают с программным обеспечением баз данных и поддерживают развитые возможности аналитики, генерацию запросов и визуализацию результатов. Подобные средства являются важной частью общей картины управления аналитическими данными, поскольку бизнес-аналитики часто не получают должную техническую подготовку, и им трудно взаимодействовать с программным обеспечением баз данных напрямую. Средства BI обычно подключаются к базам данных с использованием ODBC или JDBC, так что системы баз данных, для которых требуется обеспечить возможность работы с этими средствами, должны уметь обрабатывать SQL-запросы, поступающие через такие интерфейсы.
В идеале, в системах анализа данных должен также иметься надежный механизм, позволяющий пользователям писать определяемые ими функции (user-defined function, UDF), и запросы, включающие вызовы UDF, должны автоматически распараллеливаться по узлам кластера без совместного использования ресурсов. Таким образом, требуется поддержка как SQL, так и интерфейсного языка, не являющегося SQL.
