Det er et gammelt aksiom som går omtrent slik: Hvis du tilbyr noen full støtte og økonomisk støtte til å gjøre noe annerledes og nyskapende, vil de ende opp med å gjøre det alle andre gjør.
Så det går med Hadoop, Spark og Storm. Alle tror de gjør noe spesielt med disse nye big data-teknologiene, men det tar ikke lang tid å møte de samme mønstrene igjen og igjen. Spesifikke implementeringer kan variere noe, men basert på min erfaring er her de syv vanligste prosjektene.
Prosjekt nr. 1: Datakonsolidering
Kall det et "enterprise data hub" eller "data lake." Tanken er at du har forskjellige datakilder, og at du vil utføre analyse på tvers av dem. Denne typen prosjekter består i å få feeds fra alle kildene (enten sanntid eller som en batch) og skyve dem inn i Hadoop. Noen ganger er dette trinn 1 for å bli et "datadrevet selskap"; noen ganger vil du ganske enkelt ha pene rapporter. Datasjøer materialiserer seg vanligvis som filer på HDFS og tabeller i Hive eller Impala. Det er en dristig, ny verden der mye av dette dukker opp i HBase - og Phoenix, i fremtiden, fordi Hive er treg.
Selgere liker å si ting som "skjema når du leser", men for å lykkes, må du ha en god ide om hva du vil bruke (at Hive-skjemaet ikke ser veldig annerledes ut enn det du ville gjort i et datalager for bedrifter). Den virkelige årsaken til en datasjø er horisontal skalerbarhet og mye lavere kostnad enn Teradata eller Netezza. For "analyse" setter mange mennesker opp Tableau og Excel i frontenden. Mer sofistikerte selskaper med “ekte dataforskere” (mattegeker som skriver dårlig Python) bruker Zeppelin eller iPython-bærbar PC som en frontend.
Prosjekt nr. 2: Spesialisert analyse
Mange datakonsolideringsprosjekter begynner faktisk her, hvor du har et spesielt behov og trekker inn ett datasett for et system som gjør en slags analyse. Disse pleier å være utrolig domenespesifikke, for eksempel likviditetsrisiko / Monte Carlo-simuleringer i en bank. Tidligere var slike spesialiserte analyser avhengige av antikke, proprietære pakker som ikke kunne skaleres opp som dataene, og som ofte led av et begrenset funksjonssett (delvis fordi programvareleverandøren ikke kunne vite så mye om domenet som institusjonen. nedsenket i den).
I Hadoop- og Spark-verdenene ser disse systemene omtrent det samme som datakonsolideringssystemer, men har ofte mer HBase, tilpasset ikke-SQL-kode og færre datakilder (om ikke bare en). I økende grad er de gnistbaserte.
Prosjekt nr. 3: Hadoop som en tjeneste
I enhver stor organisasjon med "spesialiserte analyseprosjekter" (og ironisk nok ett eller to "datakonsolidering" -prosjekter) vil de uunngåelig begynne å føle "gleden" (det vil si smerte) ved å administrere noen forskjellige konfigurerte Hadoop-klynger, noen ganger fra forskjellige leverandører. Deretter vil de si: "Kanskje vi burde konsolidere dette og samle ressurser," i stedet for å ha halvparten av nodene sine inaktive halve tiden. De kan gå til skyen, men mange selskaper kan ikke eller vil ikke, ofte av sikkerhetsgrunner (les: intern politikk og jobbbeskyttelse). Dette betyr vanligvis mange kokkoppskrifter og nå Docker-containerpakker.
Jeg har ikke brukt det ennå, men Blue Data ser ut til å ha det nærmeste til en out-of-the-box-løsning her, som også vil appellere til mindre organisasjoner som mangler muligheten til å distribuere Hadoop som en tjeneste.
Prosjekt nr. 4: Streaming analytics
Mange vil kalle dette "streaming", men streaming-analyse er ganske forskjellig fra streaming fra enheter. Ofte er streaminganalyse en mer sanntidsversjon av hva en organisasjon gjorde i grupper. Ta antimoney hvitvasking eller svindeloppdagelse: Hvorfor ikke gjøre det på transaksjonsbasis og fange det som det skjer i stedet for på slutten av en syklus? Det samme gjelder lagerstyring eller noe annet.
I noen tilfeller er dette en ny type transaksjonssystem som analyserer data bit for bit mens du shunter det inn i et analytisk system parallelt. Slike systemer manifesterer seg som Spark eller Storm med HBase som vanlig datalager. Merk at streaming-analyse ikke erstatter alle former for analyse; vil du fremdeles øye på historiske trender eller se på tidligere data for noe du aldri har vurdert.
Prosjekt nr. 5: Kompleks hendelsesbehandling
Her snakker vi om sanntids hendelsesbehandling, der undersekunder betyr noe. Selv om det fremdeles ikke er raskt nok for applikasjoner med ultra-lav latens (picosekund eller nanosekund), som avanserte handelssystemer, kan du forvente svartider på millisekunder. Eksempler inkluderer sanntidsvurdering av samtaledataposter for teletelefoner eller behandling av Internett av ting hendelser. Noen ganger vil du se at slike systemer bruker Spark og HBase - men generelt faller de på ansiktet og må konverteres til Storm, som er basert på Disruptor-mønsteret utviklet av LMAX-sentralen.
Tidligere har slike systemer vært basert på tilpasset meldingsprogramvare - eller høy ytelse, klient-server-meldingsprodukter - men dagens datavolum er for mye for noen av dem. Handelsvolumene og antall personer med mobiltelefoner har skutt opp siden de eldre systemene ble opprettet, og medisinske og industrielle sensorer pumper ut for mange biter. Jeg har ikke brukt det ennå, men Apex-prosjektet ser lovende ut og hevder å være raskere enn Storm.
Prosjekt nr. 6: Streaming som ETL
Noen ganger vil du fange strømmedata og lagre dem et sted. Disse prosjektene faller vanligvis sammen med nr. 1 eller nr. 2, men legger til sitt eget omfang og egenskaper. (Noen mennesker tror de gjør nr. 4 eller nr. 5, men de dumper faktisk til disken og analyserer dataene senere.) Dette er nesten alltid Kafka- og Storm-prosjekter. Gnist brukes også, men uten begrunnelse, siden du egentlig ikke trenger analyse i minnet.
Prosjekt nr. 7: Bytte eller utvide SAS
SAS har det bra; SAS er hyggelig. SAS er også dyrt, og vi kjøper ikke bokser til alle dine dataforskere og analytikere, slik at du kan "leke" med dataene. Dessuten ønsket du å gjøre noe annerledes enn SAS kunne gjøre eller generere en penere graf. Her er den fine datasjøen din. Her er iPython Notebook (nå) eller Zeppelin (senere). Vi gir resultatene inn i SAS og lagrer resultatene fra SAS her.
Mens jeg har sett andre Hadoop-, Spark- eller Storm-prosjekter, er dette de “normale” hverdagstypene. Hvis du bruker Hadoop, kjenner du sannsynligvis igjen dem. Noen av brukssakene for disse systemene har jeg implementert mange år tidligere, og jobbet med andre teknologier.
Hvis du er en gammeldags redd for det "store" i big data eller "gjør" i Hadoop, ikke vær. Jo flere ting endres, jo mer blir de de samme. Du finner mange paralleller mellom tingene du pleide å distribuere og hipsterteknologiene som virvlet rundt Hadooposphere.
