свой hadoop cluster vs public cloud offering

User avatar
Kolbasoff
Уже с Приветом
Posts: 3481
Joined: 02 Jan 2005 22:10

Re: свой hadoop cluster vs public cloud offering

Post by Kolbasoff »

Сабина wrote: 15 Nov 2017 23:20 Cпасибо, не знала что так делают. У нас каждый spark submit job работает с одним источником данных (s3 bucket), "driver program" прикидывает что к чему, какие будут нужны ресурсы, потом скока надо экзекьюторов колбасят (partitioning + auto-scaling), возвращают результат и все контекст умирает.
Правильный подход. Transient or persistent EMR?

Что касается AWS, то это конечно дорого, но это не наши проблемы. Рукодельный кластер запаришься конфигурить и поддерживать и проблемы искать, да и вообще, если контора на AWS скупится, то значит жадобы => денюх от них не дождешься. А даже если и дадут денег, то заодно повесят админскую работу. Нафик-нафик такой график.
User avatar
Сабина
Уже с Приветом
Posts: 19045
Joined: 11 Jan 2012 09:25
Location: CA

Re: свой hadoop cluster vs public cloud offering

Post by Сабина »

Kolbasoff wrote: 16 Nov 2017 02:17
Сабина wrote: 15 Nov 2017 23:20 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 скилз потеряю, они вообще то нужные
https://www.youtube.com/watch?v=wOwblaKmyVw
iDesperado
Уже с Приветом
Posts: 1422
Joined: 28 Nov 2008 17:50

Re: свой hadoop cluster vs public cloud offering

Post by iDesperado »

Сабина wrote: 15 Nov 2017 23:20 Cпасибо, не знала что так делают. У нас каждый spark submit job работает с одним источником данных (s3 bucket), "driver program" прикидывает что к чему, какие будут нужны ресурсы, потом скока надо экзекьюторов колбасят (partitioning + auto-scaling), возвращают результат и все контекст умирает.
ну да, контекст умирает, датасеты исчезают. и как я понимаю абсолютно все так делают, но как правильно никто толком не знает. лит-ры вообще нет.
Сабина wrote: 16 Nov 2017 00:47 А вот такое что-то нельзя использовать ?

https://github.com/spark-jobserver/spar ... lated-jobs
да, я уже писал
iDesperado wrote: 15 Nov 2017 14:43 есть какие-то полуфабрикаты типа spark-jobserver и livy но не выглядит что этот хлам кто-то в серьез использует.
в этом spark-jobserver можно подпихивать джарник, как то смущает такой подход с точки зрения безопасности. а как все таки как надо не понятно.
User avatar
Сабина
Уже с Приветом
Posts: 19045
Joined: 11 Jan 2012 09:25
Location: CA

Re: свой hadoop cluster vs public cloud offering

Post by Сабина »

iDesperado wrote: 16 Nov 2017 07:16
Сабина wrote: 15 Nov 2017 23:20 Cпасибо, не знала что так делают. У нас каждый spark submit job работает с одним источником данных (s3 bucket), "driver program" прикидывает что к чему, какие будут нужны ресурсы, потом скока надо экзекьюторов колбасят (partitioning + auto-scaling), возвращают результат и все контекст умирает.
ну да, контекст умирает, датасеты исчезают. и как я понимаю абсолютно все так делают, но как правильно никто толком не знает. лит-ры вообще нет.
А мне наоборот кажется странным то что вы описали. Впрочем если я правильно поняла конечно .... замапировать какой то стейт по сути ( аггрегация из стрима) и потом из него в разветвленные процессы вычитывать и делать там что-то разное. Вроде противоречит основной идее immutability and replay ? А если второй процесс вычитал и что-то напортачил, то что делать ? Снова из Кафки то же самое выдергивать или не дай бог в Кафку собирать ? А что первый процесс будет делать если он уже свое отработал с этими данными ?
Хотя трудно конечно понять что там у вас такое не зная деталей.
https://www.youtube.com/watch?v=wOwblaKmyVw

Return to “Работа и Карьера в IT”