Storm eller gnista: Välj ditt realtidsvapen

Idén om affärsinformation i realtid har funnits ett tag (se Wikipedia-sidan om ämnet som inleddes 2006). Men medan människor har pratat om idén i flera år har jag inte sett att många företag faktiskt anammar visionen, än mindre inser de fördelar den möjliggör.

Åtminstone en del av anledningen har varit bristen på verktyg för att implementera BI och analys i realtid. Traditionella datalagringsmiljöer var starkt inriktade på batchoperationer med extremt höga latenser, var oerhört dyra eller båda.

Ett antal kraftfulla, lättanvända open source-plattformar har dykt upp för att ändra detta. Två av de mest anmärkningsvärda är Apache Storm och Apache Spark, som erbjuder bearbetningsfunktioner i realtid till ett mycket bredare spektrum av potentiella användare. Båda är projekt inom Apache Software Foundation, och medan de två verktygen ger överlappande funktioner har de var och en särdrag och roller att spela.

Storm: Hadoop av realtidsbehandling

Storm, ett distribuerat beräkningsramverk för bearbetning av händelseströmmar, började sitt liv som ett projekt av BackType, ett marknadsföringsföretag som köptes av Twitter 2011. Twitter öppnade snart projektet och lade det på GitHub, men Storm flyttade till slut till Apache Incubator. och blev ett Apache-projekt på toppnivå i september 2014.

Storm har ibland kallats Hadoop för realtidsbehandling. Storm-dokumentationen verkar vara överens: "Storm gör det enkelt att på ett tillförlitligt sätt bearbeta obegränsade dataströmmar, vilket gör för realtidsbehandling vad Hadoop gjorde för batchbehandling."

För att nå detta ändamål är Storm utformad för massiv skalbarhet, stöder feletolerans med en "misslyckande, automatisk omstart" -metod för processer och erbjuder en stark garanti för att varje tupel kommer att behandlas. Storm är som standard en "minst en gång" -garanti för meddelanden, men erbjuder också möjligheten att implementera "exakt en gång" -behandling.

Storm är främst skrivet i Clojure och är utformat för att stödja ledningar "pipar" (tänk ingångsströmmar) och "bultar" (bearbetnings- och utmatningsmoduler) tillsammans som en riktad acyklisk graf (DAG) kallad topologi. Stormtopologier körs på kluster och Stormschemaläggaren distribuerar arbete till noder runt klustret, baserat på topologikonfigurationen.

Du kan tänka dig topologier som ungefär analoga med ett MapReduce-jobb i Hadoop, förutom att med tanke på Storms fokus på realtids, strömbaserad bearbetning, är topologier standard för att köras för alltid eller tills manuellt avslutas. När en topologi har startats tar piparna data in i systemet och överlämnar data till bultar (som i sin tur kan handdata till efterföljande bultar) där det huvudsakliga beräkningsarbetet utförs. När behandlingen fortskrider kan en eller flera bultar skriva ut data till en databas eller ett filsystem, skicka ett meddelande till ett annat externt system eller på annat sätt göra resultaten av beräkningen tillgängliga för användarna.

En av styrkorna med Storm-ekosystemet är ett rikt utbud av tillgängliga pipar som är specialiserade för att ta emot data från alla typer av källor. Medan du kanske måste skriva anpassade pip för högt specialiserade applikationer, finns det en god chans att du kan hitta en befintlig pip för ett otroligt stort utbud av källor - från Twitter-streaming-API till Apache Kafka till JMS-mäklare till allt däremellan.

Adaptrar finns för att göra det enkelt att integrera med HDFS-filsystem, vilket innebär att Storm enkelt kan samarbeta med Hadoop om det behövs. En annan styrka hos Storm är dess stöd för flerspråkig programmering. Medan Storm själv är baserad på Clojure och körs på JVM kan pipar och bultar skrivas på nästan vilket språk som helst, inklusive icke-JVM-språk som utnyttjar ett protokoll för att kommunicera mellan komponenter som använder JSON över stdin / stdout.

Kort sagt är Storm ett mycket skalbart, snabbt, feltolerant öppen källkodssystem för distribuerad beräkning, med ett särskilt fokus på strömbehandling. Storm utmärker sig vid bearbetning av händelser och inkrementell beräkning och beräknar rullande mätvärden i realtid över dataströmmar. Medan Storm också tillhandahåller primitiver för att möjliggöra generisk distribuerad RPC och teoretiskt kan användas för att montera nästan alla distribuerade beräkningsjobb, är dess styrka helt klart bearbetning av händelseström.

Gnista: Distribuerad bearbetning för alla

Spark, ett annat projekt som passar distribuerad beräkning i realtid, började som ett projekt från AMPLab vid University of California i Berkeley innan han började i Apache Incubator och slutligen tog examen som ett toppnivåprojekt i februari 2014. Liksom Storm stöder Spark stream -orienterad bearbetning, men det är mer en allmänt distribuerad datorplattform.

