Kafka: historien så langt

0
180
learn-kafka.jpg

Hvis du vil vide mere om real-time databehandling, du bør vide om Kafka. Hvis du ønsker at vide om Kafka, Jay Kreps er din mand. Billede: Sammenflydende

Hvis du er til real-time data og streaming applikationer, chancerne er, Apache Kafka er en vigtig del af din arkitektur. For nylig, Sammenflydende, virksomheden er bygget af skaberne af Kafka, meddelte støtte til Kafka som en service i skyen.

Det var en fantastisk mulighed for at få en lang snak med Jay Kreps, Sammenflydende ‘s CEO og co-founder, om alt fra fremtiden med udviklingen af applikationer til de subtile forskelle i streaming Api’ er og paradigmer.

Uanset om du er en streaming-entusiast, eller undrer dig over, hvad al den ståhej er om, du vil højst sandsynligt finde noget af interesse her.

Be kind, rewind

Lad os tage det fra starten af. Kreps, sammen med co-stiftere Neha Narkhede og Jun Rao, begyndte at arbejde på Kafka i 2008, mens de var alle LinkedIn medarbejdere. Det problem, de forsøger at løse, var der beskæftiger sig med kontinuerlig strøm af data.

“Meget lidt data, der er parti i naturen,” siger Kreps. “Data i det virkelige liv er ikke produceret, når solen går op eller ned, når din virksomhed er digitale data, der holder kommer hele tiden”.

Stort set alle virksomheder er digitale i dag, men forskellen er LinkedIn ‘ s kerne er digitale og dets behov, og skalaen var der allerede er en størrelsesorden over, at almindelige virksomheder, dengang. Så Kreps og hans team ramt af det problem, før andre gjorde.

LinkedIn havde nogle infrastruktur til transaktions-behandling i stedet, plus infrastruktur for analytical processing, bestående af standard-komponenter for dem, stakke, såsom Oracle, Hadoop, og Nøgle-værdi-butikker.

“Vi kan gøre behandling i et par millisekunder og analyse så hurtigt, som vi gør i dag, men i mellem manglede,” siger Kreps.

LinkedIn havde en messaging-lag, der må applikationer bygget på toppen af denne infrastruktur til at kommunikere, og det ønskede, at gøre dette til center for program udvikling.

Kreps og hans hold har brugt en del tid på at forsøge at bygge videre på toppen af både proprietære og open source-messaging-infrastruktur, men på et tidspunkt, de indså, at ingen af disse valgmuligheder arbejdet for dem, så de var nødt til at bide i det sure æble og gå til at bygge deres eget system.

Kafka kant

Hvad var det, der gjorde eksisterende løsninger, der er uegnede til LinkedIn formål, og hvordan gjorde Kafka team til at tackle den udfordring? Med andre ord, hvad der gør Kafka speciel? Kreps siger, at de fokuserer på at forbedre tre centrale områder.

Den første var at bygge Kafka som en moderne, distribueret system. “Du typisk ikke tænke på din messaging system som en klynge, du tænker på det som en mægler system. Mæglere kan oprette forbindelse til hinanden, og det er lidt fordelt.”

Men virkelig distribuerede systemer er bedre, og lettere at udvide og fungere som en service, og så videre. Vi havde messaging og distribueres baggrunde, så vi forstod at betjene disse systemer,” siger Kreps.

Et andet aspekt Kreps understreger, er opbevaring. Messaging-systemer fungerer som afsendte oplysninger, men hvad sker der, hvis nogle modtagere, der ikke kan få deres budskaber?

“Du kan ikke forvente hver systemet til at køre hvert øjeblik,” siger Kreps. Og når systemer er offline, deres beskeder, der kræves for at blive holdt i butikken, indtil de kan modtage dem.

“Tingene ikke fungerer virkelig godt i sådanne situationer, LinkedIn,” Kreps fortsætter. “Udover det er ikke bare et spørgsmål om at komme tilbage online glat, er der en række arkitektoniske fordele, der kommer med garanteret opbevaring og levering”.

Og så, selvfølgelig, en streaming-modellen-den kontinuerlige strøm af beskeder. Kreps’ team menes i denne model, og ønskede at støtte det, men de følte, at de eksisterende messaging-systemer ikke var meget godt sat op til det.

kafkalogo.png

Kafka bort fra konventionel visdom på en række måder, som Kreps credits, som giver det den fordel frem for tidligere eksisterende messaging-platforme. Billede: Apache Foundation

Streaming for mainstream applikationsudvikling

At stream er vokset til en flod og en masse vand har fløjet under broen siden da. I dag, Kafka er en stor del af real-time data arkitekturer kendt som Lambda og Kappa. Hvor stor præcist? For Kreps, at der er to forskellige måder at måle dette: Hvordan mange virksomheder bruger Kafka, og hvor centralt det er for dem.

