Слюни в искре - производительность

У меня есть пакетное задание в Scala/Spark, которое динамически создает правила Drools в зависимости от некоторого ввода, а затем оценивает правила. У меня также есть входные данные RDD[T], которые соответствуют фактам, которые нужно вставить в механизм правил.

Пока я вставляю факты один за другим, а затем запускаю все правила по этому факту. Я делаю это, используя rdd.aggregate.

Оператор seqOp определяется следующим образом:

/**
 * @param broadcastRules the broadcasted KieBase object containing all rules
 * @param aggregator used to accumulate values when rule matches
 * @param item the fact to run Drools with
 * @tparam T the type of the given item
 * @return the updated aggregator
 */
def seqOp[T: ClassTag](broadcastRules: Broadcast[KieBase])(
  aggregator: MyAggregator,
  item: T) : MyAggregator = {
  val session = broadcastRules.value.newStatelessKieSession
  session.setGlobal("aggregator", aggregator)
  session.execute(CommandFactory.newInsert(item))
  aggregator
}

Вот пример сгенерированного правила:

dialect "mvel"
global batch.model.MyAggregator aggregator
rule "1"
 when condition
 then do something on the aggregator
end 

Для того же RDD пакету потребовалось 20 минут для оценки правил 3K, но 10 часов для оценки правил 10K!

Мне интересно, является ли вставка факта фактом лучшим подходом. Не лучше ли сразу вставить все элементы RDD, а затем запустить все правила? Мне это не кажется оптимальным, так как все факты будут в оперативной памяти одновременно.

Вы видите какие-либо проблемы с кодом выше?


person Zied Koubaa    schedule 30.05.2018    source источник
comment
Похоже, ваша работа может использовать некоторые изменения в схеме разбиения. Существуют ли правила, для которых можно ожидать, что время выполнения будет оцениваться в разном порядке, или все правила более или менее похожи?   -  person stefanobaghino    schedule 30.05.2018
comment
Правила более-менее похожи. Я положил пример сгенерированного правила выше   -  person Zied Koubaa    schedule 30.05.2018
comment
Что пользовательский интерфейс Spark говорит вам о том, как разбиваются данные? Вы замечаете некоторый перекос?   -  person stefanobaghino    schedule 30.05.2018
comment
Нет, данные хорошо разделены между разными исполнителями   -  person Zied Koubaa    schedule 30.05.2018
comment
Вы заметили необычное время GC?   -  person stefanobaghino    schedule 30.05.2018
comment
Нет, не совсем, время GC более или менее одинаково независимо от продолжительности задачи.   -  person Zied Koubaa    schedule 30.05.2018
comment
Можете ли вы дать репродукцию вашего проекта, чтобы я мог проверить, где вы делаете ошибку?   -  person Prog_G    schedule 31.05.2018


Ответы (1)


Наконец я понял проблему, она была больше связана с действием, выполняемым в агрегаторе, когда правило совпадает, а не с оценкой правил.

person Zied Koubaa    schedule 31.05.2018