Av Techopedia Staff, 24. februar 2016
Takeaway: Vert Rebecca Jozwiak diskuterer streaminganalyse med topp eksperter i bransjen.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Rebecca Jozwiak: Mine damer og herrer, Hei og velkommen til Hot Technologies i 2016! Dagens tittel er “Utnytte brannslangen: Få forretningsverdi fra Streaming Analytics.” Dette er Rebecca Jozwiak. Jeg er den nestkommanderende for webcastvert når vår kjære Eric Kavanagh ikke kan være her, så det er hyggelig å se så mange av dere der ute i dag.
Denne episoden er litt annerledes enn våre andre. Vi snakket litt om hva som er varmt og selvfølgelig i år varmt. De siste årene har vært varme. Det kommer alltid nye ting ut. I dag snakker vi om streaminganalyse. Streaminganalyser er ganske nytt i seg selv. Selvfølgelig streaming, sentrumsdata, RFID-data, de er ikke nødvendigvis nye. Men i forbindelse med dataarkitekturer har vi vært så fokusert på data i ro i flere tiår. Databaser, filsystemer, databaser - alt for det meste av batchbehandling. Men nå med skiftet til å skape verdier fra strømming av data, datafølelser, noen kaller det levende strømmer, krever de virkelig en strømbasert arkitektur, ikke dataene i ro-arkitekturer som vi har vært vant til og det må være i stand til håndtere rask svelging, sanntid eller nær sanntids behandling. Det må kunne imøtekomme ikke bare tingenes internett, men internett for alt.
Selvfølgelig, ideelt sett, ville det være fint å ha de to arkitekturene som lever side om side, den ene hånden vasker den andre, så å si. Mens de dager gamle data, uker gamle data, år gamle data fremdeles selvfølgelig har verdi, historisk analyse, trendanalyse, er det live-dataene som driver live-intelligensen i disse dager, og det er derfor streaming av analyse har blitt så viktig.
Jeg snakker mer om det i dag. Vi har dataforskeren vår, Dez Blanchfield, som ringer inn fra Australia. Det er tidlig på morgenen for ham akkurat nå. Vi har vår sjefanalytiker, Dr. Robin Bloor. Vi får selskap av Anand Venugopal, produktleder for StreamAnalytix hos Impetus Technologies. De er veldig fokusert på streaminganalyse aspektet av dette rommet.
Med det kommer jeg til å videreføre det til Dez.
Dez Blanchfield: Takk. Jeg trenger å ta tak i skjermen her og springe fremover.
Rebecca Jozwiak: Her går du.
Dez Blanchfield: Mens vi tar tak i lysbildene, la meg bare dekke kjernen.
Jeg kommer til å holde det ganske høyt nivå, og jeg holder det i omtrent 10 minutter. Dette er et veldig stort tema. Jeg deltok på et arrangement hvor vi brukte to til tre dager på å dykke ned i detaljene om hva strømforedling er og de nåværende rammene vi utvikler og hva å gjøre analyse i de høye volumstrømmene burde bety.
Vi skal bare klargjøre hva vi mener med strømming av analyser og deretter undersøke om forretningsverdi kan avledes fordi det virkelig er det bedrifter leter etter. De ser ut til å få folk til å forklare dem veldig raskt og kortfattet, hvor kan jeg hente verdi ved å bruke en form for analyse på strømningsdataene våre?
Hva er streaminganalyse?
Streaminganalyse gir organisasjoner en måte å hente ut verdier fra data om høyt volum og høy hastighet som de har kommet gjennom virksomheten i forskjellige former i bevegelse. Den vesentlige forskjellen her er at vi har hatt en lang historie med å utvikle analyser og linser og synspunkter på data som vi har behandlet i ro i flere tiår siden mainframe ble oppfunnet. Det enorme paradigmeskiftet vi har sett de siste tre til fem årene på det vi kaller "web-skala", tapper inn datastrømmene som kommer inn i oss i sanntid eller nær sanntid, og ikke bare behandler og ser etter sammenheng med hendelser eller hendelsesutløsere, men utfører virkelig detaljerte, dyptgående analyser av disse strømningene. Det er et betydelig skifte til det vi har gjort før, som enten er å samle inn data, legge dem inn i en slags depot, tradisjonelt store databaser nå, store big data-rammer som Hadoop-plattformen og utføre batch-modus-behandling på det og få en slags innsikt.
Vi har blitt veldig flinke til å gjøre det veldig raskt og prøve masse tungt jern på tingene, men vi fremdeles henter data, lagrer og så ser på det og får en slags innsikt eller analyser om det. Overgangen til å utføre disse analysene når dataene strømmer inn har vært et veldig nytt og spennende vekstområde for de typer ting som skjer rundt big data. Det krever en helt annen tilnærming for å bare fange, lagre og behandle og utføre analyser på.
En av de viktigste driverne for skift og fokus for å utføre analyser i strømmen er at du kan få betydelig forretningsverdi ved å få den innsikten raskere og lettere etter hvert som dataene kommer til deg, ettersom informasjon blir gjort tilgjengelig for bedriften. Ideen om å utføre sluttdagsbehandling nå er ikke lenger relevant i visse bransjer. Vi vil være i stand til å gjøre analysene mens du er på farten. På slutten av dagen vet vi allerede hva som har skjedd, siden det har skjedd i stedet for å komme til slutten av dagen og gjøre en 24-timers batchjobb og få den innsikten.
Streaminganalysen handler om å tappe rett inn i den strømmen mens datastrømmer vanligvis er flere strømmer med veldig høye datamengder og data som kommer mot oss veldig raskt, raskt og får innsikt eller analyse av disse strømningene når de kommer til oss i motsetning å la det komme ut i ro og utføre analyser på dem.
Som jeg nevnte, har vi hatt flere tiår og tiår med å utføre det jeg kaller batchanalyse. Jeg har lagt et veldig kult bilde her. Dette er et bilde av en herre som sto foran en hånlig datamaskin som ble opprettet av RAND Corporation for en levetid siden, og det var slik de så på en datamaskin i et hus for å se ut. Det som er interessant er at selv da hadde de dette konseptet med alle disse små ringene, og disse skiven representerte informasjon som kom inn fra huset og ble behandlet i sanntid og fortalte deg hva som skjer. Et enkelt eksempel er et sett med barometrisk trykk og temperatur som vi kan se hvor vi ser hva som skjer i sanntid. Men jeg ser for meg at til og med veien da RAND Corporation samlet det lille mockupet, tenkte de allerede på å behandle data og utføre analyser på det når det kommer i strømformat. Jeg er ikke helt sikker på hvorfor de satte rattet på datamaskinen, men det er ganske kult.
Siden oppfinnelsen av skriveren har vi sett på å fange data og utføre batchanalyser på dem. Som jeg har sagt med det store skiftet nå, og vi har sett dette fra slike som nettbaserte spillere som vi alle kjenner, de er alle husholdningsmerker som Twitter, Facebook og LinkedIn, den interaktive oppførselen som vi har med de sosiale plattformer krever ikke bare å fange opp, lagre og deretter behandle i batchmodus, men de er faktisk å fange opp og drive analyser på farten fra datastrømmene som kommer gjennom. Når jeg Tweetet noe, trenger de ikke bare å fange opp og lagre og gjøre noe senere, men de må også kunne legge det umiddelbart tilbake på strømmen min og dele det med andre mennesker som følger meg. Det er en batch-prosesseringsmodell.
Hvorfor skulle vi gå denne ruten? Hvorfor skulle organisasjoner investere tid, krefter og penger i å selv vurdere utfordringen med å forsøke å gå nedover for strømanalyse? Organisasjoner har dette enorme ønsket om å oppnå en ytelsesgevinst over sine konkurrenter i bransjene som de er i, og at ytelsesgevinst raskt kan implementeres gjennom enkel strømanalyse og den kan starte på en enkel sporing av sanntidsdata som vi allerede har kjent med. Jeg fikk et lite skjermbilde der av Google Analytics. Dette er sannsynligvis en av de første gangene vi virkelig fikk den praktiske analysen av forbrukerklasse. Så mens folk besøkte nettstedet ditt, og du får disse trefftellingene, med et lite stykke JavaScript på bunnen av websiden din i HTML innebygd på nettstedet ditt, ble disse små kodene laget i sanntid tilbake til Google, og de var utføre analyser av datastrømmene som kommer inn fra hver side på nettstedet ditt, alle objekter på nettstedet ditt i sanntid, og de sender det tilbake til deg på denne virkelig søte lille hjemmesiden i et dashbord med grafikk i sanntid, søte små histogrammer og linjediagram som viser deg X antall personer som treffer siden din historisk, men her er hvor mange det er akkurat nå.
Som du kan se på det skjermbildet, står det 25 akkurat nå. Det er 25 personer akkurat nå da skjermbildet var på den siden. Det er den første virkelige sjansen vi spilte på analyseverktøy for forbrukerklasse. Jeg tror mange mennesker virkelig har det. De forsto bare kraften i å vite hva som foregikk og hvordan de kan svare på det. Når vi tenker på omfanget av luftfart, fly som flyr rundt, er det som 18 700 innenriksflyvninger om dagen bare i USA. Jeg leste et papir for en tid tilbake - det var for rundt seks eller syv år siden - at datamengden som ble produsert av disse flyene var omtrent 200 til 300 megabyte i den gamle ingeniørmodellen. I dagens design av fly produserer disse flyene rundt 500 gigabyte med data eller omtrent en halv terabyte med data per flyvning.
Når du gjør regnestykket veldig raskt fra toppen av hodet ditt, at 18 700 innenriksflyvninger hver 24. time i det amerikanske luftrommet alene, hvis alle de moderne flyene produserer omtrent en halv terabyte, er det 43 til 44 petabyte med data som kommer gjennom og det skjer mens flyene er i lufta. Det skjer når de lander og de gjør datadumps. Det er da de går inn i butikken og har en full data dump fra ingeniørteamene for å se på hva som skjer i lagrene, hjulene og inni motorene. Noen av disse dataene må behandles i sanntid, slik at de kan ta beslutninger om det er et reelt problem mens flyet var i lufta eller mens det er på bakken. Du kan bare ikke gjøre det i batchmodus. I andre bransjer som vi ser der ute rundt økonomi, helse, produksjon og ingeniørarbeid, ser de også på hvordan de kan få tak i denne nye innsikten i hva som skjer i sanntid i motsetning til hva som bare lagres i databasene på en begrep.
Det er også dette konseptet med å håndtere data som det jeg kaller en bedervelig vare eller en lett bedervelig vare - at mye data mister verdi over tid. Dette er mer og mer tilfelle med mobilitetsapper og sosiale medieverktøy fordi det folk sier og det som nå er trending nå, er det du vil svare på. Når du tenker på andre deler av livene våre med logistikk og frakt på mat, forstår vi begrepet forgjengelig vare i den forstand. Men tenk på dataene som går gjennom organisasjonen din og verdien den har. Hvis noen gjør noe med deg akkurat nå, og du kan samhandle med dem i sanntid, vil du ikke vente i en time slik at dataene kan fanges opp og settes inn i et system som Hadoop og deretter trykke på denne knappen, vil ikke være i stand til å takle det akkurat nå, og du vil kunne gjøre det på kundens etterspørsel umiddelbart. Det er et begrep du vil dukke opp mye nå der folk snakker om å ha denne datastrømmen i sanntid som kan gi deg tilpasning, og at tilpasningen stemmer overens med systemet du bruker til din individuelle opplevelse. Så når du for eksempel treffer et verktøy som Google Søkeverktøy, hvis jeg forespørsler og gjør samme spørsmål, alltid, får vi ikke nøyaktig de samme dataene. Vi får i det vesentlige det jeg omtaler som en kjendisopplevelse. Jeg blir behandlet med en engang. Jeg får min egen personlige versjon av hva som skjer i disse systemene basert på profilene og dataene som de har samlet på meg, og jeg var i stand til å analysere i sanntid i strømmen.
Denne ideen om at data skal være en bedervelig vare er en ekte ting for nå, og verdien av data som blir redusert over tid er noe vi må håndtere i dag. Det er ikke en ting i går. Jeg elsker dette bildet av en bjørn som griper en laks som hopper ut av elven fordi den virkelig maler nøyaktig det jeg ser streaminganalyse. Det er denne enorme elven med data som kommer til oss, en brannslange hvis du vil, og bjørnen sitter midt i bekken. Det kommer til å utføre sanntidsanalyse av hva som skjer rundt det slik at det faktisk kan konstruere sin evne til å fange den fisken i luften. Det er ikke som bare å dyppe i strømmen og ta tak i en. Denne tingen hopper i luften, og den må være på rett sted til rett tid for å fange den fisken. Ellers får han ikke frokost eller lunsj.
En organisasjon vil gjøre det samme med dataene sine. De ønsker å hente ut verdi fra det som nå er store datamengder i bevegelse. De ønsker å utføre analyser av dataene og data med høy hastighet, så det er ikke bare datamengden som kommer til oss, men det er hastigheten de kommer fra dette. I sikkerhet, for eksempel, er det alle rutere, brytere, servere, brannmurer og alle hendelsene som kommer fra disse og titusenvis om ikke hundretusener av enheter, i noen tilfeller som er bedervelige data. Når vi tenker på det på tingenes internett og det industrielle Internett, snakker vi om millioner om ikke milliarder av sensorer etterhvert, og når dataene kommer igjennom som utfører analyser, ser vi nå på å gjøre komplekse hendelsesbehandlinger på bestillinger av styrke og hastighet som vi aldri en gang har sett før, og vi må håndtere dette i dag. Vi må bygge verktøy og systemer rundt det. Det er en virkelig utfordring for organisasjoner fordi vi på den ene siden har de veldig store merkevarene som gjør DIY, baker det selv, når de har kapasitet til å gjøre det og ferdighetssett og prosjektering. Men for den gjennomsnittlige organisasjonen er det ikke tilfelle. De har ikke ferdighetene. De har ikke kapasitet eller tid eller penger til å investere i å finne ut av det. De sikter alle mot dette konseptet om beslutningsprosesser nær sanntid.
Bruk saker som jeg har kommet over, og de er på tvers av alle brede spekter av alle sektorer som du kan forestille deg, folk sitter og oppmerker seg og sier: Hvordan bruker vi noen analyser på strømningsdataene våre? Vi snakker om nettbaserte tjenester på nettet. Det er de tradisjonelle sosiale medieplattformene og online e-tailing og detaljhandel - for eksempel apper. De prøver alle å gi oss denne kjendisopplevelsen i sanntid. Men når vi kommer inn på flere av teknologibunketjenestene, telefontjenester, tale og video, ser jeg folk gå rundt og gjør FaceTime på telefoner. Det eksploderer bare. Det pirrer tankene mine at folk holder telefonen foran seg og snakker med en videostrøm av en venn i motsetning til å holde den i øret lenger. Men de vet at de kan gjøre det, og de tilpasset seg, og at de likte den opplevelsen. Utviklingen av disse applikasjonene og plattformene som leverer disse, må utføre analyser i sanntid på den trafikken og på profilene til trafikken, slik at de kan gjøre enkle ting som å rute den videoen perfekt, slik at kvaliteten på stemmen i videoen du får er tilstrekkelig for å få en god opplevelse. Du kan ikke behandle den typen data. Det ville ikke gjøre sanntids videostrømmen til en funksjonell tjeneste.
Det er en styringsutfordring i finansielle transaksjoner. Det er ikke greit å komme til slutten av dagen og finne ut at du brøt loven som flyttet private data rundt på stedet. I Australia har vi en veldig interessant utfordring der å flytte personvernrelaterte data offshore er et nei-nei. Du kan ikke ta PID-en, mine personlige identifikasjonsdata, offshore. Det er lover i Australia for å hindre at det skjer. Tilbyderne av finansielle tjenester, spesielt myndighetstjenester og byråer, må de foreta sanntidsanalyse av datastrømmene og instruksjonene med meg for å sikre at det de gir meg ikke forlater bredden. Alle tingene må bo lokalt. De må gjøre det sanntid. De kan ikke bryte loven og be om tilgivelse senere. Bedragerietektering - det er ganske opplagt som vi hører om med kredittkorttransaksjoner. Men ettersom de typene transaksjoner vi gjør i finansielle tjenester endrer seg veldig, veldig raskt, er det mange ting PayPal gjør først nå for å oppdage svindel i sanntid der penger ikke går fra en ting til en annen, men det er en økonomisk transaksjon mellom systemer. Ebay budplattformer, oppdage svindel må gjøres i sanntid i et streamingkontor.
Det er en trend som beveger seg nå for å utføre ekstraksjon og transformere belastningsaktivitet i bekker, slik at vi ikke vil fange noe som kommer til strømmen. Vi kan ikke virkelig gjøre det. Folk har lært at data liker å bli brutt veldig raskt hvis vi fanger opp alt. Trikset nå er å utføre analyser på disse bekker og gjøre ETL på det og bare fange opp det du trenger, potensielt metadata, og deretter kjøre prediktiv analyse der vi faktisk så kan fortelle hva som kommer til å skje litt lenger ned i traseene på det vi har nettopp sett i strømmen basert på analysene vi utførte på det.
Leverandører av energi og verktøy opplever dette enorme ønsket fra forbrukere om å ha etterspørselspriser. Jeg bestemmer meg kanskje for at jeg vil kjøpe grønn strøm på et bestemt tidspunkt av dagen, fordi jeg bare er hjemme alene og ikke bruker mange enheter. Men hvis jeg har et middagsselskap, vil jeg kanskje ha alle enhetene mine på, og jeg vil ikke kjøpe billig strøm og vente på at den skal leveres, men er villig til å betale for mer kostnader for å få den kraften. Dette etterspørselsprissettingen spesielt innen verktøy og energirom har allerede skjedd. Uber er for eksempel et klassisk eksempel på ting du kan gjøre hver dag, og det hele er drevet av etterspørselspriser. Det er noen klassiske eksempler på at folk i Australia får $ 10.000 billetter på grunn av den enorme etterspørselen på nyttårsaften. Jeg er sikker på at de har taklet det problemet, men stream analyser som blir utført i sanntid mens du er i bilen og forteller deg hvor mye jeg skal betale.
Internet of Things og sensorstrømmer - vi har bare skrapet på overflaten på dette, og vi har egentlig bare hatt den grunnleggende samtalen på dette, men vi vil se et interessant skifte i hvordan teknologien takler det fordi når du snakker ikke omtrent tusenvis eller titusenvis, men hundretusener og potensielt milliarder av enheter som strømmer til deg, nesten ingen av de teknologibunker vi har nå, er konstruert for å takle det.
Det er noen veldig varme temaer vi ser rundt på stedet som sikkerhet og cyberrisiko. De er veldig virkelige utfordringer for oss. Det er et skikkelig pent verktøy som heter North på nettet der du kan sitte og se på en webside en rekke cyberattacks som skjer i sanntid. Når du ser på den, tenker du at "å, det er en fin søt liten webside", men etter omtrent fem minutter der inne, innser du datamengden som systemet gjør analyse på alle de forskjellige strømmer på alle de forskjellige enhetene rundt om i verden. som blir ført inn i dem. Det begynner å forstyrre tankene om hvordan de presterer det i utkanten av den posten, og gir deg den enkle lille skjermen som forteller deg hva du skal eller noe annet som angriper den i sanntid og hvilke typer angrep. Men det er en veldig fin måte å bare få en god smak på hva strømanalyse potensielt kan gjøre for deg i sanntid ved å bare se på denne siden og få en følelse av bare volumet og utfordringen med å ta strømmer, behandle analysesøk på dem og representerer det i sanntid.
Jeg tror samtalen jeg har for resten av økten kommer til å ta opp alle disse typene med ett interessant synspunkt, fra mitt synspunkt, og det er utfordringen til DIY, bake det selv, passer til noen av de klassiske enhjørninger som har råd til å bygge slike ting. De har milliarder av dollar til å bygge disse ingeniørteamene og bygge sine datasentre. Men for 99, 9% av organisasjonene der ute som ønsker å drive verdi i sin virksomhet med strømanalyse, trenger de å få en hylle-tjeneste. De trenger å kjøpe et produkt ut av esken, og de trenger vanligvis konsulenttjeneste og profesjonell service for å hjelpe dem med å implementere det, og de får den verdien tilbake i virksomheten og selger det tilbake til bedriften som en fungerende løsning.
Med det vil jeg gi deg tilbake, Rebecca, fordi jeg tror det er det vi skal dekke i detalj nå.
Rebecca Jozwiak: Utmerket. Tusen takk, Dez. Det er en flott presentasjon.
Nå vil jeg gi ballen videre til Robin. Ta den bort.
Robin Bloor: OK. Fordi Dez har gått inn i den pussige og stramme behandlingen av strømmer, så det ikke ut til å være fornuftig for meg å dekke det igjen. Så jeg skal bare ta et helt strategisk syn. Ser nesten fra et veldig høyt nivå ned på hva faen foregår og plasserer det fordi jeg tror det kan hjelpe mennesker, spesielt oss mennesker som ikke er leiret i strømmer som behandles på stor dybde før.
Behandling av strømmer har eksistert i lang tid. Vi kalte det CEP. Det var sanntidssystemer før det. De originale prosesskontrollsystemene behandlet faktisk informasjonsstrømmer - selvfølgelig gikk ingenting så langt som det er i dag. Denne grafikken som du ser på lysbildet her; det peker på mange ting faktisk, men det peker utover alt annet - det faktum at det er et spekter av forsinkelser som vises i forskjellige farger her nede. Det som faktisk skjedde siden oppfinnelsen av databehandling eller kommersiell databehandling som kom til rundt 1960, er at alt bare har blitt raskere og raskere. Vi pleide å være avhengig av hvordan dette faktisk kom ut hvis du vil i bølger, for det er slik det ser ut. Dette avhenger faktisk av det. Fordi det hele ble drevet av Moores lov og Moores lov ville gi oss en faktor på omtrent ti ganger hastighet over en periode på omtrent seks år. Så når vi faktisk kom til omtrent 2013, brøt det hele sammen, og vi begynte plutselig å akselerere med en hastighet som vi aldri har, noe som er merkelig enestående. Vi fikk en faktor på omtrent ti når det gjelder økning i hastighet og derfor en reduksjon i latenstid omtrent hvert sjette år. I løpet av de seks årene siden cirka 2010, har vi en multippel på minst tusen. Tre størrelsesordrer fremfor ett.
Det er det som har foregått, og det ser ut til at bransjen på en eller annen måte ser ut til å bevege seg i fantastiske hastigheter - for det er det. Bare gjennom betydningen av denne grafikken, er responstidene forresten faktisk i algoritmisk skala nedover den vertikale aksen. Sanntid er datahastighet, raskere enn mennesker. Interaktive tider er oransje. Det er når du samhandler med datamaskinen, det er der du virkelig ønsker en tiendedel til omtrent ett sekund med forsinkelse. Over er det transaksjoner der vi faktisk tenker på hva du gjør på datamaskinen, men hvis det går ut om femten sekunder blir det utålelig. Folk vil faktisk ikke vente på datamaskinen. Alt ble gjort i batch. Mange ting som ble gjort i batch, kommer nå ned i transaksjonsområdet, rett inn i det interaktive rommet eller til og med i sanntidsrommet. Mens tidligere, en bølgete med veldig små datamengder vi kunne gjøre noe av dette, kan vi nå gjøre med veldig store datamengder ved å bruke enormt skalert miljø.
Så i utgangspunktet, alt dette sier er virkelig transaksjonen og interaktive menneskelige responstider. Mye av det som blir gjort med bekker akkurat nå, er å informere mennesker om ting. Noe av det går raskere enn det, og det er å informere om ting så det er sanntid. Så tar vi en lisens for å bare slippe som en stein, noe som gjør øyeblikkelig analyse mulig og for øvrig ganske rimelig. Det er ikke bare farten har falt og toppen har bare kollapset også. Sannsynligvis den største innvirkningen i alle disse blant alle de forskjellige applikasjonene, kan du gjøre alle disse prediktive analysene. Jeg skal fortelle deg hvorfor om et øyeblikk.
Dette er bare jernvarehandel. Du har parallell programvare. Vi snakker om i 2004. Skaler ut arkitektur, flerkjernebrikker, minneøkning, konfigurerbar CPU. SSD-er går så mye raskere enn spinningsdisken. Du kan ganske mye bølgesnurrende disken farvel. SSD-er er i flere kjerner også, så igjen raskere og raskere. Snart dukker opp, har vi memristoren fra HP. Vi har fått 3D XPoint fra Intel og Micron. Løftet til dem er at det vil gjøre at det hele går raskere og raskere uansett. Når du faktisk tenker på to nye minneteknologier, som begge vil gjøre hele det grunnleggende lille stykket, det enkelte kretskort går langt raskere, har vi ikke en gang sett slutten på det.
Streams-teknologi, som egentlig er den neste meldingen, er her for å bli. Det kommer til å måtte være en ny arkitektur. Jeg mener at Dez har nevnt dette på flere punkter i presentasjonen. I flere tiår så vi på arkitektur som en kombinasjon av datahauger og datarør. Vi hadde en tendens til å behandle haugene og vi hadde en tendens til å røre dataene mellom hopene. Vi beveger oss nå grunnleggende mot det vi kaller Lambda-dataarkitekturen som kombinerer behandlingen av datastrømmer med datahauger. Når du faktisk behandler en strøm av hendelser som kommer inn mot historiske data som en dataflyt eller en dataheap, er det hva jeg mener med Lambda-arkitekturen. Dette er i sin spede begynnelse. Det er bare en del av bildet. Hvis du vurderer noe så komplekst som Internett av alt som Dez også har nevnt, vil du faktisk innse at det er alle slags datalokasjonsproblemer - beslutninger om hva du skal behandle i strømmen.
Det jeg virkelig sier her, er at da vi behandlet i batch, behandlet vi strømmer. Vi kunne bare ikke gjøre det en om gangen. Vi bare venter til det er en stor masse ting, og så behandler vi alt på en gang. Vi flytter til en situasjon der vi faktisk kan behandle ting i strømmen. Hvis vi kan behandle ting i strømmen, vil datahaugene som vi har, være de statiske dataene vi må henvise for å behandle dataene i strømmen.
Dette fører oss til akkurat denne tingen. Jeg har nevnt dette før i en presentasjon med den biologiske analogien. Måten jeg ønsker at du skal tenke på er i øyeblikket vi mennesker. Vi har tre distinkte nettverk for prediktiv prosessering i sanntid. De kalles det somatiske, autonome og enteriske. Det enteriske er magen din. Det autonome nervesystemet passer på kamp og flyreiser. Den ser faktisk etter raske reaksjoner på miljøet. Somatikken som ser etter bevegelsen av kroppen. Dette er sanntidssystemer. Det interessante med det - eller jeg synes er ganske interessant - er at mye av det er mer forutsigbart enn du noen gang skulle forestille deg. Det er som om du faktisk ser på en skjerm rundt 18 tommer fra ansiktet ditt. Alt du kan se tydelig, alt som kroppen din er i stand til å se tydelig handler faktisk om et 8 × 10 rektangel. Alt utenom det er faktisk uskarpt for kroppen din, men sinnet ditt fyller faktisk hullene og gjør at det ikke blir uskarpt. Du ser ikke noe uskarphet i det hele tatt. Du ser det tydelig. Sinnet ditt gjør faktisk en prediktiv metode for datastrømmen for at du skal se den klarheten. Det er litt av en merkelig ting, men du kan faktisk se på hvordan nervesystemet fungerer, og måten vi klarer å komme oss rundt på og oppføre oss rimelig - i alle fall noen av oss - med rimelig mening og ikke støte på ting hele tiden.
Det hele gjøres av en serie nevrale analyseskalaer her inne. Det som kommer til å skje er at organisasjoner kommer til å ha den samme typen ting og kommer til å bygge den samme typen ting, og det kommer til å bli prosessering av strømmer inkludert de interne strømningene i organisasjonen - de tingene som skjer innen det, tingene som skjer utenfor det, de umiddelbare svarene som faktisk må gjøres, er selvfølgelig å føde mennesket til å ta beslutninger, for å få alle disse til å skje. Det er dit vi skal, så langt jeg kan se.
Noe av det som er en konsekvens av det, er at nivået på strømningsapplikasjonen går bra. Det kommer til å bli veldig mye mer enn vi ser nå. Akkurat nå plukker vi den lavthengende frukten av å gjøre de tingene som er åpenbare.
Så uansett er det konklusjonen her. Streaminganalyse er en gang en nisje, men det begynner å bli mainstream og det vil snart bli vedtatt generelt.
Med det vil jeg gi det tilbake til Rebecca.
Rebecca Jozwiak: Tusen takk, Robin. Flott presentasjon som vanlig.
Anand, du er oppe neste gang. Gulvet er ditt.
Anand Venugopal: Fantastisk. Takk skal du ha.
Jeg heter Anand Venugopal og er produktansvarlig for StreamAnalytix. Det er et produkt som tilbys av Impetus Technologies, fra Los Gatos, California.
Impetus har faktisk hatt en stor historie med å være en leverandør av store dataløsninger for store bedrifter. Så vi har faktisk gjort en rekke streaminganalyse-implementeringer som et serviceselskap, og vi har lært mye leksjoner. Vi tok også et skifte til å bli et produktbedrift og løsningsdrevet selskap de siste par årene, og strømanalyse leder anklagen for å transformere Impetus til et stort sett produktdrevet selskap. Det er noen viktige, veldig, veldig sentrale eiendeler som Impetus tømte takket være vår eksponering for bedrifter, og StreamAnalytix er en av dem.
Vi er 20 år i bransjen, og det er en flott blanding av produkter og tjenester som gjør oss til en enorm fordel. Og StreamAnalytix ble født av alle lærdommene fra de første fem eller seks implementeringene av streaming.
Jeg vil berøre noen få ting, men analytikerne, Dez og Robin, har gjort en fantastisk jobb med å dekke plassen generelt, så jeg kommer til å hoppe over mye innhold som overlapper hverandre. Jeg vil nok gå fort. Vi ser foruten ekte strømningssaker som bruker mye bare batchakselerasjon der det bokstavelig talt er veldig, veldig viktige batchprosesser i bedrifter. Som du kan se, kan hele denne syklusen med å føle en hendelse og analysere og handle på det faktisk ta flere uker i store bedrifter, og de prøver alle å krympe den ned til minutter og noen ganger sekunder og millisekunder. Så noe raskere enn alle disse batch-prosessene er kandidater for virksomhetsoppkjøp, og det er veldig bra at verdien av data drastisk reduseres med alderen, så jo mer verdi er det i den innledende delen i løpet av sekundene at det nettopp skjedde. Ideelt sett, hvis du kunne forutsi hva som skulle skje, er det den høyeste verdien. Dette avhenger av nøyaktighet. Den neste høyeste verdien er når den er der når den skjer, du kan analysere den og svare. Selvfølgelig reduserer verdien dramatisk etter det, den viktigste restriksjonelle BI som vi er i.
Det er interessant. Du kan forvente noe dramatisk vitenskapelig svar på hvorfor streaming analytics. I mange tilfeller er det vi ser fordi det er mulig nå, og fordi alle vet at partiet er gammelt, partiet er kjedelig og at partiet ikke er kult. Det er nok utdanning som alle har hatt nå på det faktum at det er streaming mulig, og alle har Hadoop nå. Nå har Hadoop-distribusjoner en streamingteknologi innebygd i seg, enten det er Storm- eller Spark-streaming og selvfølgelig meldingskøer, som Kafka, etc.
Foretak vi ser hopper inn i det og begynner å eksperimentere med disse sakene, og vi ser to brede kategorier. Den ene har noe å gjøre med kundeanalyse og kundeopplevelse og den andre operasjonelle intelligensen. Jeg kommer litt nærmere inn på detaljene om det litt senere. Hele kundeservicen og kundeopplevelsesvinkelen, og vi i Impetus StreamAnalytix har gjort dette på mange forskjellige måter handler egentlig om virkelig, virkelig fange opp flerkanalsengasjementet til forbrukeren i sanntid og gi dem veldig, veldig kontekstsensitive opplevelser som ikke er vanlig i dag. Hvis du surfer på nettet, på Bank of America-nettstedet, og du undersøkte noen produkter, og du ringer bare til kundesenteret. Ville de sagt: "Hei Joe, jeg vet at du undersøkte noen bankprodukter, vil du at jeg skal fylle deg ut?" Du forventer ikke det i dag, men det er den typen opplevelse som virkelig er mulig med streaminganalyse. I mange tilfeller utgjør det en stor forskjell, spesielt hvis kunden begynte å undersøke måter å komme seg ut av kontrakten med deg ved å se på klausuler om tidlig oppsigelse eller vilkår og betingelser for tidlig oppsigelse på nettstedet ditt og deretter ringe inn og du ikke kan direkte konfrontere dem om det, men bare indirekte gi et tilbud om en slags første kampanje fordi systemet vet at denne personen ser på tidlig oppsigelse, og når du gir det tilbudet på det tidspunktet, kan du meget godt beskytte den usle kunden og beskytte den eiendelen .
Det vil være ett eksempel, pluss at mange kundetjenester er veldig gode eksempler. Vi implementerer i dag, reduserer kostnadene i kundesenteret, så vel som gir dramatiske herlige kundeopplevelser. Dez gjorde en god jobb med å oppsummere noen av brukstilfellene. Du kan stirre på dette diagrammet i et par minutter. Jeg klassifiserte det som vertikaler, horisontale og kombinasjonsområder, IoT, mobilapp og call center. De er alle vertikale og horisontale. Det kommer an på hvordan du ser på det. Kort sagt ser vi en god del horisontale bruksområder som er ganske vanlige på tvers av bransjens vertikaler, og det er vertikale spesifikke brukssaker som inkluderer finansielle tjenester, helsevesen, telekom, produksjon osv. Hvis du virkelig stiller deg selv spørsmålet eller forteller deg selv det, “å, jeg vet ikke hvilke brukssaker det er. Jeg er ikke sikker på om det virkelig er noen forretningsverdi i å streame analyser for selskapet mitt eller for vårt selskap, ”tenk hardt, tenk to ganger. Snakk med flere mennesker fordi det er brukssaker som i ditt selskap er aktuelle i dag. Jeg kommer inn på forretningsverdien på hvordan nøyaktig forretningsverdien er avledet.
På bunnen av pyramiden her har du forutsigbar vedlikehold, sikkerhet, beskyttelse mot kvern, etc. Disse typer brukssaker utgjør beskyttelse av inntekter og eiendeler. Hvis Target beskyttet sikkerhetsbruddet deres som skjedde over timer og uker, kunne CIO ha reddet jobben sin. Det kan spare titalls eller hundrevis av millioner av dollar osv. Analyse av strømming i sanntid hjelper virkelig med å beskytte disse eiendelene og beskytte tap. Det er direkte forretningsverdi akkurat der.
Den neste kategorien blir mer lønnsom, senker kostnadene og får mer inntekter fra dagens drift. Det er effektiviteten til den nåværende bedriften. Dette er kategorien brukssaker som vi kaller operasjonell intelligens i sanntid der du får dyp innsikt i hvordan nettverket oppfører seg, hvordan kundedriften oppfører seg, hvordan forretningsprosessen oppfører seg og du kan finpusse alt dette i sanntid fordi du får tilbakemeldinger, får du varsler. Du får avvik, avvik i sanntid, og du kan raskt handle og skille prosessen som går utenfor grensene.
Du kan potensielt også spare mye penger i dyre kapitaloppgraderinger og ting du mener er nødvendige, som kanskje ikke er nødvendig hvis du optimaliserte nettverkstjenesten. Vi hørte om et tilfelle der en større telco utsatte en oppgradering på 40 millioner dollar i nettverksinfrastrukturen fordi de fant ut at de hadde nok kapasitet til å styre sin nåværende trafikk, noe som er ved å optimalisere og bedre gjøre den intelligente rutingen av trafikken og slike ting. Disse er alle mulig bare med en sanntidsanalyse og handlingsmekanisme som virker på den innsikten i sanntid.
Det neste nivået på verdiøkning er up-sell, cross-sell der det er muligheter for å tjene mer inntekter og fortjeneste fra dagens tilbud. Dette er et klassisk eksempel som mange av oss vet om at de har opplevd hvor, du tenker på i livet ditt der du er villig til å faktisk kjøpe et produkt i dag som ikke blir tilbudt deg. I mange, mange tilfeller, skjer det faktisk. Du har ting i tankene dine som du liker å kjøpe, som du vet at du vil kjøpe, at du har en oppgaveliste eller noe, som kona sa til deg, eller hvis du ikke har en kone, men du virkelig ønsket å kjøpe og du handler enten på en nettside eller samhandler i en butikk, butikken har ikke konteksten, har ikke intelligens til å beregne hva du måtte trenge. Derfor sikrer de ikke virksomheten. Hvis streaminganalyser kan brukes til å virkelig gi nøyaktige forutsigelser og som virkelig er mulig på hva som vil passe best til denne spesielle konteksten, er denne kunden på dette tidspunktet på dette stedet, det er mye salg og kryssalg, og det kommer igjen fra streaming analytics - å kunne ta en tilbøyelighetsavgjørelse om hva denne kunden sannsynligvis vil kjøpe eller svare på i det øyeblikket av sannhet når det er en mulighet. Derfor elsker jeg det bildet som Dez viste med bjørnen omtrent for å spise den fisken. Det er ganske mye det.
Vi tror også det er en stor kategori der av dramatiske, transformasjonsendringer i en virksomhet med å tilby helt nye produkter og tjenester ganske enkelt basert på observasjon av kundeatferd, alt basert på observasjonen av en annen virksomhets oppførsel. Hvis, la oss si, et telco eller et kabelselskap som virkelig observerer bruksmønstrene til kundene i hvilket segment av markedet han ser, hvilket program på hvilket tidspunkt osv., Så ender de opp med å lage produkter og tjenester som nærmest blir tigget for på en eller annen måte. Så hele konseptet med adferd på flere skjermer akkurat nå der vi nå nesten tar det for gitt at vi kan se TV- eller kabelinnhold på mobilappene våre. Noen av disse eksemplene kommer fra de nye produktene og tjenestene som blir tilbudt oss.
Jeg får komme inn på: "Hva er arkitekturhensynene til streaminganalyse?" Det er til slutt det vi prøver å gjøre. Dette er Lambda-arkitekturen der du blander historiske data og innsikt i sanntid og ser det på samme tid. Det er det Sigma muliggjør. Vi har alle gruppearkitekturen og bedriftsbildet i dag. Vi skinner inn i en slags BI-stabel og bruksstabel og Lambda-arkitekturen lagt til. Som hastighetslaget eller behovet og Lambda handler om å slå sammen de to innsiktene og se det på en kombinert måte, på en rik måte som kombinerer begge innsiktene.
Det er et annet paradigme kalt Kappa-arkitekturen som blir foreslått der antagelsen er at hastighetslaget er den eneste inngangsmekanismen som kommer til å vedvare på lengre sikt. Alt kommer til å komme gjennom dette fartslaget. Det kommer ikke en gang til å være en offline ETL-mekanisme. Alt ETL vil skje. Rens, datarensing, kvalitet ETL - alt dette vil skje på ledningen, fordi husk at alle data ble født i sanntid. På et tidspunkt var det sanntid. Vi har blitt så vant til å sette dette på innsjøer, på elver og hav, for så å gjøre det på statisk analyse at vi glemte at dataene ble født på et tidspunkt i sanntid. Alle data er faktisk født som en sanntidshendelse som skjedde i tidspunktet, og de fleste dataene i dag på sjøen ble nettopp satt på databasen for en senere analyse, og vi har nå fordelen i Lambda og Kappa arkitektur av faktisk å se den, analysere den, forarbeide den og reagere på den når den kommer. Det er dette som er muliggjort av disse teknologiene. Når du ser på det som et helhetsbilde, ser det ut som noe sånt der det er Hadoop inne, det er MPP-er og datavarehus du allerede har.
Vi legger opp dette fordi det er viktig å ikke bare snakke om nye teknologier på en øy. De må integreres. De må være fornuftige i den nåværende virksomhetssammenheng, og som løsningsleverandører som betjener bedrifter, er vi veldig følsomme for dette. Vi hjelper bedrifter med å integrere hele saken. Det er datakilder på venstre side som mater inn til både Hadoop og datavarehuslagene, så vel som til sanntidslaget på toppen, og hver av disse enhetene er lagermaskiner som du kan se, og dataforbrukssjiktet er til høyre side. Det arbeides kontinuerlig med å flytte flertallet av overholdelse, styring, sikkerhet, styring av livssykluser osv., Som er tilgjengelig i dag, alt har blitt samlet inn i denne nye teknologien.
En av tingene som stream analytics prøver å gjøre, hvis du ser på landskapet i dag, er det mange ting som skjer i streamingteknologilandskapet, og fra et bedriftskundes synspunkt er det så mye å forstå. Det er så mye å følge med på. Det er datainnsamlingsmekanismer på venstre side - NiFi, Logstash, Flume, Sqoop. Det er klart jeg har satt opp en ansvarsfraskrivelse som sier at den ikke er uttømmende. Kommer inn i meldingskøene og kommer deretter inn i open source streaming-motorer - Storm, Spark Streaming, Samza, Flink, Apex, Heron. Heron er sannsynligvis ikke åpen kildekode ennå. Jeg er ikke sikker på om det er det, fra Twitter. Disse strømningsmotorene fører deretter inn i eller støtter en konfigurasjonsanalytisk applikasjonskomponent som kompleks hendelsesbehandling, maskinlæring, prediktiv analyse, varslingsmodul, streaming ETL, berikende statistiske operasjonsfilter. Det er alt vi kaller nå operatører. Settet til disse operatørene når de er strenget sammen, ville potensielt også en viss tilpasset, i stor grad konkludert med om nødvendig, bli et strømningsapplikasjon som kjører på en streamingmotor.
Som en del av den kjeden av komponenter, må du også lagre og indeksere dataene i favorittdatabasen din, favorittindeksen. Du må kanskje også distribuere cache og igjen som fører inn i datavisualiseringslaget på høyre side på den øverste delen til kommersielle produkter eller open source-produkter, men til slutt trenger du et slags produkt for å visualisere disse dataene i sanntid. Noen ganger må du finne andre applikasjoner. Vi har alle sett at verdiene kun er avledet av handlingen du tar på innsikten, at handlingen kommer til å være en trigger fra en analytisk stabel til en annen applikasjonsstabel som kanskje endret det som er noe på IVR-siden eller utløser et call center utgående samtale eller noe sånt. Vi må ha disse systemene integrert og en mekanisme for streaming-klyngen din for å utløse andre applikasjoner for å sende data nedstrøms.
Det er den totale stabelen fra å gå fra venstre til høyre. Så har du servicelagene, mellomovervåkningen, generell sikkerhetstjenestelaget osv. Kommer til hvilke produkter som er der ute i bedriftsområdet som kundene ser som Hadoop-distribusjoner som alt har streaming som jeg sa, og det er kommersielle eller enkeltstående -vendere løsninger som åpenbart er i våre konkurrenter. Det er mange flere i landskapet som vi kanskje ikke har nevnt her.
Det du ser der er stort sett bedriftsbrukeren ser. Et komplekst og raskt utviklende teknologilandskap for strømbehandling, som du kan se. Vi fikk forenkle valget og brukeropplevelsen deres. Det vi tror bedrifter virkelig trenger, er den funksjonelle abstraksjonen av alt dette i en-stop-shop, brukervennlig grensesnitt som samler alle disse teknologiene som gjør det veldig enkelt å bruke og ikke avslører alle bevegelige deler og nedbrytningsproblemene og ytelsesproblemene og livssyklusvedlikeholdsproblemene til bedriften.
Funksjonalitetsabstraksjonen er en. Den andre delen er abstraksjon av streamingmotorer. Streamingmotorene og domenene med åpen kildekode kommer opp hver tredje, fjerde eller sjette måned nå. Det var Storm i lang tid. Samza kom opp og nå er det Spark Streaming. Flink løfter hodet og begynner å bli oppmerksom. Til og med Spark Streaming-veikartet, de lager en måte å potensielt bruke en annen motor for ren hendelsesbehandling fordi de også innser at Spark er designet for batch, og de gjør en vei i sin arkitektursyn og sitt veikart for potensielt å ha en annen motor for strømbehandling i tillegg til gjeldende mikrobatchmønster i Spark Streaming.
Det er en realitet at du må kjempe med at det kommer til å bli mye evolusjon. Du må virkelig beskytte deg mot den teknologifluxen. For som standard må du velge en og deretter leve med den, noe som ikke er optimalt. Hvis du ser på det på en annen måte, kjemper du mellom, “OK, jeg må kjøpe en egen plattform der det ikke er innesperring, det er ingen utnyttelse av åpen kildekode, kan være veldig høye kostnader og begrenset fleksibilitet kontra alle disse open source-stakkene der du måtte gjøre det selv. ”Som igjen sa det, det er mange kostnader og forsinkelser når jeg kommer til markedet. Det vi sier er StreamAnalytix er et eksempel på en flott plattform som trekker sammen enterprise class, pålitelig, enkelt leverandør, profesjonell service som støttes - alt det du virkelig trenger som bedrift og kraften i fleksibilitet i det åpne kildekos-økosystemet der en enkelt plattform bringer dem sammen - Ingest, CEP, analyse, visualisering og alt dette.
Det gjør også en veldig, veldig unik ting, som samler mange forskjellige teknologimotorer under én brukeropplevelse. Vi tror virkelig fremtiden handler om å kunne bruke flere strømningsmotorer fordi forskjellige brukssaker virkelig krever forskjellige streamingarkitekturer. Som Robin sa, det er et helt spekter av forsinkelser. Hvis du virkelig snakker om millisekund latensnivå, titalls eller til og med hundrevis av millisekunder, trenger du virkelig Storm på dette tidspunktet til det er et annet like modent produkt for mindre mildhet eller lempelig tidsramme og forsinkelser på kanskje i løpet av et par sekunder, tre, fire, fem sekunder, det området, så kan du bruke gniststrømming. Potensielt er det andre motorer som kan gjøre begge deler. Hovedpoenget, i et stort foretak, vil det være brukstilfeller av alle slag. Du vil virkelig at tilgangen og generaliteten skal ha flere motorer med en brukeropplevelse, og det er det vi prøver å bygge i StreamAnalytix.
Bare et raskt syn på arkitekturen. Vi kommer til å omarbeide dette litt, men egentlig er det flere datakilder som kommer inn på venstre side - Kafka, RabbitMQ, Kinesis, ActiveMQ, alle disse datakildene og meldingskøene kommer inn til strømbehandlingsplattformen der du får sette sammen en app, der du får dra og slippe fra operatører som ETL-er, alle tingene som vi snakket om. Under er det flere motorer. Akkurat nå har vi Storm og Spark Streaming som næringenes eneste og første enterprise-klasse streamingplattform som har flere moterstøtter. Det er en veldig unik, fleksibilitet vi tilbyr i tillegg til all den andre fleksibiliteten ved å ha dashboards i sanntid. CET-motor innebygd. Vi har den sømløse integrasjonen med Hadoop og NoSQL indekser, Solr og Apache indekser. Du kan lande til din favorittdatabase uansett hva det er og bygge applikasjoner veldig raskt og komme til å markedsføre seg veldig raskt og være fremtidssikker. Det er hele mantraet vårt i StreamAnalytix.
Med det tror jeg at jeg vil konkludere med merknadene mine. Kom gjerne til oss for flere spørsmål. Jeg vil gjerne holde gulvet åpent for spørsmål og spørsmål og paneldebatt.
Rebecca, over til deg.
Rebecca Jozwiak: Flott, ok. Tusen takk. Dez og Robin, har du noen spørsmål før vi overfører det til publikum Spørsmål og svar?
Robin Bloor: Jeg har et spørsmål. Jeg setter hodetelefonene på igjen slik at du kan høre meg. En av de interessante tingene, hvis du vennlig kunne fortelle meg dette, ser mye av det jeg har sett på åpen kildekode, ut hva jeg vil si umoden for meg. På en måte, ja, du kan gjøre forskjellige ting. Men det ser ut som om vi ser på programvare i den første eller andre utgivelsen i virkeligheten, og jeg lurte på med erfaringen din som organisasjon, hvor mye ser du umodenhet i Hadoop-miljøet som problematisk eller er det noe som ikke gjør det t skape for mange problemer?
Anand Venugopal: Det er en realitet, Robin. Du har helt rett. Umodenhet er ikke nødvendigvis i området bare funksjonell stabilitet og ting, men kanskje noen tilfeller av det også. Men umodenheten er mer i brukernes beredskap. Open-source-produktene når de kommer ut, og selv om de tilbys av Hadoop-distribusjonen, er de alle sammen forskjellige forskjellige dyktige produkter, komponenter bare klappet sammen. De fungerer ikke sømløst og er ikke designet for en jevn, sømløs brukeropplevelse som vi får som Bank of America eller Verizon eller AT&T, for å distribuere en streaming-analyse-applikasjon i løpet av uker. De er ikke designet for det med sikkerhet. Det er grunnen til at vi kommer inn. Vi tar det sammen og gjør det veldig enkelt å forstå, å distribuere osv.
Den funksjonelle modenheten for den, tror jeg i stor grad, er der. Mange store virksomheter bruker for eksempel Storm i dag. Mange store bedrifter leker med Spark Streaming i dag. Hver av disse motorene har sine begrensninger i hva de kan gjøre, det er derfor det er viktig å vite hva du kan og hva du ikke kan gjøre med hver motor, og det er ikke noe poeng i å bryte hodet mot veggen og si: “Se jeg valgte Spark Streaming, og det fungerer ikke for meg i denne bransjen. ”Det kommer ikke til å fungere. Det kommer til å være brukssaker der Spark Streaming kommer til å være det beste alternativet, og det kommer til å være brukstilfeller der Spark Streaming kanskje ikke fungerer i det hele tatt for deg. Derfor trenger du virkelig flere alternativer.
Robin Bloor: Vel, du må ha ekspertteam om bord for det meste av dette. Jeg mener jeg ikke en gang vet hvor jeg skal begynne med dette. En fornuftig samhandling av dyktige individer. Jeg er interessert i hvordan engasjementet du engasjerer deg og hvordan det skjer. Er det fordi et bestemt selskap er etter en spesifikk applikasjon, eller ser du slags hva jeg vil kalle strategisk adopsjon der de vil ha en hel plattform for å gjøre mange ting.
Anand Venugopal: Vi ser eksempler på begge deler, Robin. Noen av de ti beste merkevarene som alle vet, handler om det på en veldig strategisk måte. De vet at de kommer til å ha en rekke brukssaker, så de evaluerer plattformer som vil passe til det behovet, som er en rekke forskjellige brukssaker på en multi-leietaker måte som skal distribueres i en bedrift. Det er sakshistorier til engangsbruk som begynner også. Det er en spesiell brukssak for overvåkning av forretningsaktiviteter i et kredittforetak som vi jobber med som du ikke kan forestille deg som første brukssak, men det er forretningsløsningen eller bruksaken de kom frem til, og deretter koblet vi prikkene til strømming . Vi sa: "Vet du hva? Dette er en flott sak for streaminganalyse, og det er slik vi kan implementere det. ”Slik begynte det. Deretter, i den prosessen, blir de utdannet og sier: “Å wow, hvis vi kan gjøre dette, og hvis dette er en generisk plattform, så kan vi dele applikasjonen, lag dem i plattform og bygge mange forskjellige applikasjoner på dette plattform."
Robin Bloor: Dez, har du noen spørsmål?
Anand Venugopal: Dez er sannsynligvis på stum.
Dez Blanchfield: Unnskyldninger, stum. Jeg hadde bare en god samtale selv. Bare å følge den originale observasjonen av Robin, er du helt riktig. Jeg tror at utfordringen nå er at bedrifter har et økosystem og et kulturelt og atferdsmiljø der gratis og åpen kildekode-programvare er noe som er kjent for dem, og de kan bruke verktøy som Firefox som nettleser og det har hatt en anstendig levetid til den blir stabil og sikker. Men noen av de veldig store plattformene de bruker er egenutviklede plattformer. Så adopsjonen av det jeg anser som åpen kildekode-plattformer er ikke alltid noe som er lett for dem å kulturelt eller følelsesmessig komme over. Jeg har sett dette på tvers av bare adopsjonen av små programmer som var lokale prosjekter for bare å spille med big data og analytics som et grunnleggende konsept. Jeg tror en av de viktigste utfordringene, jeg er sikker på at du har sett dem nå på tvers av organisasjonene, er deres ønske om å få utfallet, men samtidig ha den ene foten sin sittende fast i den gamle boksen der de bare kunne kjøpe dette fra “Sett inn et stort merke” Oracle, IBM og Microsoft. Disse nye og kjente merkene kommer med Hadoop-plattformer og enda mer. Flere spennende merker kommer gjennom som har ledende teknologi som strøm.
Hva er slags samtaler du har hatt den slags få eller klipp gjennom det? Jeg vet at vi har et massivt oppmøte i morges, og en ting som jeg er sikker på at er i tankene på alle, er "Hvordan kutter jeg gjennom hele det utfordrende laget fra styre ned til ledernivå, det er for åpen kildekode og for blødende kant? "Hvordan går samtaler du har med klienter, og hvordan kutter du deg frem til det punktet der du på en slik måte frister de typer frykt for å vurdere å ta i bruk slike som StreamAnalytix?
Anand Venugopal: Vi synes faktisk det er ganske enkelt å selge vårt verdiforslag fordi kunder naturlig beveger seg mot åpen kildekode som et foretrukket alternativ. De gir ikke lett bare opp og sier: "Ok, jeg skal nå gå med åpen kildekode." De går faktisk gjennom en veldig engasjert evaluering av et hovedprodukt, la oss si at det er en IBM eller et typisk produkt, fordi de har disse leverandørforholdene. De vil ikke behandle oss eller open source-motoren mot det produktet. De vil gjennomgå seks til åtte til tolv ukers evaluering. De vil overbevise seg om at det er en viss grad av ytelse og stabilitet her som jeg vil, og så gjør de seg opp en mening med å si: "Wow, vet du hva, jeg kan faktisk gjøre dette."
I dag har vi for eksempel et stort nivå telco som har strømanalyse som går i produksjon på toppen av mye av stabelen, og de vurderer det mot en annen veldig, veldig stor kjent selger, og de var overbevist først etter at vi beviste alle ytelsen, stabiliteten og alle disse tingene. De tar det ikke for gitt. De fant ut at open source er kompetent gjennom evalueringene sine, og de er klar over at, i verste fall, "Kanskje det er de to brukssaker som jeg kanskje ikke kan gjøre, men de fleste av sakene mine om akselerasjonsbruk i dag er veldig mulige med open source stack. ”Og vi muliggjør bruk av den. Så det er det store søte stedet der. De ville ha åpen kildekode. De er virkelig ute etter å komme seg ut av leverandørens innesperringssituasjon de har vært vant til i mange, mange år. Så her kommer vi og sier: "Du vet hva, vi vil gjøre open source mye, mye enklere og vennlig å bruke for deg."
Dez Blanchfield: Jeg tror den andre utfordringen som bedriftene finner ut er når de får inn det tradisjonelle sittende, de ofte er en generasjon bak noe av den blødende kanten til de spennende tingene vi snakker om her, og jeg mener ikke det som en negativ liten. Det er bare at virkeligheten er at de har en generasjon og reise å gå gjennom for å frigjøre det de anser som stabile plattformer å gå gjennom, old-school utvikling og UATN-integrasjonssykluser og tester og dokumentasjon, og markedsføring og salg. Mens jeg ser på noen av de siste utgivelsene dine i går kveld, noe som jeg er interessert i å tenke på, den typen du gjør, så har du denne blandingen der du har kompetanse fra et konsultasjonssynspunkt og en implementering, men du har også en stabel som du kan rulle i. Jeg tror det er her de etablerte selskapene kommer til å slite i noen tid. Vi har sett mange av dem som jeg gjorde i markedet. De er ofte i det jeg kaller fangstnoder, mens fra det du forteller oss når du er der ute og lager disse samtalene og du er ute og implementerer.
Kan du gi oss et par eksempler på noen av kantlinjene som du har sett adopsjon? For eksempel er det virkelig nichey-miljø som rakettvitenskap og å sette satellitter i verdensrommet og samle inn data fra Mars. Det er bare en håndfull mennesker som gjør det på planeten. Men det er store vertikaler som helse, for eksempel innen luftfart, innen skipsfart og logistikk, innen industri og produksjon, hva er et par eksempler på de større og mer brede sektorer du har vært så langt at du har sett virkelig bra adopsjon i?
Anand Venugopal: Telco er et stort eksempel.
Jeg skal bare fikse lysbildene mine her. Klarer du å se lysbildet her, case study 4?
Dette er et tilfelle av en stor telco som tar inn set-top-box-data og gjør flere ting med det. De ser på hva kundene virkelig gjør i sanntid. De ser på hvor feil skjer i sanntid i set-top-bokser. De prøver å informere kundesenteret om, hvis denne kunden ringer inn akkurat nå, koden koblingsinformasjon fra denne kundens set-top-boks, informasjon om vedlikeholdsbillett raskt samsvarer med om denne kundens set-top-boks har et problem eller ikke før kunden snakker et ord. Hvert kabelselskap, hver større telco prøver å gjøre dette. De inntar data fra set-top-boksen, gjør sanntidsanalyser, gjør kampanjeanalyse slik at de kan plassere annonsene sine. Det er en enorm brukssak.
Som sagt er det dette kredittforetaket som igjen er et generisk mønster der store systemer er involvert i behandlingen av data fra. Dataene som flyter gjennom system A til system B til system C, og dette er regulerte virksomheter som alt må være konsistent. Ofte går systemer ut av synkronisering, ett system sier: "Jeg behandler hundre lån til en samlet verdi av $ 10 millioner." Systemet sier: "Nei, jeg behandler 110 lån til noen andre forskjellige nummer. ”De må løse det veldig raskt fordi de faktisk behandler de samme dataene og gjør forskjellige tolkninger.
Enten det er et kredittkort, lånebehandling, forretningsprosess eller om det er en pantelånsprosess eller noe annet, hjelper vi dem med å gjøre korrelasjon og avstemming i sanntid for å sikre at forretningsprosessene forblir synkroniserte. Det er en annen interessant brukssak. Det er en stor amerikansk regjeringsentreprenør som ser på DNS-trafikk for å gjøre anomali påvisning. Det er en offline treningsmodell som de bygde, og de gjør poengene basert på den modellen i sanntidstrafikk. Noen av de interessante brukssakene. Det er et stort flyselskap som ser på sikkerhetskøene, og de prøver å gi deg den informasjonen som: “Hei, det er porten til flyet ditt for flyturen. TSA-køen i dag er omtrent 45 minutter kontra to timer kontra noe annet. ”Du får den oppdateringen på forhånd. De jobber fortsatt med det. Interessant IoT-bruk tilfelle, men flott tilfelle av streaming analytics på vei til kundeopplevelsen.
Rebecca Jozwiak: Dette er Rebecca. Mens du handler om brukssaker, er det et stort spørsmål fra et publikum som lurer på: "Er disse casestudiene, blir disse initiativene drevet fra informasjonssystemets analytiske side av huset, eller blir de mer drevet fra virksomheten som har spesifikke spørsmål eller behov i tankene? ”
Anand Venugopal: Jeg tror vi ser omtrent 60 prosent, 50 til 55 prosent, stort sett veldig proaktive, entusiastiske teknologitiltak som tilfeldigvis vet, som tilfeldigvis er ganske kyndige og forstår visse krav til virksomheten, og de har sannsynligvis en sponsor som de identifisert, men dette er teknologiteam som gjør seg klar til angrep på saker om forretningsbruk som kommer igjennom, og når de først har bygd muligheten, vet de at de kan gjøre dette, og deretter gå til virksomhet og aggressivt selge dette. I 30 til 40 prosent av tilfellene ser vi at virksomheten allerede har en spesiell brukssak som ber om en strømningsanalytisk evne.
Rebecca Jozwiak: Det er fornuftig. Jeg har fått et annet litt mer teknisk spørsmål fra et publikummedlem. Han lurer på om disse systemene støtter både strukturerte og ustrukturerte datastrømmer, som sedimenter av Twitter-strømmer eller Facebook-innlegg i sanntid, eller må det først filtreres?
Anand Venugopal: Produktene og teknologiene som vi snakker om støtter veldig forestående både strukturerte og ustrukturerte data. De kan konfigureres. Alle data har en slags struktur enten det er en tekst eller en XML eller noe i det hele tatt. Det er en viss struktur i forhold til at det er et tidsstempelstrøm. Det er kanskje en annen klatt som må analyseres slik at du kan injisere parser i strømmen for å analysere datastrukturen. Hvis det er strukturert, så forteller vi bare systemet, "OK, hvis det er komma-separerte verdier, og den første er en streng, andre er en dato." Så vi kan injisere den parsing intelligensen i lagene på skjermen og behandle enkelt både strukturerte og ustrukturerte data.
Rebecca Jozwiak: Jeg har fått et annet spørsmål fra publikum. Jeg vet at vi har løpt litt forbi toppen av timen. Denne deltakeren ønsker å vite, det virker som om streaming-applikasjoner i sanntid kan utvikle både et behov og en mulighet for å integrere seg tilbake i transaksjonssystemer, forebyggingssystemer mot svindel de tar opp for eksempel. I så fall må transaksjonssystemer tilpasses for å passe til det?
Anand Venugopal: Det er en sammenslåing, ikke sant? Det er en sammenslåing av transaksjonssystemer. Noen ganger blir de datakilden der vi analyserer transaksjoner i sanntid og i mange tilfeller hvor vi kan si at det er en applikasjonsflyt, og her prøver jeg å vise et statisk dataoppslagsside og deretter i vårt tilfelle hvor en slags streaming i, og du leter opp en statisk database som en HBase eller en RDBMS for å berike strømningsdataene og de statiske dataene sammen for å ta en beslutning eller en analytisk innsikt.
Det er en annen stor næringstrend som vi også ser - konvergensen av OLAP og OLTP - og det er derfor du har databaser som Kudu og databaser i minnet som støtter både transaksjoner og analytisk behandling samtidig. Strømbehandlingssjiktet vil være helt i minnet, og vi ser på eller grensesnitt til noen av disse transaksjonsdatabasene.
Rebecca Jozwiak: Blandet arbeidsmengde har vært et av de siste hindrene for å hoppe, tror jeg. Dez, Robin, har dere to flere spørsmål?
Dez Blanchfield: Jeg kommer til å hoppe inn på det siste spørsmålet og gjøre opp om det hvis du ikke har noe imot det. Den første utfordringen som organisasjonene jeg har taklet med det siste tiåret eller så, og som ledet inn i denne spennende utfordringen med strømanalyse, er det første de pleier å legge igjen på bordet da vi startet samtalen rundt hele utfordringen. får vi ferdighetssettet? Hvordan omskolerer vi ferdighetssettet, og hvordan får vi den evnen internt? Å ha Impetus som kommer inn og hånden holder oss gjennom reisen og deretter implementere som et flott første skritt, og det er mye fornuftig å gjøre det.
Men for mellomstore til store organisasjoner, hva er hva slags ting du ser for øyeblikket for å forberede deg på dette, å bygge den evnen internt, å få alt fra bare et grunnleggende ordforråd rundt det og hva slags budskap kan de gjøre med organisasjonen rundt overgangen til denne typen rammer og gjenvinne deres eksisterende tekniske ansatte fra IT fra administrerende direktør, slik at de kan drive dette selv når du bygger og implementerer det? Bare veldig kort, hva slags utfordringer og hvordan løser de dem, kundene du har å gjøre med, hvilke utfordringer de fant og hvordan de går gjennom å løse den omskolering og gjenvinne erfaring og kunnskap for å gjøre deg klar til dette og å være klarer å gå rundt operativt?
Anand Venugopal: Ofte er det lille settet med mennesker som prøver å gå ut og kjøpe en streaming analytisk plattform allerede rimelig smart på grunn av at de er klar over Hadoop, de har allerede fått Hadoop MapReduce ferdighetene, og fordi de jobber tett med Hadoop distribusjonsleverandør, er de enten kjent. Alt får Kafka, for eksempel. De gjør noe med det, og enten Storm eller Spark-streaming er i deres åpen kildekode. Definitivt, folk er kjent med det eller bygger ferdigheter rundt det. Men det starter med et lite sett mennesker som er dyktige nok og er smarte nok. De deltar på konferanser. De lærer og at de stiller intelligente spørsmål til leverandører og i noen tilfeller lærer de med leverandørene. Når leverandørene kommer og presenterer på det første møtet, vet de kanskje ikke ting, men de leser sammen og begynner å leke med det.
Den lille gruppen mennesker er kjernen, og så begynner den å vokse, og alle innser nå at den første saken om bruken av virksomheten blir operasjonalisert. Det begynner en bølge og vi så på Spark-toppmøtet forrige uke hvor et stort foretak som Capital One var der ute og i full styrke. De valgte Spark. De snakket om det. De utdanner mange av sine mennesker i Spark fordi de bidrar til det også i mange tilfeller som bruker. Vi ser det samme med mange, mange store bedrifter. Det starter med noen få små sett med veldig smarte mennesker, og så begynner det en bølge av samlet utdanning og folk vet at en gang en senior VP eller en gang en senior direktør er i linje, og de vil satse på denne tingen og ordet kommer rundt og de begynner å plukke opp disse ferdighetene.
Dez Blanchfield: Jeg er sikker på at du har en fantastisk tid å bygge de mestrene også.
Anand Venugopal: Ja. Vi driver mye utdanning mens vi jobber med de første mesterne, og vi holder treningskurs, og mange, mange for de store kundene våre har vi gått tilbake og hatt bølger og bølger av trening for å bringe mange brukere til mainstream-bruksfasen, spesielt i Hadoop MapReduce side. Vi fant ut at i et stort kredittkortselskap som er en kunde hos oss, har vi levert minst fem til åtte forskjellige treningsprogrammer. Vi har også gratis samfunnsutgaver av alle disse produktene, inkludert våre, sandkasser som folk kan laste ned, bli vant til og utdanne seg på den måten også.
Dez Blanchfield: Det er alt jeg har denne morgenen for deg. Tusen takk. Jeg synes det er utrolig interessant å se hvilke modeller og bruksaker du har til oss i dag. Takk skal du ha.
Anand Venugopal: Flott. Tusen takk folkens.
Rebecca Jozwiak: Takk alle sammen for å delta i denne Hot Technologies webcasten. Det har vært fascinerende å høre fra Dez Blanchfield, Dr. Robin Bloor og fra Impetus Technologies, Anand Venugopal. Takk presentatører. Takk foredragsholdere og takk publikum. Vi har en ny Hot Technologies neste måned, så se etter det. Du kan alltid finne innholdet vårt arkivert på Insideanalysis.com. Vi legger også masse innhold på SlideShare og noen interessante biter på YouTube også.
Det var alt folkens. Takk igjen og ha en god dag. Ha det.
