Šiais laikais masiškai keičiami „pub / sub“ pranešimai iš esmės yra „Apache Kafka“ sinonimai. „Apache Kafka“ ir toliau yra tvirtas, atviro kodo pasirinkimas pereinant prie srautinių srautinių programų, nesvarbu, ar pridėjote ką nors panašaus į „Apache Storm“ ar „Apache Spark“, kad apdorotumėte, ar naudojate pačios „Apache Kafka“ pateiktus apdorojimo įrankius. Tačiau „Kafka“ nėra vienintelis žaidimas mieste.
Sukurtas „Yahoo“, o dabar „Apache Software Foundation“ projektas, „Apache Pulsar“ siekia pranešimų vainiko, kurį „Apache Kafka“ dėvėjo daugelį metų. „Apache Pulsar“ siūlo greitesnio pralaidumo ir mažesnio delsos galimybes nei „Apache Kafka“ daugeliu atvejų kartu su suderinama API, leidžiančia kūrėjams palyginti lengvai pereiti nuo „Kafka“ prie „Pulsar“.
Kaip reikėtų pasirinkti tarp gerbiamo stipraus „Apache Kafka“ ir „Apache Pulsar“? Pažvelkime į jų pagrindinius atvirojo kodo pasiūlymus ir į tai, ką pagrindinės prižiūrėtojų įmonės leidimai pateikia ant stalo.
Apache Kafka
„LinkedIn“ sukurtas ir dar 2011 m. Išleistas kaip atvirasis šaltinis „Apache Kafka“ išplito toli ir plačiai, daugeliui tapdamas numatytuoju pasirinkimu daugeliui galvojant apie paslaugų magistralės ar „pub / sub“ sistemos pridėjimą prie architektūros. Po „Apache Kafka“ debiuto „Kafka“ ekosistema labai išaugo, pridėjus schemos registrą, kad būtų užtikrintos „Apache Kafka“ pranešimų schemos, „Kafka Connect“, kad būtų galima lengvai perduoti srautą iš kitų duomenų šaltinių, tokių kaip duomenų bazės į „Kafka“, „Kafka Streams“ paskirstytam srautui apdoroti, o neseniai - KSQL už SQL užklausų vykdymą Kafka temomis. („Kafka“ tema yra konkretaus kanalo pavadinimas.)
Standartinis daugelio realių laiko vamzdynų, pastatytų per pastaruosius kelerius metus, naudojimo atvejis buvo duomenų perkėlimas į „Apache Kafka“ ir duomenų srautui apdoroti, atlikti ir apdoroti, o po to naudoti srauto procesorių, pvz., „Apache Storm“ ar „Apache Spark“. išvesties į kitą vartotojų vartojimo temą. Naudojant „Kafka Stream“ ir KSQL, visi jūsų duomenų srauto poreikiai gali būti patenkinti neišeidami iš „Apache Kafka“ projekto bet kada, nors, žinoma, vis tiek galite naudoti išorinę paslaugą savo duomenims apdoroti, jei to reikia.
Nors „Apache Kafka“ kūrėjo požiūriu visada buvo labai draugiška, tai operatyviai buvo kažkas maišyto. Sukurti ir paleisti nedidelį klasterį yra gana lengva, tačiau didelio klasterio išlaikymas dažnai yra susijęs su problemomis (pvz., Lyderio skaidinio keitimas po „Kafka“ brokerio nesėkmės).
Be to, požiūris, kuriuo remtasi daugiabučių namų nuomos paslauga, vadinama „MirrorMaker“, buvo patikimas būdas priversti SRE išsitraukti plaukus. Iš tiesų, „MirrorMaker“ laikoma tokia problema, kad tokios įmonės kaip „Uber“ sukūrė savo sistemą, skirtą dauginti duomenų centruose („uReplicator“). „Confluent“ apima „Confluent Replicator“ kaip dalį įmonės „Apache Kafka“ pasiūlymo. Kalbant kaip žmogui, kuriam teko išlaikyti „MirrorMaker“ sąranką, gaila, kad „Replicator“ nėra atvirojo kodo versijos dalis.
Tačiau tai tikrai ne visos blogos naujienos operaciniame fronte. Dabartinėje „Apache Kafka 1.x“ serijoje buvo padaryta daugybė darbų, kad sumažėtų kai kurie klasterio valdymo galvos skausmai. Pastaruoju metu buvo keletas pakeitimų, leidžiančių sistemai efektyviau valdyti didelius daugiau nei 200 000 skaidinių grupes, o tokie patobulinimai, kaip „Kafka Connect“ pridedant „negyvų laiškų“ eiles, labai padeda identifikuoti ir atkurti problemas, susijusias su duomenų šaltiniais ir kriauklėmis. lengviau. Mes taip pat tikimės, kad 2019 m. „Apache Kafka“ paleidimas „Kubernetes“ bus pasiekiamas gamybos lygiu (per „Helm“ diagramas ir „Kubernetes“ operatorių).
Dar 2014 m. Trys originalūs „Kafka“ kūrėjai (Jun Rao, Jay Krepsas ir Neha Narkhede) suformavo „Confluent“, kuris savo „Confluent“ platformoje suteikia papildomų įmonės funkcijų, tokių kaip aukščiau minėtas replikatorius, „Control Center“, papildomi saugos papildiniai ir įprastų palaikymo ir profesionalių paslaugų pasiūlymų. „Confluent“ taip pat turi debesies pasiūlymą „Confluent Cloud“, kuris yra visiškai valdoma „Confluent Platform“ paslauga, veikianti „Amazon Web Services“ ar „Google Cloud Platform“, jei nenorite patys susidoroti su kai kuriomis veikiančių klasterių eksploatacinėmis sąnaudomis.
Jei esate užrakintas AWS ir naudojate „Amazon“ paslaugas, atkreipkite dėmesį, kad „Amazon“ pristatė viešą „Amazon Managed Streaming for Kafka“ (MSK) peržiūrą, kuri yra visiškai valdoma „Kafka“ paslauga AWS ekosistemoje. (Taip pat atkreipkite dėmesį, kad „Amazon MSK“ nėra teikiama bendradarbiaujant su „Confluent“, todėl paleisdami MSK gausite ne visas „Confluent Platform“ funkcijas, o tik tai, kas numatyta atvirajame šaltinyje „Apache Kafka“.)
Apache Pulsaras
Atsižvelgdami į „Apache Software Foundation“ polinkį rinktis projektus, kurie, atrodo, dubliuoja funkcionalumą (ar norėtumėte „Apache Apex“, „Apache Flink“, „Apache Heron“, „Apache Samza“, „Apache Spark“ ar „Apache Storm“ savo nukreiptų aciklinių grafikų duomenų apdorojimo poreikiams?), prieš pasirinkdami „Apache Kafka“ kaip patikimą parinktį savo pranešimų poreikiams, atleiskite, jei žvelgėte pro skelbimus apie „Apache Pulsar“ tapimą aukščiausio lygio „Apache“ projektu. Tačiau Apache Pulsaras nusipelno žvilgsnio.
Apache Pulsaras gimė „Yahoo“, kur jis buvo sukurtas siekiant patenkinti organizacijos poreikius, kurių tuo metu negalėjo suteikti kiti atvirojo kodo pasiūlymai. Dėl to „Pulsar“ buvo sukurtas nuo pat pradžių, kad galėtų tvarkyti milijonus temų ir skaidinių, visiškai palaikydamas geo replikaciją ir daugiabučių nuomą.
Po dangteliu „Apache Pulsar“ naudoja „Apache BookKeeper“, kad išlaikytų savo saugojimo poreikius, tačiau yra tam tikras dalykas: „Apache Pulsar“ turi funkciją, vadinamą „Tiered Storage“, kuri yra gana kažkas. Viena iš paskirstytų žurnalų sistemų problemų yra ta, kad nors norite, kad duomenys kuo ilgiau išliktų žurnalo platformoje, diskų įrenginiai nėra begalinio dydžio. Tam tikru momentu jūs nusprendžiate ištrinti tuos pranešimus arba saugoti juos kitur, kur prireikus ateityje juos bus galima pakartoti per duomenų perdavimo liniją. Kas veikia, bet gali būti sudėtinga eksploatuoti. „Apache Pulsar“ per daugialypę saugyklą gali automatiškai perkelti senesnius duomenis į „Amazon S3“, „Google Cloud Storage“ arba „Azure Blog Storage“ ir vis tiek pateikti skaidrų vaizdą klientui; klientas gali skaityti nuo laiko pradžios taip, lyg visi pranešimai būtų žurnale.
Kaip ir „Apache Kafka“, taip ir „Apache Pulsar“ išaugo duomenų apdorojimo ekosistema (nors ji taip pat teikia adapterius „Apache Spark“ ir „Apache Storm“). „Pulsar IO“ yra „Kafka Connect“ atitikmuo, skirtas prisijungti prie kitų duomenų sistemų kaip šaltiniai arba kriauklės, o „Pulsar Functions“ suteikia duomenų apdorojimo funkcionalumą. SQL užklausos teikiamos naudojant „Facebook“ atvirojo šaltinio „Presto“ variklio adapterį.
Įdomi raukšlė yra ta, kad „Pulsar Functions“ ir „Pulsar IO“ veikia standartiniame „Pulsar“ klasteryje, o ne yra atskiri procesai, kurie potencialiai galėtų vykti bet kur. Nors tai yra lankstumo sumažinimas, tai iš esmės viską supaprastina veiklos požiūriu. (Yra vietinis vykdymo režimas, kuriuo galima piktnaudžiauti vykdant funkcijas už klasterio ribų, tačiau dokumentacijoje nėra taip, kad būtų galima pasakyti „Negalima to padaryti!“)
„Apache Pulsar“ taip pat siūlo įvairius funkcijų vykdymo būdus klasterio viduje: juos galima paleisti kaip atskirus procesus, kaip „Docker“ konteinerius arba kaip gijas, vykdomas brokerio JVM procese. Tai siejasi su „Apache Pulsar“ diegimo modeliu, kuris jau palaiko „Kubernetes“ arba „Mesosphere DC / OS“ gamybą. Vienas dalykas, kurį reikia žinoti, yra tai, kad „Pulsar Functions“, „Pulsar IO“ ir „SQL“ yra palyginti nauji „Apache Pulsar“ priedai, todėl, jei juos naudosite, tikitės kelių aštrių briaunų.
Taip pat yra ribotas, tik „Java“ suderinamas „Kafka“ API paketas, todėl esamas „Apache Kafka“ programas galite integruoti į „Apache Pulsar“ infrastruktūrą. Tai tikriausiai geriau tinka tiriamiesiems bandymams ir tarpiniam perkėlimo planui nei gamybos sprendimui, bet malonu, kad tai yra!
Panašiai kaip „Confluent“, „Yahoo“ kūrėjai „Apache Pulsar“ (Matteo Merli ir Sijie Guo) įkūrė „spinoff“ įmonę „Streamlio“, kur jie yra kartu su „Apache Heron“ kūrėjais (Karthik Ramasamy ir Sanjeev Kulkarni). . „Streamlio“ įmonių pasiūla apima įprastą komercinę paramą ir profesionalių paslaugų sprendimus, taip pat uždaro kodo valdymo pultą, tačiau tokie dalykai kaip efektyvi ir patvari daugiabučių nuomos palaikymas yra pagrindinio atvirojo kodo produkto dalis.
Apache Kafka ar Apache Pulsaras?
„Apache Kafka“ yra brandus, atsparus ir mūšio išbandytas produktas. Jame yra klientų, parašytų beveik visomis populiariomis kalbomis, taip pat yra daugybė palaikomų jungčių skirtingiems „Kafka Connect“ duomenų šaltiniams. „Amazon“ ir „Confluent“ siūlomoms valdomoms paslaugoms lengva sukurti, valdyti ir prižiūrėti didelę „Kafka“ grupę - daug lengviau nei ankstesniais metais. Aš ir toliau naudoju „Apache Kafka“ naujuose projektuose ir greičiausiai tai darysiu dar daugelį metų.
Tačiau jei ketinate kurti pranešimų sistemą, kuri turi būti nuomininkė arba geografiškai replikuojama nuo pat pradžių, arba kuri turi didelių duomenų saugojimo poreikių, taip pat poreikį lengvai atlikti užklausas ir apdoroti visus tuos duomenis, kad ir kaip jie būtų seniau, tada siūlau spardyti „Apache Pulsar“ padangas. Tai tikrai tinka kai kuriems naudojimo atvejams, su kuriais gali kovoti „Apache Kafka“, tačiau taip pat gerai veikia pagrindinės funkcijos, kurių jums reikia iš paskirstytos žurnalo platformos. Ir jei jūs neprieštaraujate, kad esate pažangiausiame dokumentavimo ir atsakymų į „Stack Overflow“ klausimus, tuo geriau!
