Streaming hot: Real-time big data-arkitektur betyder noget

Big data er et bevægeligt mål, og det kommer i bølger: Før støvet fra hver bølge har lagt sig, stiger nye bølger i databehandlingsparadigmer. Streaming, også kaldet real-time/ubundet databehandling, er et af disse nye paradigmer.

Mange organisationer har allerede taget det til sig, andre har det i deres radar, og næsten alle forudsigelse for 2017 nævner det på den ene eller anden måde. Og hvis du er en til at gå med analytikeranbefalinger, ser Forrester realtid som et vigtigt skridt på vejen til en realtids, agil, selvbetjeningsdataplatform.

I denne introduktion til streaming tager vi et kig på use cases og fordele, overlyser forskellige arkitektoniske valg og deres implikationer og præsenterer et kort kort over løsningslandskabet.

Realtid betyder noget

Så hvad er al balladen om? Hvorfor skulle nogen gå ind i besværet med at lære om endnu en trend inden for big data, endsige investere tid og ressourcer til at adoptere og implementere det i deres organisation?

Det korte svar er, fordi real-time behandling og analyse bærer løftet om at gøre organisationer mere effektive og åbne op for nye muligheder.

Den mest velkendte anvendelse ville være detailhandel. I en nylig diskussion med Ted Orme, Attunity VP Technology EMEA, nævnte Orme sagen om en større detailhandler, der kunne skære ned på deres forladte onlinetransaktioner med 80 procent pr. anvender realtidsbehandling.

I stedet for at indsamle driftsdata til analyser, der skal anvendes på et senere tidspunkt, er evnen til at anvende analyser on the fly gjorde det muligt at identificere transaktioner, der blev opgivet på grund af problemer med kreditkortbehandling i realtid.

Ved at gøre det var forhandleren i stand til at få agenter til at kontakte kunder, hvis transaktioner blev opgivet, og tilbyde dem hjælp til at gennemføre deres køb. Dette resulterede i et dramatisk fald i procentdelen af ​​forladte transaktioner: fra 5 procent til 1 procent.

Jo større volumen og værdien af ​​transaktioner er, jo større er stigningen i omsætningen, men regnestykket lægger sig selv for mellemstore detailhandlere: for et gennemsnit på 100 transaktioner pr. dag til en værdi af 10 USD hver, ville dette resultere i 1200 USD mersalg om måneden.

Men dette er blot et eksempel på de fordele, realtidsbehandling og analyser kan give organisationer. Et andet eksempel er kombinationen af ​​realtidsbehandling med IoT. Som Andrew Brust skrev for et par uger tilbage, har IoT-sensordata potentiale til at blive brugt til applikationer, der går ud over det typiske forudsigende vedligeholdelsesscenarie.

Et eksempel på, automatisering af landbruget. Sensorer indsamler og sender miljødata i realtid, og disse data skal også behandles i realtid for at identificere og reagere hurtigt på behov, der er identificeret i marken. Dette kan resultere i et mere effektivt, videnskabeligt optimeret landbrug med mindre manuelt arbejde involveret.

IoT er et domæne, der på passende vis demonstrerer fordelene ved realtidsbehandling, men det er ikke det eneste. Ellen Friedman, MapR-løsningskonsulent, forfatter og Apache Foundation-committer, en af ​​de førende eksperter i streaming-realtidsbehandling, har identificeret flere use case domæner: reklame, finansielle tjenesteydelser, regering, sundhedspleje og biovidenskab, fremstilling, olie og gas og telekommunikation.

Men applikationerne er praktisk talt uendelige - uanset dit domæne, er chancerne for, at evnen til at få operationel indsigt i realtid kan muliggøre tidligere uopnåelige scenarier.

Lambda Kappa Alpha Beta Gaga

Som Friedman udtrykker det, "livet sker ikke i batches". En god del af behandlingen i big data-infrastruktur gør det dog.

Ifølge Doug Cutting, far til Hadoop, "det var ikke som om Hadoop var bygget op omkring batch, fordi vi følte batch var bedst. Batch, især MapReduce, var snarere et naturligt første skridt, fordi det var relativt nemt at implementere og gav stor værdi."

