Af Techopedia Staff, 24. februar 2016
Takeaway: Vært Rebecca Jozwiak diskuterer streaminganalyse med de bedste brancheeksperter.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Rebecca Jozwiak: Mine damer og herrer, hej og velkommen til Hot Technologies i 2016! Dagens titel er "Udnyttelse af ildslangen: At få forretningsværdi ved at streame Analytics." Dette er Rebecca Jozwiak. Jeg er den anden kommandant for webcast vært, når vores kære Eric Kavanagh ikke kan være her, så det er dejligt at se så mange af jer derude i dag.
Denne episode er lidt anderledes end vores andre. Vi talte slags om, hvad der er varmt, og selvfølgelig i år er varmt. De sidste flere år har været varmt. Der kommer altid nye ting ud. I dag taler vi om streaminganalyse. Streaming analytics er en slags nyt i sig selv. Naturligvis streaming, centerdata, RFID-data, disse er ikke nødvendigvis nye. Men i forbindelse med dataarkitekturer har vi været så fokuserede på data i hvile i årtier. Databaser, filsystemer, databaser - alt sammen til det meste af batchbehandling. Men nu med skiftet til at skabe værdi fra streaming af data, datafølelser, nogle kalder det levende strømme, kræver de virkelig en strømbaseret arkitektur, ikke de data i hvile-arkitekturer, som vi har været vant til, og de skal være i stand til håndtering af hurtig indtagelse, realtid eller nær realtidsbehandling. Det skal være i stand til ikke kun at imødekomme tingenes internet, men alt dets internet.
Selvfølgelig ville det ideelt være rart at have de to arkitekturer, der lever side om side, hvor den ene hånd vasker den anden, så at sige. Mens de dage gamle data, uger gamle data, år gamle data stadig naturligvis har værdi, historisk analyse, trendanalyse, er det de live data, der driver live intelligensen i disse dage, og det er derfor, streaming af analyse er blevet så vigtig.
Jeg taler mere om det i dag. Vi har vores dataforsker, Dez Blanchfield, der kalder ind fra Australien. Det er tidligt om morgenen for ham lige nu. Vi har vores chefanalytiker, Dr. Robin Bloor. Vi samles af Anand Venugopal, produktchef for StreamAnalytix hos Impetus Technologies. De er virkelig fokuseret på det streaming-analytiske aspekt af dette rum.
Med det vil jeg gå videre og videregive det til Dez.
Dez Blanchfield: Tak. Jeg er nødt til at gribe kontrollen over skærmen her og springe fremad.
Rebecca Jozwiak: Her går du.
Dez Blanchfield: Mens vi griber lysbillederne op, så lad mig bare dække kerneemnet.
Jeg vil holde det forholdsvis højt niveau, og jeg holder det i ca. 10 minutter. Dette er et meget stort emne. Jeg deltog i en begivenhed, hvor vi tilbragte to til tre dage på at dykke ned i detaljerne om, hvad strømforarbejdning er, og de nuværende rammer, som vi udvikler, og hvad det at gøre analyse i disse strømme med højt volumen skulle betyde.
Vi vil bare afklare, hvad vi mener med streaming-analyse og derefter undersøge, om forretningsværdi kan afledes, fordi det virkelig er, hvad virksomhederne leder efter. De ser ud til at få folk til at forklare dem meget hurtigt og kortfattet, hvor kan jeg udlede værdi ved at anvende en form for analyse til vores strømdata?
Hvad er streaminganalyse?
Streaminganalyse giver organisationer en måde at udtrække værdier fra data om højvolumen og høj hastighed, som de har gennem virksomheden i forskellige former i bevægelse. Den markante forskel her er, at vi har haft en lang historie med at udvikle analyser og linse og synspunkter på data, som vi har behandlet i hvile i årtier, siden mainframe blev opfundet. Det enorme paradigmeskifte, vi har set i de sidste tre til fem år, på det, vi kalder "webskala", tapper på strømmen af data, der kommer ind i os i realtid eller nær realtid, og ikke kun forarbejdning og udkig efter begivenhedskorrelation eller begivenhedsudløsere, men udfører virkelig detaljerede, dybdegående analyser af disse strømme. Det er et markant skift til det, vi har gjort før, som enten er at indsamle data, sætte dem i en slags depot, traditionelt store databaser nu, store big data-rammer som Hadoop-platformen og udføre batch-mode-behandling på det og få en slags indsigt.
Vi er meget gode til at gøre det meget hurtigt og prøve masser af tungt jern på tingene, men vi indfanger stadig virkelig data, lagrer og ser derefter på det og får en slags indsigt eller analyse af det. Skiftet til at udføre disse analyser, når dataene streamer i, har været et meget nyt og spændende vækstområde for de typer ting, der sker omkring big data. Det kræver en helt anden tilgang til bare at fange, gemme og behandle og udføre analyser på.
En af de vigtigste drivere for skift og fokus på at udføre analyser i strømmen er, at du kan få betydelig forretningsværdi ved at få disse indsigter hurtigere og lettere, når dataene kommer til dig, da information bliver gjort tilgængelig for virksomheden. Ideen om at udføre slutdato-behandling nu er ikke længere relevant i visse brancher. Vi ønsker at være i stand til at udføre analyserne på farten. Ved udgangen af dagen ved vi allerede, hvad der er sket, da det er sket i stedet for at komme til slutningen af dagen og udføre et 24-timers batchjob og få den indsigt.
Streaminganalysen handler om at tappe lige ind i denne strøm, mens strømme af data normalt er flere strømme med meget høje mængder data og data, der kommer til os i bevægelse meget, meget hurtigt og få indsigt eller analyse af disse strømme, som de kommer til os i modsætning til at lade det komme ud i ro og udføre analyser på dem.
Som nævnt har vi haft årtier og årtier med at udføre det, jeg kalder batchanalyse. Jeg har lagt et rigtig sejt billede her. Dette er et billede af en herre, der stod foran en hånlig computer, der blev oprettet af RAND Corporation for en levetid siden, og det er sådan, de så en computer i et hus for at se ud. Det, der er interessant, er, at selv da havde de dette koncept af alle disse små skiver, og disse skiver repræsenterede information, der kom ind fra huset og blev behandlet i realtid og fortæller dig, hvad der foregår. Et simpelt eksempel er et sæt barometrisk tryk og temperatur, som vi kan se, hvor vi ser hvad der sker i realtid. Men jeg kan forestille mig, at selv dengang, da RAND Corporation sammensatte det lille mockup, tænkte de allerede på at behandle data og udføre analyser på det, da det kommer i streamformat. Jeg er ikke helt sikker på, hvorfor de lægger et ratt på computeren, men det er ret cool.
Siden opfindelsen af printeren har vi haft det synspunkt at indsamle data og udføre batchanalyse på dem. Som jeg har sagt med det store skift nu, og vi har set dette fra lignende af web-skala-spillere, som vi alle kender, de er alle husholdningsmærker som Twitter, Facebook og LinkedIn, den interaktive opførsel, vi har med de sociale platforme kræver ikke kun indfangning, opbevaring og derefter behandling i batchtilstand, men de er faktisk indfangning og kørsel analytics på farten fra strømme af data, der kommer igennem. Når jeg tweeter noget, har de ikke kun brug for at fange og opbevare og gøre noget senere, men de skal også være i stand til at sætte det øjeblikkeligt tilbage på min strøm og dele det med andre mennesker, der følger mig. Det er en batchbehandlingsmodel.
Hvorfor skulle vi gå ned ad denne rute? Hvorfor skulle organisationer investere tid, kræfter og penge i endda at overveje udfordringen med at bestræbe sig på stienanalyse? Organisationer har dette enorme ønske om at få en præstationsgevinst over deres konkurrenter i de brancher, de er i, og at præstationsgevinst hurtigt kan implementeres gennem simpel strømanalyse, og det kan starte med en simpel, bare sporing af realtidsdata, som vi allerede Bekendt med. Jeg fik et lille skærmbillede der fra Google Analytics. Dette er sandsynligvis en af de første gange, hvor vi virkelig fik den praktiske analyse af forbrugerkvalitet. Så da folk besøgte dit websted, og du får disse hittællinger, med et lille stykke JavaScript i bunden af din webside i HTML indlejret på dit websted, blev disse små koder lavet i realtid tilbage til Google, og de blev udføre analyser af de strømme af data, der kommer ind fra hver side på dit websted, hvert objekt på dit websted i realtid, og de sender det tilbage til dig på denne virkelig søde lille webside i et instrumentbord med realtidsgrafik, søde små histogrammer og linjegraf, der viser dig X antal mennesker, der historisk rammer din side, men her er hvor mange der er lige nu.
Som du kan se på dette skærmbillede, står det 25 lige nu. Det er 25 personer lige nu, da skærmbilledet var på denne side. Det er den første rigtige chance, vi har spillet på analyse-værktøj til forbrugerklasse. Jeg tror, at mange mennesker virkelig har det. De forstod bare kraften ved at vide, hvad der foregik, og hvordan de kan reagere på det. Når vi tænker på omfanget af flyelektronik, fly, der flyver rundt, er der som 18.700 indenrigsflyvninger om dagen i USA alene. Jeg læste et papir for et stykke tid siden - det var omkring seks eller syv år siden - at mængden af data, der blev produceret af disse fly, var omkring 200 til 300 megabyte i den gamle ingeniørmodel. I nutidens design af fly producerer disse fly omkring 500 gigabyte data eller ca. en halv terabyte data pr. Flyvning.
Når du laver matematikken meget hurtigt fra toppen af dit hoved, at 18.700 indenrigsflyvninger hver 24. time alene i det amerikanske luftrum, hvis alle moderne fly producerer cirka en halv terabyte, er det 43 til 44 petabyte data der kommer igennem og det sker, mens flyene er i luften. Det sker, når de lander, og de udfører datadumps. Det er, når de går ind i butikken og har en fuld datadump fra ingeniørholdene for at se, hvad der sker i lejer, hjul og inde i motorerne. Nogle af disse data skal behandles i realtid, så de kan træffe beslutninger om, hvorvidt der er et reelt problem, mens flyet var i luften, eller mens det er på jorden. Du kan bare ikke gøre det i batchtilstand. I andre brancher, som vi ser derude omkring økonomi, sundhed, produktion og teknik, ser de også på, hvordan de kan få med denne nye indsigt i, hvad der sker i realtid i modsætning til hvad der lige er gemt i databaserne på en semester.
Der er også dette begreb om at håndtere data som det, jeg kalder en letfordærvelig vare eller en letfordærvelig vare - at en masse data mister værdi over tid. Dette er mere og mere tilfældet med mobilitetsapps og værktøjer til sociale medier, fordi hvad folk siger, og hvad der nu er trend nu, er det, du vil svare på. Når du tænker over andre dele af vores liv med logistik og levering af mad rundt omkring, forstår vi begrebet letfordærvelig vare i den forstand. Men tænk på de data, der gennemgår din organisation, og den værdi, den har. Hvis nogen laver noget med dig lige nu, og du kan interagere med dem i realtid, vil du ikke vente i en time, så dataene kan indfanges og placeres i et system som Hadoop og derefter trykke på denne knap, du vil ikke være i stand til at håndtere det lige nu, og du vil være i stand til at gøre det på klientens behov øjeblikkeligt. Der er et udtryk, du vil se dukke op meget nu, hvor folk taler om at have denne datastrøm i realtid, der kan give dig personalisering, og at tilpasningen stemmer overens med det system, du bruger til din individuelle oplevelse. Så når du f.eks. Rammer et værktøj som Google-søgeværktøj, hvis jeg udfører en forespørgsel, og du altid gør den samme forespørgsel, får vi ikke nøjagtigt de samme data. Vi får i det væsentlige det, jeg omtaler som en berømthedsoplevelse. Jeg bliver behandlet med en engang. Jeg får min egen personlige version af, hvad der sker i disse systemer, baseret på de profiler og data, de har samlet på mig, og jeg var i stand til at udføre analyser i realtid i strømmen.
Denne idé om data som en letfordærvelig vare er en reel ting for nu, og værdien af data, der mindskes over tid, er noget, vi er nødt til at tackle med i dag. Det er ikke en ting i går. Jeg elsker dette billede af en bjørn, der griber en laks, der springer ud af floden, fordi den virkelig maler nøjagtigt, hvad jeg ser streaminganalyser. Det er denne enorme flod af data, der kommer til os, en brandslange, hvis du vil, og bjørnen sidder midt i åen. Det vil udføre analyser i realtid om, hvad der sker omkring det, så det rent faktisk kan konstruere sin evne til at fange den fisk i luften. Det er ikke som bare at dyppe i strømmen og gribe en. Denne ting hopper i luften, og den skal være på det rigtige sted på det rigtige tidspunkt for at fange den fisk. Ellers får han ikke morgenmad eller frokost.
En organisation vil gøre det samme med deres data. De ønsker at hente værdi ud af, hvad der nu er store mængder data i bevægelse. De vil udføre analyser af disse data og data med høj hastighed, så det er ikke kun den mængde data, der kommer til os, men det er den hastighed, hvorpå de kommer fra dette. Af sikkerhed for eksempel er det alle dine routere, switches, servere, firewalls og alle begivenheder, der kommer fra disse og titusinder, hvis ikke hundretusinder af enheder, i nogle tilfælde er letfordærvelige data. Når vi tænker på det på tingenes internet og det industrielle internet, taler vi om millioner, hvis ikke milliarder af sensorer i sidste ende, og når dataene kommer igennem, som udfører analyser, ser vi nu på at udføre komplekse begivenheder ved størrelsesordener og hastighed, som vi aldrig engang har set før, og vi er nødt til at tackle dette i dag. Vi er nødt til at bygge værktøjer og systemer omkring det. Det er en reel udfordring for organisationer, fordi vi på den ene side har de meget store mærker, der laver DIY, bager det selv, når de har kapacitet til at gøre det og dygtighedssæt og teknik. Men for den gennemsnitlige organisation er det ikke tilfældet. De har ikke evnerne. De har ikke kapacitet eller tid eller endda penge til at investere i at finde ud af det. De sigter alle mod dette koncept om beslutningstagning i nær realtid.
Brug sager, som jeg er stødt på, og de er på tværs af ethvert bredt spektrum i hver sektor, som du kan forestille dig, folk sidder op og lægger mærke til og siger, hvordan anvender vi nogle analyser på vores strømdata? Vi taler om online-skala-tjenester. Der er de traditionelle sociale medieplatforme og online e-tailing og detailhandel - for eksempel apps. De prøver alle at give os denne real-time berømthedsoplevelse. Men når vi kommer ind på flere af teknologibacketjenester, telefontjenester, tale og video, ser jeg folk gå rundt og laver FaceTime på telefoner. Det eksploderer bare. Det svirrer i mit sind, at folk holder telefonen ud foran dem og snakker med en videostrøm af en ven i modsætning til at holde den ved deres øre længere. Men de ved, at de kan gøre det, og de tilpassede sig, og de kunne godt lide den oplevelse. Udviklingen af disse applikationer og de platforme, der leverer disse, er nødt til at udføre analyser i realtid på den trafik og på profilerne af trafikken, så de kan gøre enkle ting som at dirigere den video perfekt, så kvaliteten af stemmen i den video, du får, er tilstrækkelig til at få en god oplevelse. Du kan ikke batchbehandle den slags data. Det ville ikke gøre videostrømmen i realtid til en funktionel service.
Der er en regeringsudfordring i finansielle transaktioner. Det er ikke okay at komme til slutningen af dagen og finde ud af, at du har brudt loven, der flytter private data rundt på stedet. I Australien har vi en meget interessant udfordring, hvor flytning af privatlivsrelaterede data offshore er et nej. Du kan ikke tage min PID, mine private personlige identifikationsdata offshore. Der er love i Australien for at forhindre, at det sker. Udbydere af finansielle tjenester, især, offentlige tjenester og agenturer, skal de foretage i realtid analyse af deres strømme af data og instruktioner med mig for at sikre, at det, de leverer til mig, ikke forlader kysterne. Alle tingene skal bo lokalt. De er nødt til at gøre det i realtid. De kan ikke bryde loven og bede om tilgivelse senere. Svigpåvisning - det er en temmelig indlysende, som vi hører om med kreditkorttransaktioner. Men da de typer transaktioner, vi udfører i finansielle tjenester, ændrer sig meget, meget hurtigt, er der forskellige ting, som PayPal gør først nu for at opdage svig i realtid, hvor penge ikke flytter fra en ting til en anden, men det er en finansiel transaktion mellem systemer. Ebay-budplatforme, påvisning af svig skal ske i realtid på et streamingkontor.
Der er en tendens, der bevæger sig nu til at udføre ekstraktion og transformere belastningsaktivitet i vandløbene, så vi ikke ønsker at fange noget, der går til strømmen. Vi kan ikke rigtig gøre det. Folk har lært, at data kan lide at blive brudt virkelig hurtigt, hvis vi fanger alt. Tricket nu er at udføre analyser på disse streams og gøre ETL på det og bare fange det, du har brug for, potentielt metadata, og derefter køre forudsigelig analyse, hvor vi faktisk så kan fortælle, hvad der vil ske lidt længere ned ad vejen på det, vi Vi har lige set i strømmen baseret på den analyse, vi udførte på det.
Udbydere af energi og forsyningsselskaber oplever dette enorme ønske fra forbrugere om at have efterspørgselspriser. Jeg beslutter måske, at jeg vil købe grøn strøm på et bestemt tidspunkt af dagen, fordi jeg bare er hjemme alene, og jeg bruger ikke en masse enheder. Men hvis jeg har et middagsselskab, vil jeg måske have alle mine enheder tændt, og jeg vil ikke købe billig strøm og vente på, at den skal leveres, men villig til at betale for flere omkostninger for at få den strøm. Denne efterspørgselsprissætning, især inden for forsyningsselskaber og energirum, er allerede sket. Uber er for eksempel et klassisk eksempel på ting, du kan gøre hver dag, og det hele styres af efterspørgselspriser. Der er nogle klassiske eksempler på, at folk i Australien får $ 10.000 billetpriser på grund af den enorme efterspørgsel på nytårsaften. Jeg er sikker på, at de har behandlet dette problem, men streamanalyse, der udføres i realtid, mens du er i bilen, hvor du fortæller, hvor meget jeg skal betale.
Internet of Things og sensorrømme - vi har kun lige ridset overfladen på dette, og vi har virkelig bare haft den grundlæggende samtale, der sker på dette, men vi vil se et interessant skift i, hvordan teknologi håndterer det, fordi når du taler ikke næsten tusinder eller titusinder, men hundreder af tusinder og potentielt milliarder af enheder, der streamer til dig, næsten ingen af de teknologibunker, vi har nu, er konstrueret til at klare det.
Der er nogle virkelig varme emner, vi ser rundt omkring i stedet som sikkerhed og cyberrisiko. De er meget virkelige udfordringer for os. Der er et virkelig pænt værktøj kaldet nord på nettet, hvor du kan sidde og se på en webside forskellige cyberangreb, der sker i realtid. Når du ser på det, tror du, ”åh, det er en dejlig sød lille webside”, men efter cirka fem minutter derinde, er du klar over mængden af data, som systemet udfører analyse på alle de forskellige strømme på alle de forskellige enheder i hele verden der bliver fodret ind i dem. Det begynder at forstyrre sindet med, hvordan de udfører det i kanten af denne optegnelse i det væsentlige og giver dig den enkle lille skærm, der fortæller dig, hvad du skal eller noget andet angribe det i realtid og hvilke typer angreb. Men det er en virkelig pæn lille måde at bare få en god smag af, hvad strømanalyse potentielt kan gøre for dig i realtid ved bare at se denne side og få en fornemmelse af kun lydstyrken og udfordringen ved at tage streams, behandle analyseforespørgsler på dem og repræsenterer det i realtid.
Jeg tror, at den samtale, jeg har for resten af mødet, kommer til at adressere alle disse typer ting med et interessant synspunkt, fra mit synspunkt, og det er udfordringen fra DIY, bage det selv, passer til nogle af de klassiske enhjørninger, der har råd til at bygge de slags ting. De har milliarder af dollars til at bygge disse teknikhold og til at opbygge deres datacentre. Men for 99, 9% af de organisationer derude, der ønsker at skabe værdi i deres forretning med strømanalyse, er de nødt til at få en off-the-shelf service. De er nødt til at købe et produkt ud af kassen, og de har generelt brug for en vis konsulenttjeneste og professionel service for at hjælpe dem med at implementere det, og de får den værdi tilbage i virksomheden og sælger det tilbage til virksomheden som en fungerende løsning.
Med det vil jeg give Dem tilbage, Rebecca, fordi jeg tror, det er det, vi skal dække i detaljer nu.
Rebecca Jozwiak: Fremragende. Tak så meget, Dez. Det er en fantastisk præsentation.
Nu vil jeg give bolden videre til Robin. Tage det væk.
Robin Bloor: Okay. Fordi Dez er gået ind i den pittige grimme ved behandling af strømme, syntes det ikke at være fornuftigt for mig at dække det igen. Så jeg vil bare tage et helt strategisk synspunkt. Ser man næsten fra et meget højt niveau ned på hvad helvede foregår og placerer det, fordi jeg tror, det kan hjælpe mennesker, især os mennesker, der ikke er indlejret i strømme, der behandles i stor dybde før.
Behandling af strømme har eksisteret i lang tid. Vi kaldte det CEP. Der var realtidssystemer før det. De originale proceskontrolsystemer behandlede faktisk informationsstrømme - selvfølgelig gik intet så langt, som det er i dag. Denne grafik, som du ser på diaset her; det påpeger en masse ting faktisk, men det peger ud over alt andet - det faktum, at der er et spektrum af forsinkelser, der vises i forskellige farver her nede. Hvad der faktisk skete siden opfindelsen af computing eller kommerciel computing, der kom lige omkring 1960, er at alt lige er blevet hurtigere og hurtigere. Vi plejede at være afhængige af den måde, det faktisk kom ud på, hvis du kan lide i bølger, for det er sådan, det ser ud. Dette afhænger faktisk af det. Fordi det hele blev drevet af Moore's lov, og Moore's lov ville give os en faktor på cirka ti gange hurtigere hastighed over en periode på omkring seks år. Så når vi faktisk kom til omkring 2013, brød det hele, og vi pludselig begyndte at accelerere med en hastighed, som vi aldrig har, hvilket er underligt hidtil uset. Vi fik en faktor på cirka ti med hensyn til stigning i hastighed og derfor en reduktion i latenstid cirka hvert sjette år. I de seks år siden siden 2010 har vi en multipel på mindst tusind. Tre størrelsesordrer snarere end en.
Det er, hvad der har foregået, og det er derfor, at branchen på en eller anden måde ser ud til at bevæge sig i fantastiske hastigheder - fordi det er. Bare gennemgå betydningen af denne særlige grafik, er responstiderne faktisk forresten i algoritmisk skala ned ad den lodrette akse. Realtid er computerhastighed, hurtigere end mennesker. Interaktive tider er orange. Det er, når du interagerer med computeren, det er her, du virkelig ønsker en tiendedel til cirka et sekund af forsinkelse. Over er der transaktioner, hvor vi faktisk tænker over, hvad du laver på computeren, men hvis det går ud på cirka femten sekunder, bliver det utålelig. Folk vil faktisk bare ikke vente på computeren. Alt blev gjort i batch. En masse ting, der blev udført i batch, kommer nu lige ned i det transaktionsrum, lige ind i det interaktive rum eller endda i realtidsrummet. Mens tidligere, en bølget med meget små mængder data, vi kunne gøre noget af dette, kan vi nu gøre med meget store mængder data ved hjælp af enormt nedskaleret miljø.
Så dybest set, alt dette siger er virkelig transaktion og interaktive menneskelige responstider. Meget meget, hvad der sker med strømme lige nu, er at informere mennesker om tingene. Noget af det går hurtigere end det, og det informerer om ting godt, så det er realtid. Derefter tager vi en licens til bare at falde som en sten, hvilket gør øjeblikkelig analyse gennemførlig og i øvrigt ganske overkommelig. Det er ikke kun hastigheden er faldet ned, og toppen er lige lige kollapset. Sandsynligvis den største indflydelse i alle disse blandt alle de forskellige applikationer, kan du udføre alle disse forudsigelige analyser. Jeg fortæller dig hvorfor om et øjeblik.
Dette er bare hardware butikken. Du har parallel software. Vi taler om i 2004. Scale-out arkitektur, multicore-chips, hukommelsesforøgelse, konfigurerbar CPU. SSD'er går nu så meget hurtigere end spindisk disk. Du kan stort set bølgesnurrende disk farvel. SSD'er findes også i flere kerner, så igen hurtigere og hurtigere. Snart vises, har vi memristoren fra HP. Vi har 3D XPoint fra Intel og Micron. Løftet fra dem er, at det alligevel vil gøre det hele gå hurtigere og hurtigere. Når du faktisk tænker på to nye hukommelsesteknologier, som begge vil gøre hele det grundlæggende lille stykke, det enkelte kredsløbskort går meget hurtigere, har vi ikke engang set slutningen på det.
Streams-teknologi, som virkelig er den næste besked, er her for at blive. Der skal være en ny arkitektur. Jeg mener, at Dez har nævnt det i flere punkter i sin præsentation. I årtier betragtede vi arkitektur som en kombination af dataheaps og data-rør. Vi havde en tendens til at behandle dyngerne, og vi havde en tendens til at røre dataene mellem dyngerne. Vi bevæger os nu grundlæggende hen imod det, vi kalder Lambda-dataarkitektur, der kombinerer behandlingen af datastrømme med dataheaps. Når du faktisk behandler en strøm af begivenheder, der kommer ind mod historiske data som en dataflyt eller en dataheap, er det, hvad jeg mener med Lambda-arkitekturen. Dette er i sin spædbarn. Det er kun en del af billedet. Hvis du betragter noget så komplekst som Internet af alt hvad Dez også har nævnt, vil du faktisk indse, at der er alle mulige problemer med dataplacering - beslutninger om, hvad du skal behandle i strømmen.
Det, jeg virkelig siger her, er, at når vi forarbejdede i batch, behandlede vi faktisk strømme. Vi kunne bare ikke gøre det ad gangen. Vi venter bare, indtil der er en stor bunke, og så behandler vi det hele på én gang. Vi flytter til en situation, hvor vi rent faktisk kan behandle ting i strømmen. Hvis vi kan behandle ting i strømmen, vil de datahap, som vi har, være de statiske data, som vi har brug for at henvise til for at behandle dataene i strømmen.
Dette bringer os til netop denne ting. Jeg har nævnt dette før i en eller anden præsentation med den biologiske analogi. Den måde, jeg gerne vil have dig til at tænke på, er i øjeblikket vi mennesker. Vi har tre forskellige netværk til forudsigelig behandling i realtid. De kaldes det somatiske, autonome og enteriske. Enterikken er din mave. Det autonome nervesystem passer på kamp og flyvninger. Det ser faktisk efter hurtige reaktioner på miljøet. Det somatiske, der ser efter bevægelsen af kroppen. Det er realtidssystemer. Det interessante ved det - eller jeg synes er en slags interessant - er meget, det er mere forudsigeligt, end du nogensinde ville forestille dig. Det er som om du faktisk ser på en skærm omkring 18 inches fra dit ansigt. Alt hvad du kan se tydeligt, alt hvad din krop er i stand til at se klart handler faktisk om et 8 × 10-rektangel. Alt uden for det er faktisk sløret for din krop, men dit sind udfylder faktisk hullerne og gør det ikke sløret. Du ser slet ikke noget sløret. Du ser det tydeligt. Dit sind gør faktisk en forudsigelig metode til datastrømmen, så du kan se den klarhed. Det er lidt af en underlig ting, men du kan faktisk se på, hvordan nervesystemet fungerer, og den måde, hvorpå vi formår at komme rundt og opføre os med rimelighed - i det mindste nogle af os - med rimelighed sankt og ikke støde på tingene hele tiden.
Det hele gøres ved hjælp af en række neurale analyseskalaer her inde. Hvad der vil ske, er, at organisationer vil have den samme type ting og vil bygge den samme type ting, og det vil være behandling af strømme inklusive organisationens interne strømme - de ting, der sker inden for det, de ting, der sker uden for det, de øjeblikkelige reaktioner, der faktisk skal tages, er selvfølgelig fodring af mennesket til at tage beslutninger, til at få alle disse til at ske. Det er her vi skal hen, så vidt jeg kan se.
En af de ting, der er en konsekvens af det, er, at niveauet for streaming-applikationen går godt. Der kommer meget mere end vi ser nu. Lige nu vælger vi den lavthængende frugt ved at gøre de ting, der er indlysende.
Så det er alligevel konklusionen her. Streaminganalyse er engang en niche, men det bliver mainstream, og det vil snart blive vedtaget generelt.
Med det vil jeg vende det tilbage til Rebecca.
Rebecca Jozwiak: Mange tak, Robin. Fantastisk præsentation som sædvanlig.
Anand, du er næste gang. Gulvet er dit.
Anand Venugopal: Fantastisk. Tak skal du have.
Mit navn er Anand Venugopal og jeg er produktchef for StreamAnalytix. Det er et produkt, der tilbydes af Impetus Technologies, fra Los Gatos, Californien.
Impetus har faktisk haft en stor historie i at være en leverandør af store dataløsninger for store virksomheder. Så vi har faktisk udført en række streaminganalyseimplementeringer som servicevirksomhed, og vi lærte en masse lektioner. Vi skiftede også til at blive et produktfirma og løsningsdrevet selskab i de sidste par år, og streamanalyse er på vej mod gebyret ved at omdanne Impetus til et stort set produktdrevet selskab. Der er nogle kritiske, meget, meget vigtige aktiver, som Impetus ryddet takket være vores eksponering for virksomheder, og StreamAnalytix er en af dem.
Vi er 20 år i branchen, og der er en fantastisk blanding af produkter og tjenester, der gør os til en enorm fordel. Og StreamAnalytix blev født ud af alle lektioner fra vores første fem eller seks implementeringer af streaming.
Jeg vil røre ved et par ting, men analytikerne, Dez og Robin, har gjort et fantastisk stykke arbejde med at dække pladsen generelt, så jeg vil springe over en masse indhold, der overlapper hinanden. Jeg går sandsynligvis hurtigt. Vi ser foruden sande streaming-sager, der bruger en masse bare batchacceleration, hvor der bogstaveligt talt er meget, meget vigtige batch-processer i virksomheder. Som du kan se, kan hele denne cyklus med at registrere en begivenhed og analysere og handle på det faktisk tage uger i store virksomheder, og de prøver alle at skrumpe den ned til minutter og nogle gange sekunder og millisekunder. Så noget hurtigere end alle disse batch-processer er kandidater til erhvervelse af virksomheder, og det er meget godt sagt, at værdien af data drastisk falder med deres alder, så jo mere værdi der er i den indledende del i de sekunder, det netop skete. Hvis du ideelt set kunne forudsige, hvad der skulle ske, er det den højeste værdi. Det afhænger dog af nøjagtighed. Den næste højeste værdi er, når det er lige der, når det sker, du kan analysere det og svare. Naturligvis reduceres værdien dramatisk efter dette, den vigtigste restriktive BI, som vi er i.
Det er interessant. Du kan forvente noget dramatisk videnskabeligt svar på, hvorfor streaming af analytics. I mange tilfælde er det, vi ser, fordi det nu er muligt, og fordi alle ved, at batch er gammelt, batch er kedeligt, og batch er ikke cool. Der er nok uddannelse, som alle har haft nu på det faktum, at der er mulighed for streaming, og alle har Hadoop nu. Nu har Hadoop-distributioner en streamingteknologi indlejret i det, uanset om det er Storm- eller Spark-streaming og selvfølgelig meddelelseskøer, som Kafka osv.
Virksomheder, vi ser, springer ind i det og begynder at eksperimentere med disse sager, og vi ser to brede kategorier. Den ene har noget at gøre med kundeanalyse og kundeoplevelse og den anden operationelle intelligens. Jeg kommer nærmere ind på nogle detaljer herom lidt senere. Hele kundeservicen og kundeoplevelsesvinklen, og vi hos Impetus StreamAnalytix har gjort dette på mange forskellige måder handler egentlig om virkelig, virkelig at fange forbrugernes flerkanalsengagement i realtid og give dem meget, meget kontekstfølsomme oplevelser som ikke er almindelige i dag. Hvis du gennemser på nettet, på Bank of America-webstedet, og du undersøgte nogle produkter, og du ringer bare til callcenteret. Ville de sige: ”Hej Joe, jeg ved, at du undersøgte nogle bankprodukter, vil du gerne have, at jeg udfylder dig?” Det forventer du ikke i dag, men det er den slags oplevelse, der virkelig er mulig med streaminganalyse. I mange tilfælde gør det en enorm forskel, især hvis kunden begyndte at undersøge måder at komme ud af deres kontrakt med dig ved at se på tidlige opsigelsesbestemmelser eller vilkår og betingelser for tidlig opsigelse på dit websted og derefter ringe til, og du er i stand til at ikke direkte konfrontere dem om det, men bare indirekte fremsætte et tilbud om en slags første forfremmelse, fordi systemet ved, at denne person ser på tidlig opsigelse, og du fremsætter dette tilbud på det tidspunkt, du kan meget vel beskytte den udrullende kunde og beskytte det aktiv .
Det ville være et eksempel, plus en masse kundeservice er alle meget gode eksempler. Vi implementerer i dag, reducerer omkostningerne i callcenter samt giver dramatiske dejlige kundeoplevelser. Dez gjorde et godt stykke arbejde med at opsummere nogle af brugssagerne. Du kan stirre på dette diagram i et par minutter. Jeg klassificerede det som lodrette, horisontale og kombinationsområder, IoT, mobilapp og callcenter. De er alle lodrette og vandrette. Det afhænger af, hvordan man ser på det. I bund og grund ser vi en hel del horisontale anvendelser, der er forholdsvis almindelige på tværs af branche-vertikaler, og der er en vertikal specifik brugssager, herunder finansielle tjenester, sundhedsydelser, telekommunikation, fremstilling osv. Hvis du virkelig stiller dig selv spørgsmålet eller fortæller dig selv det, ”åh, jeg ved ikke, hvilke brugssager der er. Jeg er ikke sikker på, om der virkelig er nogen forretningsværdi i streaminganalyse for min virksomhed eller for vores virksomhed, ”tænk hårdt, tænk to gange. Tal med flere mennesker, fordi der er brugssager, som i din virksomhed er relevante i dag. Jeg kommer ind på forretningsværdien om, hvordan nøjagtigt er forretningsværdien afledt.
I bunden af pyramiden her har du forudsigelig vedligeholdelse, sikkerhed, beskyttelse mod korn osv. Disse slags anvendelsessager udgør beskyttelse af indtægter og aktiver. Hvis Target beskyttede deres sikkerhedsbrud, der skete over timer og uger, kunne CIO have reddet sit job. Det kan spare titusinder eller hundreder af millioner af dollars osv. Analyse af streaming i realtid hjælper virkelig med at beskytte disse aktiver og beskytte tab. Der er direkte forretningsmæssig merværdi lige der.
Den næste kategori bliver mere rentabel, sænker dine omkostninger og får flere indtægter fra den nuværende drift. Det er effektiviteten af den nuværende virksomhed. Disse er alle kategorien af brugssager, som vi kalder operationel efterretningstjeneste i realtid, hvor du får dyb indsigt i, hvordan netværket opfører sig, hvordan dine kundedrift opfører sig, hvordan din forretningsproces opfører sig, og du er i stand til at finpusse alt dette i realtid, fordi du får feedback, og du får advarsler. Du får afvigelser, afvigelser i realtid, og du kan hurtigt handle og adskille processen, der går uden for grænserne.
Du kan potentielt også spare en masse penge i dyre kapitalopgraderinger og ting, som du mener er nødvendige, som muligvis ikke er nødvendigt, hvis du optimerede netværkstjenesten. Vi hørte om et tilfælde, hvor en større telco udsatte en opgradering af $ 40 millioner i deres netværksinfrastruktur, fordi de fandt, at de havde kapacitet nok til at styre deres nuværende trafik, hvilket er ved at optimere og bedre udføre den intelligente routing af deres trafik og lignende ting. Disse er alle mulige kun med nogle realtidsanalyser og handlingsmekanismer, der virker på disse indsigter i realtid.
Det næste niveau af værditilvækst er op-sælg, krydssalg, hvor der er muligheder for at tjene flere indtægter og overskud fra aktuelle tilbud. Dette er et klassisk eksempel, som mange af os ved om, at de har oplevet, hvor du tænker over i dit liv, hvor du er villig til faktisk at købe et produkt i dag, som ikke bliver tilbudt dig. I mange, mange tilfælde sker det faktisk. Du har ting i tankerne, som du kan lide at købe, som du ved, at du vil købe, at du har en huskeliste eller noget, som din kone fortalte dig, eller hvis du ikke har en kone, men du virkelig ville købe og du handler enten på et websted, eller du interagerer i en detailbutik, butiksområdet har bare ikke konteksten, har ikke intelligens til at beregne, hvad du muligvis har brug for. Derfor får de ikke deres forretning sikkert. Hvis streaminganalyser kunne bruges til virkelig at foretage nøjagtige forudsigelser, og som virkelig er mulige for, hvad der bedst vil passe til denne bestemte kontekst, er denne kunde på dette tidspunkt på dette sted, der er en masse op-sælg og krydssalg, og det kommer igen fra streaming analytics - være i stand til at tage en tilbøjelighed beslutning om, hvad denne kunde sandsynligvis vil købe eller reagere på i det øjeblik af sandhed, når der er en mulighed. Derfor elsker jeg det billede, som Dez viste med bjørnen lige ved at spise den fisk. Det er stort set det.
Vi mener også, at der er en stor kategori derude af dramatiske, transformationelle ændringer i en virksomhed med at tilbyde helt nye produkter og tjenester, der simpelthen er baseret på observation af kundeadfærd, alt sammen baseret på observation af en anden virksomheds adfærd. Hvis, lad os sige, et telco eller et kabelfirma virkelig overvåger kundernes brugsmønstre i hvilket segment af markedet han ser, hvilket program på hvilket tidspunkt osv., Så ender de faktisk med at skabe produkter og tjenester, der næsten tigges for på en eller anden måde. Så hele konceptet med adskillelse af flere skærme lige nu, hvor vi nu næsten tager det for givet, at vi kan se tv- eller kabelindhold på vores mobile apps. Nogle af disse eksempler kommer fra de nye produkter og tjenester, der tilbydes os.
Jeg kommer ind på, "Hvad er arkitekturovervejelserne med streaminganalyse?" Det er i sidste ende, hvad vi prøver at gøre. Dette er Lambda-arkitekturen, hvor du blander de historiske data og den realtidsindblik og ser dem på samme tid. Det er, hvad Sigma muliggør. Vi har alle batcharkitektur og virksomhedsbillede i dag. Vi skinner ind i en slags BI-stabel og udnyttelsesstabel og Lambda-arkitekturen tilføjet. Som hastighedslag eller behov og Lambda handler det om at flette disse to indsigter og se det på en kombineret måde, på en rig måde, der kombinerer begge indsigter.
Der er et andet paradigme kaldet Kappa-arkitekturen, der foreslås, hvor antagelsen er, at hastighedslaget er den eneste inputmekanisme, der vil vedvare på længere sigt. Alt kommer til at komme gennem dette hastighedslag. Der er ikke engang en offline ETL-mekanisme. Alt ETL vil ske. Rens, datarensning, kvalitet ETL - alt dette vil ske på ledningen, fordi husk alle data blev født i realtid. På et tidspunkt var det realtid. Vi er blevet så vant til at lægge dette på søer, på floder og oceaner og derefter gøre det ved en statisk analyse, at vi glemte, at dataene blev født på et tidspunkt i realtid. Alle data er faktisk født som en realtidsbegivenhed, der skete i tidspunktet, og de fleste af dataene i dag på søen blev lige sat på databasen til en senere analyse, og vi har nu fordelen i Lambda og Kappa-arkitekturen med faktisk at se det, analysere det, forbehandle det og reagere på det, når det ankommer. Det er det, der er aktiveret af disse teknologier. Når du ser på det som et samlet billede, ser det ud som noget her, hvor der er Hadoop inde, der er MPP'er og datalager, som du allerede har.
Vi lægger dette op, fordi det er vigtigt ikke bare at tale om nye teknologier på en ø. De skal integreres. De skal være fornuftige i den aktuelle virksomhedssammenhæng, og som løsningsudbydere, der betjener virksomheder, er vi meget følsomme over for dette. Vi hjælper virksomheder med at integrere det hele. Der er datakilder på venstre side, der indfører både Hadoop- og datavarehaglagene og til realtidslaget ovenpå, og hver af disse enheder er lagrecomputere, som du kan se, og dataforbruget er til højre side. Der er en konstant indsats for at flytte størstedelen af overholdelse, regeringsførelse, sikkerhed, styring af livscyklus osv., Der er tilgængelig i dag, hvor alle er samlet i denne nye teknologi.
En af de ting, som streamanalyse forsøger at gøre, hvis man ser på landskabet i dag, er der en masse ting, der foregår i streamingteknologilandskabet, og fra et virksomheds kundesynspunkt er der så meget at forstå. Der er så meget at følge med på. Der er dataindsamlingsmekanismer på venstre side - NiFi, Logstash, Flume, Sqoop. Det er klart, jeg har fremsat en ansvarsfraskrivelse, der siger, at den ikke er udtømmende. Kommer ind i meddelelseskøerne og kommer derefter ind i open source streaming-motorer - Storm, Spark Streaming, Samza, Flink, Apex, Heron. Heron er sandsynligvis ikke open source endnu. Jeg er ikke sikker på, om det er, fra Twitter. Disse streaming-motorer fører derefter ind i eller understøtter en opsætning af analytisk applikationskomponent, såsom kompleks begivenhedsbehandling, maskinindlæring, forudsigelig analyse, alarmeringsmodul, streaming ETL, berigende statistiske driftsfiltre. Det er alt, hvad vi kalder nu operatører. Sættet af disse operatører, når de blev strenget sammen, ville potentielt også en række brugerdefinerede, der i vid udstrækning konkluderes, om nødvendigt, bliver et streaming-program, der kører på en streaming-motor.
Som en del af denne kæde af komponenter skal du også gemme og indeksere dataene i din yndlingsdatabase, dit yndlingsindeks. Du skal muligvis også distribuere cache og igen, der fører ind i datavisualiseringslaget til højre på øverste del til kommercielle produkter eller open source-produkter, men i sidste ende har du brug for en slags produkt for at visualisere disse data i realtid. Du skal også undertiden finde frem til andre applikationer. Vi har alle set, at værdierne kun er afledt af den handling, du udfører i indsigten, at handling vil blive en trigger fra en analytisk stak til en anden applikationsstabel, der måske har ændret det, der er noget i IVR-siden eller udløser et callcenter udgående opkald eller lignende. Vi er nødt til at have disse systemer integreret og en eller anden mekanisme til din streamingklynge til at udløse andre applikationer til at sende data nedstrøms.
Det er den samlede stak fra at gå fra venstre mod højre. Så har du servicelagene, mellemovervågningen, sikkerhedstjenesten generelt servicelager osv. Kommer til hvilke produkter der er derude i virksomhedsområdet, som kunderne ser som Hadoop-distributioner, som alle har streaming, som jeg sagde, og der er kommerciel eller enkelt -vendor-løsninger, der naturligvis er i vores konkurrenter. Der er også mange flere i landskabet, som vi måske ikke har nævnt her.
Det, du ser der, er stort set virksomhedens bruger. Et komplekst og hurtigt udviklende teknologilandskab til strømbehandling, som du kan se. Vi blev nødt til at forenkle valget og deres brugeroplevelse. Hvad vi mener, at virksomheder virkelig har brug for, er den funktionelle abstraktion af alt dette i en one-stop-shop, let at bruge interface, der samler alle disse teknologier, der gør det virkelig enkelt at bruge og ikke afslører alle bevægelige dele og problemer med nedbrydning og ydeevne og problemer med vedligeholdelse af livscyklus til virksomheden.
Funktionalitetsabstraktionen er en. Den anden del er abstraktion af streamingmotorer. Streamingmotorerne og open source-domænerne kommer op hver tredje, fire eller seks måneder nu. Det var Storm i lang tid. Samza kom op, og nu er det Spark Streaming. Flink løfter hovedet og begynder at få opmærksomhed. Selv Spark Streaming-køreplanen, de laver en måde at potentielt bruge en anden motor til ren begivenhedsbehandling, fordi de også er klar over, at Spark er designet til batch, og de gør en måde i deres arkitektursyn og deres køreplan for potentielt at have en anden motor til strømbehandling ud over det aktuelle mikrobatchmønster i gniststreaming.
Det er en realitet, som du er nødt til at kæmpe med, at der vil være en masse evolution. Du er virkelig nødt til at beskytte dig mod den teknologiske flux. For som standard bliver du nødt til at vælge en og derefter leve med den, hvilket ikke er optimalt. Hvis du ser på det på en anden måde, kæmper du imellem, ”okay, jeg var nødt til at købe en proprietær platform, hvor der ikke er en lock-in, der ikke er nogen gearing af open source, kunne være meget høje omkostninger og begrænset fleksibilitet versus alle disse open source-stakke, hvor du selv skulle gøre det. ”Igen, som jeg sagde, er det en masse omkostninger og forsinkelse med at komme på markedet. Det, vi siger, er StreamAnalytix er et eksempel på en fantastisk platform, der samler enterprise class, pålidelig, enkelt leverandør, professionel service understøttet - alt det, som du virkelig har brug for som virksomhed og kraften i fleksibilitet i open source-økosystemet hvor en enkelt platform bringer dem sammen - Ingest, CEP, analyse, visualisering og alt det her.
Det gør også en meget, meget unik ting, der samler mange forskellige teknologimotorer under en enkelt brugeroplevelse. Vi tror virkelig, at fremtiden handler om at være i stand til at bruge flere streaming-motorer, fordi forskellige brugssager virkelig kræver forskellige streaming-arkitekturer. Som Robin sagde, der er et helt spektrum af forsinkelser. Hvis du virkelig taler om millisekund latensniveau, titusinde eller endda hundreder af millisekunder, har du virkelig brug for Storm på dette tidspunkt, indtil der er et andet lige så modent produkt til mindre mildhed eller lempelig tidsramme og forsinkelser på måske inden for et par sekunder, tre, fire, fem sekunder, det interval, så kan du bruge gniststreaming. Potentielt er der andre motorer, der kunne gøre begge dele. I en stor virksomhed vil der være brugssager af alle slags. Du ønsker virkelig, at adgangen og generaliteten skal have flere motorer med en brugeroplevelse, og det er, hvad vi prøver at opbygge i StreamAnalytix.
Bare et hurtigt overblik over arkitekturen. Vi vil omarbejde dette lidt, men i det væsentlige er der flere datakilder der kommer ind på venstre side - Kafka, RabbitMQ, Kinesis, ActiveMQ, alle disse datakilder og meddelelseskøer kommer ind til streambehandlingsplatformen, hvor du får til at samle en app, hvor du kommer til at trække og slippe fra operatører som ETL'erne, alt det, vi har talt om. Under er der flere motorer. Lige nu har vi Storm og Spark Streaming som branchenes eneste og første enterprise-klasse streamingplatform, der har flere motorstøtter. Det er en meget unik fleksibilitet, som vi tilbyder udover al den anden fleksibilitet ved at have dashboards i realtid. CET-motor indlejret. Vi har den sømløse integration med Hadoop og NoSQL indekser, Solr og Apache indekser. Du kan lande til din foretrukne database uanset hvad det er og opbygge applikationer virkelig hurtigt og komme på markedet virkelig hurtigt og forblive fremtidssikret. Det er vores hele mantra i StreamAnalytix.
Med det tror jeg, jeg vil afslutte mine bemærkninger. Du er velkommen til at komme til os for flere spørgsmål. Jeg vil gerne holde gulvet åbent for spørgsmål og spørgsmål og paneldiskussion.
Rebecca, over til dig.
Rebecca Jozwiak: Fantastisk, okay. Mange tak. Dez og Robin, har du nogle spørgsmål, før vi videregiver det til publikumets spørgsmål og svar?
Robin Bloor: Jeg har et spørgsmål. Jeg sætter mine hovedtelefoner på igen, så du kan høre mig. En af de interessante ting, hvis du venligt kunne fortælle mig dette, ser meget af det, jeg har set i open source-rummet, hvad jeg ville sige umodent til mig. På en måde, ja, du kan gøre forskellige ting. Men det ser ud til, at vi ser på software i dets første eller anden udgivelse i virkeligheden, og jeg spekulerede bare på din oplevelse som en organisation, hvor meget ser du umodenhedens umodenhed som problematisk, eller er det noget, der ikke gør ' t skabe for mange problemer?
Anand Venugopal: Det er en realitet, Robin. Du har helt ret. Umodenhed er ikke nødvendigvis inden for blot funktionel stabilitet og ting, men måske også nogle tilfælde af det. Men umodenheden er mere klar til brug. Open-source-produkterne, når de kommer ud, og selvom de tilbydes af Hadoop-distributionen, er de alle en masse forskellige dygtige produkter, komponenter er lige slået sammen. De fungerer ikke problemfrit og er ikke designet til en glat, sømløs brugeroplevelse, som vi får som Bank of America eller Verizon eller AT&T, til at implementere en streaminganalyseapplikation inden for uger. De er ikke designet til det med sikkerhed. Det er grunden til, at vi kommer ind. Vi samler det sammen og gør det virkelig let at forstå, at implementere osv.
Den funktionelle modenhed, tror jeg i vid udstrækning, er der. Mange store virksomheder bruger fx Storm i dag. Mange store virksomheder spiller med Spark Streaming i dag. Hver af disse motorer har deres begrænsninger i, hvad de kan gøre, hvorfor det er vigtigt at vide, hvad du kan, og hvad du ikke kan gøre med hver motor, og der er ingen mening i at bryde hovedet mod væggen og sige: ”Se jeg valgte Spark Streaming, og det fungerer ikke for mig i denne branche. ”Det vil ikke fungere. Der vil være anvendelsestilfælde, hvor gniststreaming vil være den bedste mulighed, og der vil være brugstilfælde, hvor gniststreaming muligvis ikke fungerer overhovedet for dig. Derfor har du virkelig brug for flere indstillinger.
Robin Bloor: Du skal have eksperthold om bord for det meste af dette. Jeg mener, at jeg ikke engang ved, hvor jeg skal starte med dette. En fornuftig samhandling af dygtige individer. Jeg er interesseret i, hvordan det engagement, du engagerer dig, og hvordan det sker. Er det fordi et bestemt firma er efter en bestemt applikation, eller ser du slags, hvad jeg vil kalde strategisk vedtagelse, hvor de vil have en hel platform til at gøre en masse ting.
Anand Venugopal: Vi ser eksempler på begge ting, Robin. Nogle af de ti største mærker, som alle kender, handler om det på en meget strategisk måde. De ved, at de vil have en række forskellige anvendelsessager, så de evaluerer platforme, der passer til det behov, som er en række forskellige anvendelsessager på en multi-lejer-måde, der skal implementeres i en virksomhed. Der er sagshistorier til engangsbrug, der også begynder. Der er en bestemt brugssag for overvågning af forretningsaktiviteter i et prioritetsselskab, som vi arbejder på, som du ikke kunne forestille dig som første brugssag, men det er forretningsløsningen eller brugssagen, de kom frem til, og så forbundne vi prikkerne til streaming . Vi sagde: ”Ved du hvad? Dette er en fantastisk sag til streaming analytics, og det er sådan vi kan implementere det. ”Sådan begyndte det. Derefter bliver de i denne proces uddannet og siger: ”Åh wow, hvis vi kan gøre dette, og hvis dette er en generisk platform, så kan vi opdele applikationen, lagde dem i platformen og bygge en masse forskellige applikationer på dette platform."
Robin Bloor: Dez, har du spørgsmål?
Anand Venugopal: Dez er sandsynligvis på stum.
Dez Blanchfield: Undskyld, stum. Jeg havde bare en god samtale selv. Bare efter den oprindelige observation af Robin, er du helt korrekt. Jeg tror, at udfordringen nu er, at virksomheder har et økosystem og et kulturelt og adfærdsmiljø, hvor fri og open source-software er noget, der er kendt for dem, og de er i stand til at bruge værktøjer som Firefox som en browser, og det har haft en anstændig levetid, indtil det bliver stabilt og sikkert. Men nogle af de meget store platforme, som de bruger, er enterprise-grade proprietære platforme. Så vedtagelsen af, hvad jeg betragter som open source-platforme, er ikke altid noget, der er let for dem at kulturelt eller følelsesmæssigt komme over. Jeg har set dette på tværs af vedtagelsen af små programmer, der var lokale projekter, der bare skulle spille med big data og analyse som et grundlæggende koncept. Jeg tror, en af de vigtigste udfordringer, jeg er sikker på, at du har set dem nu på tværs af organisationerne, er deres ønske om at få resultatet, men samtidig har deres ene fod fast i den gamle dåse, hvor de bare kunne købe dette fra “Indsæt et stort brand” Oracle, IBM og Microsoft. Disse nye og kendte mærker kommer igennem med Hadoop platforme og endnu mere. Flere spændende mærker kommer igennem, som har førende teknologi som strøm.
Hvilke slags samtaler har du haft den slags get eller gennemskåret det? Jeg ved, at vi har et massivt fremmøde i morges, og en ting, som jeg er sikker på, er i alles sind, er ”Hvordan skærer jeg gennem hele det udfordrende lag fra bord ned til ledelsesniveau, åh, det er for open source og for blødende kant? "Hvordan går samtaler, du har med klienter, og hvordan skærer du igennem til det punkt, hvor du slags lægger disse typer frygt til at overveje at vedtage lignende af StreamAnalytix?
Anand Venugopal: Vi synes faktisk, det er forholdsvis let at sælge vores værdiproposition, fordi kunder naturligt bevæger sig mod open source som en foretrukken mulighed. De giver ikke let bare op og siger: ”Okay, jeg skal nu gå open source.” De gennemgår faktisk en meget engageret evaluering af et større produkt, lad os sige det er en IBM eller et typisk produkt, fordi de har disse leverandørforhold. De ville ikke behandle os eller open source-motoren mod det produkt. De gennemgår seks til otte til tolv ugers evaluering. De vil overbevise sig selv om, at der er en vis præstation og stabilitet her, som jeg ønsker, og så gør de sig op med at sige, "Wow, ved du hvad, jeg kan faktisk gøre dette."
I dag har vi for eksempel et stort telco, der har strømanalyse, der kører i produktion oven på en masse af stakken, og de vurderer det mod en anden meget, meget stor velkendt leverandør, og de blev overbevist først efter at vi beviste alle ydeevne, stabilitet og alle disse ting. De tager det ikke for givet. De fandt ud af, at open source er kompetent gennem deres evalueringer, og de er klar over, at i værste fald, ”Måske er der de to brugssager, som jeg måske ikke kan gøre, men de fleste af mine virksomhedsaccelerationssager i dag er meget muligt med open source stack. ”Og vi aktiverer brugen af det. Så det er det store søde sted lige der. De ville have open source. De er virkelig på udkig efter at komme ud af leverandørens lock-in situation, de har været vant til i mange, mange år. Så her kommer vi og siger: ”Ved du hvad, vi gør open source meget, meget lettere og venlig at bruge til dig.”
Dez Blanchfield: Jeg tror, at den anden udfordring, som virksomhederne finder, er, når de bringer den traditionelle mandat til, de ofte er en generation bag noget af den blødende kant af det spændende materiale, vi taler om her, og det mener jeg ikke som en negativ svag. Det er bare, at virkeligheden er, at de har en generation og rejse til at gennemgå for at frigive, hvad de betragter som stabile platforme, de skal gennemgå, old-school-udvikling og UATN-integrationscykler og test og dokumentation, og markedsføring og salg. Mens den type, du laver, tror jeg, at den ting, som jeg er interesseret i at tænke på, er at se på nogle af dine seneste udgivelser i går aftes, der laver et slags forskningsarbejde, du har denne blanding nu, hvor du fik kompetence fra et forudgående konsulentsynspunkt og en implementering, men du har også en stak, som du kan rulle i. Jeg tror, det er her, de påhviler vil kæmpe i nogen tid. Vi har set mange af dem, som jeg gjorde på markedet. De er ofte i det, jeg kalder indhentningsknudepunkter, hvorimod fra det, du fortæller os, når du er derude, der foretager disse samtaler, og du er derude, der implementerer.
Kan du give os et par eksempler på nogle af de vertikale grænser, som du har set vedtagelse? For eksempel er der virkelig nichey-miljøer som raketvidenskab og at sætte satellitter i rummet og indsamle data fra Mars. Der er kun en håndfuld mennesker, der gør det på planeten. Men der er store vertikale som f.eks. Sundhed inden for luftfart, inden for skibsfart og logistik, inden for produktion og teknik, hvad er et par eksempler på de større og mere brede sektorer, du har været så langt, at du har set virkelig godt vedtagelse i?
Anand Venugopal: Telco er et stort eksempel.
Jeg vil bare rette mine lysbilleder her. Kan du se diaset her, case study 4?
Dette er tilfældet med en stor telco indtagelse af set-top box data og gør flere ting med det. De ser på, hvad kunderne virkelig laver i realtid. De ser på, hvor der sker fejl i realtid i set-top-bokse. De forsøger at informere callcenter om, hvis denne kunde ringer ind lige nu, kodeklinkoplysningerne fra denne kundes set-topbox, information om vedligeholdelsesbillet sammenhænger hurtigt, om netop denne kundes set-top-boks har et problem eller ikke før kunden taler et ord. Hvert kabelselskab, ethvert større telco forsøger at gøre dette. De indtager data fra set-topbox, foretager analyser i realtid, foretager kampagneanalyse, så de kan placere deres annoncer. Der er en enorm brugssag.
Som jeg sagde, der er dette panteselskab, der igen er et generisk mønster, hvor store systemer er involveret i behandling af data fra. Dataene, der flyder gennem system A til system B til system C, og disse er regulerede virksomheder, som alt skal være konsistent. Ofte går systemer ud af synkronisering med hinanden. Et system siger: ”Jeg behandler hundrede lån til en samlet værdi af 10 millioner dollars.” Systemet siger: ”Nej, jeg behandler 110 lån til et andet forskellige numre. ”De er nødt til at løse det virkelig hurtigt, fordi de faktisk behandler de samme data og foretager forskellige fortolkninger.
Uanset om det er et kreditkort, lånebehandling, forretningsproces, eller om det er en realkreditproces eller noget andet, hjælper vi dem med at gøre korrelation og afstemning i realtid for at sikre, at disse forretningsprocesser forbliver synkroniserede. Det er en anden interessant brugssag. Der er en stor amerikansk regeringsentreprenør, der kigger på DNS-trafik for at foretage afvigelse af afvigelser. Der er en offline træningsmodel, som de har bygget, og de laver scoringen baseret på denne model i realtidstrafik. Nogle af disse interessante anvendelsessager. Der er et større flyselskab, der ser på sikkerhedskøer, og de prøver at give dig de oplysninger, der ”Hej, det er din port til dit fly til din flyvning. TSA-køen i dag er ca. 45 minutter mod to timer i forhold til noget andet. ”Du får den opdatering på forhånd. De arbejder stadig på det. Interessant IoT-brugssag, men fantastisk tilfælde af streaminganalyse, der går mod kundeoplevelsen.
Rebecca Jozwiak: Dette er Rebecca. Mens du handler om brugssager, er der et stort spørgsmål fra et publikummedlem, der spekulerer på: ”Er disse casestudier, bliver disse initiativer drevet fra informationssystemets analytiske side af huset, eller bliver de mere drevet fra den virksomhed, der har specifikke spørgsmål eller behov i tankerne? ”
Anand Venugopal: Jeg tror, vi ser cirka 60 procent eller deromkring, 50 procent til 55 procent, stort set meget proaktive, entusiastiske teknologiinitiativer, der tilfældigvis ved, som tilfældigvis er ret dygtige og forstår visse forretningskrav, og de har sandsynligvis en sponsor, som de identificeret, men dette er teknologiteam, der gør sig klar til angreb på sager om forretningsbrug, der kommer igennem, og så når de først har opbygget kapaciteten, ved de, at de kan gøre dette, og så går de til forretning og sælger aggressivt dette. I 30 til 40 procent af sagerne ser vi, at virksomheden allerede har en bestemt brugssag, der tigger om en streaminganalysefunktion.
Rebecca Jozwiak: Det giver mening. Jeg har et andet lidt mere teknisk spørgsmål fra et publikummedlem. Han spekulerer på, om disse systemer understøtter både strukturerede og ustrukturerede datastrømme, som sedimenter af Twitter-streams eller Facebook-indlæg i realtid, eller skal det oprindeligt filtreres?
Anand Venugopal: De produkter og teknologier, som vi taler om, understøtter meget forestående både strukturerede og ustrukturerede data. De kan konfigureres. Alle data har en slags struktur, hvad enten det er en tekst eller en XML eller noget som helst. Der er en vis struktur med hensyn til, at der er et tidsstempel feed. Der er måske en anden klods, der skal parses, så du kan injicere parser i strømmen for at analysere datastrukturerne. Hvis det er struktureret, fortæller vi bare systemet, "Okay, hvis der er komma-adskilte værdier, og den første er en streng, den anden er en dato." Så vi kan injicere den parsing intelligens i up-screen lagene og behandler let både strukturerede og ustrukturerede data.
Rebecca Jozwiak: Jeg har et andet spørgsmål fra publikum. Jeg ved, at vi er løbet lidt forbi toppen af timen. Denne deltager vil gerne vide, det ser ud til, at streaming-applikationer i realtid muligvis udvikler både et behov og en mulighed for at integrere tilbage i transaktionssystemer, svindelforebyggende systemer, de bringer op for eksempel. I så fald skal transportsystemer tilpasses for at passe til det?
Anand Venugopal: Det er en fusion, ikke? Det er en fusion af transaktionssystemer. De bliver undertiden datakilden, hvor vi analyserer transaktioner i realtid, og i mange tilfælde, hvor vi siger, at der er en applikationsstrøm, og her prøver jeg at vise et statisk dataopslagsside og derefter i vores tilfælde, hvor en slags streaming i, og du søger en statisk database op som en HBase eller en RDBMS for at berige streamingdataene og de statiske data sammen for at tage en beslutning eller en analytisk indsigt.
Der er en anden stor branchetrend, som vi også ser - konvergensen af OLAP og OLTP - og det er derfor, du har databaser som Kudu og i-hukommelsesdatabaser, der understøtter både transaktioner og analytisk behandling på samme tid. Strømbehandlingslaget ville være helt i hukommelsen, og vi ser på eller samles med nogle af disse transaktionsdatabaser.
Rebecca Jozwiak: Blandet arbejdsbyrde har været en af de sidste forhindringer, jeg tror. Dez, Robin, har I to flere spørgsmål?
Dez Blanchfield: Jeg kommer til at hoppe ind på et sidste spørgsmål og slå det op, hvis du ikke har noget imod det. Den første udfordring, som de organisationer, som jeg har beskæftiget sig med i det sidste årti eller så, førte ind i denne spændende udfordring med strømanalyse, den første ting, de har en tendens til at lægge tilbage på bordet, da vi startede samtalen omkring hele denne udfordring, er hvor skal får vi evnerne? Hvordan omskolerer vi færdighedsættet, og hvordan får vi denne kapacitet internt? At have impetus der kommer ind og hånden holder os gennem rejsen og derefter implementere som et stort første skridt, og det giver en masse mening at gøre det.
Men for mellemstore til store organisationer, hvad er de slags ting, du ser i øjeblikket for at forberede dig på dette, at opbygge denne kapacitet internt, at få alt fra bare et grundlæggende ordforråd omkring det, og hvilken slags budskab kan de gøre med organisationen omkring overgangen til denne form for rammer og genindlæse deres eksisterende tekniske personale fra IT fra CEO, så de kan køre dette selv, når du bygger og implementerer det? Bare meget kort, hvilken slags udfordringer, og hvordan løser de dem, kunderne, du har at gøre med, hvilke typer udfordringer, de fandt, og hvordan de går gennem at løse den omskoling og genvinde erfaring og viden for at blive klar til dette og at være i stand til at gå rundt operationelt?
Anand Venugopal: Ofte er det lille sæt mennesker, der prøver at gå ud og købe en streaming analytisk platform allerede rimeligt smart, idet de er Hadoop opmærksomme, de har allerede fået deres Hadoop MapReduce færdigheder, og fordi de arbejder tæt sammen med Hadoop distributionsleverandør, de er enten velkendte. Alt får Kafka, for eksempel. De gør noget med det, og enten er Storm- eller Spark-streaming i deres open source-domæne. Definitivt er folk fortrolige med det eller bygger færdigheder omkring det. Men det starter med et lille sæt mennesker, der er dygtige nok og er smarte nok. De deltager i konferencer. De lærer, og at de stiller intelligente spørgsmål til leverandørerne, og i nogle tilfælde lærer de sammen med leverandørerne. Når sælgerne kommer og præsenterer på det første møde, ved de muligvis ikke ting, men de læser op og derefter begynder de at lege med det.
Den lille gruppe mennesker er kernen, og så begynder den at vokse, og alle er nu klar over, at den første sag til forretningsbrug bliver operationel. Der begynder en bølge, og vi så på Spark-topmødet i sidste uge, hvor en stor virksomhed som Capital One var derude og i fuld styrke. De valgte Spark. De talte om det. De uddanner mange af deres mennesker i Spark, fordi de bidrager til det også i mange tilfælde som bruger. Vi ser det samme med mange, mange store virksomheder. Det starter med et par små sæt meget smarte mennesker, og derefter begynder det en bølge af samlet uddannelse, og folk ved, at når en senior VP eller en gang en senior director er på linje, og de vil satse på denne ting, og ordet kommer rundt og de begynder alle at afhente disse færdigheder.
Dez Blanchfield: Jeg er sikker på, at du også har en fantastisk tid på at bygge disse mestre.
Anand Venugopal: Ja. Vi laver en masse uddannelse, mens vi arbejder med de indledende mestre, og vi holder kurser, og mange, mange for vores store kunder, vi er gået tilbage og havde bølger og bølger af træning for at bringe mange af brugerne ind i mainstream-brugsfasen, især i Hadoop MapReduce site. Vi fandt, at vi i et stort kreditkortselskab, der er vores kunde, har leveret mindst måske fem til otte forskellige træningsprogrammer. Vi har også gratis community-udgaver af alle disse produkter inklusive vores, sandkasser, som folk kan downloade, vænne sig til og uddanne sig på den måde også.
Dez Blanchfield: Det er alt, hvad jeg har denne morgen til dig. Mange tak. Jeg synes det er utroligt interessant at se de typer modeller og bruge sager, du har til os i dag. Tak skal du have.
Anand Venugopal: Fantastisk. Mange tak, folkens.
Rebecca Jozwiak: Tak alle for deres deltagelse i denne Hot Technologies webcast. Det har været fascinerende at høre fra Dez Blanchfield, Dr. Robin Bloor og fra Impetus Technologies, Anand Venugopal. Tak præsentanter. Tak talere og tak publikum. Vi har en anden Hot Technologies næste måned, så kig efter det. Du kan altid finde vores indhold arkiveret på Insideanalysis.com. Vi lægger også masser af indhold op på SlideShare og nogle interessante bits på YouTube også.
Det var alt folkens. Tak igen og have en god dag. Hej hej.
