I disse dager er massivt skalerbar pub / sub-melding praktisk talt synonymt med Apache Kafka. Apache Kafka fortsetter å være det bunnsolide, åpne kildekoden, valgfrihet for distribuerte streamingapplikasjoner, enten du legger til noe som Apache Storm eller Apache Spark for behandling eller bruker behandlingsverktøyene som tilbys av Apache Kafka selv. Men Kafka er ikke det eneste spillet i byen.
Utviklet av Yahoo og nå et Apache Software Foundation-prosjekt, går Apache Pulsar for kronen på meldinger som Apache Kafka har hatt i mange år. Apache Pulsar tilbyr potensialet for raskere gjennomstrømning og lavere ventetid enn Apache Kafka i mange situasjoner, sammen med et kompatibelt API som gjør det mulig for utviklere å bytte fra Kafka til Pulsar med relativt letthet.
Hvordan skal man velge mellom den ærverdige dyktige Apache Kafka og den oppstartede Apache Pulsar? La oss se på de viktigste tilbudene for åpen kildekode og hva kjernevedarbeidernes virksomhetsutgaver bringer til bordet.
Apache Kafka
Apache Kafka ble utviklet av LinkedIn og utgitt som åpen kildekode tilbake i 2011, og har spredt seg vidt og bredt, og blitt stort sett standardvalget for mange når man tenker på å legge til en servicebuss eller pub / undersystem i en arkitektur. Siden Apache Kafkas debut har Kafka-økosystemet vokst betraktelig, og lagt til Scheme Registry for å håndheve skjemaer i Apache Kafka-meldinger, Kafka Connect for enkel streaming fra andre datakilder som databaser til Kafka, Kafka Streams for distribuert strømbehandling, og sist KSQL for å utføre SQL-lignende spørsmål om Kafka-emner. (Et emne i Kafka er navnet på en bestemt kanal.)
Standard brukstilfelle for mange rørledninger i sanntid bygget de siste årene har vært å skyve data inn i Apache Kafka og deretter bruke en strømprosessor som Apache Storm eller Apache Spark til å hente inn data, utføre og behandle, og deretter publisere output til et annet emne for nedstrøms forbruk. Med Kafka Streams og KSQL kan alle dine datarørledningsbehov håndteres uten å måtte forlate Apache Kafka-prosjektet når som helst, men selvfølgelig kan du fortsatt bruke en ekstern tjeneste for å behandle dataene dine om nødvendig.
Mens Apache Kafka alltid har vært veldig vennlig fra en utviklers synspunkt, har det vært noe av en blandet pose operativt. Det er relativt enkelt å få en liten klynge i gang, men det er ofte problemer med å opprettholde en stor klynge (f.eks. Bytte av lederpartisjon etter en Kafka-meglerfeil).
Videre har tilnærmingen tatt for å støtte flerleieforhold, via et verktøy kalt MirrorMaker, vært en sikker måte å få SRE til å trekke ut håret. Faktisk betraktes MirrorMaker som et slikt problem at selskaper som Uber har laget sitt eget system for replikering på tvers av datasentre (uReplicator). Confluent inkluderer Confluent Replicator som en del av selskapets tilbud av Apache Kafka. Når vi snakker som noen som har måttet opprettholde et MirrorMaker-oppsett, er det synd at Replicator ikke er en del av åpen kildekodeversjon.
Imidlertid er det definitivt ikke alle dårlige nyheter på operativ front. Mye arbeid er gjort i den nåværende Apache Kafka 1.x-serien for å redusere noe av hodepinen ved å drive en klynge. Nylig har det skjedd noen endringer som gjør at systemet kan kjøre store klynger med mer enn 200 000 partisjoner på en mer strømlinjeformet måte, og forbedringer som å legge til "dead letter" -køer til Kafka Connect gjør det mulig å identifisere og gjenopprette problemer i datakilder og synker så mye lettere. Vi ser sannsynligvis også støtte på produksjonsnivå for å kjøre Apache Kafka på Kubernetes i 2019 (via Helm-diagrammer og en Kubernetes-operatør).
Tilbake i 2014 dannet tre av de opprinnelige utviklerne av Kafka (Jun Rao, Jay Kreps og Neha Narkhede) Confluent, som gir ytterligere virksomhetsfunksjoner i Confluent Platform, slik som den ovennevnte Replicator, Control Center, ekstra sikkerhetstillegg, og det vanlige tilbudet om støtte og profesjonelle tjenester. Confluent har også et skytilbud, Confluent Cloud, som er en fullstendig administrert Confluent Platform-tjeneste som kjører på Amazon Web Services eller Google Cloud Platform, hvis du foretrekker å ikke håndtere noen av de operasjonelle omkostningene ved å kjøre klynger selv.
Hvis du er låst inn i AWS og bruker Amazon-tjenester, må du merke deg at Amazon har introdusert en offentlig forhåndsvisning av Amazon Managed Streaming for Kafka (MSK), som er en fullstendig administrert Kafka-tjeneste innen AWS-økosystemet. (Merk også at Amazon MSK er ikke levert i partnerskap med Confluent, så å kjøre MSK gir deg ikke alle funksjonene til Confluent Platform, men bare det som er gitt i åpen kildekode Apache Kafka.)
Apache Pulsar
Gitt Apache Software Foundation's forkjærlighet for å plukke opp prosjekter som ser ut til å duplisere funksjonalitet (vil du ha Apache Apex, Apache Flink, Apache Heron, Apache Samza, Apache Spark eller Apache Storm for dine regisserte acykliske grafbehandlingsbehov?), Ville du bli tilgitt for å se rett forbi kunngjøringene om at Apache Pulsar blir et topp-Apache-prosjekt før du velger Apache Kafka som et pålitelig alternativ for dine meldingsbehov. Men Apache Pulsar fortjener en titt.
Apache Pulsar ble født på Yahoo, hvor den ble opprettet for å imøtekomme organisasjonens behov som andre open source-tilbud ikke kunne gi den gangen. Som et resultat ble Pulsar bygget fra grunnen av for å håndtere millioner av emner og partisjoner med full støtte for georeplikering og flerleietag.
Under dekslene bruker Apache Pulsar Apache BookKeeper for å opprettholde lagringsbehovet, men det er en vri: Apache Pulsar har en funksjon kalt Tiered Storage som er ganske noe. Et av problemene med distribuerte loggsystemer er at mens du vil at dataene skal være i loggplattformen så lenge som mulig, er ikke diskstasjoner uendelig i størrelse. På et eller annet tidspunkt tar du avgjørelsen om å enten slette disse meldingene eller lagre dem andre steder, der de potensielt kan spilles gjennom datarørledningen om nødvendig i fremtiden. Som fungerer, men kan være operativt komplisert. Apache Pulsar, gjennom Tiered Storage, kan automatisk flytte eldre data til Amazon S3, Google Cloud Storage eller Azure Blog Storage, og fremdeles presentere en gjennomsiktig visning tilbake til klienten; klienten kan lese fra begynnelsen av akkurat som om alle meldingene var til stede i loggen.
Akkurat som Apache Kafka har Apache Pulsar vokst til et økosystem for databehandling (selv om det også gir adaptere for Apache Spark og Apache Storm). Pulsar IO tilsvarer Kafka Connect for tilkobling til andre datasystemer som enten kilder eller vasker, og Pulsar Functions gir databehandlingsfunksjonalitet. SQL-spørring leveres ved å bruke et adapter for Facebooks Presto-motor med åpen kilde.
En interessant rynke er at Pulsar Functions og Pulsar IO kjører i en standard Pulsar-klynge i stedet for å være separate prosesser som potensielt kan kjøre hvor som helst. Selv om dette er en reduksjon i fleksibilitet, gjør det ting mye enklere fra et operativt synspunkt. (Det er en lokal kjøremodus som kan misbrukes for å kjøre funksjoner utenfor klyngen, men dokumentasjonen går ut av sin måte å si "Ikke gjør dette!")
Apache Pulsar tilbyr også forskjellige metoder for å kjøre funksjoner inne i klyngen: De kan kjøres som separate prosesser, som Docker-containere, eller som tråder som kjører i en meglers JVM-prosess. Dette henger sammen med distribusjonsmodellen for Apache Pulsar, som allerede støtter Kubernetes eller Mesosphere DC / OS i produksjon. En ting å være oppmerksom på er at Pulsar Functions, Pulsar IO og SQL er relativt nye tillegg til Apache Pulsar, så forvent noen skarpe kanter hvis du bruker dem.
Det er også en begrenset, bare Java, Kafka-kompatibel API-innpakning, slik at du potensielt kan integrere eksisterende Apache Kafka-applikasjoner i en Apache Pulsar-infrastruktur. Dette er sannsynligvis bedre egnet til utforskende testing og en midlertidig migrasjonsplan enn en produksjonsløsning, men det er hyggelig å ha!
På samme måte som Confluent har utviklerne av Apache Pulsar på Yahoo (Matteo Merli og Sijie Guo) dannet et spinoff-selskap, Streamlio, hvor de er medstiftere sammen med skaperne av Apache Heron (Karthik Ramasamy og Sanjeev Kulkarni) . Streamlios bedriftstilbud inkluderer de vanlige kommersielle support- og profesjonelle tjenesteløsningene, sammen med en konsoll for lukket kildekontroll, men ting som effektiv og holdbar støtte for flere leieforhold er en del av kjernen i åpen kildekode.
Apache Kafka eller Apache Pulsar?
Apache Kafka er et modent, elastisk og kamptestet produkt. Den har klienter skrevet på nesten alle populære språk, samt en rekke støttede kontakter for forskjellige datakilder i Kafka Connect. Med administrerte tjenester som tilbys av Amazon og Confluent, er det enkelt å få en stor Kafka-klynge i gang, vedlikeholdt og vedlikeholdt - mye enklere enn tidligere år. Jeg fortsetter å bruke Apache Kafka i nye prosjekter, og jeg vil sannsynligvis gjøre det i mange år fremover.
Men hvis du skal bygge et meldingssystem som må være multi-leietaker eller geo-replikert fra starten, eller som har store behov for datalagring, pluss behovet for å enkelt spørre og behandle alle dataene uansett hvordan for lenge siden, så foreslår jeg å sparke dekkene til Apache Pulsar. Det passer definitivt i noen brukstilfeller som Apache Kafka kan slite med, samtidig som det fungerer bra når det gjelder kjernefunksjonene du trenger fra en distribuert loggplattform. Og hvis du ikke har noe imot å være i forkant når det gjelder dokumentasjon og spørsmål om Stack Overflow, så mye bedre!
