тоже как вариант, спасибо

но можно и свои контейнеры деплоить в ярн, кто ж мешает

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

Тормоза у хттп в таком сервинге

распределенный, поверх спарка умеет работать (и standalone тоже распределенный)

ну во всяком случае был пару лет назад, когда я с ним игрался

а что есть тормоза? какие-то SLA жесткие?

Вы просто сказали про линейную масштабируемость, да, добавляй тачки чтобы кормить хттп питона

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

Или сервить с плюсов

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

жестоко

Но это если нужно прям по хттп

Чем например кафка плюс питон не устраивает?

ну по хттп большие вектора данных гонять это плохая идея, априори

Так я про это же

То есть в 90% это бред

так вы и не гоняйте их целиком.
передавайте только исходные фичи, а их расчет пусть на сервак ложится, а на сервере оптимизируйте с numba + jit-том

Господа. А какой способ передачи данных в HIVE самый адекватно быстрый? Есть цель, максимально быстро выкачивать данные с источника, и класть в партицированную таблицу в HIVE.

В качестве источника сейчас выступает HANA. И способ забора данных по jdbc.

Это раз в 5 быстрей старой схемы через pyrfc. Но все равно медленно.

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

Ну а с большими сервисами лучше подумать