Programmering

Storm eller Gnist: Velg våpen i sanntid

Ideen om forretningsinformasjon i sanntid har eksistert en stund (se Wikipedia-siden om emnet startet i 2006). Men mens folk har snakket om ideen i årevis, har jeg ikke sett mange bedrifter som faktisk omfavner visjonen, og langt mindre innser fordelene den muliggjør.

I det minste har en del av årsaken vært mangelen på verktøy for implementering av BI og analyse i sanntid. Tradisjonelle datalagermiljøer var sterkt orientert mot batchoperasjoner med ekstremt høy ventetid, var utrolig dyre eller begge deler.

En rekke kraftige, brukervennlige open source-plattformer har dukket opp for å endre dette. To av de mest bemerkelsesverdige er Apache Storm og Apache Spark, som tilbyr sanntidsbehandlingsfunksjoner til et mye bredere utvalg av potensielle brukere. Begge er prosjekter innen Apache Software Foundation, og mens de to verktøyene gir overlappende muligheter, har de hver sin særegne funksjon og rolle å spille.

Storm: Hadoop av sanntidsbehandling

Storm, et distribuert rammeverk for behandling av hendelsesstrøm, begynte livet som et prosjekt av BackType, et markedsføringsselskap som ble kjøpt av Twitter i 2011. Twitter åpnet snart prosjektet og la det på GitHub, men Storm flyttet til slutt til Apache Incubator. og ble et Apache toppnivåprosjekt i september 2014.

Storm har noen ganger blitt referert til som Hadoop for sanntidsbehandling. Storm-dokumentasjonen ser ut til å være enig: "Storm gjør det enkelt å behandle ubegrensede datastrømmer pålitelig, og gjøre for sanntidsbehandling av det Hadoop gjorde for batchbehandling."

For å oppnå dette, er Storm designet for massiv skalerbarhet, støtter feiltoleranse med en “fail fast, auto restart” -tilnærming til prosesser, og gir en sterk garanti for at hver tuple blir behandlet. Storm er som standard en "minst en gang" -garanti for meldinger, men tilbyr også muligheten til å implementere "nøyaktig en gang" -behandling.

Storm er først og fremst skrevet i Clojure og er designet for å støtte ledninger "tuter" (tenk inngangsstrømmer) og "bolter" (prosesserings- og utgangsmoduler) sammen som en rettet acyklisk graf (DAG) kalt topologi. Stormtopologier kjøres på klynger, og Stormplanleggeren distribuerer arbeid til noder rundt klyngen, basert på topologikonfigurasjonen.

Du kan tenke på topologier som omtrent analoge med en MapReduce-jobb i Hadoop, bortsett fra at gitt Storms fokus på sanntids, strømbasert prosessering, er topologier standard for å kjøre for alltid eller til manuelt avsluttes. Når en topologi er startet, bringer tutene data inn i systemet og overleverer dataene til bolter (som igjen kan hånddata til påfølgende bolter) der hovedberegningsarbeidet utføres. Etter hvert som behandlingen skrider frem, kan en eller flere bolter skrive data ut til en database eller et filsystem, sende en melding til et annet eksternt system, eller på annen måte gjøre resultatene av beregningen tilgjengelig for brukerne.

En av styrkene til Storm-økosystemet er et rikt utvalg av tilgjengelige tuter som er spesialisert for å motta data fra alle typer kilder. Mens du kanskje må skrive tilpassede tuter for høyspesialiserte applikasjoner, er det en god sjanse for at du kan finne en eksisterende tut for et utrolig stort utvalg av kilder - fra Twitter-streaming-API til Apache Kafka til JMS-meglere til alt i mellom.

Adaptere eksisterer for å gjøre det greit å integrere med HDFS-filsystemer, noe som betyr at Storm enkelt kan samarbeide med Hadoop om nødvendig. En annen styrke ved Storm er støtten til flerspråklig programmering. Mens Storm i seg selv er basert på Clojure og kjører på JVM, kan tuter og bolter skrives på nesten hvilket som helst språk, inkludert ikke-JVM-språk som benytter seg av en protokoll for å kommunisere mellom komponenter ved bruk av JSON over stdin / stdout.

Kort fortalt er Storm et veldig skalerbart, raskt, feiltolerant open source-system for distribuert beregning, med spesielt fokus på strømbehandling. Storm utmerker seg ved hendelsesbehandling og inkrementell beregning, og beregner rullende beregninger i sanntid over datastrømmer. Mens Storm også gir primitiver for å muliggjøre generisk distribuert RPC og teoretisk kan brukes til å montere nesten hvilken som helst distribuert beregningsjobb, er styrken tydelig behandling av hendelsesstrøm.

Gnist: Distribuert behandling for alle

Spark, et annet prosjekt som er egnet for distribuert beregning i sanntid, startet som et prosjekt fra AMPLab ved University of California i Berkeley før han begynte i Apache Incubator og til slutt ble uteksaminert som et toppnivåprosjekt i februar 2014. I likhet med Storm støtter Spark stream -orientert behandling, men det er mer en generell distribuert databehandlingsplattform.

