Не пользовательский интерфейс для спарка а пользовательский интерфейс для работы с данными.

Тут задача не совсем ясна. Похожую проблему решает Zeppelin, который позволяет пользователям запросы через спарк писать. Он сам сессиями спарка управляет

То есть есть шанс что время будет некомфортно большим?

оно будет пипец каким некомфортным

Вот да но! Пользователь неопытный и для него пишется собственный интерфейс

Я к тому что можно своё решение с похожей архитектурой сделать

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

Похоей - какой?

ничего себе какой пользователь, что стоит разработки интерфейса под него
может он все-таки научится sql?

Без шансов. Это простой бухгалтер 🙂

Дорогое решение получится для вашего бухгалтера. Вам же потом ещё сопровождать все это и оборудование выделять. Чем больше компонент - тем больше вероятность отказа. Кто-то ещё будет потреблять эти данные из Кафки или только UI для бухгалтера?

Только. Там народу будет около 100человек.

Решение не дорогое. Интерфейс уже готов. В принципе решение сделано с вышрузом данных в постгре. Но мне не нравится такое решение. Я хочу пользователю давать данные сразу из hdfs

а чем вам не нравится такое решение, если не секрет? логичное разделение ответственности и архитектуры: операционное приложение с операционной базой, аналитический сервис отдельно с прикладным интерфейсом

будет что-то еще вместо HDFS - достаточно переделать небольшую часть

Мне по началу тоже так показалось. Достаточно логичное решение. Но тут возникают серьезные проблемы с ограничением по транзакционности. проблемы с взаимодействием с базой. Синхронизация данных. Очень много вопросов с сохранением актуальноысти данных на источнике и в витринной базе. А тут, когда пользователь смотрит на реальные данные - все эти вопросы отпадают. Я уже не беру в расчет, что пришлось серьезно извратиться чтобы выборка данных для пользователя была максимально оперативно подготовленной.

У меня было видение и движение к следующм решениям. Поднимать открытые сессии и в рамках нескольких сессий отправлять spark запросы к данным. Еще одним вариантом - HBase, как база для хранения. Но вот пришла мысль насчет кафки. и подумалось.

Еще очень не плохой вариант - Apache Livy. И больше скажу - я его реализовал и получилось годно, но в компании на него харам

ну а если livy вам так подошел, то почему не просто Spark Thrift Server и JDBC подключение к нему из бэка?

Ну вот это как вариант я тоже рассматриваю.