Als u wilt weten over de real-time verwerking van gegevens, moet u weten over Kafka. Als je meer wilt weten over Kafka, Jay Kreps is uw man. Afbeelding: Samenvloeiende
Als u in real-time gegevens en streaming toepassingen, is de kans groot Apache Kafka is een belangrijk onderdeel van uw architectuur. Onlangs, Samenvloeiende, het bedrijf is gebouwd door de makers van Kafka, aangekondigd ondersteuning voor Kafka als een managed service in de cloud.
Dat was een mooie gelegenheid om een lang gesprek met Jay Kreps, Samenvloeiende is CEO en mede-oprichter, over alles van de toekomst van de ontwikkeling van de applicatie naar de subtiele verschillen in de streaming Api ‘s en paradigma’ s.
Of u nu een streaming-liefhebber wel benieuwd wat al die drukte over is, zult u waarschijnlijk iets vinden dat van belang hier.
Be kind, rewind
Laten we het vanaf het begin. Kreps, samen met mede-oprichters Neha Narkhede en Jun Rao, begon te werken aan Kafka in 2008, terwijl zij in alle LinkedIn medewerkers. Het probleem proberen op te lossen was het omgaan met de continue stromen van gegevens.
“Zeer weinig gegevens batch in de natuur,” zegt Kreps. “Gegevens in het echte leven is niet geproduceerd wanneer de zon omhoog gaat of omlaag — als uw bedrijf digitale gegevens houdt die de hele tijd”.
Vrijwel elk bedrijf is het digitale vandaag, maar het verschil is LinkedIn de kern van digitale en zijn behoeften en schaal werden reeds een orde van grootte hoger dan die van gewone bedrijven. Dus Kreps en zijn team raken dat probleem voor anderen deed.
LinkedIn had een aantal van de infrastructuur voor transactie verwerking in de plaats, plus infrastructuur voor analytische verwerking, bestaande uit standaard componenten voor die stapels, zoals Oracle, Hadoop, en Key-value-winkels.
“We kunnen het doen verwerken in een paar milliseconden en analyse zo snel als we vandaag doen, maar de in-tussen ontbrak”, zegt Kreps.
LinkedIn had een laag berichten dat mag worden toepassingen gebouwd op de top van de infrastructuur om te communiceren, en wilde dit het centrum van de ontwikkeling van de applicatie.
Kreps en zijn team wat tijd besteed aan het proberen te bouwen op de top van zowel proprietary en open source messaging infrastructuur, maar op een gegeven moment realiseerden ze zich geen van deze opties werkte voor hen, dus ze moesten bijten de kogel en ga voor het bouwen van hun eigen systeem.
De Kafka rand
Wat was het dat gemaakt bestaande oplossingen niet geschikt voor LinkedIn doel en hoe is het Kafka-team de uitdaging aan te gaan? In andere woorden, wat maakt Kafka speciaal? Kreps, zegt ze gericht op het verbeteren van drie belangrijke gebieden.
De eerste was de bouw van Kafka als een moderne gedistribueerd systeem. “Meestal denk niet dat van uw messaging-systeem als een cluster, zie het als een broker systeem. Makelaars kunnen verbinden met elkaar en het is een beetje verdeeld.”
Maar echt gedistribueerde systemen zijn beter, makkelijker uit te breiden en werken als een service en zo. We hadden messaging en verspreid achtergronden, zo begrepen we dat het werken met dergelijke systemen,” zegt Kreps.
Een ander aspect Kreps benadrukt opslag. Messaging-systemen fungeren als coördinatoren van de informatie, maar wat gebeurt er als sommige ontvangers niet kan ontvangen hun berichten?
“Je kunt niet verwachten dat elk systeem te worden uitgevoerd op elk moment,” zegt Kreps. En als het systeem offline is, hun berichten dat nodig is om te worden gehouden in de winkel, totdat ze kan ontvangen.
“Dingen werkten niet echt goed in dergelijke situaties LinkedIn,” Kreps blijft. “Trouwens het is niet alleen een kwestie van het krijgen van terug online te laten verlopen, zijn er een aantal architectonische voordelen die komen met gegarandeerde opslag en levering”.
En dan, natuurlijk, het streaming model — de continue stroom van berichten. Kreps’ team geloofde in dit model en wilde steunen, maar ze voelde bestaande messaging systemen waren niet erg goed op ingesteld.
Kafka is afgeweken van de conventionele wijsheid in een aantal manieren, die Kreps credits geeft het een voorsprong op eerder bestaande messaging platformen. Afbeelding: De Apache Foundation
Streaming voor reguliere applicatie ontwikkeling
Die stroom is uitgegroeid tot een rivier en veel water heeft gevlogen onder de brug. Vandaag, Kafka is een groot deel van de real-time data-architecturen bekend als de Lambda-en Kappa. Hoe groot precies? Voor Kreps er zijn twee manieren om te meten: hoeveel bedrijven maken gebruik van Kafka en hoe belangrijk het voor hen is.
Kreps beweert dat “Kafka heeft bijna 100 procent van de early adopters. U kunt naar elke tech-conferentie en het kijken naar mensen is de architectuur van schema ‘ s, en je vindt Kafka er als een belangrijke component.”
Maar Kafka is verder te gaan dan dat volgens Kreps:
“We starten om te zien non-tech bedrijven tot vaststelling van Kafka en het bouwen van hun architectuur, en dat is heel spannend. Hoeveel kan de wereld bewegen in de richting van streaming-architectuur en wat is de kans dat zoiets gebeurt? Honderd procent. Het harde deel is om de bal aan het rollen, en de bal is aan het rollen. De tijdlijn is altijd langer dan je denkt hoor.
“De huidige status is dat er grote plussen, en een paar nadelen. Streaming is aangenomen meest waar is het zinvol het meest: In de financiële sector, in de IoT — waar heb je grote datastromen. Nieuwe projecten zullen worden gebouwd die manier komen we uit op een niveau van volwassenheid, eenvoud, gemak en functionaliteit, dat maakt het het omslagpunt. Zodra u kunt continu en real-time-natuur-projecten zonder grote bezwaren. We zijn nog steeds in het proces van het maken van dat gebeuren.”
Wees gerust
Voor Kreps, het is allemaal over het nemen van de streaming van het lab en maken het u zo gemakkelijk te gebruiken als, zeg, de REST van diensten. Een deel van de reden REST is zo succesvol is het feit dat er op de kaders en methodieken in de plaats die het in de reguliere ontwikkeling van de applicatie in kaart.
Kreps zegt er is nog werk om er te komen, maar “we zijn op dat traject.” En aangezien we praten over RUST, wat zou je zeggen als je gehoord Kafka is de plaats om te bouwen van uw Microservices?
Niet bepaald de eerste plaats zou je denken van waarschijnlijk. Maar voor Kreps, dit is nu precies waar ze willen Kafka te worden: “Als we kijken naar hoe Microservices worden ingezet, is er in feite sprake van twee verschillende soorten”, zegt hij. En hij maakt gebruik van de detailhandel als een voorbeeld.
In de detailhandel, is er een lijn van synchrone interactie plaatsvindt dat heeft te maken met de opdrachtgever acties-het tonen van items, items toe te voegen aan mandje, enzovoort. Maar er zijn ook acties die plaatsvinden in de achtergrond, zoals het bijwerken van de voorraad, prijzen, logistiek, etc.
Het eerste type van acties synchroon zijn, terwijl de tweede is asynchroon, en Kreps betoogt dat voor asynchrone diensten die van essentieel belang zijn (u kunt zich niet veroorloven om drop-updates of krijgen ze in de verkeerde volgorde, etc) een platform, zoals Kafka is de juiste om op te bouwen.
“We hadden Microservices dat snel actie ondernemen ter ondersteuning van Api’ s met een REST in LinkedIn, en de REST was een goede technologie te gebruiken voor deze. Kafka is niet bijzonder geschikt voor iets als dit. Maar dan heb je nog andere Microservices dat zijn asynchroon, en ze worden getriggerd door een bepaalde gebeurtenis en nemen een soort van actie. Welke technologie moet u gebruiken om te bouwen?
“Wij geloven dat de volgende generatie van dergelijke diensten moeten worden gebouwd op een bedrijf-breed platform eerder op een per-applicatie basis, en de abstractie te gebruiken moet stream processing in plaats van een laag niveau messaging API.”
Gegevens real-time in het echte leven, en het is allemaal over de plaats te
Kafka versus de wereld
Is streaming set over te nemen van de wereld dan? En als we praten over streaming, is Kafka het enige spel in de stad?
Pro-streaming argumenten klinken overtuigend, en Kreps is niet de enige die dat ondersteunt. Flink, bijvoorbeeld, is een big data-platform dat mensen die ook gepassioneerd over real-time gegevens, toepassingen en streaming, en hun standpunten en filosofie lijken te komen uit dezelfde plaats.
“Als je praat met smart technologen in deze ruimte, de antwoorden die je krijgt vandaag moet het vrij consistent,” zegt Kreps. “Misschien een paar jaar geleden zou je hoort van mensen die dingen als ‘streaming kan je de juiste antwoorden,’ ‘het is niet efficiënt,’ ‘het is lossy,’ enzovoort.
Vandaag de dag weten we dat dat niet waar is. Ja, er zijn afwegingen, maar laten we eens efficiëntie, bijvoorbeeld. Streaming 10 procent minder efficiënt zijn, maar dat betekent niet dat het inefficiënt is.”
Het is interessant dat Kreps ziet Kafka in de eerste plaats als een streaming platform voor het bouwen van diensten op, in plaats van de infrastructuur voor de verzending van de berichten. “Dat veranderde vorig jaar — we toegevoegd aanzienlijke stream processing mogelijkheden om Kafka. We hebben zin om het toevoegen van dit jaar — nu we het hebben,” Kreps opmerkingen.
Dus, streaming kan groot zijn, maar waarom specifiek voor Kafka dan? Er zijn andere streaming platforms die er zijn, zoals Flink, Spark Streaming, of Storm — alle Apache open source projecten. Hoe is Kafka ‘ s relatie met deze? Ingewikkeld, volgens Kreps.
Kafka ‘ s visie is om te dienen als een streaming-platform verbinding maken met alle platforms, en om dat te kunnen doen, moet je in staat zijn om drie dingen doen, zoals per Kreps. Je moet in staat zijn om verbinding te maken en te integreren beken en Api ‘ s en ze op te slaan, te verwerken en te transformeren en het bouwen van applicaties op de top van hen.
Kreps zegt dat er overlap bestaat alleen in het laatste punt. “We kunnen nu niet alleen de lees/schrijf-streams, maar ook doen transformaties op hen, zelfs ingewikkelde SQL verwerking, lid te worden of te aggregeren. De manier waarop we bedacht en gebouwd, het is een beetje anders dan andere platformen.”
Hoe? In Kreps’ woorden:
- Geen cluster nodig. Voor het bouwen van een stream application, je doet het gewoon zoals elke andere applicatie — geen noodzaak voor een Kafka-streams cluster. Kafka niet ingaan op de implementatie, maar delegeert naar een externe laag houdt Mesos of Kubernetes.Volledige integratie. Kafka moet worden, zoals een database, waar sprake is van een verwerking van laag-en een opslag van laag-en inschakelen van functies, zoals veiligheid, bijvoorbeeld — werken over hen.Database ondersteuning. De meerderheid van de gegevens woont in tabellen in een relationele databases en Kafka ondersteunt stream integratie met hen te kunnen hebben een holistische visie.
In typische real-time data-architecturen, Kafka is de toegangspoort voor andere streaming platforms, dus nu zie je waarom dingen worden steeds ingewikkelder. Kreps zegt dat ze graag werken met mensen met behulp van Kafka als een gateway of op zijn eigen, en ze zorgen ervoor dat de integratie met andere platformen werkt.
Het spreken van integratie, wat over de Balk ondersteuning dan? De Bundel API is een poging ondersteund door Google te verenigen met het streamen van verschillende platforms. Kreps, echter, zegt dat ze het niet zien “een ton van de vraag” voor en het is niet in hun onmiddellijke plannen tenzij Bundel voegt ondersteuning voor tabellen.
Wanneer de Kafka-team begon te werken, het opbouwen van een vennootschap niet meer aan hun hoofd, maar de mondiale overheersing. Afbeelding: Samenvloeiende.
World domination? Check
Dus, laten we samenvatten. Real-time verwerking van gegevens is op de stijging. Kafka is een belangrijke component van de real-time data-architecturen. En nu is het uitbreiden van het bereik om te doen wat andere onderdelen van deze architectuur aan het doen zijn, en wil om zich te vestigen als een mainstream platform ontwikkelingssamenwerking. En het gaat de cloud en het nemen van op Amazon.
Klinkt dat als een plan voor wereldheerschappij voor u?
Kreps zegt dat ze een grote visie voor de Kafka-het centrale zenuwstelsel voor bedrijven. “Toen we begonnen, waren we niet na te denken over het bouwen van een bedrijf of Ipo’ s en dergelijke, maar de mondiale overheersing in onze lijst.”
Waren Kreps en zijn team de juiste mensen op de juiste plaats op het juiste moment? Alle andere organisaties van LinkedIn orde van grootte waren vergelijkbare problemen en het gebruik van soortgelijke systemen intern op dezelfde tijd, dus waarom zou ze? Misschien is het een combinatie van framing, de strategie en de visie.
“Dit probleem niet erg sexy uit de buitenwereld op dat moment,” Kreps herinnert. “Databases waren cool, Hadoop was cool, maar het verplaatsen van gegevens en berichten was erg cool. Mensen vroegen waarom werken we op dat spul en niet iets anders te doen.
“Andere organisaties waren op zoek naar het als het oplossen van problemen, zoals hoe te aggregeren log bestanden of het beheren van messaging systemen. Dus ze zou eindigen met de relatief low-end oplossingen, zelfs als hun schaal was vergelijkbaar.” Plus, ze gaan niet open source. Dus, wat nu?
“Toen we begonnen met het bedrijf, er was een enorme vraag naar een software aanbieden”, zegt Kreps. “We begonnen met die, die is toegestaan voor de bouw van veel van de gereedschappen mensen nodig om te beginnen met Kafka en om functies toe te voegen aan acceptatie.
We zijn nu met een SaaS-oplossing, die hebben we ook intern voor een tijdje, dus we zijn erg enthousiast om deze beschikbaar te maken voor de wereld. Het is een betere manier voor ons om onze service, mensen die Kafka in de cloud voor licenties en ondersteuning en hun werking wordt door ons beheerd.
De respons was overweldigend, en het is een essentiële stap voor elk bedrijf, als je niet in staat op te maken dat de overgang, je kan niet bestaan in 10 jaar vanaf nu. Plus, kunnen we niet kieskeurig zijn over ons aanbod — het is moeilijker als een startup, maar we willen gewoon om dingen aan de manier waarop mensen willen om ze te gebruiken.”
Wie echt de eigenaar van uw Internet der Dingen gegevens?
In een wereld waar meer en meer objecten komen online en leveranciers zijn betrokken te raken in de supply chain, hoe kan je houden van wat van jou is en wat niet?