Kafka tapo atvirojo kodo pasirinkimo ramsčiu, skirtu valdyti didžiulius įvykių srautus. Iššūkis yra tobulinti įrankius ir patobulinti žaidimo saugumą ne tik pagrindinį autentifikavimą.
„Hadoop“ ir didelių duomenų platformos iš pradžių buvo žinomos dėl masto, o ne dėl greičio. Tačiau didelio našumo skaičiavimo variklių, tokių kaip „Spark“ ir srautinio perdavimo varikliai, atsiradimas leido sujungti paketinį ir realiojo laiko apdorojimą.
Bet kas atsitinka, kai jūsų potraukis dideliems duomenims apima daugybę šaltinių ir kiekius, kurie atspindi viešosios svetainės srautą? Arba kaip elgtis su IoT pasauliu? Esamos „Hadoop“ projekto komunalinės paslaugos, tokios kaip „Flume“, buvo nustatytos srautams po vieną perduoti į HDFS kaip bendrą tikslą.
„LinkedIn“ susidūrė su šia problema dar 2009 metais kai norėjo detalesnio, realiuoju laiku veikiančio sprendimo, skirto naudotojų elgsenai savo svetainėje stebėti. Problema buvo ta, kad esamos atvirojo kodo pranešimų alternatyvos kaip RabbitMQ ir ActiveMQ
tiesiog nesumažėjo. Vietoj to, „LinkedIn“ pakeitė nusistovėjusią technologijų modelį: publikuoti / prenumeruoti (PubSub) pranešimų siuntimas.„PubSub“ pranešimų sistemos, sukurtos dar devintojo dešimtmečio pradžioje, buvo laikomos klijais, leidžiančiais įmonėms prijungti naujas priekines sistemas su nekilnojamuoju paveldėtu pagrindiniu finansiniu ar sandoriu sistemos. Paprastai jie buvo laikomi paprastesniais, palyginti su sudėtingesniais įmonės programų integravimas schemos. „PubSub“ yra technologija Tibco gimė.
„LinkedIn“ Kafka buvo rezultatas. Tai užtrunka „PubSub“ pranešimų siuntimą ir jį labai padidina; jis gali laikyti ir platinti pranešimus, gaunamus iki milijonų įrašų per sekundę. Duomenų srautai yra suskirstyti į temas, susijusias su konkrečiomis veiklos rūšimis, objektais ar kategorijomis. Skirtingai nuo srautinio perdavimo sistemų, Kafka nefiltruoja pranešimų ar įrašų ir skirtingai nuo senų pranešimų sistemų, pvz. IBM MQ, nevykdo maršruto parinkimo. Bet jei turite gaisrinę žarną, su kuria susitvarkysite, Kafka yra jūsų kūdikis.
Įprastas Kafka naudojimo atvejis yra susijęs su tiesioginiu stebėjimu, pvz., svetainės veiklos ir naudotojų elgsenos stebėjimu. Tačiau naudojimo atvejis, atveriantis Kafkos lauką, yra tas pats, dėl kurio daugumos organizacijų srautas taip pat išryškėjo: viskas, kas susiję su daiktų internetu. Be to, „Kafka“ gali būti naudinga apdorojant realaus laiko įrašus (arba įvykius) įvairiuose scenarijuose, pradedant tiekimo grandinės optimizavimu ir baigiant viešojo sektoriaus naudojimo atvejais, pvz., mokesčių įvykdymo realiuoju laiku.
Kadangi Kafka siejama su judančiais duomenimis, ji dažnai painiojama su srautinio perdavimo varikliais. Tačiau Kafka veikia kaip eismo policininkas, tarnaujantis kaip srauto perdavimo taškas arba perdavimo taškas į srautą.
Tačiau iššūkis yra tas, kad Kafka, kaip atvirojo kodo technologija, yra gana nuogas. Pagrindinėje atvirojo kodo technologijoje trūksta vizualinio kūrimo, konfigūravimo ir stebėjimo aplinkų, kurios būtų būtinos norint plačiai pritaikyti įmonėje.
Susiliejantis yra išimtis, kuri patvirtina taisyklę; tai nušlifuota vizualinė priekinė dalis ir valdymo mazgas, skirtas įmonės vartojimui. Tai apima an integracijos sistema kuri apima sertifikuotas jungtis prie kelių dešimčių duomenų bazių, srautinio perdavimo variklių ir saugyklų telkinių bei API, skirtus tinkintoms jungtims kurti; a valdymo pultas kuri užtikrina išsamesnį operacijų matomumą, palyginti su bendrosios paskirties Hadoop stiklo ekranais; ir savo srautinio perdavimo API, tik tuo atveju, jei norite, kad visą integravimą ir srauto apdorojimą atliktų vienas centras.
Tiesą sakant, Kafkos konkurencija yra ne kitos pranešimų magistralės, o platformos, kurios atlieka daugiau duomenų srautų integravimo ir nukreipimo paskesnio darbo. Savo ruožtu „Confluent“ konkurencija yra platformos, kurios prie pagrindinės pranešimų dalies prideda supančias integracijos, analizės ir programų kūrimo funkcijas.
Taigi, nors dauguma „Hadoop“ platformų, NoSQL duomenų bazių ir debesies paslaugų palaiko „Kafka“, daugelis jų siūlo konkuruojančias valdomas paslaugas. Amazon Kinezė yra paslauga, kuri valdo duomenų perdavimą ir suteikia aplinką srautinio duomenų perdavimo programoms kurti ir SQL užklausoms formuoti. Kad nebūtų pralenktas, „Google“ debesies duomenų srautas suteikia valdomą aplinką, skirtą teikti paslaugas, būtinas srautinio perdavimo ir paketinių programų, atliekamų duomenų vamzdynuose, palaikymui; į Apache Beam projektas perima API iš šios paslaugos, kad galėtumėte derinti skirtingus komponentus, įskaitant pranešimų siuntimą pagal bendrą programavimo modelį.
„Hadoop“ pusėje MapR srautai one-ups Confluent perkeldamas pranešimų tarpininkavimą tiesiai į Hadoop klasterį (kuris MapR palaipsniui keičiasi kaip platesnė didelių duomenų saugojimo ir taikomųjų programų platforma). Tuo tarpu „Hortonworks“ duomenų srautas tiesiogiai nekonkuruoja su Kafka (jį gali maitinti Kafka), bet teikia paslaugas, skirtas valdyti duomenų integravimą ir srautą pasroviui.
„Kafka“ sukūrė plačią komercinės paramos ekosistemą ir, pasak „Confluent“, maždaug trečdalis „Fortune 500“ jau naudoja ją. Tačiau, kad Kafka įgytų pagrindinį patrauklumą, reikalinga platesnė įrankių ekosistema; Be Confluent pasiūlymo, valdymo įrankiai yra elementarūs. Kaip „Netflix“ patirtis rodo, vis dar kyla problemų, jei norite įdiegti „Kafka“ itin dideliu mastu debesyje.
Be to, saugumas autentifikavimo palaikymo forma Kafka atsirado tik neseniai. Kaip „Hadoop“ teikėjai patobulino savo žaidimą su papildoma vaidmenimis pagrįsta prieiga ir linija, „Kafka“ reikalauja aukštesnio lygio galimybių, kurios padės saugą lengviau valdyti, ypač plečiantis naudotojų grupėms, kad galėtų pasinaudoti didžiuliais duomenų srautais, kuriuos šis mažas PubSub variklis galėtų pristato.