Som sådan kan Spark ses som en potentiell ersättare för MapReduce-funktionerna i Hadoop, medan Spark har förmågan att springa ovanpå ett befintligt Hadoop-kluster och förlita sig på YARN för resursplanering. Förutom Hadoop YARN kan Spark lagras ovanpå Mesos för schemaläggning eller köras som ett fristående kluster med hjälp av den inbyggda schemaläggaren. Observera att om Spark inte används med Hadoop krävs fortfarande någon typ av nätverk / distribuerat filsystem (NFS, AFS och så vidare) om det körs i ett kluster, så varje nod kommer att ha tillgång till underliggande data.

Spark är skrivet i Scala och stöder, precis som Storm, flerspråkig programmering, även om Spark endast ger specifikt API-stöd för Scala, Java och Python. Spark har inte den specifika abstraktionen av en "pip", men innehåller adaptrar för att arbeta med data som lagras i många olika källor, inklusive HDFS-filer, Cassandra, HBase och S3.

Where Spark shines är i sitt stöd för flera bearbetningsparadigmer och de stödjande biblioteken. Ja, Spark stöder en strömmande modell, men detta stöd tillhandahålls av endast en av flera Spark-moduler, inklusive specialbyggda moduler för SQL-åtkomst, grafoperationer och maskininlärning, tillsammans med strömbehandling.

Spark tillhandahåller också ett extremt praktiskt interaktivt skal som möjliggör snabb och smutsig prototypning och utforskande dataanalys i realtid med Scala eller Python API. När du arbetar i det interaktiva skalet märker du snabbt en annan stor skillnad mellan Spark och Storm: Spark har mer en "funktionell" smak, där arbete med API drivs mer genom att kedja successiva metodanrop för att åberopa primitiva operationer - i motsats till Stormmodell, som tenderar att drivas av att skapa klasser och implementera gränssnitt. Varken tillvägagångssätt är bättre eller sämre, men den stil du föredrar kan påverka ditt beslut om vilket system som passar bättre för dina behov.

Liksom Storm är Spark utformad för massiv skalbarhet, och Spark-teamet har dokumenterat användare av systemet som kör produktionskluster med tusentals noder. Dessutom vann Spark den senaste 2014 Daytona GraySort-tävlingen, vilket gav bästa möjliga tid för en arbetsbelastning som består av att sortera 100 TB data. Spark-teamet dokumenterar också Spark ETL-operationer med produktionsarbetsbelastningar i flera Petabyte-sortiment.

Spark är en snabb, skalbar och flexibel databehandlingsplattform med öppen källkod, kompatibel med Hadoop och Mesos, som stöder flera beräkningsmodeller, inklusive streaming, grafcentrerad operation, SQL-åtkomst och distribuerad maskininlärning. Spark har dokumenterats att skala utomordentligt bra och är, precis som Storm, en utmärkt plattform att bygga ett realtidsanalys- och business intelligence-system på.

Fatta ditt beslut

Hur väljer du mellan Storm och Spark?

Om dina krav huvudsakligen är inriktade på strömbehandling och CEP-stilbehandling och du startar ett greenfield-projekt med ett specialbyggt kluster för projektet skulle jag förmodligen gynna Storm - speciellt när befintliga Storm-pipar som matchar dina integrationskrav finns tillgängliga . Detta är inte alls en hård och snabb regel, men sådana faktorer skulle åtminstone föreslå att börja med Storm.

Å andra sidan, om du använder ett befintligt Hadoop- eller Mesos-kluster och / eller om din bearbetningsbehov innebär stora krav för grafbehandling, SQL-åtkomst eller batchbehandling, kanske du vill titta på Spark först.

En annan faktor att tänka på är flerspråkigt stöd för de två systemen. Till exempel, om du behöver utnyttja kod skriven i R eller något annat språk som inte stöds av Spark, har Storm fördelen av bredare språkstöd. På samma sätt, om du måste ha ett interaktivt skal för datautforskning med API-samtal, erbjuder Spark dig en funktion som Storm inte gör.

I slutändan vill du förmodligen utföra en detaljerad analys av båda plattformarna innan du fattar ett slutgiltigt beslut. Jag rekommenderar att du använder båda plattformarna för att bygga ett litet bevis på konceptet - kör sedan dina egna riktmärken med en arbetsbelastning som speglar dina förväntade arbetsbelastningar så nära som möjligt innan du förbinder dig till någon av dem.

Naturligtvis behöver du inte fatta ett eller annat beslut. Beroende på dina arbetsbelastningar, infrastruktur och krav kan du hitta att den perfekta lösningen är en blandning av Storm och Spark - tillsammans med andra verktyg som Kafka, Hadoop, Flume och så vidare. Där ligger skönheten i öppen källkod.

Oavsett vilken rutt du väljer visar dessa verktyg att BI-spelet i realtid har förändrats. Kraftfulla alternativ som en gång endast var tillgängliga för en få elit är nu inom räckhåll för de flesta, om inte alla, medelstora organisationer. Dra nytta av dem.