Конвергенция больших данных и машинного обучения

Больше линейной алгебры и масштабируемых вычислений

У меня недавно было два довольно интересных обсуждения со студентами здесь в TU Berlin, которые, я думаю, являются репрезентативными в отношении того, насколько велик разрыв между сообществом машинного обучения и сообществом больших данных.

Линейная алгебра против функциональных коллекций

Один студент работает над реализацией метода повышения, который я написал несколько лет назад, с использованием фреймворков Big Data следующего поколения, таких как Flink и Spark, как часть его магистерской диссертации. Я выбрал этот алгоритм, потому что его операции были довольно просты: вычисление скалярных произведений, разностей векторов и норм векторов. Вероятно, самая сложная вещь — это вычислить накопленную сумму.

Все эти операции сводятся к линейной алгебре, и весь алгоритм представляет собой несколько строк кода в псевдо-обозначениях, выраженных в линейной алгебре. Мне было интересно, насколько сложно было бы сформулировать это с помощью API в стиле «более функциональной коллекции».

Например, чтобы вычислить квадратную норму вектора, вы должны возвести в квадрат каждый элемент и суммировать их. На языке, подобном C, вы бы сделали это так:

double squaredNorm(int n, double a[]) {
  double s = 0;
  for(i = 0; i < n; i++) {
    s += a[i] * a[i];
  }
  return s;
}

В Scala вы бы выразили то же самое с

def squaredNorm(a: Seq[Double]) =
	a.map(x => x*x).sum

В некотором смысле, главная задача здесь состоит в том, чтобы разбить эти циклы for на эти примитивы последовательности, предоставляемые языком. Другой пример: скалярное произведение (сумма произведений соответствующих элементов двух векторов) станет

def scalarProduct(a: Seq[Double], b: Seq[Double]) =
	a.zip(b).map(ab => ab._1 * ab._2).sum

и так далее.

Теперь, обращаясь к такой системе, как Flink или Spark, которая предоставляет очень похожий набор операций и может распределять их, следует использовать аналогичный подход. Однако первым сюрпризом было то, что в распределенных системах нет понятия порядка последовательности. Это действительно больше коллекция вещей.

Поэтому, если вам нужно вычислить скалярное произведение между векторами, вам нужно расширить хранимые данные, включив в них также индекс каждой записи, а затем вам сначала нужно объединить две последовательности в индексе, чтобы иметь возможность выполнить карту ,

Студент все еще на полпути к этому, но уже стоило немалого умственного труда, чтобы переосмыслить стандартные операции в новой нотации и, самое главное, поверить в основную систему, которая способна выполнять такие вещи, как соединение векторов, например что элементы выровнены умным способом.

Я думаю, что основная идея здесь заключается в том, что изучающие машины действительно любят мыслить в терминах матриц и векторов, а не столько баз данных и языков запросов. Именно так алгоритмы описываются в статьях, так думают люди, как обучаются люди, и было бы чрезвычайно полезно, если бы для этого был слой поверх Spark или Flink. В этом направлении уже есть некоторые виды деятельности, такие как распределенные векторы в Spark или спарк-оболочка в Mahout , и мне очень интересно посмотреть, как они будут развиваться.

Большие данные против больших вычислений

Другая интересная дискуссия была с доктором философии. студент, который работает по прогнозированию свойств в физике твердого тела с помощью машинного обучения. Он, очевидно, не слишком много знал о Hadoop, и когда я объяснил ему это, он также обнаружил, что это совсем не привлекательно, хотя он тратит довольно много времени на вычисления в кластере групп.

В TU Berlin существует кластер среднего размера для группы машинного обучения. Он состоит из около 35 узлов и содержит около 13 ТБ данных для всех видов исследовательских проектов за последние десять лет или около того. Но кластер не работает на Hadoop, он использует gridengine от Sun , который теперь поддерживается Univa. Для этого есть исторические причины. Собственно, нынешняя инфраструктура развивалась в течение ряда лет. Итак, вот краткая история распределенных вычислений в лаборатории:

Еще в начале 2000-х люди все еще держали настольные ПК под своими столами. В то время люди выполняли большую часть своей работы на своем собственном компьютере, хотя я думаю, что дисковое пространство уже было распределено по NFS (возможно, в основном по причинам резервного копирования). Поскольку людям требовалось больше вычислительной мощности, они начали входить в другие компьютеры (конечно, после того, как спросили, нормально ли это), в дополнение к нескольким компьютерам большего размера, которые были куплены в то время.

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

Следующим шагом было не дать людям войти в систему на отдельных компьютерах. Вместо этого был установлен gridengine, который позволяет отправлять задания в виде сценариев оболочки для выполнения в кластере при наличии свободных ресурсов. В некотором смысле gridengine похож на YARN , но ограничен сценариями оболочки и интерактивными оболочками. У него есть более продвинутые возможности, но люди в основном отправляют его для запуска своих программ где-то в кластере.