Kas ta Apache Pulsar ir kodėl apie ją verta žinoti
Jei dirbi su duomenų srautais, mikroservisais ar tiesiog domies paskirstytomis sistemomis, turbūt jau esi girdėjęs apie Apache Kafka. Bet štai Apache Pulsar – tai platforma, kuri pastaraisiais metais vis labiau traukia dėmesį ir ne be reikalo. Ši messaging sistema atsirado Yahoo! laboratorijose 2013 metais, o 2016-aisiais tapo Apache Software Foundation inkubatoriaus projektu.
Pulsar sukurtas spręsti problemas, su kuriomis susiduria tradicinės messaging sistemos, kai reikia apdoroti milžiniškus duomenų kiekius realiu laiku. Skirtingai nei kitos panašios platformos, Pulsar nuo pat pradžių buvo projektuojamas kaip multi-tenant sistema su natūraliu geografiniu replikavimo palaikymu. Tai reiškia, kad viena Pulsar instancija gali aptarnauti kelis projektus ar komandas, kiekviena turėdama savo izoliuotą erdvę.
Įdomu tai, kad Pulsar sujungia du skirtingus messaging modelius – tradicinį publish-subscribe ir message queuing. Tai suteikia lankstumo, kurio trūksta daugeliui konkurentų. Galima sakyti, kad Pulsar bando būti ir streaming platforma, ir message broker viename pakete.
Architektūra: kaip tai veikia po gaubtu
Pulsar architektūra tikrai skiriasi nuo to, prie ko įpratę Kafka vartotojai. Vienas svarbiausių skirtumų – tai storage ir serving sluoksnių atskyrimas. Pulsar naudoja Apache BookKeeper kaip savo persistence sluoksnį, o brokeriai lieka stateless. Ką tai reiškia praktiškai? Tai reiškia, kad galite lengvai pridėti ar pašalinti brokerius neprarasdami duomenų ir nesukeldami downtime.
BookKeeper yra atsakingas už duomenų saugojimą ir replikavimą. Jis garantuoja, kad jūsų žinutės bus patikimai išsaugotos net jei keletas mazgų sugenda. Tuo tarpu brokeriai tiesiog tvarko žinučių maršrutizavimą tarp produserių ir konsumerių. Toks atskyrimas leidžia kiekvieną komponentą skaluoti nepriklausomai.
Pulsar naudoja hierarchinę namespace struktūrą: tenant → namespace → topic. Tai labai patogu, kai turite daug skirtingų projektų ar komandų. Kiekvienas tenant gali turėti savo autentifikacijos taisykles, resource quotas ir konfigūraciją. Namespace lygmenyje galite nustatyti retention policies, replication strategijas ir kitus parametrus.
Dar vienas įdomus dalykas – Pulsar naudoja segment-based storage. Kiekvienas topic’as yra skaidomas į segmentus, kurie paskirstomi per BookKeeper mazgus. Tai leidžia efektyviai valdyti storage ir greitai atsikurti po gedimų. Jei vienas BookKeeper mazgas sugenda, tik nedidelė duomenų dalis turi būti atkurta iš kitų replikų.
Subscription modeliai ir jų panaudojimas
Čia Pulsar tikrai šviečia. Sistema palaiko keturis skirtingus subscription tipus, ir kiekvienas turi savo use case’us. Exclusive subscription – tai klasikinis modelis, kur tik vienas consumeris gali skaityti iš topic’o. Naudinga, kai reikia garantuoti griežtą žinučių tvarką ir nenorite dublikatų.
Failover subscription leidžia turėti kelis consumerius, bet aktyvus bus tik vienas. Kiti laukia kaip backup. Jei pagrindinis consumeris sugenda, kitas automatiškai perima darbą. Tai puikus pasirinkimas high-availability scenarijams, kai negalite sau leisti prarasti žinučių apdorojimo.
Shared subscription – čia jau prasideda įdomesni dalykai. Keletas consumerių gali vienu metu skaityti iš to paties subscription, o žinutės paskirstomos round-robin principu. Tvarka nėra garantuojama, bet galite lengvai skaluoti apdorojimą horizontaliai. Idealus variantas, kai turite daug žinučių ir kiekviena gali būti apdorota nepriklausomai.
Key_shared subscription – tai naujesnis papildymas, kuris sujungia abiejų pasaulių privalumus. Žinutės su tuo pačiu key visada eina tam pačiam consumeriui, o skirtingi key’ai gali būti apdorojami lygiagrečiai. Tai puikiai tinka, kai reikia išlaikyti tvarką per-entity lygmenyje, bet vis tiek norite paralelizmo.
Functions ir Pulsar IO: integruota stream processing
Vienas iš dalykų, kuris Pulsar išskiria iš minios – tai integruotas stream processing funkcionalumas. Pulsar Functions leidžia rašyti paprastas data processing logikos dalis tiesiog Java, Python ar Go kalbomis ir deploy’inti jas tiesiai į Pulsar cluster’į. Nereikia jokio Flink ar Spark – visa infrastruktūra jau yra.
Pavyzdžiui, galite parašyti funkciją, kuri filtruoja žinutes, transformuoja duomenis ar net daro aggregacijas. Funkcija gali skaityti iš vieno ar kelių topic’ų ir rašyti rezultatus į kitus. Pulsar automatiškai tvarko scaling, fault tolerance ir state management. Tai labai patogu paprastoms ETL operacijoms ar real-time duomenų apdorojimui.
Pulsar IO – tai connector’ių sistema, kuri leidžia integruotis su išorinėmis sistemomis. Yra built-in connector’ių Kafka, RabbitMQ, Cassandra, Elasticsearch ir daugeliui kitų populiarių platformų. Source connector’iai traukia duomenis į Pulsar, o sink connector’iai stumia duomenis iš Pulsar į kitas sistemas.
Praktiškai tai reiškia, kad galite sukurti data pipeline’ą be papildomo kodo. Pavyzdžiui, galite skaityti duomenis iš Kafka topic’o, apdoroti juos su Pulsar Function ir rezultatus įrašyti į Elasticsearch. Visa tai konfigūruojama per YAML failus ar REST API.
Multi-tenancy ir security: ne tik buzzword’ai
Pulsar multi-tenancy nėra tik marketing’o terminas – tai tikrai veikianti funkcija. Kiekvienas tenant turi savo izoliuotą namespace’ą su atskiromis authentication ir authorization taisyklėmis. Galite nustatyti resource quotas, kad vienas tenant’as nesuėstų visų cluster’io resursų.
Authentication palaiko kelis mechanizmus: TLS client certificates, JWT tokens, Kerberos, OAuth 2.0. Tai leidžia integruotis su jūsų esamomis identity management sistemomis. Authorization veikia role-based principu – galite suteikti produce, consume ar admin teises konkretiems vartotojams ar aplikacijoms.
Encryption palaikomas tiek transport, tiek storage lygmenyje. TLS užtikrina, kad duomenys kelionėje tarp komponentų yra šifruoti. O jei reikia, galite įjungti end-to-end encryption, kur žinutės šifruojamos produserio pusėje ir dešifruojamos tik konsumerio pusėje. Pulsar tik saugo šifruotus duomenis nežinodamas rakto.
Dar vienas svarbus aspektas – audit logging. Pulsar gali loginti visas svarbias operacijas: kas sukūrė topic’ą, kas pakeitė konfigūraciją, kas skaitė ar rašė žinutes. Tai būtina reguliuojamose industrijose, kur reikia atitikti compliance reikalavimus.
Geo-replication: duomenys keliose lokacijose
Pulsar geo-replication funkcionalumas yra vienas iš stipriausių jo pusių. Galite turėti cluster’ius skirtinguose regionuose ar net žemynuose, ir Pulsar automatiškai replikuos duomenis tarp jų. Tai ne tik disaster recovery – tai pilnavertis multi-datacenter deployment modelis.
Replikacija konfigūruojama namespace lygmenyje. Galite nurodyti, į kuriuos cluster’ius norite replikuoti konkrečius topic’us. Pulsar palaiko tiek synchronous, tiek asynchronous replikaciją. Synchronous lėtesnė, bet garantuoja, kad duomenys yra keliose vietose prieš patvirtinant produserį. Asynchronous greitesnė, bet yra mažas lag’as tarp regionų.
Įdomu tai, kad Pulsar leidžia produserti ir konsumerti iš bet kurio cluster’io. Jei turite aplikaciją Europoje ir Azijoje, abi gali rašyti į savo lokalius cluster’ius, o duomenys automatiškai sinchronizuojasi. Tai sumažina latency ir pagerina user experience.
Conflict resolution Pulsar’e yra gana paprastas – paskutinė žinutė laimi. Tai veikia gerai daugumai use case’ų, bet jei reikia sudėtingesnės logikos, galite implementuoti ją application lygmenyje naudojant Pulsar Functions.
Performance ir skalabilumas: skaičiai ir faktai
Pulsar performance metrikų yra įspūdingos. Yahoo! (dabar Verizon Media) naudoja Pulsar production’e ir tvarko daugiau nei milijoną topic’ų su milijardais žinučių per dieną. Latency paprastai yra 5-15 milisekundžių range’e, kas yra labai gera streaming platformai.
Throughput priklauso nuo daugelio faktorių – hardware, network, konfigūracijos. Bet tipiškai vienas broker’is gali tvarkyti 100K-200K žinučių per sekundę. O kadangi brokeriai yra stateless, galite pridėti tiek, kiek reikia. Kai kurie vartotojai reportuoja cluster’ius, kurie tvarko milijonus žinučių per sekundę.
Storage skalabilumas irgi įspūdingas. Kadangi Pulsar naudoja BookKeeper, galite saugoti terabyte’us ar net petabyte’us duomenų. Retention policies leidžia kontroliuoti, kiek ilgai saugoti žinutes. Galite nustatyti time-based (pvz., 7 dienos) ar size-based (pvz., 1TB) limitus.
Vienas dalykas, kurį reikia turėti omenyje – Pulsar nėra lengviausias setup’inti. Jums reikia tvarkyti ne tik brokerius, bet ir BookKeeper, ZooKeeper (nors naujesnės versijos gali naudoti etcd). Tai daugiau moving parts nei, pavyzdžiui, Kafka. Bet kai viskas veikia, sistema yra labai stabili ir lengvai valdoma.
Kada rinktis Pulsar ir kaip pradėti
Pulsar nėra silver bullet, bet yra scenarijai, kur jis tikrai šviečia. Jei jums reikia multi-tenancy, Pulsar yra akivaizdus pasirinkimas. Jei planuojate multi-region deployment su aktyvia-aktyvia replikacija, Pulsar tai palaiko iš dėžės. Jei norite unified platformos streaming ir messaging workload’ams, Pulsar gali būti tas, ko ieškote.
Pradėti galite su standalone mode, kur viskas veikia vienoje JVM. Tai puiku development’ui ir testavimui. Docker image’ai irgi prieinami, galite pakelti visą cluster’į su docker-compose per kelias minutes. Yra oficialūs Helm charts Kubernetes deployment’ui, kas labai palengvina production setup’ą.
Dokumentacija yra gana gera, nors kartais trūksta praktinių pavyzdžių. Community aktyvus, yra Slack channel’as ir mailing list’ai, kur galite gauti pagalbos. Apache Pulsar Summit vyksta kasmet ir ten galite išgirsti real-world use case’us iš įmonių kaip Yahoo!, Splunk, Tencent.
Jei migruojate iš Kafka, yra Kafka-on-Pulsar projektas (KoP), kuris leidžia naudoti Kafka client’us su Pulsar backend’u. Tai gali būti geras pirmasis žingsnis – galite išbandyti Pulsar be aplikacijų przepisymo. Vėliau galite pereiti prie native Pulsar client’ų ir pasinaudoti visomis funkcijomis.
Kalbant apie client’us – Pulsar palaiko Java, Python, Go, C++, Node.js, C#. Visi client’ai palaiko pagrindines funkcijas, nors Java client’as paprastai būna most feature-complete. Jei jūsų kalba nepalaikoma, galite naudoti REST API ar WebSocket, nors tai bus lėčiau.
Monitoring ir observability yra svarbu bet kuriai distributed sistemai. Pulsar exportuoja metricas Prometheus formatu, tad galite lengvai integruotis su Grafana. Yra community dashboard’ų, kurie rodo pagrindinius metrics – throughput, latency, storage usage, replication lag. Pulsar Manager – tai web UI, kuri leidžia valdyti cluster’į, topic’us, subscriptions per browser’į.
Kaina irgi svarbus faktorius. Jei self-host’inate, pagrindinis cost’as bus infrastructure – serveriai, storage, network. Pulsar gali būti brangiau deploy’inti nei Kafka dėl daugiau komponentų, bet operacinis efektyvumas gali kompensuoti tai. Yra ir managed service’ų – StreamNative Cloud, DataStax Astra Streaming – kur mokate už consumption ir neturite galvos skausmo su infrastructure.
Taigi, Apache Pulsar yra brandus, production-ready messaging sistema su unikaliomis funkcijomis. Ji gali būti ne pati paprasčiausia pradėti, bet jei jūsų use case’as atitinka jos stipriąsias puses, investicija tikrai atsipirks. Streaming pasaulis nėra vieno dydžio visiems, ir gerai, kad turime tokių alternatyvų kaip Pulsar, kurios stumia industriją į priekį.
