Verslo intelekto realiuoju laiku idėja egzistuoja kurį laiką (žr. „Wikipedia“ puslapį šia tema, pradėtą 2006 m.). Tačiau nors žmonės daugelį metų kalbėjo apie šią idėją, nemačiau, kad daugelis įmonių iš tikrųjų pritaria vizijai, o tuo labiau nesuvokia jos teikiamų pranašumų.
Bent dalis priežasties yra tai, kad nėra įrankių BI ir analizės diegimui realiuoju laiku. Tradicinė duomenų saugojimo aplinka buvo labai orientuota į paketines operacijas su itin dideliais vėlavimo laikais, buvo nepaprastai brangi arba tiek.
Norėdami tai pakeisti, atsirado daug galingų, lengvai naudojamų atvirojo kodo platformų. Du žymiausi yra „Apache Storm“ ir „Apache Spark“, kurie realiuoju laiku siūlo daug platesnių potencialių vartotojų rato apdorojimo galimybes. Abu projektai yra „Apache Software Foundation“ projektai, ir nors šie du įrankiai suteikia galimybių sutapti, kiekvienas iš jų turi išskirtinių funkcijų ir vaidmenų.
Audra: realaus laiko apdorojimo Hadoopas
„Storm“, platinama įvykių srautų apdorojimo skaičiavimo sistema, pradėjo savo veiklą kaip „BackType“, rinkodaros žvalgybos įmonės, kurią „Twitter“ įsigijo 2011 m., Projektas. „Twitter“ netrukus atidarė projektą ir įdėjo jį į „GitHub“, tačiau „Storm“ galiausiai persikėlė į „Apache“ inkubatorių. ir tapo „Apache“ aukščiausio lygio projektu 2014 m. rugsėjo mėn.
„Storm“ kartais vadinama realaus laiko apdorojimo Hadoopu. Atrodo, kad „Storm“ dokumentai sutinka: „„ Storm “leidžia lengvai patikimai apdoroti neribotus duomenų srautus, realiuoju laiku apdorojant tai, ką Hadoopas darė paketiniam apdorojimui“.
Siekdamas šio tikslo, „Storm“ yra sukurtas dideliam masteliui, palaiko atsparumą triktims, taikydamas procesus „greitai nepavyksta, automatiškai iš naujo paleisdamas“, ir suteikia tvirtą garantiją, kad bus apdorojami visi paketai. Pagal „Storm“ numatytoji pranešimų garantija yra „bent kartą“, tačiau taip pat suteikiama galimybė įgyvendinti „tiksliai vieną kartą“ apdorojimą.
„Storm“ pirmiausia rašoma „Clojure“ ir yra skirta palaikyti „snapelius“ (pagalvokite apie įvesties srautus) ir „varžtus“ (apdorojimo ir išvesties modulius) kartu kaip nukreiptą aciklinį grafiką (DAG), vadinamą topologija. „Storm“ topologijos veikia grupėse, o „Storm“ tvarkaraštis paskirsto darbą mazgams aplink grupę, remdamasis topologijos konfigūracija.
Galite galvoti apie topologijas, kurios yra maždaug analogiškos „MapReduce“ užduotims „Hadoop“, išskyrus tai, kad atsižvelgiant į tai, kad „Storm“ daugiausia dėmesio skiria realiuoju laiku, srautu pagrįstam apdorojimui, numatytosios topologijos veikia visam laikui arba tol, kol bus nutrauktos rankiniu būdu. Paleidus topologiją, snapeliai atneša duomenis į sistemą ir perduoda duomenis varžtams (kurie savo ruožtu gali perduoti duomenis kitiems varžtams), kur atliekamas pagrindinis skaičiavimo darbas. Vykstant apdorojimui, vienas ar keli varžtai gali įrašyti duomenis į duomenų bazę ar failų sistemą, siųsti pranešimą į kitą išorinę sistemą ar kitaip padaryti skaičiavimo rezultatus prieinamus vartotojams.
Viena iš „Storm“ ekosistemos stipriųjų pusių yra gausus turimų snapelių rinkinys, kuris specializuojasi duomenims gauti iš visų tipų šaltinių. Nors jums gali tekti rašyti specialius snapelius labai specializuotoms programoms, yra didelė tikimybė, kad galite rasti esamą snapelį neįtikėtinai daugybei šaltinių - nuo „Twitter“ srautinio perdavimo API iki „Apache Kafka“ iki JMS brokerių iki visko, kas yra tarp jų.
Adapteriai egzistuoja, kad būtų paprasta integruoti su HDFS failų sistemomis, o tai reiškia, kad „Storm“ prireikus gali lengvai sąveikauti su „Hadoop“. Dar viena „Storm“ stiprybė yra parama daugiakalbiam programavimui. Nors pati „Storm“ yra pagrįsta „Clojure“ ir veikia JVM, snapelius ir varžtus galima rašyti beveik bet kokia kalba, įskaitant ir ne JVM kalbas, kurios naudojasi protokolo pranašumais bendravimui tarp komponentų naudojant JSON per stdin / stdout.
Trumpai tariant, „Storm“ yra labai keičiama, greita, tolerantiška gedimams atvirojo kodo sistema paskirstytam skaičiavimui, ypatingą dėmesį skiriant srauto apdorojimui. „Storm“ puikiai tinka įvykių apdorojimui ir inkrementiniam skaičiavimui, skaičiuojant slenkančią metriką realiuoju laiku per duomenų srautus. Nors „Storm“ taip pat teikia primityvų funkciją, leidžiančią generuoti paskirstytą RPC, ir teoriškai gali būti naudojama beveik bet kokiam paskirstytam skaičiavimo darbui surinkti, jos stiprybė aiškiai yra įvykių srauto apdorojimas.
„Spark“: paskirstytas apdorojimas visiems
Kitas „Spark“ projektas, tinkamas paskirstytam skaičiavimui realiu laiku, prasidėjo kaip AMPLab projektas Kalifornijos universitete Berklyje prieš prisijungiant prie „Apache“ inkubatoriaus ir 2014 m. Vasario mėn. Baigiant aukščiausio lygio projektu. Kaip ir „Storm“, „Spark“ palaiko srautą orientuotas apdorojimas, bet tai daugiau bendros paskirties paskirstytos skaičiavimo platformos.
Taigi „Spark“ gali būti vertinamas kaip potencialus „Hadoop“ „MapReduce“ funkcijų pakaitalas, o „Spark“ turi galimybę veikti esamo „Hadoop“ klasterio viršuje, išteklių planavimui pasikliaudama „YARN“. Be „Hadoop YARN“, „Spark“ gali susidėti ant „Mesos“ viršaus, kad būtų galima planuoti, arba paleisti kaip atskirą grupę, naudodamas savo įmontuotą tvarkaraštį. Atkreipkite dėmesį, kad jei „Spark“ nenaudojamas kartu su „Hadoop“, vis tiek reikalinga tam tikros rūšies tinklo / paskirstyta failų sistema (NFS, AFS ir pan.), Jei ji veikia klasteryje, todėl kiekvienas mazgas turės prieigą prie pagrindinių duomenų.
„Spark“ yra parašyta „Scala“ ir, kaip ir „Storm“, palaiko daugiakalbį programavimą, nors „Spark“ teikia specifinį API palaikymą tik „Scala“, „Java“ ir „Python“. „Spark“ neturi specifinio „snapelio“ abstrakcijos, tačiau jame yra adapteriai, skirti dirbti su duomenimis, saugomais daugybėje skirtingų šaltinių, įskaitant HDFS failus, „Cassandra“, „HBase“ ir S3.
Kur „Spark“ šviečia, tai palaiko kelias apdorojimo paradigmas ir jas palaikančias bibliotekas. Taip, „Spark“ palaiko srautinio perdavimo modelį, tačiau šį palaikymą teikia tik vienas iš kelių „Spark“ modulių, įskaitant specialiai sukurtus modulius, skirtus SQL prieigai, grafiko operacijoms ir mašininiam mokymuisi, kartu su srauto apdorojimu.
„Spark“ taip pat suteikia itin patogų interaktyvų apvalkalą, leidžiantį greitai ir nešvariai kurti prototipus ir tiriamąją informaciją realiuoju laiku analizuoti naudojant „Scala“ arba „Python“ API. Dirbdami interaktyviame apvalkale, greitai pastebite dar vieną svarbų skirtumą tarp „Spark“ ir „Storm“: „Spark“ yra labiau „funkcinio“ skonio, kai darbas su API labiau priklauso nuo grandininių nuoseklių metodinių iškvietimų, kad būtų galima primityviai atlikti operacijas, o ne „Storm“ modelis, kurį paprastai lemia kuriant klases ir diegiant sąsajas. Nei vienas, nei kitas požiūris nėra geresnis ar blogesnis, tačiau jūsų pageidaujamas stilius gali turėti įtakos jūsų sprendimui, kuri sistema labiau tinka jūsų poreikiams.
Kaip ir „Storm“, „Spark“ yra sukurtas dideliam masteliui pritaikyti, o „Spark“ komanda dokumentavo sistemos vartotojus, kuriuose veikia tūkstančiai mazgų. Be to, „Spark“ laimėjo neseniai vykusį 2014 m. „Daytona GraySort“ konkursą, kuris pasirodė tinkamiausiu metu, kai darbo krūvis tenka surenkant 100 TB duomenų. „Spark“ komanda taip pat dokumentuoja „Spark ETL“ operacijas su daugelio „Petabyte“ diapazono gamybos krūviais.
„Spark“ yra greita, keičiamo dydžio ir lanksti atvirojo kodo paskirstyto skaičiavimo platforma, suderinama su „Hadoop“ ir „Mesos“, palaikanti kelis skaičiavimo modelius, įskaitant srautinį perdavimą, į diagramas orientuotas operacijas, SQL prieigą ir paskirstytą mašininį mokymąsi. Įrodyta, kad „Spark“ skalė yra išskirtinai gera, ir, kaip ir „Storm“, tai yra puiki platforma, kuriant realaus laiko analizės ir verslo žvalgybos sistemą.
Priimdamas savo sprendimą
Kaip pasirinkti tarp „Storm“ ir „Spark“?
Jei jūsų reikalavimai visų pirma skirti srauto apdorojimui ir CEP stiliaus apdorojimui, o jūs pradedate žaliojo lauko projektą su specialiai sukurtu projekto klasteriu, aš tikriausiai palinkėčiau „Storm“ - ypač kai yra esamų „Storm“ snapelių, atitinkančių jūsų integracijos reikalavimus. . Tai anaiptol nėra griežta ir greita taisyklė, tačiau tokie veiksniai bent jau siūlytų pradėti nuo „Storm“.
Kita vertus, jei naudojate esamą „Hadoop“ arba „Mesos“ klasterį ir (arba) jei jūsų apdorojimo poreikiai apima didelius grafiko apdorojimo, SQL prieigos ar paketinio apdorojimo reikalavimus, pirmiausia norėtumėte pažvelgti į „Spark“.
Kitas veiksnys, į kurį reikia atsižvelgti, yra daugiakalbis dviejų sistemų palaikymas. Pavyzdžiui, jei jums reikia panaudoti kodą, parašytą R ar bet kuria kita kalba, kurios natūraliai nepalaiko „Spark“, tada „Storm“ pranašumas yra platesnis kalbų palaikymas. Tuo pačiu principu, jei turite turėti interaktyvų apvalkalą duomenims tirti naudojant API skambučius, tada „Spark“ siūlo funkciją, kurios „Storm“ neturi.
Galų gale, prieš priimdami galutinį sprendimą, tikriausiai norėsite atlikti išsamią abiejų platformų analizę. Aš rekomenduoju naudoti abi platformas, kad sukurtumėte nedidelį koncepcijos įrodymą - tada atlikite savo etalonus naudodami darbo krūvį, kuris kuo tiksliau atspindi jūsų numatomus darbo krūvius, prieš visiškai įsipareigodami.
Žinoma, nereikia priimti nei vieno, nei kito sprendimo. Atsižvelgiant į jūsų darbo krūvį, infrastruktūrą ir reikalavimus, galite pastebėti, kad idealus sprendimas yra „Storm“ ir „Spark“ mišinys kartu su kitais įrankiais, tokiais kaip „Kafka“, „Hadoop“, „Flume“ ir kt. Čia slypi atvirojo kodo grožis.
Nepriklausomai nuo pasirinkto maršruto, šie įrankiai rodo, kad realaus laiko BI žaidimas pasikeitė. Galingas galimybes, kurias kadaise galėjo įsigyti tik nedaugelis elitų, dabar gali pasiekti dauguma, jei ne visos, vidutinio dydžio organizacijos. Pasinaudokite jais.