Så nu hvor (batch) big data er overalt, er tiden så inde til at gå videre til næste fase og droppe batch for altid?

Ikke så hurtigt, siger Cutting: "Jeg tror ikke, at der vil ske noget gigantisk skift i retning af streaming. Tværtimod slutter streaming sig nu til pakken af ​​behandlingsmuligheder, som folk har til deres rådighed."Og det er her, tingene begynder at blive rodede og tekniske, og meninger og arkitekturer begynder at divergere.

Til de uindviede, Lambda og Kappa, de 2 konkurrerende arkitekturer til realtidsbehandling, lyd lige så græsk som Alpha Beta Gaga. Hvad er forskellene, og hvorfor betyder det noget?

Lambda-arkitekturen blev introduceret i 2011 af Nathan Marz. Den har en hybridmodel, der bruger et batchlag til storskalaanalyse over alle historiske data, et hastighedslag til behandling med lav latens af nyligt ankomne data (ofte med omtrentlige resultater) og et serveringslag for at give en forespørgsel/visningsfunktion, der forener batch- og hastighedslagene.

Den største ulempe, som kritikere af Lambda Architecture har påpeget, er det faktum, at "uden et værktøj [..], der kan bruges til at implementere batch- og streamingjobs, finder du dig selv implementering af logik to gange: en gang ved at bruge værktøjerne til batchlaget og igen ved at bruge værktøjerne til hastighedslag. Serveringslaget kræver typisk også tilpassede værktøjer til at integrere de to datakilder."

Dette oversættes til mere kompleksitet, mindre lydhørhed og øgede omkostninger til vedligeholdelse, hvorfor Lambda-arkitekturen af ​​mange anses for at være en overgangsmodel.

Som Dean Wampler, forfatter til Fast Data Architectures for Streaming Applications hævder, "hvis alt betragtes som en "strøm" - enten endeligt (som i batch behandling) eller ubegrænset -- så forener den samme infrastruktur ikke bare batch- og hastighedslagene, men batchbehandling bliver en delmængde af strømmen forarbejdning."

Dette har givet anledning til en modificeret arkitektur kaldet Kappa, eller blot hurtig dataarkitektur, som også introducerer en anderledes tankegang: hvis alt er en strøm, så har vi et nyt paradigme, og nye paradigmer kommer med deres egne definitioner.

Tyler Akidau, Staff Software Engineer hos Google og stærkt involveret i Googles streamingmotor og model, har argumenterede for brugen af ​​begreberne afgrænsede og ubundne data og behandling for at præcisere og faktisk erstatte udtrykket "streaming":

Ubegrænsede data: En type evigt voksende, i det væsentlige uendelige datasæt. Disse omtales ofte som "streaming data." Begreberne streaming eller batch er dog problematiske hvornår anvendt på datasæt, fordi [..] de indebærer brugen af ​​en bestemt type eksekveringsmotor til at behandle disse datasæt. Nøgleforskellen mellem de to typer af datasæt, der er tale om, er i virkeligheden deres endelighed, og det er derfor at foretrække at karakterisere dem med termer, der fanger denne skelnen. Som sådan vil jeg referere til uendelige "streaming" datasæt som ubegrænsede data og endelige "batch" datasæt som afgrænsede data.

Ubundet databehandling: En igangværende form for databehandling, der anvendes på den førnævnte type ubundne data. Lige så meget som jeg personligt kan lide brugen af ​​udtrykket streaming til at beskrive denne type databehandling, er det brug i denne sammenhæng indebærer igen brugen af ​​en streaming-udførelsesmotor, hvilket i bedste fald er misvisende; gentagne kørsler af batchmotorer er blevet brugt til at behandle ubundne data, siden batchsystemer først blev udtænkt (og omvendt er veldesignede streamingsystemer mere end i stand til at håndtere "batch" arbejdsbelastninger over afgrænsede data).

Holder det i realtid

Fantastisk, flere definitioner. Betyder det noget, når det, du virkelig ønsker, er at kunne implementere, uhm, ubegrænset databehandling? Det gør det sådan set, ifølge ubegrænsede forarbejdningseksperter. Men før vi kommer til, hvem de er, og hvad deres argumenter er, så lad os præcisere noget: beskeder er ikke lig med streaming.

