Может и так быть. И тут бааа, фастлоад)

так я про то и пытался донести, TDCH позволяет очень гранулярно контролировать нагрузку: если нехватает fastload сессий - используйте batch.insert, если нужно строго задать число сессий - используйте tdch.throttle.num.mappers, причем все это сделано максимально эффективно для системы, никаких 1000 DDL и потом insert c 999 union statements (или 1000 insert select)

на такой загруженной системе идея запускать 1000 DDL на каждый джоб кмк субоптимальна

причем мы оставляем в стороне саму архитектуру писать из спарк джоба (видимо с бизнес-логикой) во внешнюю систему, как это тестировать, как рекавери делать при падении одного экзекьютора и так дальше - это просто ужасный дизайн, если это не стриминг

писать спарком во внешние бд получается не правильно? какой best practics тут?

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

Я просто обратил внимание на "рекавери делать при падении одного экзекьютора" - это действие получается не имеет решения из коробки?

Плюсую за вот эту часть. Мухи отдельно - котлеты отдельно.
У нас сейчас есть две отдельные джобы- одна делает бизнес-логику, а вторая просто перекладывает результат из S3 в бд

если решения нет, то получается, в целом такому подходу сложно доверять

может как вариант: проверять наличие дубликатов на принимающей стороне и в случае их наличия перезапускать или группировать или чистить..

Тут зависит от конкретного коннектора, там можно нагородить логики доплогики, но да, в худшем случае вы получите пересчёт результата в Спарке и дубли в приёмнике

А данные коммитятся в удаленную бд в самом конце выполнения контейнера или каждый batchsize строк?

У нас можно и по кусочкам, и целиком (надо сказать JDBC что type=fastload, но только в пустую таблицу)

Действительно, insert select group by по все полям having cnt=1 на каждую таблицу - это достойная трата ресурсов МРР СУБД (когда можно было всего этого избежать и просто взять готовую таблицу)

ну чтото делать надо, в идеале, конечно, чтобы spark коммитил строки вконце выоплнения контейнера

получилось поюзать?

Идёт проект

и как?

дрил с паркетами