Kreps hævder, at “Kafka har tæt på 100 procent af early adopters. Du kan gå til alle tech-konferencen og ser på folk, arkitektur diagrammer, og du vil finde ud af, Kafka, der som et centralt element.”

Men Kafka bevæger sig ud over det, der ifølge Kreps:

“Vi er begyndt at se ikke-tech virksomheder vedtage Kafka og opbygge deres arkitektur omkring det, og det er meget spændende. Hvor meget kan verden bevæger sig mod streaming arkitektur og hvad er chancen for at det sker? Et hundrede procent. Den hårde del er at få bolden, og bolden er begyndt at rulle. Tidslinjen er altid længere tid, end du tror selv.

“Den aktuelle status er, at der er store plusser og et par ulemper. Streaming er vedtaget de fleste, hvor det giver mest mening: I den finansielle sektor, i IoT — hvor du har store strømme af data. Nye projekter kommer til at blive bygget på den måde, når vi nå et niveau af modenhed, enkelhed, bekvemmelighed og brugervenlighed, der gør det tipping point. Når du kan have løbende og i real-tid, natur-projekter uden store kompromiser. Vi er stadig i færd med at gøre det til at ske.”

Forvisset om,

For Kreps, det handler om at tage streaming fra laboratoriet, og gør det så let at bruge som, siger, RESTEN tjenester. En del af årsagen til, RESTEN er så vellykket, er det faktum, at der er de rammer og metoder, der har sat det i mainstream applikationsudvikling kort.

Kreps siger, at der er stadig arbejde at komme dertil, men “vi er på denne bane.” Og da vi taler om RESTEN, hvad ville du sige, hvis du hørt Kafka er plads til at bygge din Microservices?

Ikke ligefrem det første sted, du ville tænke på, sandsynligvis. Men for Kreps, er dette præcis, hvor de vil Kafka til at være: “Hvis vi ser på, hvordan Microservices er indsat, er der faktisk to forskellige typer,” siger han. Og han bruger detail som et eksempel.

I detailhandelen, der er en linje af synkron interaktion, der finder sted, der har at gøre med kundens handlinger — viser elementer, tilføje varer til kurven, og så videre. Men der er også handlinger, der finder sted i baggrunden, såsom opdatering af lagerbeholdning, priser, logistik, etc.

Den første type af tiltag er synkrone, mens den anden er asynkron, og Kreps hævder, at for asynkron tjenester, der er kritiske (du kan ikke råd til at slippe opdateringer eller få dem i den forkerte rækkefølge, osv.) en platform som Kafka er den rigtige til at bygge videre på.

“Vi havde Microservices at træffe hurtige foranstaltninger til støtte for Api’ er ved hjælp HVILE i LinkedIn, og RESTEN var en god teknologi til brug for dem. Kafka er ikke særlig velegnet for noget som dette. Men så har du andre Microservices, der er asynkron, og de er udløst af en hændelse og tage nogle form for handling. Hvad slags teknologi, bør du bruge til at bygge dem?

“Vi mener, at den næste generation af sådanne tjenester bør være bygget på et selskab, bred platform i stedet på et pr-redskab, og indvindingen til brug, bør stream processing snarere end en lav-niveau messaging API.”

broadcasting.jpg

Data er real time i det virkelige liv, og det er alle over sted for

Kafka vs verden

Er streaming indstillet til at overtage verden så? Og når vi taler om streaming, er Kafka det eneste spil i byen?

Pro-streaming argumenter lyde overbevisende, og Kreps er ikke den eneste, der støtter dem. Flink, for eksempel, er en stor data platform, der er mennesker, der også brænder for real-time data, applikationer og streaming, og deres synspunkter og filosofi synes at være, der kommer fra det samme sted.

“Hvis du taler til smart teknologer i dette rum, de svar, du vil få i dag bør være temmelig konsekvent,” siger Kreps. “Måske om et par år siden ville jeg høre fra personer, ting som ‘streaming, kan ikke få dig rigtige svar,’ ‘det er ikke effektiv,’ ‘det er uskarp,’ og så videre.

Vi ved nu, at er ikke sandt. Ja, der er kompromiser, men lad os tage effektivitet, for eksempel. Streaming kan være 10 procent mindre effektivt, men det betyder ikke gøre det ineffektivt.”

Det er interessant, at Kreps ser Kafka primært som en streaming-platform til at opbygge en service frem for infrastruktur til afsendelse af beskeder. “Det ændrede sig sidste år-vi tilføjet væsentlige stream processing kapaciteter til Kafka. Vi har været mening at tilføje dette i årevis-nu har vi det,” Kreps noter.

Så, streaming kan være stor, men hvorfor gå specifikt til Kafka så? Der er andre streaming-platforme derude også, ligesom Flink, Spark Streaming, eller Storm — alle Apache open source-projekter. Hvordan er kafkas forhold til disse? Kompliceret, efter at Kreps.

