Длительное выполнение запроса SQL в Spark из-за трансляции - PullRequest
0 голосов
/ 21 февраля 2020

В настоящее время я использую Spark SQL для выполнения большого запроса, который выбирает данные из внешней таблицы в Hive. Запрос формирует 64 таблицы с помощью оператора WITH и содержит 65 левых соединений маленькой таблицы с большими таблицами; небольшая таблица содержит от 100 до 200 тысяч записей, т.е. около 150 тысяч записей, а большие таблицы содержат в среднем около 5-10 миллионов записей.

Первоначально время выполнения варьировалось от 50 минут до 80 минут с spark.sql.broadcastTimeout=1; после того, как я оставил эту опцию по умолчанию, как предлагал мазанейча, время выполнения увеличилось до 130 минут. Большая часть этого времени выполнения (около 40-80 минут) приходится на широковещательную рассылку, когда запрос фактически не выполняется, но готовится к выполнению. Пожалуйста, посмотрите пример вывода Spark SQL ниже:

2020-02-21 11:19:56 INFO  FileInputFormat:247 - Total input paths to process : 1
2020-02-21 11:19:56 INFO  FileInputFormat:247 - Total input paths to process : 1
2020-02-21 11:19:56 INFO  FileInputFormat:247 - Total input paths to process : 1
2020-02-21 11:19:56 INFO  FileInputFormat:247 - Total input paths to process : 1
2020-02-21 11:19:56 INFO  FileInputFormat:247 - Total input paths to process : 1
2020-02-21 11:19:56 INFO  CodeGenerator:54 - Code generated in 14.347002 ms
2020-02-21 11:19:56 INFO  CodeGenerator:54 - Code generated in 26.140162 ms
2020-02-21 11:19:56 INFO  CodeGenerator:54 - Code generated in 35.269363 ms
2020-02-21 11:19:56 INFO  CodeGenerator:54 - Code generated in 27.790616 ms
2020-02-21 11:19:56 INFO  MemoryStore:54 - Block broadcast_80 stored as values in memory (estimated size 298.2 KB, free 4.1 GB)
2020-02-21 11:19:56 INFO  MemoryStore:54 - Block broadcast_80_piece0 stored as bytes in memory (estimated size 27.9 KB, free 4.1 GB)
2020-02-21 11:19:56 INFO  BlockManagerInfo:54 - Added broadcast_80_piece0 in memory on <HOST>:35221 (size: 27.9 KB, free: 4.1 GB)
2020-02-21 11:19:56 INFO  SparkContext:54 - Created broadcast 80 from

Подобный вывод я вижу очень долго до фактического выполнения запроса. Такое долгое время расстраивает меня, и я пытаюсь найти способы сократить время выполнения, так как мне нужно выполнять этот запрос для каждого дня в 2019 и 2020 годах. Например, я добавил подсказку о трансляции, надеясь, что она ускорит трансляцию (sql настройка производительности в режиме spark ). Я также добавил подсказки по объединению и перераспределению следующим образом:

INSERT OVERWRITE TABLE <table_name>
PARTITION (date='2020-02-20')
SELECT 
/*+ BROADCAST(base_features) */
/*+ COALESCE(8192) */
/*+ REPARTITION(8192) */
COALESCE(...

Я выполняю запрос следующим образом:

--master yarn --num-executors 8 --executor-memory 32G --executor-cores 8 --driver-memory 8G --conf "spark.executor.heartbeatInterval=500000" --conf "spark.network.timeout=510000" -f query.hql

, и в настоящее время его выполнение занимает около 60-70 минут.

Я добавил увеличенные тайм-ауты, чтобы избежать завершенных задач и исключений в конце выполнения.

Я также попробовал EXPLAIN EXTENDED оператор, но вывод большой и плохо интерпретируется и содержит конфиденциальную информацию, которым я не могу поделиться. На что я могу обратить внимание в файле?

Проблема в запросе? Может быть, полезно использовать оператор CACHE TABLE для небольшого стола, но я не знаю, как это сделать правильно.

...