 Okay, so we're starting in a minute. So the next talk is is Nakadi even broker by Lionel Montreux. Yes, exactly. So fun. Thank you. Okay, so I Guess I can start right? So my name is Lionel. That was fantastically well pronounced And I'm an engineer at Zalando I'm sure you've all heard of Zalando before And I'm very lucky that I get to do open source software and get paid for it So that's really great. And I work on something that's called Nakadi even broker Nakadi is a Georgian word that means trim. So now that makes a bit more sense For you and what is it? It's a restful API on top of Kafka like cues will come to that So Nakadi is entirely open source. You can get it on github and run the exact same version we're running Internally, but we have our own deployment, of course for Zalando we've got about I don't know 150 200 teams of engineers and We have an architecture with services microservices and rest APIs and JSON format So they use Nakadi in order to exchange messages between between services It works quite well. They seem to be quite happy what we do. So that's quite nice and But that's not all we also use it to archive all the data that should be archived into our own data lake and then it can be used by researchers and data scientists and bi people and everything This is our new logo and it's actually so new. There's not even on the website yet so you get to see it for the first time and Let's go back to let's see. What is it? So that's Nakadi. It's a restful API on top Of Kafka like you so restful API. I think that's okay for everyone But can I ask you to stand up if you use or have used Kafka? like Maybe one-tenth of you if that okay, that's great. And who's heard of Nakadi? Yeah, that guy was with me So that we're going to change that because now you all have heard of Nakadi, right? So Kafka like Q's they're a bit different than the Q's in like something like rabbit and Q or something So since not that many of you have used it. Let's spend a few minutes to Do a quick recap, right? So In Kafka and in Nakadi you can write to an append only log, right? And you have producers who write and you have consumers who consume so they read What's on the log and here you've got one producer There could be several ones and he's writing like messages zero one two three four five and Consumers they can say well I want to start consuming here And I'll just sequentially consume everything and I'll wait when I get catch up to with the producer for And to write something and then I'll read it etc So the difference is that You can have several groups of consumers and they can all consume the same amount the all the data That it's not distributed to all of them So what do you do in Kafka when you want to have more throughput? Because you want to write a lot of messages. We get a lot of messages Well, you can create partitions and Kafka guarantees older only within the partitions So the producer gets to write to either partitioning is to choose probably Okay, what chooses for him and the consumers they can read from both partitions and they can write twice as much That's really nice So Kafka is actually a distributed Streaming platform so every partition in Kafka is replicated on a number of brokers on In your Kafka cluster For us at three, but I think you can configure it to something different and That that's how you get a distributed very highly available system because any broker can go down It comes back up There's no problem and even while it's down Things keep working. So that's really great What does it have to do with Nakadi well, this is the very high level architecture of Nakadi We've got Nakadi sitting between the producers and consumers in our case everyone is a random But maybe you and Kafka on the other side and what Nakadi does is quite a bit more than just being some sort of HTTP proxy for Kafka although it is an HTTP proxy for Kafka It's got a bunch of other features So in Kafka you create a topic as we saw earlier and that's your append only log that has a number of partitions The equivalent in Nakadi is called an event type, but essentially it's pretty much the same and with your event type You create it in Nakadi and it appears in Kafka. Okay, it's all fine And Nakadi has this nice feature you can say well This is the schema in JSON schema that every single event that is published To this event type is guaranteed to To confold to yeah And you can also do schema evolution. So there are rules to evolve your schema in only a forward or only a backward compatible way So that all your consumers will you don't necessarily know have a number of guarantees with regards to their ability to read your messages even when your Schema has evolved. So these are three features of Nakadi. You've got HTTP proxy. You've got schema registry. You've got schema evolution that Forward compatible backward compatible not compatible at all if you want. It's a bit more risky Got other things too. You can say Well, I don't want everyone to read or write to this event type And I don't want someone to go and change my schema and then break everything So you can set per event type authorization rules that define who gets to administer the schema the event type Sorry, so change the schema recent time bunch of things Who gets to write to the event type and you gets to read from the event type? Which is very useful when you have sensitive data to Put in there You can also set an archival that gets to read everything by the way. This is new So that's That's for the high level view of Nakadi and it's got a bunch of other features But there is one I really want to talk about because I think that's what makes nakadi different from The competition which would be something like maybe confluent platform or kinesis on aws What we've got is called timelines new logo um And timelines is really cool because we have that problem With uh operating our big kafka cluster. We handle several terabytes of data a day Is that sometimes you want to move data from one broker to another or from one cluster to another And that requires copying a lot of data between brokers And when we do that We have a big problem We use more bandwidth We use more we have more IO Usage Which means that everything slows down for everyone else And if I can take an example Last year end of last year we had to Rebalance a cluster Because we wanted to add Three new brokers to the cluster The rebalance operation took an entire week Of copying data around and for an entire week we had people complain Why is nakadi slow? Because we're rebalancing when is he going to finish? We don't know but it's probably going to be a week. It was a week. So they weren't happy And we thought well, what can we do because sometimes we really do need to move data around There's no way around that But can we do it without actually copying the data and can we do it in a way that will not Interrupt service either for consumers or for producers So we want to be able to move essentially an event type From one place to another Without no one noticing and without slowdown and that's what we do with timelines. So Let's imagine that we have an event type That is represented by a topic in our cluster a and we want to move it to our cluster b Right, so we've got one producer Right here. He's connected to nakadi and nakadi on his behalf writes the messages To the a pandemic log in kafka and we've got two consumers. So these can't be disconnected They have to be able to keep writing and reading And the data that is in topic one mustn't be moved To the cluster b because otherwise everything will slow down Well, we decide to create a timeline We consider that topic one is the first timeline We say well for this event type i'm creating a new timeline There you go We create a topic a different topic in the other cluster And of course nakadi keeps track of the end of the first timeline which was offset five and then immediately The producer is connected to the other topic and he's publishing to the new topic And the consumers they are still catching up. So they're behind with the the old topic Eventually some consumers will be reading from the new topic others will be reading still from the old one That's fine. At some point everyone will have called up It's okay and because these These topics they have a retention time that is set we set it to four days But you can set it to of course however long you want Eventually the data in the first topic in the first timeline will disappear. It's gone So at that point you can just delete the old topic and everyone is writing to you and reading from Your new topic a new timeline using this You can move The data Well, you don't move the data, but you move your Event type from one cluster to another. So we've done that. That's fine The producers haven't noticed because they kept writing all the time. No problem So that's fine The consumers are happy too because they kept consuming just a little bit of slowdown at some point for some blocking and synchronization, but that's it and Data hasn't moved. So Nakadi hasn't been slow The first time we used this feature We needed for a specific event A much bigger Kafka cluster than the one we had we needed it to be three four times bigger We could have added more brokers to our cluster Don't know one week rebalance Have everyone complained for a week and then at the end of the event Done the same thing rebalance everything back to only a few of the brokers another week of complaining and And remove the the brokers I say complaining, but they're right to complain. Well, if it's slow, it's slow. It's a problem So what we did is we created a new cluster that was bigger We create timelines for every single event type that we had we have over 2000 and Everyone immediately started using the the second cluster And then what did we do waited? We left the old one still there because we knew we had to go back to it after the event again timelines for everyone back to the old cluster and when the The big one was empty the event was passed. We could just get rid of it very easily So that's our first use of timelines or second use of timelines We're working on this right now. So future that's coming up Well, you can use timelines to repartition the topic if you want more throughput as I said in the beginning You want more partitions? Let's get a bunch of problems But essentially you could use timelines create a new topic that has more partitions And because we have a very nice Consumption API You will actually the consumers will also get the data from all the new partitions that didn't even know existed Immediately and we benefit from all the locking and synchronization. We have already implemented in timelines. So that's really nice another thing we can do with timelines is well, actually Who says we need to have only Kafka any pop sub? Model that works in the same way could work potentially And by the way, who said we need to have a single cluster We can have several ones and configure them differently depending on our users requirements and we can move The event types from one cluster to another depending on changing Requirements from user which happens actually quite a lot So that's it for timelines Nakadi you can find it online. The first link is nakadi itself. It's written in java. So spring boot application. There's All you need to get started with docker images and Only one second link is an ecosystem. We try to create around nakadi. There's a bunch of client libraries There's some for scala seven ones for java There's a python one and I think there's a go one that's coming up at some point We have a web ui which isn't open source yet, but we're working on it So you can like see things. It's really really nice And we're waiting for your contributions Thank you So we have time for one or two questions. So if anyone has a question Any features that we lose by using nakadi and not kafka directly? Yes, so one thing we're working on at the moment is log compaction in kafka Unfortunately doesn't play well with timelines because You have to somehow refeed the data from the old Topic to the new one. So we're working on a solution for that But at the moment you wouldn't be able to to use it. This is one example Yes We don't have immediate plans to do it, but it's a possibility That could work Sorry Oh, yeah, are we are we going to support kinesis as a as a backend? So you mean like Yeah, yeah, we thought about it actually someone implemented some proof of concepts as possible, but it's not production ready yet Do you want to contribute? Okay, okay. Thank you. There's one more other one more. Okay It's stateless Yeah, it's stateless We use it in uh, we run it on ews and we use auto scanning groups and it just changes all the time Okay, okay. I guess time is up. All right. Thank you