Kafka ‘ s vision er at fungere som en streaming platform til at forbinde alle platforme, og for at gøre det, du har brug for at være i stand til at gøre tre ting, som per Kreps. Du er nødt til at være i stand til at oprette forbindelse til og integrere vandløb og Api ‘ er og gemme dem, til at behandle dem, og forvandle dem og bygge applikationer på toppen af dem.

Kreps siger, der overlapper hinanden, eksisterer kun i det sidste punkt. “Vi kan nu ikke blot læse/skrive vandløb, men også gøre transformationer på dem, selv komplicerede SQL behandling, forening eller samle dem. Den måde vi havde forestillet mig, og det er bygget lidt anderledes end andre platforme.”

Hvordan? I Kreps’ ord:

    Ingen klynge, der kræves. At opbygge en strøm program, skal du bare gøre det som enhver anden ansøgning — der er ingen grund til Kafka vandløb klynge. Kafka ikke rører ved indsættelsen, men uddelegerer den til et ydre lag kan lide Mesos eller Kubernetes.Fuld integration. Kafka skal være som en database, hvor der er en behandling lag og et lager lag, og dreje på funktioner-som sikkerhed, for eksempel-arbejder på tværs af dem.Database support. De fleste af data liv i tabeller i relationelle databaser, og Kafka understøtter stream integration med dem for at være i stand til at have et holistisk syn.

I typiske real-time data arkitekturer, Kafka er indgang til andre streaming-platforme, så nu kan du se, hvorfor tingene bliver kompliceret. Kreps siger, at de er glade for at arbejde med mennesker, der bruger Kafka enten som en gateway eller på egen hånd, og de sørger for integration med andre platforme virker.

Taler om integration, hvad Stråle støtte så? Strålen API er en indsats bakket op af Google til at forene streaming på tværs af platforme. Kreps, men siger at de ikke kan se “et ton af efterspørgsel” efter det, og det er ikke i deres umiddelbare planer medmindre Stråle tilføjer understøttelse af tabeller.

copy-of-2016429groupfounders56.jpg

Når Kafka holdet er begyndt at arbejde på, at opbygge en virksomhed ikke var på deres sind, men verdensherredømme var. Billede: Sammenflydende.

World domination? Check

Så, lad os opsummere. Real-time databehandling er på fremmarch. Kafka er en central komponent af real-time data-arkitekturer. Og nu er det med at udvide sin rækkevidde til at gøre, hvad andre dele af denne arkitektur er at gøre, og at det ønsker at etablere sig selv som en mainstream platform. Og det vil sky og tager på Amazon.

Lyder det som en plan for at dominere verden for dig?

Kreps siger, at de har en stor vision for Kafka — at være det centrale nervesystem for virksomheder. “Da vi begyndte at arbejde på det, var vi ikke tænker på at opbygge en virksomhed eller Børsintroduktioner og lignende, men verdensherredømme var på vores liste.”

Var Kreps og hans team de rigtige mennesker på det rigtige sted på det rigtige tidspunkt? Alle andre organisationer i LinkedIn ‘ s størrelse blev der står over for tilsvarende udfordringer og ved hjælp af lignende systemer internt på samme tid, så hvorfor dem? Måske er det en kombination af framing, strategi og vision.

“Dette problem ikke se meget sexet udefra på det tidspunkt,” Kreps minder. “Databaser var cool, Hadoop var cool, men flytning af data og beskeder var meget besværligt. Folk blev spurgt, hvorfor vi arbejder på, at ting og ikke gøre noget andet.

“Andre organisationer, der var at se på det som at løse problemer, såsom hvordan man samlet log-filer eller hvordan man skal håndtere messaging systemer. Så ville de ende med at bruge relativt low-end løsninger, selv hvis deres skala var den samme.” Plus, de ikke gå open source. Så hvad nu?

“Da vi startede virksomheden, der blev en stor efterspørgsel efter en software tilbyder,” siger Kreps. “Vi begyndte med, og som gav os lov til at bygge mange af de værktøjer, folk havde brug for at begynde at bruge Kafka og til at tilføje funktioner til at drive vedtagelse.

Vi følger nu op med en SaaS-tilbud, som vi har brugt internt i et stykke tid, så vi er virkelig glade for at gøre det til rådighed for verden. Det er en bedre måde for os at tilbyde vores service, folk kører Kafka i cloud få licenser og support, og deres drift er styret af os.

Responsen har været overvældende, og det er et vigtigt skridt for enhver virksomhed-hvis du ikke er i stand til at gøre denne overgang, du kan ikke findes i 10 år fra nu. Plus, vi kan ikke være kræsne om vores tilbud — det er sværere, da en start, men vi ønsker, at tilbyde ting den måde, folk ønsker at bruge dem.”

Who really owns your Internet of Things data?

Hvem der egentlig ejer din Internet af Ting, data?

I en verden, hvor flere og flere objekter kommer online og leverandører er ved at blive involveret i forsyningskæden, hvordan kan du holde styr på, hvad der er dit og hvad er ikke?