Thanks for the insight!

_______________

*Mike Wright*
Principal Architect, Software Engineering
S&P Capital IQ and SNL

434-951-7816 *p*
434-244-4466 *f*
540-470-0119 *m*

mwri...@snl.com



On Fri, Dec 11, 2015 at 2:38 PM, Michael Armbrust <mich...@databricks.com>
wrote:

> The way that we do this is to have a single context with a server in front
> that multiplexes jobs that use that shared context.  Even if you aren't
> sharing data this is going to give you the best fine grained sharing of the
> resources that the context is managing.
>
> On Fri, Dec 11, 2015 at 10:55 AM, Mike Wright <mwri...@snl.com> wrote:
>
>> Somewhat related - What's the correct implementation when you have a
>> single cluster to support multiple jobs that are unrelated and NOT sharing
>> data? I was directed to figure out, via job server, to support "multiple
>> contexts" and explained that multiple contexts per JVM is not really
>> supported. So, via job server, how does one support multiple contexts in
>> DIFFERENT JVM's? I specify multiple contexts in the conf file and the
>> initialization of the subsequent contexts fail.
>>
>>
>>
>> On Fri, Dec 4, 2015 at 3:37 PM, Michael Armbrust <mich...@databricks.com>
>> wrote:
>>
>>> On Fri, Dec 4, 2015 at 11:24 AM, Anfernee Xu <anfernee...@gmail.com>
>>> wrote:
>>>
>>>> If multiple users are looking at the same data set, then it's good
>>>> choice to share the SparkContext.
>>>>
>>>> But my usercases are different, users are looking at different data(I
>>>> use custom Hadoop InputFormat to load data from my data source based on the
>>>> user input), the data might not have any overlap. For now I'm taking below
>>>> approach
>>>>
>>>
>>> Still if you want fine grained sharing of compute resources as well, you
>>> want to using single SparkContext.
>>>
>>
>>
>

Reply via email to