Время зажигания и изоляции, необходимое для выполнения задач

Question

Я недавно начал использовать Spark для обработки огромного количества данных (~ 1 ТБ). И смогли сделать работу тоже. Однако я все еще пытаюсь понять его работу. Рассмотрим следующий сценарий:

1. Установить отсчета времени (скажем, т _исх )

2. Распечатайте размер RDD или DataFrame, если применимо, и разницу во времени относительно t _ref (ie, t _0a / t _0b )

3. Выполните некоторые вычисления
4. Сохраните результаты

Другими словами, 1b создает DataFrame после обработки RDD, сгенерированных точно так же, как в 1a.

Мой запрос следующий:

Правильно ли сделать вывод, что t _0b - t _0a = время, необходимое для предварительной обработки? Где я могу найти надежную ссылку на то же самое?

Редактировать: Добавлено объяснение происхождения вопроса ...

Мое подозрение связано с ленивым подходом вычислений Spark и его способность выполнять асинхронные работы. Может ли он инициировать последующие (предварительную обработку) задачи, которые могут быть вычислены во время чтения тысяч входных файлов? Происхождение подозрения кроется в невероятном исполнении (с проверенными результатами, все в порядке). Я вижу, что это выглядит слишком фантастично c, чтобы быть правдой.

Спасибо за любой ответ.

Answer 1

Я полагаю, что что-то подобное может помочь вам (используя Scala):

def timeIt[T](op: => T): Float = {
  val start = System.currentTimeMillis
  val res = op
  val end = System.currentTimeMillis
  (end - start) / 1000f
}

def XYZ = {
 val r00 = sc.parallelize(0 to 999999)
 val r01 = r00.map(x => (x,(x,x,x,x,x,x,x)))
 r01.join(r01).count()
}

val time1 = timeIt(XYZ)
// or like this on next line
//val timeN = timeIt(r01.join(r01).count())

println(s"bla bla $time1 seconds.")

Вам нужно проявлять творческий подход и постепенно работать с действиями, которые вызывают фактическое выполнение. Это имеет ограничения, таким образом. Ленивая оценка и тому подобное.

С другой стороны, Spark Web UI записывает каждое действие и записывает продолжительность этапа для действия.

В целом: измерение производительности в общих средах затруднено. Динамическое распределение c в Spark в зашумленном кластере означает, что вы удерживаете приобретенные ресурсы во время Стадии, но при последовательных запусках той же или следующей Стадии вы можете получить меньше ресурсов. Но это по крайней мере показательно, и вы можете работать в менее загруженный период.