Вот есть у меня Spark-кластер (спасибо Cloudera за это) , параллельно спарку  живёт Presto для  аналитиков
Насколько это критично? Как сделать так, чтобы они не дрались за ресурсы?

Подскажите гудпрактисы как запилить замер времени внутри pyspark app грамотно (на постоянную основу). Например, если завернуть интересные блоки в самописный timeit, а перед выходом из блока инициализировать расчеты фреймов типа count() или сброс на диск, это вообще как?)

в чатике датаинженеров буквально 3 дня назад был такой же вопрос https://t.me/hadoopusers

Или через https://github.com/LucaCanali/sparkMeasure идти например?

а просто враппер с логгером не хочешь? потом можно в условном airflow смотреть время логов

можно спарковый event log попарсить, там все входы и выходы из jobs/stages записаны

Так и делаем, но чтобы время было реальным нужно как-то пнуть исполнение дага, иначе последний блок выходит самым долгим.

а, понял

Хочется получать именно время общей логической единицы, а она может много стейджей включать. Я так понимаю в эвент лог py-команда никак не прорастает, чтобы можно было соотнести блоки.

https://github.com/sashgorokhov/pyspark-sugar тут просовывают инфу о логических блоках, но для другого

Спасибо. Позаимствовал оттуда выставление групп. По результатом ресеча выглядит так что парсинг эвент логов все-таки оверхед, необходимый для дебага. При этом получаю довольно значимое расхождение времени исполнения с инициализацией расчетов насильно, и пассивно в конце пайплайна (даже с учетом оверхеда на count в роли инициализации), хотя по идее стейджы принадлежащие определённой группе после аггрегации (самописной) должны давать одно время, независимо есть ли инициализация или нет. (тут либо я с парсером накосячил, либо спарк по хитрому оптимизирует даг). Для логгирования на постоянной основе (для мониторинга) выглядит, что простой декоратор timeit с насильной инициализацией (естественно не везде где душе угодно, а реально жирных кусков пайплайна) выглядит норм решением.

Всем привет. А вот такой вопрос. Есть on-prem кластер спарка и кластер в датабриксе. Хочется, чтобы в одном питоновском интерпретаторе можно было бы поднять две спарк сессии к этим кластерам. Вроде как такое из коробки не работает, кто-то упражнялся?

Сессия - синглтон

Хотя через livy мне как-то удалось запустить две сессии в одной тетрадке, не то, чтобы это было то, что я хотел😆

Но можно попробовать, spark magic kernels что ли называется

BNB Giveway has been banned! Reason: CAS ban.

Давно не было в этом чате тупых вопросов.
Есть вопрос по спарку. Представьте что есть цепочка из тридцати модулей и они сохраняют промежуточные результаты в хдфс. По сути их цель - это обработать батч и выдать результат.
Сейчас эта цепочка аппликейшенов с промежуточными записью\чтением отрабатывает за 2 часа.
Есть большое предположение, что если убрать лишних 30 запись\чтение на HDD,  то скорость пайплана возрастет.
Но такое можно достичь только объединением в один аппликейшн. Или есть еще какие-то варианты?
Как хранить в памяти результат и не скидывать на диск... И мб шарить между приложениями)
Объединять большую бизнес логику в одном приложении тоже не хочется... Сложно будет дебажить..
...
Понимаю что пишу треш, но вы, наверно, поняли в чем суть...

tmpfs? )

а оно вообще надо? работает на кластере со спарком? что-то вообще гугл ничего нормального не говорит...

в общем, вот сама идея объединить модули ради сокращения кол-ва записей\чтения это норм?
мб даже не стоит пытаться оптимизировать этот момент?
может замерить как-то можно сколько у приложения занимает запись/чтение?

замерить можно например профайлером