Kas tie message streaming įrankiai ir kam jų reikia?
Prieš keletą metų dirbau projekte, kur mums reikėjo apdoroti milžinišką srautą duomenų iš IoT įrenginių. Tuomet pirmą kartą susidūriau su realiu poreikiu pasirinkti tarp skirtingų message streaming platformų. Ir žinot ką? Tai nebuvo paprasta.
Message streaming platformos – tai tarsi labai galingos pašto sistemos, tik vietoj laiškų jos perduoda duomenis realiu laiku tarp skirtingų aplikacijų ir sistemų. Įsivaizduokite, kad turite e-komercijos svetainę: kiekvienas vartotojo veiksmas (paspaudimas, užsakymas, atsiliepimas) generuoja duomenis, kuriuos reikia perduoti į analitikos sistemą, inventoriaus valdymą, rekomendacijų variklį ir dar dešimt kitų vietų. Čia ir prasideda magija.
Šiandien rinkoje dominuoja du žaidėjai: Apache Kafka, kuri jau tapo beveik industrijos standartu, ir Apache Pulsar – jaunesnis, bet labai ambicingai besiveržiantis konkurentas. Abiejų tikslas tas pats, bet požiūris į problemą gana skirtingas. Pabandykime išsiaiškinti, kuris iš jų geriau tinka jūsų projektui.
Kafka: patikimas senbūvis su savo keistybėmis
Apache Kafka atsirado LinkedIn kompanijoje dar 2011 metais, ir nuo to laiko tapo faktiškai standartu streaming duomenų apdorojimui. Jei dirbate su duomenimis, greičiausiai jau girdėjote apie Kafka bent keliolika kartų.
Kafka architektūra paremta gana paprasta koncepcija: turite topics (temas), į kurias produceriai rašo žinutes, ir iš kurių consumeriai jas skaito. Kiekviena tema suskirstyta į partitions (skaideles), kurios leidžia horizontaliai plėsti sistemą. Skamba paprasta, bet velnias slypi detalėse.
Vienas didžiausių Kafka privalumų – jos ekosistema. Kafka Connect leidžia lengvai integruotis su daugybe duomenų šaltinių ir paskirčių vietų. Kafka Streams suteikia galimybę apdoroti duomenis realiu laiku be papildomų įrankių. O dokumentacijos ir community pagalbos rasite tiek, kad galėsite skaityti visą savaitę.
Tačiau Kafka turi ir savo skaudulius. Pirmiausia – operacinė sudėtingumas. Norėdami paleisti Kafka, jums reikės ZooKeeper (bent jau iki neseniai, naujesniose versijose jau galima be jo). Reikės suprasti, kaip veikia replication, kaip teisingai sukonfigūruoti retention policies, kaip monitorinti offset lag. Tai nėra „įdiek ir pamiršk” sprendimas.
Dar viena problema – multi-tenancy. Kafka nebuvo sukurta turint omenyje kelis nepriklausomus vartotojus toje pačioje klasteryje. Jei turite kelis komandas ar projektus, kurie nori naudoti tą pačią Kafka infrastruktūrą, pasiruoškite galvos skausmui su namespace’ais ir izoliavimu.
Pulsar: naujos kartos požiūris į streaming
Apache Pulsar atsirado Yahoo (dabar Verizon Media) 2016 metais ir nuo pat pradžių buvo projektuojamas kaip Kafka alternatyva, išsprendžianti daugelį jos trūkumų. Ir reikia pripažinti, kai kuriose srityse jiems tai pavyko.
Pagrindinė Pulsar architektūros ypatybė – tai storage ir serving sluoksnių atskyrimas. Kafka viskas yra viename – brokeriai tvarko ir duomenų saugojimą, ir jų teikimą. Pulsar naudoja Apache BookKeeper duomenų saugojimui, o brokeriai tik aptarnauja klientus. Skamba kaip smulkmena, bet tai leidžia daug lankščiau skalėti sistemą.
Praktiškai tai reiškia, kad galite pridėti naujų brokerių be duomenų perkėlimo. Galite atskirai skalėti storage ir compute. Tai ypač naudinga, kai turite labai nevienodus darbo krūvius – pavyzdžiui, dieną daug rašoma, o naktį daugiau skaitoma.
Multi-tenancy Pulsar yra first-class citizen. Galite turėti skirtingus tenant’us, kiekvienas su savo namespace’ais, kvotomis, autentifikacija. Tai puikiai tinka didelėms organizacijoms ar cloud provaideriams, kurie nori pasiūlyti streaming kaip paslaugą.
Dar vienas įdomus dalykas – Pulsar palaiko kelis subscription modelius iš dėžės: exclusive, shared, failover, key_shared. Kafka turi tik vieną būdą – consumer groups, ir jei jums reikia ko nors kito, teks improvizuoti.
Performance: kas greičiau ir efektyviau?
Čia prasideda įdomiausia dalis, nes atsakymas, kaip visada, yra „depends”. Bet pabandykime būti konkretesni.
Kafka throughput yra tikrai įspūdingas. Gerai sukonfigūruota Kafka gali apdoroti milijonus žinučių per sekundę. Tai pasiekiama dėl labai efektyvaus disko naudojimo – Kafka naudoja sequential I/O, kuris yra daug greitesnis už random I/O. Duomenys rašomi į append-only logą, ir OS page cache daro savo magiją.
Pulsar irgi nėra lėtas. Benchmark’ai rodo panašius ar net geresnius rezultatus tam tikruose scenarijuose. Bet čia svarbu suprasti, kad performance priklauso nuo use case. Jei turite daug mažų žinučių, Pulsar gali būti efektyvesnis dėl geresnio batching. Jei turite didelius burst’us, Kafka gali geriau susidoroti.
Vienas aspektas, kur Pulsar tikrai žiba – tai latency esant mažam throughput. Kai turite nedaug žinučių, bet joms reikia mažo latency, Pulsar architektūra su atskirtu storage leidžia pasiekti geresnius rezultatus. Tai svarbu, pavyzdžiui, finansinėse aplikacijose.
Svarbu paminėti ir storage efficiency. Kafka saugo duomenis kiekviename brokeryje, kuris turi tos partijos repliką. Pulsar su BookKeeper naudoja erasure coding, kuris leidžia pasiekti tą patį patikimumo lygį su mažesnėmis storage sąnaudomis. Jei saugote duomenis ilgai, tai gali sutaupyti nemažai pinigų.
Operacinis valdymas ir deployment
Čia Kafka ir Pulsar labai skiriasi, ir tai gali būti lemiamas faktorius jūsų pasirinkimui.
Kafka deployment’as yra santykinai paprastas koncepciniu lygmeniu, bet sudėtingas praktikoje. Jums reikia ZooKeeper cluster’io (arba KRaft mode naujose versijose), Kafka broker’ių, ir geros konfigūracijos. Problema ta, kad tų konfigūracijos parametrų yra šimtai, ir ne visi jie gerai dokumentuoti.
Viena iš didžiausių Kafka operacinių problemų – rebalancing. Kai pridedame naują brokerį ar išjungiame seną, partijos turi būti perskirstytos. Tai gali užtrukti valandas dideliems cluster’iams, ir per tą laiką performance gali nukentėti. Yra įrankiai kaip Cruise Control, kurie padeda, bet tai dar vienas dalykas, kurį reikia mokėti.
Pulsar deployment’as yra sudėtingesnis architektūriškai – jums reikia ir BookKeeper, ir Pulsar broker’ių, ir ZooKeeper. Bet paradoksaliai, operacinė našta gali būti mažesnė. Brokerius galima pridėti ar pašalinti be duomenų perkėlimo. Storage skalėjimas yra nepriklausomas.
Vienas dalykas, kuris man asmeniškai labai patinka Pulsar – tai geo-replication. Jis yra įtaisytas į platformą ir veikia labai gerai. Kafka geo-replication galimas su MirrorMaker, bet tai atskirai valdomas komponentas su savo quirks.
Ekosistema ir integracijos
Čia Kafka turi milžinišką pranašumą tiesiog dėl savo amžiaus ir populiarumo.
Kafka ekosistema yra neįtikėtinai turtinga. Kafka Connect turi šimtus connector’ių beveik bet kokiai sistemai, kurią galite įsivaizduoti. Nuo duomenų bazių iki cloud storage, nuo CRM sistemų iki analytics platform’ų. Greičiausiai, jei jums reikia integruotis su kažkuo, jau yra paruoštas connector’ius.
Kafka Streams ir ksqlDB leidžia apdoroti duomenis realiu laiku be papildomų framework’ų kaip Spark ar Flink. Schema Registry padeda valdyti duomenų schemas. Viskas gerai dokumentuota, yra daug pavyzdžių, tutorial’ų, blog post’ų.
Pulsar ekosistema auga, bet dar nėra tokia brandi. Pulsar Functions leidžia rašyti lightweight stream processing logiką, ir tai veikia gerai paprastiems use case’ams. Pulsar IO turi connector’ių, bet jų pasirinkimas mažesnis nei Kafka.
Tačiau Pulsar turi vieną įdomų privalumą – Pulsar Protocol Handler framework’as leidžia Pulsar kalbėti kitais protokolais. Yra oficialus Kafka protocol handler, kuris reiškia, kad galite naudoti Kafka klientus su Pulsar. Tai gali būti naudinga migracijos scenarijuose.
Kaina ir licensing
Abu projektai yra Apache 2.0 licensijuoti open source, tai puiku. Bet realios sąnaudos yra ne tik licensing.
Infrastructure sąnaudos gali skirtis. Kafka paprastai reikalauja mažiau komponentų (bent jau paprastam setup’ui), bet gali reikėti daugiau storage dėl replication modelio. Pulsar reikalauja daugiau komponentų, bet gali būti efektyvesnis storage naudojime.
Jei planuojate naudoti managed service, pasirinkimas yra platesnis Kafka. AWS MSK, Confluent Cloud, Azure Event Hubs (Kafka compatible), Aiven – pasirinkimų netrūksta. Pulsar managed services yra, bet jų mažiau: StreamNative Cloud, DataStax Astra Streaming.
Svarbu įvertinti ir operational costs – kiek žmonių valandų reikės sistemai palaikyti. Čia Kafka turi pranašumą, kad lengviau rasti žmonių su patirtimi. Pulsar specialistų rinkoje mažiau, tai gali reikšti didesnes sąnaudas mokymui ar samdymui.
Kada rinktis ką: praktiniai scenarijai ir rekomendacijos
Gerai, užteks teorijos. Pabandykime būti konkretūs ir praktiški.
Rinkitės Kafka, jei:
Jūsų organizacija jau turi Kafka patirties. Migracija nuo veikiančio sprendimo turi būti labai gerai pagrįsta, ir „naujesnis” nėra pakankamai geras argumentas.
Jums reikia turtingos ekosistemos ir daug integracijų. Jei planuojate naudoti daug skirtingų connector’ių, Kafka Connect biblioteka sutaupys jums labai daug laiko.
Turite paprastą use case su dideliu throughput. Jei jums tiesiog reikia perkelti daug duomenų iš A į B, Kafka tai daro puikiai ir be papildomų komplikacijų.
Jums svarbu community ir dokumentacija. Kai kažkas neveikia 2 AM, galimybė greitai rasti atsakymą Stack Overflow yra neįkainojama.
Rinkitės Pulsar, jei:
Kuriate multi-tenant platformą. Jei planuojate teikti streaming kaip paslaugą arba turite daug nepriklausomų komandų, Pulsar native multi-tenancy sutaupys daug skausmo.
Jums reikia geo-replication. Nors Kafka tai gali, Pulsar daro tai geriau ir paprasčiau.
Turite labai skirtingus workload’us ir jums reikia lankstumo skalėjime. Storage ir compute atskyrimas čia tikrai praverčia.
Jums svarbus low latency su mažu throughput. Finansinės aplikacijos, gaming, IoT scenarijai, kur kiekviena milisekundė svarbi.
Praktiniai patarimai prieš sprendimą:
Pirma, padarykite proof of concept su savo realiais duomenimis. Benchmark’ai iš interneto yra įdomūs, bet jūsų duomenys ir use case yra unikalūs. Paleiskite abu sprendimus test environment’e ir pamatysite, kaip jie elgiasi su jūsų workload.
Antra, įvertinkite team expertise. Geriausias technologinis sprendimas, kurio niekas jūsų komandoje nemoka, yra blogesnis už vidutinį sprendimą, kurį visi supranta.
Trečia, pagalvokite apie ilgalaikę perspektyvą. Streaming platforma nėra kažkas, ką keisi kas metus. Tai core infrastructure, kuri bus su jumis ilgai. Ar jūsų pasirinkimas skalėsis kartu su verslu?
Ketvirta, nepamirškit monitoring ir observability. Bet kurį sprendimą pasirinksite, jums reikės gero monitoring. Kafka turi Prometheus exporters, JMX metrics, daug įrankių. Pulsar irgi turi, bet ekosistema mažesnė. Įsitikinkite, kad galėsite matyti, kas vyksta sistemoje.
Galiausiai, jei vis dar negalite apsispręsti – pradėkite nuo Kafka. Ji labiau battle-tested, turi didesnę community, ir yra safer choice. Pulsar yra įdomus ir technologiškai pažangesnis, bet Kafka vis dar yra industrijos standartas ne be priežasties. Galite migruoti vėliau, jei tikrai reikės.
Ir dar vienas dalykas – nebijokite eksperimentuoti. Technologijos keičiasi, ir tai, kas buvo tiesa prieš metus, gali būti pasenę dabar. Sekite abu projektus, skaitykite release notes, dalyvaukite community. Geriausias sprendimas yra informuotas sprendimas.
