Ohjelmointi

Apache Kafka vs. Apache Pulsar: Kuinka valita

Nykyään massiivisesti skaalautuva pubi- / alaviestintä on käytännössä synonyymi Apache Kafkalle. Apache Kafka on edelleen rock-solid, avoimen lähdekoodin, valintamalli hajautetuille suoratoistosovelluksille, lisäämällä Apache Stormin tai Apache Sparkin kaltaista käsittelyä varten tai käyttämällä itse Apache Kafkan tarjoamia käsittelytyökaluja. Mutta Kafka ei ole ainoa peli kaupungissa.

Yahoon kehittämä ja nyt Apache Software Foundation -hanke Apache Pulsar pyrkii saamaan viestipalvelun kruunun, jota Apache Kafka on käyttänyt monien vuosien ajan. Apache Pulsar tarjoaa nopeamman suorituskyvyn ja pienemmän viiveen kuin Apache Kafka monissa tilanteissa, sekä yhteensopiva API, jonka avulla kehittäjät voivat vaihtaa Kafkasta Pulsariin suhteellisen helposti.

Kuinka pitäisi valita kunnioitettavan voimakas Apache Kafka ja nouseva Apache Pulsar? Tarkastellaan heidän avoimen lähdekoodin tarjouksiaan ja sitä, mitä ydin ylläpitäjien yritysversiot tuovat pöydälle.

Apache Kafka

LinkedInin kehittämä ja julkaistu avoimen lähdekoodin muodossa vuonna 2011 Apache Kafka on levinnyt kauas ja laajalle, ja siitä on tullut melko paljon oletusvalinta monille, kun ajatellaan palveluväylän tai pubi- / alijärjestelmän lisäämistä arkkitehtuuriin. Apache Kafkan debyyttinsä jälkeen Kafka-ekosysteemi on kasvanut huomattavasti, lisäämällä Scheme-rekisterin noudattamaan skeemejä Apache Kafka -viestinnässä, Kafka Connectilla suoratoistoa varten helposti muista tietolähteistä, kuten tietokannoista Kafkaan, Kafka Streameista hajautettujen suoratoistojen käsittelyyn ja viimeksi KSQL: stä. SQL-tyyppisen kyselyn suorittamiseksi Kafka-aiheista. (Kafkan aihe on tietyn kanavan nimi.)

Monien viime vuosina rakennettujen reaaliaikaisten putkistojen vakiokäytäntö on ollut tietojen työntäminen Apache Kafkaan ja sitten suoratoistoprosessorin, kuten Apache Stormin tai Apache Sparkin, käyttö tietojen hakemiseen, suorittamiseen ja käsittelyyn sekä julkaisemiseen tuotos toiseen aiheeseen jatkokulutusta varten. Kafka Streamin ja KSQL: n avulla kaikki dataputken tarpeesi voidaan hoitaa poistumatta Apache Kafka -projektista milloin tahansa, vaikka tietenkin voit silti käyttää ulkoista palvelua tietojen käsittelyyn tarvittaessa.

Vaikka Apache Kafka on aina ollut erittäin ystävällinen kehittäjien näkökulmasta, se on ollut toiminnallisesti jotain sekalaista. Pienen klusterin saaminen käyttöön on suhteellisen helppoa, mutta suuren klusterin ylläpitäminen on usein täynnä ongelmia (esim. Johtajaosion vaihto Kafka-välittäjän epäonnistumisen jälkeen).

Lisäksi lähestymistapa, jolla tuetaan monivuokralaisuutta MirrorMaker-apuohjelman kautta, on ollut varma tapa saada SRE: t vetämään hiuksensa. MirrorMakeria pidetään todellakin ongelmana, että Uberin kaltaiset yritykset ovat luoneet oman järjestelmän replikointiin datakeskusten välillä (uReplicator). Confluent sisältää Confluent Replicator -yrityksen osana Apache Kafkan yritysvalikoimaa. On häpeä, että Replicator ei ole osa avoimen lähdekoodin versiota puhuessaan henkilönä, jonka on pitänyt ylläpitää MirrorMaker-asetuksia.

