Ответ 1

Малые вычисления быстрые

Мы используем Spark в интерактивной настройке, как бэкэнд веб-интерфейса. Субсекундные задержки возможны, но нелегко. Некоторые советы:

• Создайте SparkContext при запуске. Требуется несколько секунд, чтобы подключиться и заставить исполнителей начать работу с рабочими.
• Вы упомянули много одновременных вычислений. Вместо каждого пользователя, имеющего собственный SparkContext и собственный набор исполнителей, есть только один, который каждый может разделить. В нашем случае несколько пользователей могут одновременно использовать веб-интерфейс, но есть только один веб-сервер.
• Работайте с RDD с кэшем памяти. Сериализация, вероятно, слишком медленная, поэтому используйте кэширование по умолчанию, а не Tachyon. Если вы не можете избежать сериализации, используйте Kryo. Это быстрее, чем серийная сериализация Java.
• Используйте RDD.sample либерально. Беспристрастный образец часто достаточно хорош для интерактивного исследования.

Балансировка нагрузки

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

Альтернативный справедливый планировщик, вероятно, решает эту проблему, но я еще не пробовал.

Spark также может отключить планирование до YARN или Mesos, но у меня нет опыта в этом. Я сомневаюсь, что они совместимы с вашими требованиями к задержкам.

Ответ 2

Я думаю, что короткий ответ - "да". Spark рекламирует себя как "почти в реальном времени". Одна или две статьи, которые я прочитал, описывают задержку пропускной способности как одну секунду, так и несколько секунд. Для лучшей производительности посмотрите на объединение его с Tachyon, распределенной файловой системой в памяти.

Что касается балансировки нагрузки, более поздние выпуски Spark могут использовать планировщик с круговым движением, так что большие и малые задания могут сосуществовать в одном кластере:

Начиная с Spark 0.8, также можно настроить справедливое распределение между заданиями. При справедливом совместном использовании Spark назначает задачи между заданиями в режиме "round robin", так что все задания получают примерно равную долю ресурсов кластера. Это означает, что короткие задания, отправленные во время длительной работы, могут сразу же начать получать ресурсы и получать хорошие ответы, не дожидаясь завершения длительной работы. Этот режим лучше всего подходит для многопользовательских настроек.

Однако я не понимаю, что вы подразумеваете под "... также интересно, не пытаюсь ли я вообще использовать Spark для цели, для которой он не был предназначен, не используя основные преимущества: MapReduce и in- памяти RDD."

Возможно, я ошибаюсь, но я не думаю, что вы можете использовать Spark без RDD. Spark - распределенные вычисления с RDD. Какие рабочие места вы пытаетесь запустить, если не заданы в стиле MapReduce? Если ваши варианты использования не подходят для примеров использования, которые поставляются с документацией или учебными пособиями Spark, то какие ваши варианты использования подходят? Hadoop/Spark блеск, когда есть тонны данных, и очень мало итеративных вычислений по данным. Например, решение систем уравнений не является традиционным прецедентом для этих технологий.

Есть ли необходимость распространять задания, которые включают только 1-100 МБ? Такие небольшие объемы данных часто обрабатываются наиболее быстро на одном мощном node. Если есть причина для распределения вычислений, посмотрите на работу MPI под Mesos. Многие задания, которые подпадают под название "научные вычисления", продолжают использовать MPI в качестве модели распределенных вычислений.

Если задание относится к хрустким числам (например, умножению матрицы), то задания с малой средой можно быстро обрабатывать с помощью графических процессоров на одном node. Я использовал среду программирования Nvidia CUDA. Он походит на вычислительно-интенсивные задачи, такие как компьютерное зрение.

Какова природа заданий, которые будут выполняться в вашей среде?

Ответ 3

Если я получу это правильно из предоставленных вами комментариев, ЕСЛИ вы находитесь в статистике и прогнозировании, то MLlib с распределенными алгоритмами машинного обучения будет очень полезен. Когда ваша проблема касается нераспределенной задачи, она использует библиотеку breeze для вычислений линейной алгебры и очень быстро. Таким образом, вы можете иметь как реализацию, так и не в том же файле. Если у вас есть предварительная информация о вашем размере ввода, вы можете переключиться на любую реализацию.

Как отмечалось в других ответах, создание общего контекста искры - хорошая идея. Что-то подобное мы используем для тестирования алгоритмов с использованием scalaTest

import org.scalatest.Suite
import org.scalatest.BeforeAndAfterAll

import org.apache.spark.{SparkConf, SparkContext}

trait LocalSparkContext extends BeforeAndAfterAll { self: Suite =>
  @transient var sc: SparkContext = _

  override def beforeAll() {
    val conf = new SparkConf()
      .setMaster("local")
      .setAppName("test")
    sc = new SparkContext(conf)
    super.beforeAll()
  }

  override def afterAll() {
    if (sc != null) {
      sc.stop()
    }
    super.afterAll()
  }
}