I disse dage er masserbart skalerbar pub / sub-messaging næsten synonymt med Apache Kafka. Apache Kafka fortsætter med at være det bundsolid, open source, valg til distribuerede streamingapplikationer, uanset om du tilføjer noget som Apache Storm eller Apache Spark til behandling eller ved hjælp af behandlingsværktøjerne leveret af Apache Kafka selv. Men Kafka er ikke det eneste spil i byen.
Udviklet af Yahoo og nu et Apache Software Foundation-projekt, går Apache Pulsar til kronen på beskeder, som Apache Kafka har båret i mange år. Apache Pulsar tilbyder potentialet for hurtigere kapacitet og lavere latenstid end Apache Kafka i mange situationer sammen med en kompatibel API, der giver udviklere mulighed for at skifte fra Kafka til Pulsar med relativ lethed.
Hvordan skal man vælge mellem den ærværdige dygtige Apache Kafka og den oprindelige Apache Pulsar? Lad os se på deres centrale open source-tilbud, og hvad kerneforholdets virksomhedsudgaver bringer til bordet.
Apache Kafka
Udviklet af LinkedIn og udgivet som open source tilbage i 2011, har Apache Kafka spredt sig vidt og bredt, og stort set blevet standardvalget for mange, når man tænker på at tilføje en servicebus eller pub / sub-system til en arkitektur. Siden Apache Kafkas debut er Kafka-økosystemet vokset betydeligt, idet der tilføjes skemaregistret for at håndhæve skemaer i Apache Kafka-messaging, Kafka Connect til nem streaming fra andre datakilder som databaser til Kafka, Kafka Streams til distribueret stream-behandling og senest KSQL til at udføre SQL-lignende forespørgsel om Kafka-emner. (Et emne i Kafka er navnet på en bestemt kanal.)
Standard use-case for mange realtidsrørledninger, der er bygget de seneste par år, har været at skubbe data ind i Apache Kafka og derefter bruge en streamprocessor som Apache Storm eller Apache Spark til at hente data, udføre og behandle og derefter offentliggøre output til et andet emne til downstream-forbrug. Med Kafka Streams og KSQL kan alle dine datarørledningsbehov håndteres uden at skulle forlade Apache Kafka-projektet på noget tidspunkt, selvom du selvfølgelig stadig kan bruge en ekstern tjeneste til at behandle dine data, hvis det er nødvendigt.
Mens Apache Kafka altid har været meget venlig set fra en udviklers synspunkt, har det været noget af en blandet taske operationelt. At komme i gang med en lille klynge er relativt let, men det er ofte fyldt med problemer at vedligeholde en stor klynge (f.eks. Bytte af lederpartition efter en Kafka-mæglerfejl).
Yderligere har tilgangen til støtte for multi-tenancy via et værktøj kaldet MirrorMaker været en sikker måde at få SRE'er til at trække deres hår ud. Faktisk betragtes MirrorMaker som et sådant problem, at virksomheder som Uber har oprettet deres eget system til replikering på tværs af datacentre (uReplicator). Confluent inkluderer Confluent Replicator som en del af virksomhedens tilbud af Apache Kafka. Når det tales som en person, der har været nødt til at opretholde en MirrorMaker-opsætning, er det en skam, at Replicator ikke er en del af open source-versionen.
Det er dog bestemt ikke alle dårlige nyheder på den operationelle front. Der er gjort meget arbejde i den nuværende Apache Kafka 1.x-serie for at reducere nogle af hovedpine ved at køre en klynge. For nylig har der været nogle ændringer, der gør det muligt for systemet at køre store klynger på mere end 200.000 partitioner på en mere strømlinet måde, og forbedringer som tilføjelse af "dead letter" -køer til Kafka Connect gør identifikation og gendannelse af problemer i datakilder og synker så meget lettere. Vi vil sandsynligvis også se produktionsstøtte til at køre Apache Kafka på Kubernetes i 2019 (via Helm charts og en Kubernetes-operatør).
Tilbage i 2014 dannede tre af de originale udviklere af Kafka (Jun Rao, Jay Kreps og Neha Narkhede) Confluent, som giver yderligere virksomhedsfunktioner i sin Confluent Platform, såsom den ovennævnte Replicator, Control Center, yderligere sikkerhedsprogrammer og det sædvanlige tilbud og professionelle tjenester. Confluent har også et cloud-tilbud, Confluent Cloud, som er en fuldt administreret Confluent Platform-tjeneste, der kører på Amazon Web Services eller Google Cloud Platform, hvis du foretrækker ikke at håndtere nogle af de operationelle omkostninger ved kørende klynger selv.
Hvis du er låst i AWS og bruger Amazon-tjenester, skal du bemærke, at Amazon har introduceret en offentlig forhåndsvisning af Amazon Managed Streaming for Kafka (MSK), som er en fuldt administreret Kafka-tjeneste inden for AWS-økosystemet. (Bemærk også, at Amazon MSK ikke er leveres i partnerskab med Confluent, så kørsel af MSK giver dig ikke alle funktionerne i Confluent Platform, men kun det, der findes i open source Apache Kafka.)
Apache Pulsar
I betragtning af Apache Software Foundation's forkærlighed for at hente projekter, der ser ud til at duplikere funktionalitet (vil du gerne have Apache Apex, Apache Flink, Apache Heron, Apache Samza, Apache Spark eller Apache Storm til dine målrettede acykliske grafbehandlingsbehov?), Ville du blive tilgivet for at se lige forbi meddelelserne om, at Apache Pulsar bliver et top-niveau Apache-projekt, inden du vælger Apache Kafka som en pålidelig mulighed for dine messaging-behov. Men Apache Pulsar fortjener et kig.
Apache Pulsar blev født i Yahoo, hvor det blev oprettet for at imødekomme organisationens behov, som andre open source-tilbud ikke kunne levere på det tidspunkt. Som et resultat blev Pulsar bygget fra bunden til at håndtere millioner af emner og partitioner med fuld støtte til geo-replikering og multi-tenancy.
Under omslaget bruger Apache Pulsar Apache BookKeeper til at opretholde sine lagerbehov, men der er et twist: Apache Pulsar har en funktion kaldet Tiered Storage, der er ret noget. Et af problemerne med distribuerede logsystemer er, at mens du vil have dataene i logplatformen så længe som muligt, er diskdrev ikke uendelige i størrelse. På et eller andet tidspunkt tager du beslutningen om enten at slette disse meddelelser eller gemme dem andre steder, hvor de potentielt kan afspilles igen via datapipelinen, hvis det er nødvendigt i fremtiden. Hvilket fungerer, men kan være operationelt kompliceret. Apache Pulsar kan via Tiered Storage automatisk flytte ældre data til Amazon S3, Google Cloud Storage eller Azure Blog Storage og stadig præsentere en gennemsigtig visning tilbage til klienten; klienten kan læse fra tidens start, som om alle meddelelserne var til stede i loggen.
Ligesom Apache Kafka har Apache Pulsar vokset et økosystem til databehandling (selvom det også giver adaptere til Apache Spark og Apache Storm). Pulsar IO svarer til Kafka Connect til tilslutning til andre datasystemer som enten kilder eller dræn, og Pulsar Functions giver databehandlingsfunktionalitet. SQL-forespørgsel leveres ved hjælp af en adapter til Facebooks Presto-motor med open source.
En interessant rynke er, at Pulsar-funktioner og Pulsar IO kører inden for en standard Pulsar-klynge snarere end at være separate processer, der potentielt kan køre hvor som helst. Selv om dette er en reduktion i fleksibilitet, gør det tingene meget enklere fra et operationelt synspunkt. (Der er en lokal kørselstilstand, der kan misbruges til at køre funktioner uden for klyngen, men dokumentationen går ud af sin måde at sige "Gør ikke dette!")
Apache Pulsar tilbyder også forskellige metoder til at køre funktioner inde i klyngen: De kan køres som separate processer, som Docker-containere eller som tråde, der kører i en mæglers JVM-proces. Dette hænger sammen med implementeringsmodellen til Apache Pulsar, som allerede understøtter Kubernetes eller Mesosphere DC / OS i produktion. En ting at være opmærksom på er, at Pulsar-funktioner, Pulsar IO og SQL er relativt nye tilføjelser til Apache Pulsar, så forvent et par skarpe kanter, hvis du bruger dem.
Der er også en begrænset, kun Java, Kafka-kompatibel API-indpakning, så du potentielt kan integrere eksisterende Apache Kafka-applikationer i en Apache Pulsar-infrastruktur. Dette er sandsynligvis bedre egnet til sonderende test og en midlertidig migrationsplan end en produktionsløsning, men det er rart at have!
På samme måde som Confluent har udviklerne af Apache Pulsar på Yahoo (Matteo Merli og Sijie Guo) dannet et spinoff-firma, Streamlio, hvor de er medstiftere sammen med skaberne af Apache Heron (Karthik Ramasamy og Sanjeev Kulkarni) . Streamlios virksomhedstilbud inkluderer de sædvanlige kommercielle support- og professionelle serviceløsninger sammen med en styringskonsol med lukket kilde, men ting som effektiv og holdbar support til flere lejemål er en del af kernen i open source-produktet.
Apache Kafka eller Apache Pulsar?
Apache Kafka er et modent, modstandsdygtigt og kamptestet produkt. Det har klienter skrevet på næsten alle populære sprog såvel som en række understøttede stik til forskellige datakilder i Kafka Connect. Med administrerede tjenester, der tilbydes af Amazon og Confluent, er det let at få en stor Kafka-klynge, kørende og vedligeholdt - meget lettere end i tidligere år. Jeg fortsætter med at bruge Apache Kafka i nye projekter, og jeg vil sandsynligvis gøre det i mange år fremover.
Men hvis du skal opbygge et messaging-system, der skal multi-lejer eller geo-replikeres fra starten, eller som har store behov for datalagring, plus behovet for let at spørge og behandle alle disse data, uanset hvordan for længe siden tidligere, så foreslår jeg at sparke Apache Pulsars dæk. Det passer bestemt til nogle brugssager, som Apache Kafka kan kæmpe med, samtidig med at det fungerer godt med hensyn til de kernefunktioner, du har brug for fra en distribueret logplatform. Og hvis du ikke har noget imod at være i forkant med hensyn til dokumentation og spørgsmål om Stack Overflow besvaret, så meget bedre!
