свой hadoop cluster vs public cloud offering

[Kolbasoff]

Cпасибо, не знала что так делают. У нас каждый spark submit job работает с одним источником данных (s3 bucket), "driver program" прикидывает что к чему, какие будут нужны ресурсы, потом скока надо экзекьюторов колбасят (partitioning + auto-scaling), возвращают результат и все контекст умирает.

Правильный подход. Transient or persistent EMR?

Что касается AWS, то это конечно дорого, но это не наши проблемы. Рукодельный кластер запаришься конфигурить и поддерживать и проблемы искать, да и вообще, если контора на AWS скупится, то значит жадобы => денюх от них не дождешься. А даже если и дадут денег, то заодно повесят админскую работу. Нафик-нафик такой график.

[Сабина]

Cпасибо, не знала что так делают. У нас каждый spark submit job работает с одним источником данных (s3 bucket), "driver program" прикидывает что к чему, какие будут нужны ресурсы, потом скока надо экзекьюторов колбасят (partitioning + auto-scaling), возвращают результат и все контекст умирает.

Правильный подход. Transient or persistent EMR?

Что касается AWS, то это конечно дорого, но это не наши проблемы. Рукодельный кластер запаришься конфигурить и поддерживать и проблемы искать, да и вообще, если контора на AWS скупится, то значит жадобы => денюх от них не дождешься. А даже если и дадут денег, то заодно повесят админскую работу. Нафик-нафик такой график.

Persistent. у нас постоянно ранается 8 джобов минимум, через дженскинс удобно контролировать нагрузку - как краном. Еще у нас для executors используются spot instances, в том числе в продакшене. Спарк позволяет. В комбинации с грамотно настроенным auto-scaling получается очень хорошая экономия
Я не знаю почему у них свой кластер, компания занимается файрволами, возможно тоже крен что в паблик клауд не секьюр етс. Думаю несмертельно, наоборот научусь новому. Больше расстраивает что AWS скилз потеряю, они вообще то нужные

[iDesperado]

Cпасибо, не знала что так делают. У нас каждый spark submit job работает с одним источником данных (s3 bucket), "driver program" прикидывает что к чему, какие будут нужны ресурсы, потом скока надо экзекьюторов колбасят (partitioning + auto-scaling), возвращают результат и все контекст умирает.

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

А вот такое что-то нельзя использовать ?

https://github.com/spark-jobserver/spar ... lated-jobs

да, я уже писал

есть какие-то полуфабрикаты типа spark-jobserver и livy но не выглядит что этот хлам кто-то в серьез использует.

в этом spark-jobserver можно подпихивать джарник, как то смущает такой подход с точки зрения безопасности. а как все таки как надо не понятно.

[Сабина]

Cпасибо, не знала что так делают. У нас каждый spark submit job работает с одним источником данных (s3 bucket), "driver program" прикидывает что к чему, какие будут нужны ресурсы, потом скока надо экзекьюторов колбасят (partitioning + auto-scaling), возвращают результат и все контекст умирает.

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

А мне наоборот кажется странным то что вы описали. Впрочем если я правильно поняла конечно .... замапировать какой то стейт по сути ( аггрегация из стрима) и потом из него в разветвленные процессы вычитывать и делать там что-то разное. Вроде противоречит основной идее immutability and replay ? А если второй процесс вычитал и что-то напортачил, то что делать ? Снова из Кафки то же самое выдергивать или не дай бог в Кафку собирать ? А что первый процесс будет делать если он уже свое отработал с этими данными ?
Хотя трудно конечно понять что там у вас такое не зная деталей.