Tjep køkultur med Apache Kafka

27. januar 2017 kl. 06:164
Apache Kafka er den nye yndling i big data-verdenen. Det er en enterprise-kø, som kan skalere systemer i den helt store stil og med masser af fart på. Det giver god mening for dansk startup.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Apache Kafka er navnet på en kø-server, som har stor opmærksomhed for tiden. Enhver it-konference med respekt for sig selv har kø-systemet på programmet og udviklerblogs flyder over med indlæg om systemet.

Det problem, som Kafka løser er, når en stor mængde delsystemer skal kommunikere med hinanden. I stedet for at de enkelte delsystemer smider meddelelser rundt med løs hånd, fungerer Kafka som et slags transportbånd, der opfanger og videresender meddelelser rundt fra og til systemets komponenter.

Kafka opdeler meddelelserne i 'topics', som køens abonnenter skriver sig op til at modtage.

Man kan hælde hundredvis af terabyte data i røret og foretage millionvis af forespørgsler per sekund.

Artiklen fortsætter efter annoncen

Apache Kafka er udviklet af det sociale netværk LinkedIn, men blev i 2011 sat i verden som open source i Apache-organisationens regi.

Systemet er populært i enterprise-verdenen, men giver også god mening for små startups.

Godt til mikrotjenester

Bjarne Ørum Fruergaard er nyslået it-chef i firmaet Relink, som benytter maskinlæring til at finde match mellem jobsøgere og stillingsopslag.

Relink benytter mikrotjenester som arkitektur, hvor delene i systemets logik er splittet i mindre komponenter, som hvert har et isoleret ansvar, eller 'seperation of concerns' som det kaldes i engelsk it-lingo.

Artiklen fortsætter efter annoncen

I den sammenhæng hjælper Kafka med kommunikationen mellem tjenesterne. Producenter skriver til topics i Kafka og andre komponenter i stakken læser så fra samme topics.

»I bund og grund sælger vi API’er. Vi kan logge når kunderne bruger vores API. Én tjeneste kan kigge på topics i Kafka, skrive i en log og gemme oplysninger i et datawarehouse. En anden tjeneste kan så tage sig af at svare på forespørgslen fra kunden via API’et,« fortæller Bjarne Ørum Fruergaard.

Det betyder komponenters arbejdsområder kan adskilles og afkobles, uden at have direkte kommunikation mellem komponenterne.

Baggrunden for Relinks valg af Kafka er blandt andet, at produktet er open source samt at der er en stor skare af virksomheder, som benytter produktet og bidrager til at gøre det bedre.

Det er også vigtigt at kunne kigge i kildekoden, hvis tingene ikke fungerer som de skal. Licensomkostninger har også betydning, når man arbejder i en startup, siger Bjarne Ørum Fruergaard.

Der er mange andre kø-systemer end Kafka, både kommercielle og open source, men én af de ting som Relink sætter pris på, er dets evne til at håndtere 'backpressure.'

»Hvis vi har ting, der fejler eller belastning, som vi har svært at følge med, så bliver det pænt håndteret i Kafka.«

Det er blandt andet systemet evne til at garantere at en meddelelse modtages præcist én gang, der er en fordel i Relinks systemer. Firmaet benytter Apache Spark, som er et produkt til distribueret processering, der understøtter maskinlæring i stor skala.

Artiklen fortsætter efter annoncen

Den indbyggede integration mellem Spark og Kafka, hvor en strøm af data kan sendes fra det ene system til det andet, er en stor fordel.

Hurtigere end Hadoop

Kasper Sørensen arbejder for Satori Software, som skaber systemer til datavask i den store stil. Det handler om at rette navne og adresser på automatisk vis. Her er Kafka er centralt i firmaets sky-arkitektur. Det er kø-systemets gode ydelse og evne til at skalere, som gør det attraktivt for firmaet.

»I enterprise-udvikling har du komponenter, der skal reagere på beskeder om hændelser fra forskellige kilder, men de skal samtidig kunne planlægge deres arbejde og først reagere når der er ressourcer tilgængeligt til at behandle beskeden.«

Kasper Sørensen er også med-styrmand på et andet Apache-projekt, Metamodel, og har derfor lagt mærke til Kafkas stigende popularitet.

»Det er helt tydeligt at Kafka har stor opmærksomhed, ligesom f.eks. Hadoop tidligere har haft. Hadoop er skalerbart, men ikke nødvendigvis hurtigt. Der er meget snak om big data, som Hadoop adresserede, og Kafka adresserer ‘fast data’, som er det nødvendige modsvar. «

4 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Fortsæt din læsning

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
4
22. februar 2017 kl. 16:56

ActiveMQ er en traditionel kø, hvorimod Kafka er bedre beskrevet som en distribueret log. I Kafka er beskederne i loggen gemt og tilgængelige lige så længe du ønsker det, hvorimod en kø typisk fjerner beskeden når den er læst. Kafka har derfor i praksis (for consumerne) en interessant kombination af både broadcast, kø og load-balancer.

3
30. januar 2017 kl. 08:33
  • som jo må siges, på beskrivelsen, at være "det samme" - er der nogen der kan nævne noget fundamentalt eller væsentligt?
2
28. januar 2017 kl. 22:49

...og ikke køer. Du kan fx tilføje en ny konsument til allerede behandlede beskeder, hvilket normalt ikke kan lade sig gøre i et kø-system, der kun gemmer beskederne indtil de er læst.

Kafka's operationelle styrke ligger i, at producent-siden er afkoblet fra konsument-siden, da kafka persisterer beskederne. Derfor giver kafka netop ikke backpressure. Producenten kan bare producere løs - uanset om konsument(en/erne) er klar til at læse eller er faldet bagud, hvis de(n) fx er ved at blive opdateret eller bare ikke kan følge med. Det er altså intet pres tilbage fra konsument-siden til producenten om, at den skal producere langsommere - dvs. ingen backpressure.

Det er dejligt at se, at flere får øjnene op for streaming arkitektur og eventlogs, som kan være første skridt på vejen til event sourcing nirvana. :-)

1
27. januar 2017 kl. 11:19

.... i morgen til et surprise party her i San Francisco. Hvad skal jeg spørge hende om?

Jeg får hende til Danmark i april. Så må vi arrangere nogle foredrag mv.

Mvh. Mogens.