VI
Это где то в логах?
Size: a a a
2021 July 31
ЕГ
Нет, веб-интерфейс, если у вас ярн, то там можно найти ссылку на каждое спарк-приложение
VI
Ресурс менеджер
ЕГ
Да, там справа будет ссылка на application master
ЕГ
Это и есть спарк юи
VI
Пытался там смотреть, но надо знать, где и что смотреть куча ссылок проваливашься и их ещё больше😊
ЕГ
Можно начать с вкладки sql, там будет план запроса, хотя бы будет понятно, броадкаст джойн или сортмёрдж
ЕГ
Для каждого запроса будет ссылка на джобы, с помощью которых он выполняется
ЕГ
Дальше уже конкретный джоб смотреть - сколько данных считал, сколько сложил в spill, сколько записал
2021 August 01
ДД
Господа, подскажите, пожалуйста:
в каких случаях использование
coalesce(1) или
repartition (1)
перед записью паркета в hdfs будет хорошей практикой, а в каком случае этого стоит избегать?
в каких случаях использование
coalesce(1) или
repartition (1)
перед записью паркета в hdfs будет хорошей практикой, а в каком случае этого стоит избегать?
ДД
Плюсы понятно какие - меньше файлов на кластере.
Но если это не последний слой данных, и на следующем шаге пайплайна этот же паркет будет читаться Спарком - будут ли проблемы с параллелизмом?
Но если это не последний слой данных, и на следующем шаге пайплайна этот же паркет будет читаться Спарком - будут ли проблемы с параллелизмом?
NN
Обычно имеет смысл только тогда, когда размер выходного датасета оч маленький.
Причем коалеск стоит использовать аккуратно, желательно при грамотном разбиении на отдельные пайплайны через .cache() или .checkpoint, иначе спарк закинет его в план запроса максимально рано, и запрос будет крайне медленно отрабатывать.
Причем коалеск стоит использовать аккуратно, желательно при грамотном разбиении на отдельные пайплайны через .cache() или .checkpoint, иначе спарк закинет его в план запроса максимально рано, и запрос будет крайне медленно отрабатывать.
ДД
Понял, спасибо большое!
ЕГ
Если файл больше 256 мегов, то он сам разобъётся на блоки, и блоки параллельно в следующих джобах будут считываться
ЕГ
Вообще общая рекомендация такая - сначала попробовать сделать репартишен как можно меньше, если запись слишком долгая - увеличить число партиций. Тут должен быть баланс между размером файла и временем записи, если у вас 2 часа один таск записи работает, а от него потом зависит весь остальной пайплайн и итоговые витрины, тоже наверно нехорошо, а вдруг упадёт, придётся ещё два часа ждать
NN
А за это какая настройка в конфиге отвечает?
ЕГ
Ходуб за это отвечает, размер блока😆
NN
Ну так у спарка же свое мнение на этот счёт, свой конфиг)
ЕГ
Не, если посмотришь, как записывается большой файл, через хдфс веб Юи, там будет список блоков
ЕГ
Любой блок конечно считывается независимо, ещё у спарка есть инпут сплиты, но они чёт не очень хорошо работают