DT
Потому что не понятно, какой экзекьютор на каком воркере поднимается, какой у кого айпишник, когда какая таска и где упала, без того, чтоб перебирать все логи руками
Size: a a a
2021 June 16
P
Вы правы. Перезаписанный спарком даже в один партишн паркет прекрасно им читается и обрабатывается во все доступные ядра, в отличие от паркета записанного пандасом. Теперь причина ясна, спасибо.
EC
В уях я сортировал воркеры по статусу, их действительно много и не всегда это удобно, но все подобные отстрелы в том числе по дискам, я всегда находил.
Ещё разок, причин потери воркеров может быть много. С датабриксёрами ты получается раскопал один свой кейс.
И то судя по тексту причина названа на основе предположения, что не радует.
Ещё разок, причин потери воркеров может быть много. С датабриксёрами ты получается раскопал один свой кейс.
И то судя по тексту причина названа на основе предположения, что не радует.
DT
Так и есть
2021 June 17
МК
Можно подробнее: почему из партиции более одного файла (или - когда больше одного файла)?
ИК
ИК
начинается новая партиция - имеется в виду секция таблицы hive. конечно
ИК
в стандартном названии файла, записанного спарком, перед расширением есть суффикс .c000, в нем как раз будут номера файлов, записанных одним таском. Если все нули - это первый файл, почти всегда так и есть
МК
Спасибо - количество записей в файле, понятно
N
Я тут читаю доку от датабрикса и не могу понять, там ошибки или это я туповат? В разделе inner join for watermarking для событий задаётся ретеншон 10 и 20 секунд, а допустимое логическое временное окно между ними - 1 минута. Получается, они будут дропаться до возможного по логике джойна. И ещё в withWatermark написано 10 секунд, а в каментах к этой строке-1 минута.
https://docs.databricks.com/spark/latest/structured-streaming/examples.html?_ga=2.171317286.723057760.1623847257-786899134.1623070143#id1
https://docs.databricks.com/spark/latest/structured-streaming/examples.html?_ga=2.171317286.723057760.1623847257-786899134.1623070143#id1
МК
вот все-таки возвращаясь к теме разбиения файла на части (=партиции) при чтении: кластер, 5 узлов, csv файл 400M, все конфигурационные параметры (типа maxPartitionBytes и проч) - по дефолту. Читаю файл - получаю 7 партиций (строчки ровненько разложились по 1млн строк, последняя получила чуть меньше). Почему 7 ??? спарк 2.4.0
DT
spark.default.parallelism посмотри
МК
тоже по дефолту (кстати, как посмотреть - через getConf().getAll() его нету, из чего делаю заключение - дефолтное значение)
GP
sc.defaultParallelism
DT
Ну если ровно по миллиону, то тут явно что-то нечисто
DT
Вероятно где-то настройка какая-то есть,
DT
Попробуй разложить карты таро
МК
вот я и думаю, что бы это могло быть... раньше вроде ровно получалось (типа 4 по количеству узлов), теперь - не понял когда и почему - стали такие странности вылезать. Я разберусь (со временем), отпишусь (если не забуду...) Но если идеи есть - буду рад
2021 June 18
A
@mvkorolev хм, а где файл лежит?
может на hdfs с блок сайзом в 64 мб? тогда 400 мб это и есть 7 блоков приблизительно -> 7 партиций
может на hdfs с блок сайзом в 64 мб? тогда 400 мб это и есть 7 блоков приблизительно -> 7 партиций