Направления и размышления
Работа, описываемая в этой статье, является результатом довольно быстрых интерактивных обсуждений с людьми разных профессий и с разной подготовкой, основной интерес для которых представляют данные. Структура статьи заранее не планировалась; вместо этого мы применили МОГучий подход: собрали много данных, организовали быстрые обсуждения с несколькими заинтересованными сторонами и постарались поглубже вникнуть в детали.
Как и в MAD-анализе, мы ожидаем новых вопросов и новых выводов при поступлении большего числа данных. В число проблем, исследуемых в настоящее время, входит следующее:
Управление пакетами и повторное использование: Во многих случаях аналитику требуется всего лишь увязать и параметризовать готовые методы из учебников типа линейной регрессии повторного взятия образцов. Для поддержки этого имеется настоятельная потребность (в средах и SQL, и MapReduce) в некотором решении для управления пакетов и в репозитории наподобие репозитория CRAN для R, чтобы обеспечить очень простое повторное использование кода. Помимо прочего, для этого требуется стандартизовать словарь таких объектов, как векторы, матрицы, функции и функционалы.
Совместная оптимизация методов хранения и запросов для линейной алгебры: Имеется много вариантов размещения матриц в узлах кластера . Мы полагаем, что во всех случаях для хранения матрицы могут использоваться записи, к которым применяются методы, написанные в синтаксисе SQL или MapReduce. Следующим шагом является усложнение оптимизатора запросов, которое позволит ему (a) учитывать наличие нескольких одновременно используемых способов хранения матриц и (b) выбирать из числа эквивалентных библиотечных процедур линейной алгебры те процедуры, которые настраиваются к разным способам хранения.
Автоматизация физического проектирования для повторяющихся задач: Аналитики, занимающиеся ETL/ELT или базовой аналитикой, часто выполняют несколько разного рода проходов по массивным наборам данных. Обычно им приходится задумываться над тем, как следует хранить эти данные: оставить их вне базы данных, использовать один из многочисленных форматов хранения базы данных, материализовать повторяющиеся вычисления и т.д. Аналитикам эти вопросы не интересны, их интересуют данные. Было бы полезно, чтобы система принимала соответствующие решения автоматически (или, возможно, полуавтоматически).
Оперативная обработка запросов для MAD-аналитики: Быстрота аналитики зависит от того, насколько часто аналитик сможет выполнять свои задачи. Методы, подобные онлайновой агрегации (Online Aggregation ), могут радикально ускорить этот процесс, но для этого их нужно значительно расширить, чтобы обеспечить обсуждаемую здесь основательную аналитику. Требуются методы получения полезных скользящих оценок (running estimates) для более сложных вычислений, включая эпизодический код наподобие программ MapReduce. Нужны также методы приоритизации данных, позволяющие учитывать данные на "хвостах" распределений.
