Кажется мы просто постоянно храним текущее самое большое и самое меньшее значение и нормируем новые приходящие значения по ним. Начнётся неточно, но чем больше данных - тем точнее будет
Кажется мы просто постоянно храним текущее самое большое и самое меньшее значение и нормируем новые приходящие значения по ним. Начнётся неточно, но чем больше данных - тем точнее будет
Всем привет - столкнулись с проблемой в Google cloud - может у кого был похожий кейс - пропадания хартбита и вследстии этого завершения работы спарка с ошибкой? корректно проходит много итераций обучения модели и примерно через 5 часов на очередной итерации нет ответа от драйвера насколько я понимаю и вылетает ERROR Executor: Exit as unable to send heartbeats to driver more than 60 times До этого падало при таких же обстоятельствах но с classNotFoundExceptioin - т.е. проходили интерации норм но после 5 часов работы программа не могла найти класс который до этого использовала( первым делом подумали про то что может гарбедж коллектор удалял класс из jvm но промониторили память там вроде все ок без аномалий В логах ошибки написано что можно увеличить хардбит но это костыльное решение насоклько понимаю - возможно это изза каких то проблем сетью? Заранее спасибо кто чем мыслями поделиться)
Всем привет! А какая fraction памяти спарк используется для сжатия данных для спилла (storage ?). Что еще можно сделать для избежания редких оом при спиле ? (больше партиций ?)