Can you provide some examples on your naming patterns described below? Thanks
** julio On 3/3/15, 6:56 AM, "Thunder Stumpges" <tstump...@ntent.com> wrote: >I'm not sure who you were asking the question to, but since Gwen's was >not bound to any restrictions just a guideline, I'll assume you meant me >:) > >We have a concept of a "topic suffix property" that is some property in >the data that can change dynamically. The full topic name then becomes >"<avro_class>-<topic_suffix>" the dash is agreed never to be used in a >topic suffix so we can strip just the last dash to get back to the class >name. You could pick any delimiter not used in class names or suffixes. > >The topic suffix is then where we put things like processing stage >(incoming, cleaned, duplicate, etc) as well as any other orthogonal >delineation that needs to be in a different topic. > >We use .NET so I'm not sure the terminology for java but we have property >attributes to declare a property as the "topic suffix property" (and also >the "message key property") and we use "property getters" in a partial >class to do dynamic computation of these if necessary. > >A "message registry" then uses reflection to get the topic name and >message key for any message going out our producer. It also deals with >stripping the topic suffix for consumers looking for the avro type given >a topic name. > >So far this has worked great for us. >Cheers, >Thunder > > > >-----Original Message----- >From: Maciej Jaśkowski [maciej.jaskow...@gmail.com] >Received: Tuesday, 03 Mar 2015, 2:34AM >To: users@kafka.apache.org [users@kafka.apache.org] >CC: Taylor Gautier [tgaut...@yahoo.com]; kafka-us...@incubator.apache.org >[kafka-us...@incubator.apache.org] >Subject: Re: Stream naming conventions? > >This approach sounds nice at first but it would fail if you start >sending the same message but partitioned in different (orthogonal) >ways. How would you go about that? > >Maciej > >On 25 February 2015 at 05:17, Gwen Shapira <gshap...@cloudera.com> wrote: >> Nice :) I like the idea of tying topic name to avro schemas. >> >> I have experience with other people's data, and until now I mostly >> recommended: >> <app type>.<app name>.<data set name>.<stage of processing> >> >> So we end up with things like: >> etl.onlineshop.searches.validated >> >> Or if I have my own test dataset that I don't want to share: >> users.gshapira.newapp.testing1 >> >> Makes it relatively easy to share datasets across the organization, and >> also makes white-listing and black-listing relatively simple because of >>the >> hierarchy (until we add a real topic hierarchy to kafka...). >> >> Gwen >> >> On Tue, Feb 24, 2015 at 1:13 PM, Thunder Stumpges <tstump...@ntent.com> >> wrote: >> >>> We have a global namespace hierarchy for topics that is exactly our >>>Avro >>> namespace with Class Name. The template is basically: >>> >>> <root_ns>.Core.<core_data_types_shared_across_company> >>> <root_ns>.<product>.<product_specific_hierarchy> >>> >>> The up side of this for us is that since the topics are named based on >>>the >>> Avro schema namespace and type, we can look up the avro schema in the >>>Avro >>> Schema Repository using the topic name, and the schema ID coded into >>>the >>> message. Each product then also has the flexibility of defining >>>whatever >>> topics they find useful. >>> >>> Hope this helps, >>> Thunder >>> >>> -----Original Message----- >>> From: Taylor Gautier [mailto:tgaut...@yahoo.com.INVALID] >>> Sent: Tuesday, February 24, 2015 12:11 PM >>> To: kafka-us...@incubator.apache.org >>> Subject: Stream naming conventions? >>> >>> Hello all, >>> Just wondering if those with a good amount of experience using Kafka in >>> production with many streams have converged on any sort of naming >>> convention. If so would you be willing to share? >>> Thanks in advance, >>> Taylor >>> > > > >-- > >Twitter: @mjaskowski NOTICE: This e-mail and any attachments to it may be privileged, confidential or contain trade secret information and is intended only for the use of the individual or entity to which it is addressed. If this e-mail was sent to you in error, please notify me immediately by either reply e-mail or by phone at 408.498.6000, and do not use, disseminate, retain, print or copy the e-mail or any attachment. All messages sent to and from this e-mail address may be monitored as permitted by or necessary under applicable law and regulations.