Se ei todellakaan ole kaikki huono uutinen operatiivisella tasolla. Nykyisessä Apache Kafka 1.x -sarjassa on tehty paljon työtä vähentääkseen joitain klusterin käyttämisen päänsärkyä. Viime aikoina on tapahtunut joitain muutoksia, jotka mahdollistavat järjestelmän ajaa suuria yli 200 000 osion klustereita virtaviivaisemmalla tavalla, ja parannukset, kuten "kuollut kirjain" -jonojen lisääminen Kafka Connectiin, tekevät tietolähteiden ja nielujen ongelmien tunnistamisesta ja palautumisesta niin paljon helpompaa. Todennäköisesti myös Apache Kafkan käyttämisen Kubernetes-sovelluksessa vuonna 2019 (Helm-kaavioiden ja Kubernetes-operaattorin kautta).

Vuonna 2014 kolme Kafkan alkuperäistä kehittäjää (Jun Rao, Jay Kreps ja Neha Narkhede) muodostivat Confluentin, joka tarjoaa Confluent Platform -alustalleen lisää yritysominaisuuksia, kuten edellä mainitut kopiokoneet, Control Center, ylimääräiset tietoturvalaajennukset ja tavalliset tuki- ja asiantuntijapalvelutarjoukset. Confluentilla on myös pilvitarjonta Confluent Cloud, joka on täysin hallinnoitu Confluent Platform -palvelu, joka toimii Amazon Web Services -palvelussa tai Google Cloud Platform -palvelussa, jos et halua itse käsitellä joitain käynnissä olevien klustereiden toimintakustannuksia.

Jos olet lukittu AWS: ään ja käytät Amazon-palveluja, huomaa, että Amazon on ottanut käyttöön julkisen esikatselun Amazon Managed Streaming for Kafka (MSK) -palvelusta, joka on täysin hallinnoitu Kafka-palvelu AWS-ekosysteemissä. (Huomaa myös, että Amazon MSK ei ole tarjotaan yhteistyössä Confluentin kanssa, joten MSK: n suorittaminen ei tuo sinulle kaikkia Confluent Platform -ominaisuuksia, vaan vain avoimen lähdekoodin Apache Kafkan tarjoamia ominaisuuksia.)

Apache Pulsar

Ottaen huomioon Apache Software Foundationin taipumuksen hankkia projekteja, jotka näyttävät kopioivan toiminnallisuutta (haluaisitko Apache Apexin, Apache Flinkin, Apache Heronin, Apache Samzan, Apache Sparkin tai Apache Stormin suunnattuihin asyklisiin kaavioiden tietojenkäsittelytarpeisiin?), anna anteeksi, että katsot heti ilmoituksia siitä, että Apache Pulsarista tulee huipputason Apache-projekti, ennen kuin valitset Apache Kafkan luotettavaksi vaihtoehdoksi viestintätarpeisiisi. Mutta Apache Pulsar ansaitsee katseen.

Apache Pulsar syntyi Yahoossa, missä se luotiin vastaamaan organisaation tarpeisiin, joita muut avoimen lähdekoodin tarjoukset eivät tuolloin pystyneet tarjoamaan. Tuloksena Pulsar rakennettiin alusta asti käsittelemään miljoonia aiheita ja osioita täydellä tuella georeplikointiin ja monivuokraukseen.

Kannen alla Apache Pulsar käyttää Apache BookKeeper -ohjelmaa säilyttääkseen tallennustarpeensa, mutta siinä on käänne: Apache Pulsarilla on ominaisuus nimeltä Tiered Storage, joka on melko jotain. Yksi hajautettujen lokijärjestelmien ongelmista on, että vaikka haluat tietojen pysyvän lokialustalla niin kauan kuin mahdollista, levyasemien koko ei ole ääretön. Jossain vaiheessa päätät joko poistaa nämä viestit tai tallentaa ne muualle, missä ne voidaan tarvittaessa toistaa dataputken kautta tarvittaessa tulevaisuudessa. Mikä toimii, mutta voi olla toiminnallisesti monimutkaista. Apache Pulsar voi porrastetun tallennustilan kautta siirtää vanhemmat tiedot automaattisesti Amazon S3: een, Google Cloud Storageen tai Azure Blog Storage -palveluun ja silti tarjota läpinäkyvän näkymän takaisin asiakkaalle. asiakas voi lukea ajan alusta aivan kuin kaikki viestit olisivat lokissa.