Bemærk, at i Kappa-arkitekturen er der to forskellige komponenter til dataindtagelse og databehandling. Hvorfor er det det, og hvad er deres forskel?

"Strømme af data kommer ind i systemet via sockets fra andre servere i miljøet eller fra udenfor, såsom telemetrifeeds fra IoT-enheder i marken, sociale netværksfeeds som Twitter "brandslange" osv. Disse strømme indtages i en distribueret Kafka-klynge til skalerbar, holdbar, midlertidig opbevaring. Kafka er rygraden i arkitekturen", som ifølge Wampler.

Så data kommer ind i behandlingspipelinen via beskedkøinfrastruktur, der fungerer som en slags lager- og distributionshub under flyvningen. Message queues (MQ) som Kafka er ikke nye, og Kafka er ikke det eneste spil i byen.

Systemer som IBM MQ-serien og forskellige implementeringer af Java JMS-specifikationen som Apache Camel eller RabbitMQ har eksisteret i lang tid, er velbrugte og forståede og kan ses som forløberne for ubundne data forarbejdning.

MQ'er er gateways til et ubegrænset behandlingssystem. Hvad der derefter sker, er kompliceret, men "for strømbehandling med lav latens er den mest robuste mekanisme at indtage data fra [Kafka] ind i strømbehandlingsmotoren. Der er mange motorer, der i øjeblikket kappes om opmærksomhed," ifølge Wampler.

Ifølge Kostas Tzoumas, PMC-medlem af Apache Flink, en af ​​disse mange motorer, "starter det hele med en streaming-først-arkitektur, hvor alle data er i form af uforanderlige, uendelige strømme. I denne arkitektur er staten ikke centraliseret, men hver applikation eller tjeneste beholder sin egen lokale stat. Flinks rolle i streaming-first-arkitekturen er, at den giver applikationsudviklere værktøjer til at udvikle stateful applikationer.

De fleste interessante datasæt i den virkelige verden er ubegrænsede i naturen, eller i det mindste er det sådan, dataene er født. Tænk på handler, transaktioner, klik, maskinmålinger, logfiler; alle disse er ubundne datasæt. hvis du ser nærmere på de fleste batchjobs, og hvordan data kommer ind og ud, vil du se en pipeline omkring dem, der rent faktisk håndterer ubundne data. Dette er et streamingproblem i naturen, og det løses bedst med streamingteknologi."

Dette vil bringe os ind i det noget uklare vand, hvor vi sammenligner disse mange motorer, der kappes om opmærksomhed, og hvad hver enkelt har at tilbyde i form af arkitektur, understøttede use cases, leverandørtilbud og så på. Dette går ud over omfanget af et enkelt indlæg, men den interesserede læser kan henvise til rapporter skrevet af Forrester og Bloor der forsøger at kaste lys over emnet.

Selvom Forrester og Bloor ikke overraskende har noget forskellige holdninger til domænet, har de én ting til fælles: de fokuserer på brugen af ​​streaming til analyse. Det er klart, at analyseløsninger til ubegrænsede data er afhængige af en underliggende motor, men ubegrænset databehandling er ikke kun anvendelig til analyse.

Desuden har ikke alle motorer den samme arkitektur, hvilket betyder, at de ikke nødvendigvis understøtter de samme use cases, eller gør de samme ting på samme måde.

I øjeblikket er de mest populære blandt disse motorer alle open source Apache-projekter: Apex, Beam, Flink, Storm og Spark. Deres udbredelse taler dog meget om den øgede anvendelse og betydning af ubegrænset behandling hvis vi skulle vælge den ene motor ud af dem, der i øjeblikket får mest opmærksomhed, ville det være Gnist.

Dette kommer som et resultat af en række faktorer og vil blive genstand for yderligere analyse i fremtiden. Men vi vil fortsætte med dybdegående dækning af ubegrænset behandling, motorer, arkitekturer, modeller og leverandører bag det, såvel som brugssager i den virkelige verden i vores næste indlæg, der byder på eksklusive nyheder fra en af ​​nøglespillerne i dette plads.

Hvordan kan du omdanne big data til forretningsindsigt?