Наверное, это выходит за рамки тех задач, которые я все это время решал, потому что не знал о таких проблемах. (

У вас есть пользователи которые Спарк используют исключительно через JDBC/ODBC?

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

Тогда да, вам это не актуально

Понял, спасибо

Интересно что они будут пушить когда крипта схлопнется

Откатятся до каких-нибудь электронных кошельков, наверное.

Да, беттинг какой-нибудь, с «гарантированным выигрышем»

Ну как раз пользоваться тулами чтобы делать запросики в spark-sql через dbeaver или ещё какие-то удобные тулы , которым удобней в jdbc

То есть вы сейчас упираетесь в возможности STS?

Нет, только собираюсь, просто решил сразу посмотреть на альтернативы

Вдруг кто-то может сказать своё мнение

Ну и я не увидел в STS интерфейса по jdbc

Я бы сказал так: если у вас пользователей через JDBC единицы, у них нет жестких SLA, то хватит STS; Kyuubi работает (у меня есть знакомый пользователь из Китая), но там не все гладко, например он ложится на больших резалтсетах

Ну и это все применимо только если вы сами держите всю спарковую инфру, на датабриксе не нужны никакие фронты

А вот кстати какие ограничения у датабрикса на выгрузку данных через jdbc? Раньше в документации видел 4gb, но сейчас пропало как то. Там же все от driver.MaxResultSize зависит?

Спасибо за отзыв, попробую начать с обычного STS

Коллеги, нужно ваше мнение/критика.

Как лучше раскатить Спарк в кубере, причем в 2-х вариантах работы:
1) Чтобы с юпитерхаба можно через toree или pyspark ядра работать интерактивно, с динамической аллокацией ресурсов и все такое.(такое видел, и даже делал, но с yarnом, а не кубом) Видел с кубом тоже так делают, немного работал, но мало, чтобы понять боли и плюсы.
2)Чтобы с airflow сабмитить джобы спарка в этот куб кластер.

Я думаю идти по пути настройки конфигов spark-defaults.conf для работы с кубом. Но куб  в aws(eks) и опсы мне говорят, что там не все  так просто, чтобы работать с ним извне кластера. Я вот не очень понимаю эту проблему, если честно(типа создал сервисную учетку, накинул прав в iam, прокинул серты в настройки спарка). Может кто сталкивался?  
Поэтому раскатили standalone кластер спарка в кубере и предлагают работать с ним. Мне кажется, что это не очень рабочее решение. Типа скейлить воркеров будет не очень удобно. Но опять же, я со стендалон кластером работал 1 раз. Поэтому точно не могу понимать что не так будет. Поэтому может быть вы знаете плюсы и минусы такой реализации?

Итого 2 вопроса:
1) Какие есть трудности в настройке спарка с кубером, которы из под aws(eks)?
2) Какие есть плюсы и минусы standalone кластера спарка, который развернут в кубере, а дальше к этому кластеру будут ходить через shell и через сабмит?

Заранее благодарю!

На первый вопрос нашел, кажется, ответ:
"Use the spark-submit command from the server responsible for the deployment. Spark currently only supports Kubernetes authentication through SSL certificates. This method is not compatible with Amazon EKS because it only supports IAM and bearer tokens authentication."
Дока aws

кто сталкивался с этой проблемой можете помочь?