Der er et gammelt aksiom, der går sådan her: Hvis du tilbyder nogen din fulde støtte og økonomiske støtte til at gøre noget andet og innovativt, ender de med at gøre, hvad alle andre laver.
Så det går med Hadoop, Spark og Storm. Alle tror, de laver noget specielt med disse nye big data-teknologier, men det tager ikke lang tid at støde på de samme mønstre igen og igen. Specifikke implementeringer kan variere noget, men baseret på min erfaring er her de syv mest almindelige projekter.
Projekt nr. 1: Datakonsolidering
Kald det et "enterprise data hub" eller "data lake". Ideen er, at du har forskellige datakilder, og at du vil udføre analyse på tværs af dem. Denne type projekt består i at få feeds fra alle kilder (enten realtid eller som en batch) og skubbe dem ind i Hadoop. Nogle gange er dette trin et til at blive en "datadrevet virksomhed"; nogle gange vil man bare have smukke rapporter. Datasøer bliver normalt som filer på HDFS og tabeller i Hive eller Impala. Der er en dristig, ny verden, hvor meget af dette dukker op i HBase - og Phoenix, i fremtiden, fordi Hive er langsom.
Sælgere kan lide at sige ting som "skema ved læsning", men for at få succes skal du i sandhed have en god idé om, hvad dine brugssager vil være (at Hive-skema ikke ser meget anderledes ud end hvad du ville gøre i et virksomhedsdatalager). Den virkelige årsag til en datasø er vandret skalerbarhed og meget lavere omkostninger end Teradata eller Netezza. Til "analyse" opretter mange mennesker Tableau og Excel i frontenden. Mere sofistikerede virksomheder med “rigtige dataforskere” (matematiske nørder, der skriver dårlig Python) bruger Zeppelin eller iPython-notebook som en frontend.
Projekt nr. 2: Specialiseret analyse
Mange datakonsolideringsprojekter begynder faktisk her, hvor du har et specielt behov og trækker et datasæt til et system, der foretager en slags analyse. Disse har tendens til at være utroligt domænespecifikke, såsom likviditetsrisiko / Monte Carlo-simuleringer i en bank. Tidligere var sådanne specialiserede analyser afhængige af forældede, proprietære pakker, der ikke kunne skaleres op som dataene, og ofte led af et begrænset funktionssæt (dels fordi softwareleverandøren ikke kunne vide så meget om domænet som institutionen nedsænket i det).
I Hadoop- og Spark-verdenen ser disse systemer stort set ud som datakonsolideringssystemer, men har ofte mere HBase, tilpasset ikke-SQL-kode og færre datakilder (hvis ikke kun en). I stigende grad er de Spark-baserede.
Projekt nr. 3: Hadoop som en tjeneste
I enhver stor organisation med "specialiserede analyseprojekter" (og ironisk nok et eller to "datakonsolidering" -projekter) begynder de uundgåeligt at føle "glæden" (det vil sige smerte) ved at styre et par forskellige konfigurerede Hadoop-klynger, nogle gange fra forskellige leverandører. Derefter vil de sige, "Måske skal vi konsolidere dette og samle ressourcer", snarere end at have halvdelen af deres noder siddende inaktive halvdelen af tiden. De kunne gå til skyen, men mange virksomheder kan eller kan ikke, ofte af sikkerhedsmæssige årsager (læs: intern politik og jobbeskyttelse). Dette betyder generelt en masse Chef-opskrifter og nu Docker-containerpakker.
Jeg har ikke brugt det endnu, men Blue Data ser ud til at have den tætteste ting til en out-of-the-box-løsning her, som også vil appellere til mindre organisationer, der mangler bevægelsen til at implementere Hadoop som en tjeneste.
Projekt nr. 4: Streaming analytics
Mange mennesker vil kalde dette "streaming", men streaming-analyse er ret forskellig fra streaming fra enheder. Streaminganalyse er ofte en mere realtidsversion af, hvad en organisation gjorde i batches. Tag antimoney hvidvaskning eller afsløring af svig: Hvorfor ikke gøre det på transaktionsbasis og fange det som det sker snarere end i slutningen af en cyklus? Det samme gælder for lagerstyring eller andet.
I nogle tilfælde er dette en ny type transaktionssystem, der analyserer data bit for bit, mens du shunter det ind i et analytisk system parallelt. Sådanne systemer manifesterer sig som Spark eller Storm med HBase som det sædvanlige datalager. Bemærk, at streaming-analyse ikke erstatter alle former for analyse; du vil stadig gerne overflade historiske tendenser eller se på tidligere data for noget, som du aldrig har overvejet.
Projekt nr. 5: Kompleks behandling af begivenheder
Her taler vi om behandling i realtid af begivenheder, hvor undersekunder betyder noget. Selvom det stadig ikke er hurtigt nok til applikationer med ultra-lav latens (picosekund eller nanosekund), såsom avancerede handelssystemer, kan du forvente svartider på millisekunder. Eksempler inkluderer realtidsvurdering af opkaldsdataoptegnelser til teletelefoner eller behandling af internet af tingbegivenheder. Nogle gange vil du se, at sådanne systemer bruger Spark og HBase - men generelt falder de på deres ansigter og skal konverteres til Storm, som er baseret på Disruptor-mønsteret udviklet af LMAX-børsen.
Tidligere har sådanne systemer været baseret på tilpasset messaging-software - eller højtydende, off-the-shelf klient-server-messaging-produkter - men nutidens datamængder er for meget for begge. Handelsvolumener og antallet af mennesker med mobiltelefoner er steget siden disse ældre systemer blev oprettet, og medicinske og industrielle sensorer pumper for mange bits ud. Jeg har ikke brugt det endnu, men Apex-projektet ser lovende ud og hævder at være hurtigere end Storm.
Projekt nr. 6: Streaming som ETL
Nogle gange vil du fange streamingdata og lagre dem et eller andet sted. Disse projekter falder normalt sammen med nr. 1 eller nr. 2, men tilføjer deres eget omfang og egenskaber. (Nogle mennesker tror, de laver nr. 4 eller nr. 5, men de dumper faktisk til disken og analyserer dataene senere.) Disse er næsten altid Kafka- og Storm-projekter. Gnist bruges også, men uden begrundelse, da du ikke rigtig har brug for analyse i hukommelsen.
Projekt nr. 7: Udskiftning eller udvidelse af SAS
SAS har det fint; SAS er rart. SAS er også dyrt, og vi køber ikke kasser til alle jeres dataforskere og analytikere, så du kan "lege" med dataene. Desuden ønskede du at gøre noget andet end SAS kunne gøre eller generere en pænere graf. Her er din dejlige datasø. Her er iPython Notebook (nu) eller Zeppelin (senere). Vi indfører resultaterne i SAS og gemmer resultater fra SAS her.
Mens jeg har set andre Hadoop-, Spark- eller Storm-projekter, er det de "normale" hverdagstyper. Hvis du bruger Hadoop, kan du sandsynligvis genkende dem. Nogle af brugssagerne til disse systemer har jeg implementeret mange år før og arbejdet med andre teknologier.
Hvis du er en ældre, der er for bange for det "store" i big data eller "gør" i Hadoop, skal du ikke være det. Jo flere ting ændres, jo mere forbliver de de samme. Du finder masser af paralleller mellem de ting, du plejede at implementere, og hipsterteknologierne, der hvirvler rundt om Hadooposphere.
