Yeah - i wish we'd named KGroupedStream GroupedKStream, similarly for
KGroupedTable.
On Tue, 16 May 2017 at 17:59 Kyle Winkelman <winkelman.k...@gmail.com>
wrote:
> I have added code blocks and a note about the partial results.
>
> Can I ask why you dont like KCogroupedStream? I just think that because it
> is created from a KGroupedStream we should keep a similar name format.
>
> On May 16, 2017 9:23 AM, "Damian Guy" <damian....@gmail.com> wrote:
>
> Hi Kyle,
>
> Can you put the code examples etc in {code} blocks to make it easier to
> read?
>
> I think this is probably a pretty common use-case and therefore a
> worthwhile addition to the API.
>
> I'd suggest dropping the K from KCogroupedStream and calling it
> CogroupedStream or CogroupedKStream.
> In your example, wouldn't the output potentially have more partial results?
> I.e, for each input on any stream you'd potentially see a record produced?
> I think it is worth mentioning this.
>
> Thanks,
> Damian
>
> On Tue, 16 May 2017 at 12:26 Kyle Winkelman <winkelman.k...@gmail.com>
> wrote:
>
> > No problem, I just wanted to make sure people still had more to say. I
> will
> > wait another week.
> >
> > Thanks,
> > Kyle
> >
> > On May 16, 2017 4:25 AM, "Eno Thereska" <eno.there...@gmail.com> wrote:
> >
> > > Hi Kyle,
> > >
> > > Sorry for the delay in reviews, tomorrow is feature freeze deadline (
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+0.11.0.0
> > <
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+0.11.0.0
> > >)
> > > so people are busier than usual. Stay tuned.
> > >
> > > Eno
> > > > On 15 May 2017, at 13:25, Kyle Winkelman <winkelman.k...@gmail.com>
> > > wrote:
> > > >
> > > > Damian Guy, could you let me know if you plan to review this further?
> > > There
> > > > is no rush, but if you dont have any additional comments I could
> start
> > > the
> > > > voting and finish my WIP PR.
> > > >
> > > > Thanks,
> > > > Kyle
> > > >
> > > > On May 9, 2017 11:07 AM, "Kyle Winkelman" <winkelman.k...@gmail.com>
> > > wrote:
> > > >
> > > >> Eno, is there anyone else that is an expert in the kafka streams
> realm
> > > >> that I should reach out to for input?
> > > >>
> > > >> I believe Damian Guy is still planning on reviewing this more in
> depth
> > > so
> > > >> I will wait for his inputs before continuing.
> > > >>
> > > >> On May 9, 2017 7:30 AM, "Eno Thereska" <eno.there...@gmail.com>
> > wrote:
> > > >>
> > > >>> Thanks Kyle, good arguments.
> > > >>>
> > > >>> Eno
> > > >>>
> > > >>>> On May 7, 2017, at 5:06 PM, Kyle Winkelman <
> > winkelman.k...@gmail.com>
> > > >>> wrote:
> > > >>>>
> > > >>>> *- minor: could you add an exact example (similar to what Jay’s
> > > example
> > > >>> is,
> > > >>>> or like your Spark/Pig pointers had) to make this super concrete?*
> > > >>>> I have added a more concrete example to the KIP.
> > > >>>>
> > > >>>> *- my main concern is that we’re exposing this optimization to the
> > > DSL.
> > > >>> In
> > > >>>> an ideal world, an optimizer would take the existing DSL and do
> the
> > > >>> right
> > > >>>> thing under the covers (create just one state store, arrange the
> > nodes
> > > >>>> etc). The original DSL had a bunch of small, composable pieces
> > (group,
> > > >>>> aggregate, join) that this proposal groups together. I’d like to
> > hear
> > > >>> your
> > > >>>> thoughts on whether it’s possible to do this optimization with the
> > > >>> current
> > > >>>> DSL, at the topology builder level.*
> > > >>>> You would have to make a lot of checks to understand if it is even
> > > >>> possible
> > > >>>> to make this optimization:
> > > >>>> 1. Make sure they are all KTableKTableOuterJoins
> > > >>>> 2. None of the intermediate KTables are used for anything else.
> > > >>>> 3. None of the intermediate stores are used. (This may be
> impossible
> > > >>>> especially if they use KafkaStreams#store after the topology has
> > > already
> > > >>>> been built.)
> > > >>>> You would then need to make decisions during the optimization:
> > > >>>> 1. Your new initializer would the composite of all the individual
> > > >>>> initializers and the valueJoiners.
> > > >>>> 2. I am having a hard time thinking about how you would turn the
> > > >>>> aggregators and valueJoiners into an aggregator that would work on
> > the
> > > >>>> final object, but this may be possible.
> > > >>>> 3. Which state store would you use? The ones declared would be for
> > the
> > > >>>> aggregate values. None of the declared ones would be guaranteed to
> > > hold
> > > >>> the
> > > >>>> final object. This would mean you must created a new state store
> and
> > > not
> > > >>>> created any of the declared ones.
> > > >>>>
> > > >>>> The main argument I have against it is even if it could be done I
> > > don't
> > > >>>> know that we would want to have this be an optimization in the
> > > >>> background
> > > >>>> because the user would still be required to think about all of the
> > > >>>> intermediate values that they shouldn't need to worry about if
> they
> > > only
> > > >>>> care about the final object.
> > > >>>>
> > > >>>> In my opinion cogroup is a common enough case that it should be
> part
> > > of
> > > >>> the
> > > >>>> composable pieces (group, aggregate, join) because we want to
> allow
> > > >>> people
> > > >>>> to join more than 2 or more streams in an easy way. Right now I
> > don't
> > > >>> think
> > > >>>> we give them ways of handling this use case easily.
> > > >>>>
> > > >>>> *-I think there will be scope for several such optimizations in
> the
> > > >>> future
> > > >>>> and perhaps at some point we need to think about decoupling the
> 1:1
> > > >>> mapping
> > > >>>> from the DSL into the physical topology.*
> > > >>>> I would argue that cogroup is not just an optimization it is a new
> > way
> > > >>> for
> > > >>>> the users to look at accomplishing a problem that requires
> multiple
> > > >>>> streams. I may sound like a broken record but I don't think users
> > > should
> > > >>>> have to build the N-1 intermediate tables and deal with their
> > > >>> initializers,
> > > >>>> serdes and stores if all they care about is the final object.
> > > >>>> Now if for example someone uses cogroup but doesn't supply
> > additional
> > > >>>> streams and aggregators this case is equivalent to a single
> grouped
> > > >>> stream
> > > >>>> making an aggregate call. This case is what I view an optimization
> > as,
> > > >>> we
> > > >>>> could remove the KStreamCogroup and act as if there was just a
> call
> > to
> > > >>>> KGroupedStream#aggregate instead of calling
> KGroupedStream#cogroup.
> > (I
> > > >>>> would prefer to just write a warning saying that this is not how
> > > >>> cogroup is
> > > >>>> to be used.)
> > > >>>>
> > > >>>> Thanks,
> > > >>>> Kyle
> > > >>>>
> > > >>>> On Sun, May 7, 2017 at 5:41 AM, Eno Thereska <
> > eno.there...@gmail.com>
> > > >>> wrote:
> > > >>>>
> > > >>>>> Hi Kyle,
> > > >>>>>
> > > >>>>> Thanks for the KIP again. A couple of comments:
> > > >>>>>
> > > >>>>> - minor: could you add an exact example (similar to what Jay’s
> > > example
> > > >>> is,
> > > >>>>> or like your Spark/Pig pointers had) to make this super concrete?
> > > >>>>>
> > > >>>>> - my main concern is that we’re exposing this optimization to the
> > > DSL.
> > > >>> In
> > > >>>>> an ideal world, an optimizer would take the existing DSL and do
> the
> > > >>> right
> > > >>>>> thing under the covers (create just one state store, arrange the
> > > nodes
> > > >>>>> etc). The original DSL had a bunch of small, composable pieces
> > > (group,
> > > >>>>> aggregate, join) that this proposal groups together. I’d like to
> > hear
> > > >>> your
> > > >>>>> thoughts on whether it’s possible to do this optimization with
> the
> > > >>> current
> > > >>>>> DSL, at the topology builder level.
> > > >>>>>
> > > >>>>> I think there will be scope for several such optimizations in the
> > > >>> future
> > > >>>>> and perhaps at some point we need to think about decoupling the
> 1:1
> > > >>> mapping
> > > >>>>> from the DSL into the physical topology.
> > > >>>>>
> > > >>>>> Thanks
> > > >>>>> Eno
> > > >>>>>
> > > >>>>>> On May 5, 2017, at 4:39 PM, Jay Kreps <j...@confluent.io> wrote:
> > > >>>>>>
> > > >>>>>> I haven't digested the proposal but the use case is pretty
> common.
> > > An
> > > >>>>>> example would be the "customer 360" or "unified customer
> profile"
> > > use
> > > >>>>> case
> > > >>>>>> we often use. In that use case you have a dozen systems each of
> > > which
> > > >>> has
> > > >>>>>> some information about your customer (account details, settings,
> > > >>> billing
> > > >>>>>> info, customer service contacts, purchase history, etc). Your
> goal
> > > is
> > > >>> to
> > > >>>>>> join/munge these into a single profile record for each customer
> > that
> > > >>> has
> > > >>>>>> all the relevant info in a usable form and is up-to-date with
> all
> > > the
> > > >>>>>> source systems. If you implement that with kstreams as a
> sequence
> > of
> > > >>>>> joins
> > > >>>>>> i think today we'd fully materialize N-1 intermediate tables.
> But
> > > >>> clearly
> > > >>>>>> you only need a single stage to group all these things that are
> > > >>> already
> > > >>>>>> co-partitioned. A distributed database would do this under the
> > > covers
> > > >>>>> which
> > > >>>>>> is arguably better (at least when it does the right thing) and
> > > >>> perhaps we
> > > >>>>>> could do the same thing but I'm not sure we know the
> partitioning
> > so
> > > >>> we
> > > >>>>> may
> > > >>>>>> need an explicit cogroup command that impllies they are already
> > > >>>>>> co-partitioned.
> > > >>>>>>
> > > >>>>>> -Jay
> > > >>>>>>
> > > >>>>>> On Fri, May 5, 2017 at 5:56 AM, Kyle Winkelman <
> > > >>> winkelman.k...@gmail.com
> > > >>>>>>
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Yea thats a good way to look at it.
> > > >>>>>>> I have seen this type of functionality in a couple other
> > platforms
> > > >>> like
> > > >>>>>>> spark and pig.
> > > >>>>>>> https://spark.apache.org/docs/0.6.2/api/core/spark/
> > > >>>>> PairRDDFunctions.html
> > > >>>>>>> https://www.tutorialspoint.com/apache_pig/apache_pig_
> > > >>>>> cogroup_operator.htm
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> On May 5, 2017 7:43 AM, "Damian Guy" <damian....@gmail.com>
> > wrote:
> > > >>>>>>>
> > > >>>>>>>> Hi Kyle,
> > > >>>>>>>>
> > > >>>>>>>> If i'm reading this correctly it is like an N way outer join?
> So
> > > an
> > > >>>>> input
> > > >>>>>>>> on any stream will always produce a new aggregated value - is
> > that
> > > >>>>>>> correct?
> > > >>>>>>>> Effectively, each Aggregator just looks up the current value,
> > > >>>>> aggregates
> > > >>>>>>>> and forwards the result.
> > > >>>>>>>> I need to look into it and think about it a bit more, but it
> > seems
> > > >>> like
> > > >>>>>>> it
> > > >>>>>>>> could be a useful optimization.
> > > >>>>>>>>
> > > >>>>>>>> On Thu, 4 May 2017 at 23:21 Kyle Winkelman <
> > > >>> winkelman.k...@gmail.com>
> > > >>>>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> I sure can. I have added the following description to my KIP.
> > If
> > > >>> this
> > > >>>>>>>>> doesn't help let me know and I will take some more time to
> > build
> > > a
> > > >>>>>>>> diagram
> > > >>>>>>>>> and make more of a step by step description:
> > > >>>>>>>>>
> > > >>>>>>>>> Example with Current API:
> > > >>>>>>>>>
> > > >>>>>>>>> KTable<K, V1> table1 =
> > > >>>>>>>>> builder.stream("topic1").groupByKey().aggregate(initializer1,
> > > >>>>>>>> aggregator1,
> > > >>>>>>>>> aggValueSerde1, storeName1);
> > > >>>>>>>>> KTable<K, V2> table2 =
> > > >>>>>>>>> builder.stream("topic2").groupByKey().aggregate(initializer2,
> > > >>>>>>>> aggregator2,
> > > >>>>>>>>> aggValueSerde2, storeName2);
> > > >>>>>>>>> KTable<K, V3> table3 =
> > > >>>>>>>>> builder.stream("topic3").groupByKey().aggregate(initializer3,
> > > >>>>>>>> aggregator3,
> > > >>>>>>>>> aggValueSerde3, storeName3);
> > > >>>>>>>>> KTable<K, CG> cogrouped = table1.outerJoin(table2,
> > > >>>>>>>>> joinerOneAndTwo).outerJoin(table3, joinerOneTwoAndThree);
> > > >>>>>>>>>
> > > >>>>>>>>> As you can see this creates 3 StateStores, requires 3
> > > initializers,
> > > >>>>>>> and 3
> > > >>>>>>>>> aggValueSerdes. This also adds the pressure to user to define
> > > what
> > > >>> the
> > > >>>>>>>>> intermediate values are going to be (V1, V2, V3). They are
> left
> > > >>> with a
> > > >>>>>>>>> couple choices, first to make V1, V2, and V3 all the same as
> CG
> > > and
> > > >>>>> the
> > > >>>>>>>> two
> > > >>>>>>>>> joiners are more like mergers, or second make them
> intermediate
> > > >>> states
> > > >>>>>>>> such
> > > >>>>>>>>> as Topic1Map, Topic2Map, and Topic3Map and the joiners use
> > those
> > > to
> > > >>>>>>> build
> > > >>>>>>>>> the final aggregate CG value. This is something the user
> could
> > > >>> avoid
> > > >>>>>>>>> thinking about with this KIP.
> > > >>>>>>>>>
> > > >>>>>>>>> When a new input arrives lets say at "topic1" it will first
> go
> > > >>> through
> > > >>>>>>> a
> > > >>>>>>>>> KStreamAggregate grabbing the current aggregate from
> > storeName1.
> > > It
> > > >>>>>>> will
> > > >>>>>>>>> produce this in the form of the first intermediate value and
> > get
> > > >>> sent
> > > >>>>>>>>> through a KTableKTableOuterJoin where it will look up the
> > current
> > > >>>>> value
> > > >>>>>>>> of
> > > >>>>>>>>> the key in storeName2. It will use the first joiner to
> > calculate
> > > >>> the
> > > >>>>>>>> second
> > > >>>>>>>>> intermediate value, which will go through an additional
> > > >>>>>>>>> KTableKTableOuterJoin. Here it will look up the current value
> > of
> > > >>> the
> > > >>>>>>> key
> > > >>>>>>>> in
> > > >>>>>>>>> storeName3 and use the second joiner to build the final
> > aggregate
> > > >>>>>>> value.
> > > >>>>>>>>>
> > > >>>>>>>>> If you think through all possibilities for incoming topics
> you
> > > will
> > > >>>>> see
> > > >>>>>>>>> that no matter which topic it comes in through all three
> stores
> > > are
> > > >>>>>>>> queried
> > > >>>>>>>>> and all of the joiners must get used.
> > > >>>>>>>>>
> > > >>>>>>>>> Topology wise for N incoming streams this creates N
> > > >>>>>>>>> KStreamAggregates, 2*(N-1) KTableKTableOuterJoins, and N-1
> > > >>>>>>>>> KTableKTableJoinMergers.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> Example with Proposed API:
> > > >>>>>>>>>
> > > >>>>>>>>> KGroupedStream<K, V1> grouped1 = builder.stream("topic1").
> > > >>>>>>> groupByKey();
> > > >>>>>>>>> KGroupedStream<K, V2> grouped2 = builder.stream("topic2").
> > > >>>>>>> groupByKey();
> > > >>>>>>>>> KGroupedStream<K, V3> grouped3 = builder.stream("topic3").
> > > >>>>>>> groupByKey();
> > > >>>>>>>>> KTable<K, CG> cogrouped = grouped1.cogroup(initializer1,
> > > >>> aggregator1,
> > > >>>>>>>>> aggValueSerde1, storeName1)
> > > >>>>>>>>> .cogroup(grouped2, aggregator2)
> > > >>>>>>>>> .cogroup(grouped3, aggregator3)
> > > >>>>>>>>> .aggregate();
> > > >>>>>>>>>
> > > >>>>>>>>> As you can see this creates 1 StateStore, requires 1
> > initializer,
> > > >>> and
> > > >>>>> 1
> > > >>>>>>>>> aggValueSerde. The user no longer has to worry about the
> > > >>> intermediate
> > > >>>>>>>>> values and the joiners. All they have to think about is how
> > each
> > > >>>>> stream
> > > >>>>>>>>> impacts the creation of the final CG object.
> > > >>>>>>>>>
> > > >>>>>>>>> When a new input arrives lets say at "topic1" it will first
> go
> > > >>> through
> > > >>>>>>> a
> > > >>>>>>>>> KStreamAggreagte and grab the current aggregate from
> > storeName1.
> > > It
> > > >>>>>>> will
> > > >>>>>>>>> add its incoming object to the aggregate, update the store
> and
> > > pass
> > > >>>>> the
> > > >>>>>>>> new
> > > >>>>>>>>> aggregate on. This new aggregate goes through the
> > KStreamCogroup
> > > >>> which
> > > >>>>>>> is
> > > >>>>>>>>> pretty much just a pass through processor and you are done.
> > > >>>>>>>>>
> > > >>>>>>>>> Topology wise for N incoming streams the new api will only
> > every
> > > >>>>>>> create N
> > > >>>>>>>>> KStreamAggregates and 1 KStreamCogroup.
> > > >>>>>>>>>
> > > >>>>>>>>> On Thu, May 4, 2017 at 4:42 PM, Matthias J. Sax <
> > > >>>>> matth...@confluent.io
> > > >>>>>>>>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> Kyle,
> > > >>>>>>>>>>
> > > >>>>>>>>>> thanks a lot for the KIP. Maybe I am a little slow, but I
> > could
> > > >>> not
> > > >>>>>>>>>> follow completely. Could you maybe add a more concrete
> > example,
> > > >>> like
> > > >>>>>>> 3
> > > >>>>>>>>>> streams with 3 records each (plus expected result), and show
> > the
> > > >>>>>>>>>> difference between current way to to implement it and the
> > > proposed
> > > >>>>>>> API?
> > > >>>>>>>>>> This could also cover the internal processing to see what
> > store
> > > >>> calls
> > > >>>>>>>>>> would be required for both approaches etc.
> > > >>>>>>>>>>
> > > >>>>>>>>>> I think, it's pretty advanced stuff you propose, and it
> would
> > > >>> help to
> > > >>>>>>>>>> understand it better.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Thanks a lot!
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> -Matthias
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> On 5/4/17 11:39 AM, Kyle Winkelman wrote:
> > > >>>>>>>>>>> I have made a pull request. It can be found here.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> https://github.com/apache/kafka/pull/2975
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I plan to write some more unit tests for my classes and get
> > > >>> around
> > > >>>>>>> to
> > > >>>>>>>>>>> writing documentation for the public api additions.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> One thing I was curious about is during the
> > > >>>>>>>>>> KCogroupedStreamImpl#aggregate
> > > >>>>>>>>>>> method I pass null to the
> > KGroupedStream#repartitionIfRequired
> > > >>>>>>>> method.
> > > >>>>>>>>> I
> > > >>>>>>>>>>> can't supply the store name because if more than one
> grouped
> > > >>> stream
> > > >>>>>>>>>>> repartitions an error is thrown. Is there some name that
> > > someone
> > > >>>>>>> can
> > > >>>>>>>>>>> recommend or should I leave the null and allow it to fall
> > back
> > > to
> > > >>>>>>> the
> > > >>>>>>>>>>> KGroupedStream.name?
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Should this be expanded to handle grouped tables? This
> would
> > be
> > > >>>>>>>> pretty
> > > >>>>>>>>>> easy
> > > >>>>>>>>>>> for a normal aggregate but one allowing session stores and
> > > >>> windowed
> > > >>>>>>>>>> stores
> > > >>>>>>>>>>> would required KTableSessionWindowAggregate and
> > > >>>>>>> KTableWindowAggregate
> > > >>>>>>>>>>> implementations.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Thanks,
> > > >>>>>>>>>>> Kyle
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On May 4, 2017 1:24 PM, "Eno Thereska" <
> > eno.there...@gmail.com
> > > >
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> I’ll look as well asap, sorry, been swamped.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Eno
> > > >>>>>>>>>>>>> On May 4, 2017, at 6:17 PM, Damian Guy <
> > damian....@gmail.com
> > > >
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Hi Kyle,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thanks for the KIP. I apologize that i haven't had the
> > chance
> > > >>> to
> > > >>>>>>>> look
> > > >>>>>>>>>> at
> > > >>>>>>>>>>>>> the KIP yet, but will schedule some time to look into it
> > > >>>>>>> tomorrow.
> > > >>>>>>>>> For
> > > >>>>>>>>>>>> the
> > > >>>>>>>>>>>>> implementation, can you raise a PR against kafka trunk
> and
> > > mark
> > > >>>>>>> it
> > > >>>>>>>> as
> > > >>>>>>>>>>>> WIP?
> > > >>>>>>>>>>>>> It will be easier to review what you have done.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>> Damian
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Thu, 4 May 2017 at 11:50 Kyle Winkelman <
> > > >>>>>>>> winkelman.k...@gmail.com
> > > >>>>>>>>>>
> > > >>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I am replying to this in hopes it will draw some
> attention
> > > to
> > > >>> my
> > > >>>>>>>> KIP
> > > >>>>>>>>>> as
> > > >>>>>>>>>>>> I
> > > >>>>>>>>>>>>>> haven't heard from anyone in a couple days. This is my
> > first
> > > >>> KIP
> > > >>>>>>>> and
> > > >>>>>>>>>> my
> > > >>>>>>>>>>>>>> first large contribution to the project so I'm sure I
> did
> > > >>>>>>>> something
> > > >>>>>>>>>>>> wrong.
> > > >>>>>>>>>>>>>> ;)
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On May 1, 2017 4:18 PM, "Kyle Winkelman" <
> > > >>>>>>>> winkelman.k...@gmail.com>
> > > >>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Hello all,
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> I have created KIP-150 to facilitate discussion about
> > > adding
> > > >>>>>>>>> cogroup
> > > >>>>>>>>>> to
> > > >>>>>>>>>>>>>>> the streams DSL.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Please find the KIP here:
> > > >>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > >>>>>>>>>>>>>>> 150+-+Kafka-Streams+Cogroup
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Please find my initial implementation here:
> > > >>>>>>>>>>>>>>> https://github.com/KyleWinkelman/kafka
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>>> Kyle Winkelman
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > >
> > >
> >
>
