Ideen om realtids business intelligence har eksisteret i et stykke tid (se Wikipedia-siden om emnet, der blev påbegyndt i 2006). Men mens folk har talt om ideen i årevis, har jeg ikke set mange virksomheder faktisk omfavne visionen, og langt mindre indse de fordele, den muliggør.
I det mindste en del af årsagen har været manglen på værktøj til implementering af BI og analyse i realtid. Traditionelle datalagermiljøer var stærkt orienteret mod batchoperationer med ekstremt høje latenstider, var utroligt dyre eller begge dele.
Et antal magtfulde, brugervenlige open source-platforme er opstået for at ændre dette. To af de mest bemærkelsesværdige er Apache Storm og Apache Spark, som tilbyder behandlingsfunktioner i realtid til en meget bredere vifte af potentielle brugere. Begge er projekter inden for Apache Software Foundation, og mens de to værktøjer giver overlappende muligheder, har de hver især særpræg og roller at spille.
Storm: Hadoop af realtidsbehandling
Storm, en distribueret beregningsramme til behandling af begivenhedsstrømme, begyndte livet som et projekt fra BackType, et marketingintelligentfirma, der blev købt af Twitter i 2011. Twitter åbnede snart projektet og satte det på GitHub, men Storm flyttede til sidst til Apache Incubator. og blev et Apache-topniveau-projekt i september 2014.
Storm er undertiden blevet kaldt Hadoop til realtidsbehandling. Storm-dokumentationen ser ud til at være enig: "Storm gør det let at behandle ubegrænsede datastrømme pålideligt, hvilket gør realtidsbehandling, hvad Hadoop gjorde for batchbehandling."
For at nå dette mål er Storm designet til massiv skalerbarhed, understøtter fejltolerance med en “fail hurtigt, automatisk genstart” tilgang til processer og tilbyder en stærk garanti for, at hver tuple bliver behandlet. Storm er som standard en "mindst en gang" garanti for meddelelser, men tilbyder også muligheden for at implementere "nøjagtigt en gang" behandling.
Storm er primært skrevet i Clojure og er designet til at understøtte ledningsnet "tud" (tænk inputstrømme) og "bolte" (processerings- og outputmoduler) sammen som en rettet acyklisk graf (DAG) kaldet en topologi. Stormtopologier kører på klynger, og Stormplanlæggeren distribuerer arbejde til noder omkring klyngen baseret på topologikonfigurationen.
Du kan tænke på topologier som nogenlunde analoge med et MapReduce-job i Hadoop, bortset fra at da Storms fokus på strømbaseret behandling i realtid, topologier som standard kører for evigt eller indtil manuelt afsluttes. Når en topologi er startet, bringer tudene data ind i systemet og afleverer dataene til bolte (som igen kan hånddata til efterfølgende bolte), hvor hovedberegningsarbejdet udføres. Efterhånden som behandlingen skrider frem, kan en eller flere bolte skrive data ud til en database eller et filsystem, sende en besked til et andet eksternt system eller på anden måde gøre resultaterne af beregningen tilgængelige for brugerne.
En af styrkerne ved Storm-økosystemet er et rigt udvalg af tilgængelige tud, der er specialiseret til at modtage data fra alle typer kilder. Mens du muligvis bliver nødt til at skrive tilpassede tud til højt specialiserede applikationer, er der en god chance for, at du kan finde en eksisterende tud til et utroligt stort udvalg af kilder - fra Twitter-streaming API til Apache Kafka til JMS-mæglere til alt imellem.
Der findes adaptere for at gøre det ligetil at integrere med HDFS-filsystemer, hvilket betyder, at Storm let kan samarbejde med Hadoop, hvis det er nødvendigt. En anden styrke ved Storm er dens støtte til flersproget programmering. Mens Storm i sig selv er baseret på Clojure og kører på JVM, kan tude og bolte skrives på næsten ethvert sprog, herunder ikke-JVM-sprog, der udnytter en protokol til kommunikation mellem komponenter ved hjælp af JSON over stdin / stdout.
Kort sagt er Storm et meget skalerbart, hurtigt, fejltolerant open source-system til distribueret beregning med særligt fokus på strømbehandling. Storm udmærker sig ved hændelsesbehandling og inkrementel beregning og beregner rullende målinger i realtid over datastrømme. Mens Storm også leverer primitiver til at muliggøre generisk distribueret RPC og teoretisk kan bruges til at samle næsten ethvert distribueret beregningsjob, er dets styrke klart behandling af begivenhedsstrøm.
Gnist: Distribueret behandling til alle
Spark, et andet projekt, der er egnet til distribueret beregning i realtid, startede som et projekt fra AMPLab ved University of California i Berkeley, inden han tiltrådte Apache Incubator og til sidst dimitterede som et topniveau-projekt i februar 2014. Ligesom Storm understøtter Spark stream -orienteret behandling, men det er mere en distribueret computerplatform til generelle formål.
Som sådan kan Spark ses som en mulig erstatning for MapReduce-funktionerne i Hadoop, mens Spark har evnen til at køre oven på en eksisterende Hadoop-klynge og stole på YARN til ressourceplanlægning. Ud over Hadoop YARN kan Spark lag oven på Mesos til planlægning eller køre som en enkeltstående klynge ved hjælp af sin indbyggede planlægning. Bemærk, at hvis Spark ikke bruges med Hadoop, er der stadig brug for en form for netværk / distribueret filsystem (NFS, AFS osv.), Hvis det kører på en klynge, så hver node har adgang til de underliggende data.
Spark er skrevet i Scala og understøtter ligesom Storm flersproget programmering, selvom Spark kun leverer specifik API-understøttelse til Scala, Java og Python. Spark har ikke den specifikke abstraktion af en "tud", men inkluderer adaptere til at arbejde med data gemt i adskillige forskellige kilder, herunder HDFS-filer, Cassandra, HBase og S3.
Hvor Spark skinner er i sin understøttelse af flere behandlingsparadigmer og de understøttende biblioteker. Ja, Spark understøtter en streamingmodel, men denne support leveres kun af et af flere Spark-moduler, herunder specialbyggede moduler til SQL-adgang, grafhandlinger og maskinindlæring sammen med stream-behandling.
Spark giver også en ekstremt praktisk interaktiv skal, der muliggør hurtig og snavset prototyping og udforskende dataanalyse i realtid ved hjælp af Scala eller Python API'er. Når du arbejder i den interaktive skal, bemærker du hurtigt en anden stor forskel mellem Spark og Storm: Spark har mere af en "funktionel" smag, hvor arbejde med API styres mere af sammenkædning af successive metodeopkald for at påberåbe sig primitive operationer - i modsætning til Storm-model, som har tendens til at være drevet af oprettelse af klasser og implementering af grænseflader. Hverken tilgang er bedre eller dårligere, men den stil, du foretrækker, kan påvirke din beslutning om, hvilket system der passer bedre til dine behov.
Ligesom Storm er Spark designet til massiv skalerbarhed, og Spark-teamet har dokumenteret brugere af systemet, der kører produktionsklynger med tusinder af noder. Derudover vandt Spark den nylige Daytona GraySort-konkurrence i 2014 og blev den bedste tid til en større arbejdsbyrde bestående af sortering af 100 TB data. Spark-teamet dokumenterer også Spark ETL-operationer med produktionsarbejdsbelastninger i det mange Petabyte-sortiment.
Spark er en hurtig, skalerbar og fleksibel open source-distribueret computerplatform, kompatibel med Hadoop og Mesos, som understøtter flere beregningsmodeller, herunder streaming, grafcentrerede operationer, SQL-adgang og distribueret maskinindlæring. Spark er dokumenteret til at skalere usædvanligt godt og er ligesom Storm en fremragende platform, hvorpå man kan opbygge et realtidsanalyse- og business intelligence-system.
At tage din beslutning
Hvordan vælger du mellem Storm og Spark?
Hvis dine krav primært er fokuseret på strømbehandling og CEP-stilbehandling, og du starter et greenfield-projekt med en specialbygget klynge til projektet, vil jeg sandsynligvis favorisere Storm - især når eksisterende Storm-tud, der matcher dine integrationskrav, er tilgængelige . Dette er på ingen måde en hård og hurtig regel, men sådanne faktorer vil i det mindste antyde at begynde med Storm.
På den anden side, hvis du udnytter en eksisterende Hadoop- eller Mesos-klynge, og / eller hvis dine behandlingsbehov involverer væsentlige krav til grafbehandling, SQL-adgang eller batchbehandling, vil du måske først se på Spark.
En anden faktor, der skal overvejes, er de to sprogs understøttelse af flere sprog. For eksempel, hvis du har brug for at udnytte kode skrevet i R eller et hvilket som helst andet sprog, der ikke understøttes af Spark, så har Storm fordelen ved bredere sprogstøtte. På samme måde, hvis du skal have en interaktiv skal til dataudforskning ved hjælp af API-opkald, så tilbyder Spark dig en funktion, som Storm ikke gør.
I sidste ende vil du sandsynligvis udføre en detaljeret analyse af begge platforme, inden du træffer en endelig beslutning. Jeg anbefaler, at du bruger begge platforme til at opbygge et lille bevis på konceptet - kør derefter dine egne benchmarks med en arbejdsbyrde, der afspejler dine forventede arbejdsbelastninger så tæt som muligt, inden du fuldt ud forpligter dig til en af dem.
Selvfølgelig behøver du ikke tage en eller anden beslutning. Afhængigt af dine arbejdsbyrder, infrastruktur og krav kan du muligvis finde ud af, at den ideelle løsning er en blanding af Storm og Spark - sammen med andre værktøjer som Kafka, Hadoop, Flume osv. Deri ligger skønheden i open source.
Uanset hvilken rute du vælger, viser disse værktøjer, at BI-spillet i realtid er ændret. Kraftfulde muligheder, der kun en gang var tilgængelige for en elite, er nu inden for rækkevidden af de fleste, hvis ikke alle, mellemstore til store organisationer. Udnyt dem.
