, then join with another table and do a second
>>> aggregation. I could probably rewrite the query in such a way that it does
>>> aggregation in one pass but that would obfuscate the purpose of the various
>>> stages.
>>> Le 7 juil. 2016 12:55, "Sivakumaran S&quo
2:31 PM
To: Arnaud Bailly
Cc: Sivakumaran S , "user @spark"
Subject: Re: Multiple aggregations over streaming dataframes
> We are planning to address this issue in the future.
>
> At a high level, we'll have to add a delta mode so that updates can be
> communicat
rnauld,
>>>
>>> Sorry for the doubt, but what exactly is multiple aggregation? What is
>>> the use case?
>>>
>>> Regards,
>>>
>>> Sivakumaran
>>>
>>>
>>> On 07-Jul-2016, at 11:18 AM, Arnaud Bailly
>>> wro
t;> the use case?
>>
>> Regards,
>>
>> Sivakumaran
>>
>>
>> On 07-Jul-2016, at 11:18 AM, Arnaud Bailly
>> wrote:
>>
>> Hello,
>>
>> I understand multiple aggregations over streaming dataframes is not
>> currently supported
doubt, but what exactly is multiple aggregation? What is the
> use case?
>
> Regards,
>
> Sivakumaran
>
>
>> On 07-Jul-2016, at 11:18 AM, Arnaud Bailly > <mailto:arnaud.oq...@gmail.com>> wrote:
>>
>> Hello,
>>
>> I understand mu
Le 7 juil. 2016 12:55, "Sivakumaran S" a écrit :
> Hi Arnauld,
>
> Sorry for the doubt, but what exactly is multiple aggregation? What is the
> use case?
>
> Regards,
>
> Sivakumaran
>
>
> On 07-Jul-2016, at 11:18 AM, Arnaud Bailly wrote:
>
> Hello,
Hi Arnauld,
Sorry for the doubt, but what exactly is multiple aggregation? What is the use
case?
Regards,
Sivakumaran
> On 07-Jul-2016, at 11:18 AM, Arnaud Bailly wrote:
>
> Hello,
>
> I understand multiple aggregations over streaming dataframes is not currently
> supp
Hello,
I understand multiple aggregations over streaming dataframes is not
currently supported in Spark 2.0. Is there a workaround? Out of the top of
my head I could think of having a two stage approach:
- first query writes output to disk/memory using "complete" mode
- second query
