Мы переносим наши программы Scala Spark с 1.6.3 на 2.2.0.Рассматриваемая программа состоит из четырех частей: давайте назовем их разделами A, B, C и D. Раздел A анализирует входные данные (файлы паркета), а затем кэширует DF и создает таблицу.Затем секции B, C и D выполняют различные виды обработки на DF один за другим.
Это задание запускается примерно 50 раз в час с различным количеством входных файлов в зависимости от того, какие файлы доступны в данный момент.Количество исполнителей, ядер, памяти исполнителя и количество разделов agg рассчитывается на основе количества входных файлов и их размеров.Они рассчитываются следующим образом:
- n_execs = min (n_infiles, num_datanodes)
- n_cores = ceil (n_infiles / n_execs)
- exec_mem = 1500 * n_cores (МБ)
- shuffle_partitions = n_infiles
- driver_mem = ceil (n_infiles / 200) (ГБ)
- макс. Байт раздела = 5 *1024* 1024 (постоянная)
В нашей среде модульного тестирования в настоящее время у нас есть 12 узлов данных, а средний размер входного файла составляет 11 МБ / 630 КБ записей.Вот некоторые примеры:
- n_infiles (24): driver_mem (1G), n_execs (12), n_cores (2), exec_mem (3000M), shuffle_partitions (24)
- n_infiles (4): driver_mem (1G), n_execs: (4), n_cores (1), exec_mem (1500M), shuffle_partitions (4)
Теперь проблема: анализ 1095 работает с Spark 2.2, мыувидеть, что раздел C занял в среднем 41,2 секунды, а раздел D занял 47,73 секунды.В Spark 1.6.3 за 425 пробежек секция C заняла в среднем 23 секунды, а секция D - 64,12 секунды.Секции A и B имеют практически одинаковое среднее время выполнения между двумя версиями.Большое улучшение для Раздела D, но большая проблема для Раздела C. Это плохо масштабировалось на нашем производственном кластере (314 данных).
Некоторые сведения о разделе C:
- Мы используем кэшированный DF, созданный из раздела A
, DF из раздела A объединяется на меньшем столе(~ 1000 строк) четыре раза, и они объединяются вместе, в основном, как:
SELECT *
FROM t1 JOIN t2
WHERE t1.a = t2.x AND t2.z = 'a'
UNION ALL
SELECT *
FROM t1 JOIN t2
WHERE t1.b = t2.x AND t2.z = 'b'
UNION ALL
SELECT *
FROM t1 JOIN t2
WHERE t1.c = t2.x1 AND t1.d = t2.x2 AND t2.z = 'c'
UNION ALL
SELECT *
FROM t1 JOIN t2
WHERE t1.e = t2.y1 AND t1.f = t2.y2 AND t2.z = 'd'
Этот запрос выполняется еще раз с немного другими параметрами.
Результаты каждого из этих запросов кэшируются, поскольку они фильтруются несколько раз, а затем записываются в паркет.
Есть ли что-нибудьне знаю, что объясняет расхождение между свечой 1.6 и 2.2?
Я новичок в настройках зажигания, поэтому, пожалуйста, дайте мне знать, могу ли я предоставить больше информации.