Aivan kuten Apache Kafka, Apache Pulsar on kasvanut ekosysteemin tietojen käsittelyä varten (vaikka se tarjoaa myös sovittimia Apache Sparkille ja Apache Stormille). Pulsar IO on vastaava Kafka Connect -laite yhteyden muodostamiseksi muihin tietojärjestelmiin joko lähteinä tai nieluina, ja Pulsar Functions tarjoaa tietojenkäsittelytoiminnot. SQL-kysely tapahtuu Facebookin avoimen Presto-moottorin sovittimella.

Mielenkiintoinen ryppy on, että Pulsar Functions ja Pulsar IO toimivat tavallisessa Pulsar-klusterissa sen sijaan, että ne olisivat erillisiä prosesseja, jotka voisivat mahdollisesti toimia missä tahansa. Vaikka tämä on joustavuuden väheneminen, se tekee asioista paljon yksinkertaisempia toiminnallisesta näkökulmasta. (On olemassa paikallinen ajotila, jota voidaan käyttää väärin toimintojen suorittamiseen klusterin ulkopuolella, mutta dokumentaatiossa sanotaan "Älä tee tätä!")

Apache Pulsar tarjoaa myös erilaisia ​​toimintoja toimintojen suorittamiseksi klusterin sisällä: Ne voidaan suorittaa erillisinä prosesseina, Docker-säilöinä tai ketjuina, jotka kulkevat välittäjän JVM-prosessissa. Tämä liittyy Apache Pulsarin käyttöönottomalliin, joka tukee jo Kubernetes- tai Mesosphere DC / OS -tuotteita tuotannossa. Yksi tietoinen asia on, että Pulsar-toiminnot, Pulsar IO ja SQL ovat suhteellisen uusia lisäyksiä Apache Pulsariin, joten odota muutama terävä reuna, jos käytät niitä.

Siellä on myös rajoitettu, vain Java, Kafka-yhteensopiva API-kääre, joten voit integroida olemassa olevat Apache Kafka -sovellukset Apache Pulsar -infrastruktuuriin. Tämä sopii todennäköisesti paremmin kokeellisiin testauksiin ja väliaikaiseen siirtymäsuunnitelmaan kuin tuotantoratkaisuun, mutta on mukavaa saada!

Samalla tavalla kuin Confluent, Yahoon Apache Pulsarin kehittäjät (Matteo Merli ja Sijie Guo) ovat perustaneet spinoff-yrityksen Streamlio, jossa he ovat yhdessä perustamassa Apache Heronin (Karthik Ramasamy ja Sanjeev Kulkarni) luojia. . Streamlion yritystarjonta sisältää tavanomaisen kaupallisen tuen ja asiantuntijapalveluratkaisut sekä suljetun lähdekoodin hallintakonsolin, mutta muun muassa tehokas ja kestävä monivuokraustuki ovat osa avoimen lähdekoodin ydintuotetta.

Apache Kafka vai Apache Pulsar?

Apache Kafka on kypsä, joustava ja taistelutestattu tuote. Siinä on asiakkaita, jotka on kirjoitettu lähes kaikilla suosituilla kielillä, sekä joukko tuettuja liittimiä Kafka Connectin eri tietolähteille. Kun Amazon ja Confluent tarjoavat hallinnoituja palveluja, on helppo saada suuri Kafka-klusteri käyttöön, ylläpitää ja ylläpitää - paljon helpompaa kuin edellisinä vuosina. Jatkan Apache Kafkan käyttöä uusissa projekteissa, ja teen sen todennäköisesti monien vuosien ajan.

Kuitenkin, jos aiot rakentaa viestijärjestelmää, jonka on oltava alusta alkaen monivuokralaisia ​​tai maantieteellisesti replikoituja, tai jolla on suuret tietovarastointitarpeet sekä tarve kysellä ja käsitellä kaikkia näitä tietoja helposti riippumatta siitä, miten kauan sitten, ehdotan sitten potkia Apache Pulsarin renkaita. Se sopii ehdottomasti joihinkin käyttötapauksiin, joita Apache Kafka voi taistella, samalla kun se toimii hyvin myös hajautetun lokialustan tarvitsemien ydinominaisuuksien suhteen. Ja jos et halua olla kärjessä dokumentaation ja pinon ylivuotokysymysten suhteen, niin paljon parempi!

$config[zx-auto] not found$config[zx-overlay] not found