Som sådan kan Spark sees på som en potensiell erstatning for MapReduce-funksjonene til Hadoop, mens Spark har muligheten til å løpe på toppen av en eksisterende Hadoop-klynge, og stole på YARN for ressursplanlegging. I tillegg til Hadoop YARN, kan Spark lag på toppen av Mesos for planlegging eller kjøre som en frittstående klynge ved hjelp av den innebygde planleggeren. Merk at hvis Spark ikke brukes med Hadoop, er det fortsatt behov for en eller annen type nettverk / distribuert filsystem (NFS, AFS og så videre) hvis den kjører på en klynge, slik at hver node vil ha tilgang til de underliggende dataene.

Spark er skrevet i Scala og støtter, i likhet med Storm, flerspråklig programmering, selv om Spark bare gir spesifikk API-støtte for Scala, Java og Python. Gnist har ikke den spesifikke abstraksjonen av en "tut", men inkluderer adaptere for å jobbe med data lagret i mange forskjellige kilder, inkludert HDFS-filer, Cassandra, HBase og S3.

Where Spark shines er i sin støtte til flere prosesseringsparadigmer og støttende biblioteker. Ja, Spark støtter en streamingmodell, men denne støtten leveres av bare en av flere Spark-moduler, inkludert spesialbygde moduler for SQL-tilgang, grafoperasjoner og maskinlæring, sammen med strømbehandling.

Spark gir også et ekstremt praktisk interaktivt skall som tillater rask og skitten prototyping og utforskende dataanalyse i sanntid ved hjelp av Scala eller Python APIer. Når du arbeider i det interaktive skallet, merker du raskt en annen stor forskjell mellom Spark og Storm: Spark har mer en “funksjonell” smak, der arbeid med API-et drives mer av å kjede påfølgende metodekall for å påkalle primitive operasjoner - i motsetning til Storm-modell, som har en tendens til å være drevet av å lage klasser og implementere grensesnitt. Verken tilnærming er bedre eller dårligere, men stilen du foretrekker kan påvirke din beslutning om hvilket system som passer bedre til dine behov.

I likhet med Storm, er Spark designet for massiv skalerbarhet, og Spark-teamet har dokumentert brukere av systemet som kjører produksjonsklynger med tusenvis av noder. I tillegg vant Spark den nylige Daytona GraySort-konkurransen i 2014, og ble den beste tiden for en tyngre arbeidsmengde bestående av å sortere 100 TB data. Spark-teamet dokumenterer også Spark ETL-operasjoner med produksjonsbelastninger i flere Petabyte-serien.

Spark er en rask, skalerbar og fleksibel åpen kildekode distribuert databehandlingsplattform, kompatibel med Hadoop og Mesos, som støtter flere beregningsmodeller, inkludert streaming, graf-sentriske operasjoner, SQL-tilgang og distribuert maskinlæring. Spark har blitt dokumentert for å skalere seg eksepsjonelt godt, og er i likhet med Storm en utmerket plattform for å bygge et sanntids analyse- og business intelligence-system.

Å ta din beslutning

Hvordan velger du mellom Storm og Spark?

Hvis kravene dine først og fremst er fokusert på strømbehandling og CEP-stilbehandling og du starter et greenfield-prosjekt med en spesialbygd klynge for prosjektet, vil jeg sannsynligvis favorisere Storm - spesielt når eksisterende Storm-tuter som samsvarer med integrasjonskravene dine er tilgjengelige . Dette er på ingen måte en hard og rask regel, men slike faktorer vil i det minste foreslå å begynne med Storm.

På den annen side, hvis du utnytter en eksisterende Hadoop- eller Mesos-klynge og / eller hvis behandlingsbehovene dine innebærer store krav til grafbehandling, SQL-tilgang eller batchbehandling, vil du kanskje se på Spark først.

En annen faktor å vurdere er flerspråklig støtte for de to systemene. For eksempel, hvis du trenger å bruke kode skrevet i R eller et annet språk som ikke støttes av Spark, så har Storm fordelen med bredere språkstøtte. På samme måte, hvis du må ha et interaktivt skall for datautforskning ved hjelp av API-samtaler, så tilbyr Spark deg en funksjon som Storm ikke gjør.

Til slutt vil du sannsynligvis ønske å utføre en detaljert analyse av begge plattformene før du tar en endelig beslutning. Jeg anbefaler at du bruker begge plattformene til å bygge et lite bevis på konseptet - kjør deretter dine egne referanser med en arbeidsbelastning som speiler dine forventede arbeidsbelastninger så tett som mulig før du forplikter deg til en av dem.

Selvfølgelig trenger du ikke ta en / eller beslutning. Avhengig av arbeidsbelastning, infrastruktur og krav, kan du oppdage at den ideelle løsningen er en blanding av Storm og Spark - sammen med andre verktøy som Kafka, Hadoop, Flume og så videre. Der ligger skjønnheten til åpen kildekode.

Uansett hvilken rute du velger, viser disse verktøyene at BI-spillet i sanntid har endret seg. Kraftige alternativer som en gang kun var tilgjengelige for en elite, er nå innen rekkevidde for de fleste, om ikke alle, mellomstore organisasjoner. Dra nytte av dem.

$config[zx-auto] not found$config[zx-overlay] not found