При джойне нужно эти 5тб разместить в темп

У вас свободного темп на кластере 6гб

При 90% забитии дисков начинают с кластера отваливаться ярн ноды

У вас забитие 146%

Читайте таблицы кусками по 50гб, может отсчитается

Они не партицированные

Цельный паркет

Как ни крути это ресурсы

Спасибо коллеги

Можно пофайлово читать

Не умею

Научиться быстрее, чем закупить новые ноды в кластер)

Просто нужно сформировать список файлов в хдфс в папке конкретной таблицы

Разбить его в питончике на части например

И считать эти части

Идею понял спасибо

No change...
jedisConfig.setMaxWaitMillis(500)
jedisConfig.setMaxWaitMillis(8000)

Привет, есть возможные решения? spark 2.4.4

Знатоки спарка подскажите пожалуйста как можно решить такую проблему.

Есть большой граф вычислений с кучей join/groupby и прочего. На одном из stage непонятно с чем связанного (по картинке графа вычислений это не join) жуткий перекос в данных, одна таска принимает слишком много.

Как мне проще всего найти нужный проблемый stage, чтобы прооптимизировать его?

пока самый тупой вариант вижу навешивать сохранение на диск после каждого groupby и join, чтобы найти эту операцию. Но он довольно долгий.

есть еще такая вещь как sparkContext.setJobGroup , но она сетит лейбл в ui для целой джобы, но для stage нельзя такое нельзя разметить

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