Innehåll
Källa: Madmaxer / Dreamstime.com
Hämtmat:
Värd Rebecca Jozwiak diskuterar strömningsanalys med de bästa branschexperterna.
Rebecca Jozwiak: Mina damer och herrar, hej och välkommen till Hot Technologies 2016! Dagens titel är "Utnyttja brandslangen: få affärsvärde från Streaming Analytics." Detta är Rebecca Jozwiak. Jag är den nästkommande för webbcastvärden när vår kära Eric Kavanagh inte kan vara här, så det är trevligt att se så många av er ute idag.
Det här avsnittet skiljer sig lite från våra andra. Vi pratade lite om vad som är varmt och naturligtvis i år varmt. De senaste åren har varit heta. Det kommer alltid nya saker ut. Idag talar vi om strömningsanalyser. Streaming analytics är lite nytt. Naturligtvis strömning, centerdata, RFID-data, de är inte nödvändigtvis nya. Men när det gäller dataarkitekturer har vi varit så fokuserade på data i vila i decennier. Databaser, filsystem, databaser - allt för det mesta för batchbehandling. Men nu med övergången till att skapa värde från strömmande data, datakänslor, vissa kallar det levande strömmar, kräver de verkligen en strömbaserad arkitektur, inte de data i vila-arkitekturer som vi har varit vana vid och den måste kunna hantering av snabb förtäring, realtid eller nära realtidsbehandling. Det måste kunna tillgodose inte bara tingenes internet utan allt för internet.
Naturligtvis skulle det helst vara trevligt att ha de två arkitekturerna sida vid sida, ena handen tvättar den andra, så att säga. Medan de gamla dagar, veckor gamla data, år gamla data har naturligtvis fortfarande värde, historisk analys, trendanalys, är det livedata som driver liveintelligensen idag och det är därför strömning av analys har blivit så viktig.
Jag pratar mer om det idag. Vi har vår datavetare, Dez Blanchfield, som ringer in från Australien. Det är tidigt på morgonen för honom just nu. Vi har vår chefanalytiker, Dr. Robin Bloor. Vi samarbetar med Anand Venugopal, produktchef för StreamAnalytix på Impetus Technologies. De är verkligen fokuserade på strömningsanalysaspekten i detta utrymme.
Med det kommer jag att gå vidare och skicka det till Dez.
Dez Blanchfield: Tack. Jag måste ta kontroll över skärmen här och springa framåt.
Rebecca Jozwiak: Här har du.
Dez Blanchfield: Medan vi tar tag i bilderna, låt mig bara täcka kärnämnet.
Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
Du kan inte förbättra dina programmeringsfärdigheter när ingen bryr sig om mjukvarukvalitet.
Jag kommer att hålla den ganska hög och jag kommer att hålla den i ungefär 10 minuter. Detta är ett mycket stort ämne. Jag deltog i ett evenemang där vi tillbringade två till tre dagar på att dyka ned i detaljerna om vad strömbearbetning är och de nuvarande ramarna som vi utvecklar och vad att göra analys i dessa högvolymströmmar skulle betyda.
Vi kommer bara att klargöra vad vi menar med att strömma analyser och sedan gå in i om affärsvärde kan härledas eftersom det verkligen är det företag letar efter. De letar efter att få folk att förklara för dem mycket snabbt och kortfattat, var kan jag hämta värde genom att tillämpa någon form av analys på våra strömdata?
Vad är strömningsanalys?
Streaming analytics ger organisationer ett sätt att extrahera värde från högvolym- och höghastighetsdata som de har kommit genom verksamheten i olika former i rörelse. Den väsentliga skillnaden här är att vi har haft en lång historia av att utveckla analyser och linser och visningar av data som vi har behandlat i vila i decennier sedan mainframe uppfanns. Den enorma paradigmförändringen som vi har sett under de senaste tre till fem åren på det vi kallar ”webbskala” utnyttjar de strömmar av data som kommer in i oss i realtid eller nära realtid och inte bara bearbetar och letar efter händelsekorrelation eller händelseutlösare men utför riktigt detaljerad, djupgående analys av dessa strömmar. Det är en betydande förskjutning till vad vi har gjort tidigare som antingen samlar in data, lägger det i någon form av förvar, traditionellt stora databaser nu, stora big data-ramar som Hadoop-plattformen och utför batch-läge-behandling på det och få någon slags insikt.
Vi har blivit väldigt bra på att göra det mycket snabbt och prova massor av tungt järn på grejerna, men vi fångar fortfarande data, lagrar och sedan tittar på det och får lite slags insikter eller analyser om det. Övergången till att utföra dessa analyser när data strömmar in har varit ett mycket nytt och spännande tillväxtområde för de typer av saker som händer kring big data. Det kräver en helt annan strategi för att bara fånga, lagra och bearbeta och utföra analyser på.
En av de viktigaste drivkrafterna för skift och fokus för att utföra analys i strömmen är att du kan få betydande affärsvärde genom att få dessa insikter snabbare och lättare när data kommer till dig eftersom information görs tillgänglig för företaget. Idén att göra slutbehandling nu är inte längre relevant i vissa branscher. Vi vill kunna göra analyser i farten. I slutet av dagen vet vi redan vad som har hänt eftersom det har hänt snarare än att komma till slutet av dagen och göra ett 24-timmars batchjobb och få dessa insikter.
Streaminganalysen handlar om att knacka direkt i den strömmen medan dataströmmar vanligtvis är flera strömmar med mycket höga volymer data och data som kommer mot oss i rörelse väldigt, mycket snabbt och få insikter eller analys av dessa strömmar som de kommer till oss i motsats att låta det komma ut i vila och utföra analyser på dem.
Som jag nämnde har vi haft decennier och decennier av att utföra det jag kallar batchanalys. Jag har lagt en riktigt cool bild här. Detta är en bild av en gentleman som står framför en hårad dator som skapades av RAND Corporation för en livstid sedan och det var så de såg en dator i ett hus att se ut. Det som är intressant är att de redan hade det här konceptet med alla dessa lilla ringer och dessa ringer representerade information som kom in från huset och bearbetades i realtid och berättade vad som händer. Ett enkelt exempel är en uppsättning av barometriskt tryck och temperatur som vi kan se var vi ser vad som händer i realtid. Men jag kan föreställa mig att det ens långt tillbaka då RAND Corporation samlade det lilla mockupet, tänkte de faktiskt redan på att bearbeta data och utföra analyser på det när det kommer i strömformat. Jag är inte helt säker på varför de satte en ratt på datorn, men det är ganska coolt.
Sedan er-uppfinningen har vi haft en uppfattning om att fånga upp data och utföra batchanalys på den. Som jag har sagt med det stora skiftet nu och vi har sett detta från liknande spelare på webben som vi alla känner, de är alla hushållsmärken som och LinkedIn, det interaktiva beteende som vi har med dessa sociala plattformar kräver inte bara fånga, lagra och sedan bearbeta i batchläge men de är faktiskt att fånga och driva analyser i farten från dataströmmar som kommer igenom. När jag Tweetar något, behöver de inte bara fånga och lagra och göra något senare, utan de måste också kunna sätta tillbaka det direkt på min ström och dela det med andra människor som följer mig. Det är en batchbehandlingsmodell.
Varför skulle vi gå ner den här vägen? Varför skulle organisationer investera tid, ansträngning och pengar i att till och med överväga utmaningen att sträva efter strömanalys? Organisationer har denna enorma önskan att få en prestationsförstärkning jämfört med sina konkurrenter i de branscher som de befinner sig i och att prestationsförstärkningen snabbt kan implementeras genom enkel strömanalys och det kan börja med en enkel spårning i realtid som vi redan har bekant med. Jag fick en liten skärmdump där från Google Analytics. Detta är förmodligen en av de första gångerna som vi verkligen fick praktiska analyser för konsumentklass. Så när folk besökte din webbplats och du får dessa träffar, med en liten bit JavaScript på botten av din webbsida i HTML inbäddad på din webbplats, gjordes dessa små koder i realtid tillbaka till Google och de var utföra analyser av de strömmar av data som kommer in från varje sida på din webbplats, varje objekt på din webbplats i realtid och de återger det till dig på denna riktigt söta lilla webbsida i en instrumentpanel med realtidsgraf, söta lilla histogram och linje graf som visar dig X antal personer som träffar din sida historiskt, men här är hur många det finns just nu.
Som du kan se på den skärmdumpen står det 25 just nu. Det är 25 personer just nu när skärmdumpen fanns på den sidan. Det är den första verkliga chansen vi spelade på analysverktyg för konsumentklass. Jag tror att många människor verkligen fick det. De förstod kraften i att veta vad som hände och hur de kan svara på det. När vi tänker på omfattningen av flygelektronik, flygplan som flyger runt, finns det 18.700 inrikesflyg per dag i USA ensam. Jag läste ett papper för en tid sedan - det var för cirka sex eller sju år sedan - att mängden data som producerades av dessa flygplan var cirka 200 till 300 megabyte i den gamla teknikmodellen. I dagens design av flygplan producerar dessa flygplan cirka 500 gigabyte data eller ungefär en halv terabyte data per flygning.
När du gör matematiken mycket snabbt utanför huvudet, att 18 700 inrikesflyg var dygnet runt i det amerikanska luftrummet, om alla moderna flygplan producerar ungefär en halv terabyte, så är det 43 till 44 petabyte data som kommer igenom och det händer medan flygplanen är i luften. Det händer när de landar och de gör datadumpar. Det är när de går in i butiken och har en fullständig datadump från ingenjörerna för att titta på vad som händer i lager, hjul och inuti motorerna. Vissa av dessa uppgifter måste behandlas i realtid så att de kan fatta beslut om det finns en verklig fråga medan planet var i luften eller medan det är på marken. Du kan bara inte göra det i batchläge. I andra branscher som vi ser där ute kring finans, hälsa, tillverkning och teknik tittar de också på hur de kan få med denna nya insikt i vad som händer i realtid i motsats till vad som bara lagras i databaserna på en termin.
Det finns också detta begrepp att hantera data som det jag kallar en förgänglig vara eller en förgänglig vara - att mycket data förlorar värde över tid. Detta är mer och mer fallet med mobilitetsappar och sociala medieverktyg eftersom vad folk säger och vad som nu trender är det du vill svara på. När du tänker på andra delar av våra liv med logistik och leverans av mat runt, förstår vi begreppet förgärlig vara i den meningen. Men tänk på de data som går igenom din organisation och värdet den har. Om någon gör affärer med dig just nu och du kan interagera med dem i realtid, vill du inte vänta en timme så att data kan fångas in och läggas in i ett system som Hadoop och sedan trycka på den här knappen, du kommer inte att kunna hantera det just nu och du vill kunna göra det på kundens begäran omedelbart. Det finns en term som du kommer att dyka upp mycket nu där folk pratar om att ha den här dataströmmen i realtid som kan ge dig anpassning och att anpassningen stämmer med systemet du använder till din individuella upplevelse. Så när du till exempel träffar ett verktyg som Google Sökverktyg, om jag gör en fråga och gör samma fråga, alltid får vi inte exakt samma data. Vi får i huvudsak vad jag kallar en kändisupplevelse. Jag behandlas med en engång. Jag får min egen personliga version av vad som händer i dessa system baserat på profiler och data som de har samlat på mig och jag kunde göra analys i realtid i strömmen.
Denna idé om att data är en förgänglig vara är en verklig sak för nu och värdet på data som minskar över tiden är något som vi måste ta itu med i dag. Det är inte en grej i går. Jag älskar den här bilden av en björn som tar en lax som hoppar ut ur floden eftersom den verkligen målar exakt vad jag ser strömningsanalys. Det är denna enorma flod av data som kommer till oss, en brandslang om du vill, och björnen sitter mitt i bäcken. Det kommer att utföra analyser i realtid om vad som händer runt det så att det faktiskt kan konstruera sin förmåga att fånga den fisken i luften. Det är inte som att bara doppa i strömmen och ta tag i en. Den här saken hoppar i luften och den måste vara på rätt plats vid rätt tidpunkt för att fånga den fisken. Annars får han inte frukost eller lunch.
En organisation vill göra samma sak med sina uppgifter. De vill hämta värde från det som nu är enorma mängder data i rörelse. De vill utföra analyser av data och hög hastighetsdata så det är inte bara mängden data som kommer till oss utan det är den hastighet som den kommer från detta. I säkerhet till exempel är det alla dina routrar, switchar, servrar, brandväggar och alla händelser som kommer från dessa och tiotusentals om inte hundratusentals enheter, i vissa fall är förgängliga data. När vi tänker på det på Internet of Things och det industriella Internet, vi talar om miljoner om inte miljarder sensorer så småningom, och när data kommer igenom som utför analyser, tittar vi nu på att göra komplexa händelserhantering på beställningar av storlek och hastighet som vi aldrig ens har sett förut och vi måste ta itu med detta idag. Vi måste bygga verktyg och system runt det. Det är en verklig utmaning för organisationer eftersom vi å ena sidan har de väldigt stora varumärken som gör DIY, baka det själv, när de har kapacitet att göra det och skicklighet och teknik. Men för den genomsnittliga organisationen är det inte fallet. De har inte skicklighetsuppsättningarna. De har inte kapacitet eller tid eller ens pengar att investera i att räkna ut det. De siktar alla mot detta koncept om nära realtidsbeslut.
Använd fall som jag har stött på, och de finns över alla brett spektrum i varje sektor som du kan föreställa dig, människor sitter upp och uppmärksammar och säger, hur använder vi vissa analyser på våra strömdata? Vi talar om onlinetjänster på webben. Det finns de traditionella sociala medieplattformarna och online e-tailing och detaljhandel - appar till exempel. De försöker alla ge oss den här kändisupplevelsen i realtid. Men när vi kommer in på fler av teknikstacktjänsterna, telefontjänster, röst och video, ser jag människor gå runt och gör FaceTime på telefoner. Det exploderar bara. Det vaggar i mitt sinne att folk håller telefonen framför dem och pratar med en videoström av en vän i motsats till att hålla den i örat längre. Men de vet att de kan göra det och de anpassade sig och de gillade den upplevelsen. Utvecklingen av dessa applikationer och plattformarna som levererar dessa måste utföra realtidsanalys för den trafiken och på profilerna för trafiken så att de kan göra enkla saker som att dirigera den videon perfekt så att röstkvaliteten i en video som du får är tillräcklig för att få en bra upplevelse. Du kan inte behandla den typen av data. Det skulle inte göra videoströmmen i realtid till en funktionell tjänst.
Det finns en styrande utmaning i finansiella transaktioner. Det är inte okej att komma till slutet av dagen och ta reda på att du bröt lagen som flyttar privat information runt platsen. I Australien har vi en mycket intressant utmaning där flyttning av sekretessrelaterade data offshore är ett nej. Du kan inte ta min PID, min privata personliga identifieringsinformation offshore. Det finns lagar i Australien för att hindra det från att hända. Tillhandahållare av finansiella tjänster, i synnerhet statliga tjänster och myndigheter, de måste göra analyser i realtid på sina dataströmmar och instruktioner med mig för att se till att det de ger mig inte lämnar stränderna. Alla saker måste stanna lokalt. De måste göra det i realtid. De kan inte bryta lagen och be om förlåtelse senare. Bedrägeri upptäckt - det är ganska uppenbart att vi hör till med kreditkortstransaktioner. Men eftersom de typer av transaktioner vi gör i finansiella tjänster förändras mycket, mycket snabbt, finns det olika saker som PayPal gör först nu för att upptäcka bedrägerier i realtid där pengar inte flyttar från en sak till en annan, men det är en finansiell transaktion mellan system. Ebays budplattformar, upptäcka bedrägeri måste göras i realtid på ett streamingkontor.
Det går nu en trend att utföra extraktion och omvandla lastaktivitet i strömmarna så att vi inte vill fånga något som går till strömmen. Vi kan inte riktigt göra det. Folk har lärt sig att data gillar att brytas riktigt snabbt om vi fångar allt. Tricket nu är att utföra analyser på dessa strömmar och göra ETL på det och bara fånga vad du behöver, eventuellt metadata, och sedan köra prediktiv analys där vi faktiskt kan sedan berätta vad som kommer att hända lite längre ner på vägarna på vad vi har just sett i strömmen baserat på den analys vi utförde på det.
Leverantörer av energi och verktyg upplever denna enorma önskan från konsumenterna att ha prissättning efterfrågan. Jag kanske bestämmer mig för att jag vill köpa grön kraft vid en viss tid på dagen för jag är bara hemma ensam och jag använder inte många enheter. Men om jag äter middag, kanske jag vill ha alla mina enheter på och jag vill inte köpa billig ström och vänta på att den ska levereras men vill betala för mer kostnad för att få den kraften. Denna efterfrågan prissätter särskilt i verktyg och energiutrymme har redan hänt. Uber är till exempel ett klassiskt exempel på saker du kan göra varje dag och allt drivs av efterfrågan prissättning. Det finns några klassiska exempel på att människor i Australien får 10 000 $ biljetter på grund av den enorma efterfrågan på nyårsafton. Jag är säker på att de har hanterat det problemet men strömanalyser som utförs i realtid medan de är i bilen berättar hur mycket jag ska betala.
Internet of Things och sensorströmmar - vi har bara skrapat ytan på detta och vi har egentligen bara haft den grundläggande konversationen som händer på detta men vi kommer att se en intressant förändring i hur tekniken hanterar det eftersom när du pratar inte ungefär tusentals eller tiotusentals men hundratusentals och potentiellt miljarder enheter som strömmar till dig, nästan ingen av de teknikstackar vi har nu är konstruerade för att hantera det.
Det finns några riktigt heta ämnen som vi kommer att se på plats som säkerhet och cyberrisk. De är mycket verkliga utmaningar för oss. Det finns ett riktigt snyggt verktyg som heter North på webben där du kan sitta och titta på en webbsida olika cyberattacker som händer i realtid. När du tittar på det tror du att "åh, det är en fin söt liten webbsida", men efter ungefär fem minuter där inse du hur mycket datan systemet gör analys på alla de olika strömmarna på alla olika enheter runt om i världen som matas in i dem. Det börjar svåra hur de presterar det i utkanten av den skivan väsentligen och ger dig den enkla lilla skärmen som berättar vad du ska eller något annat som attackerar den i realtid och vilka typer av attacker. Men det är ett riktigt snyggt sätt att bara få en god smak på vad strömanalyser potentiellt kan göra för dig i realtid genom att bara titta på den här sidan och få en känsla av bara volymen och utmaningen att ta strömmarna, bearbeta analysfrågor på dem och representerar det i realtid.
Jag tror att konversationen som jag har för resten av sessionen kommer att ta itu med alla dessa typer av saker med en intressant vy, ur min synvinkel, och det är utmaningen för DIY, baka det själv, passar några av de klassiska enhörningar som har råd att bygga den typen av saker. De har miljarder dollar för att bygga dessa ingenjörsteam och bygga sina datacenter. Men för 99,9% av organisationerna där ute som vill driva värde i sin verksamhet med strömanalys måste de få en tjänst utanför hyllan. De måste köpa en produkt ur lådan och de behöver i allmänhet konsulttjänster och professionell service för att hjälpa dem att genomföra den och de får det värdet tillbaka i verksamheten och säljer det tillbaka till företaget som en fungerande lösning.
Med det kommer jag att ge tillbaka till dig, Rebecca, för jag tror att det är vad vi ska täcka i detalj nu.
Rebecca Jozwiak: Excellent. Tack så mycket, Dez. Det är en fantastisk presentation.
Nu ska jag skicka bollen till Robin. Ta bort det.
Robin Bloor: Okej. Eftersom Dez har gått in i det snygga med strömbearbetning verkade det inte vara vettigt för mig att täcka det igen. Så jag ska bara ta en helt strategisk syn. Ser nästan från en mycket hög nivå ner på vad i helvete som händer och placerar det eftersom jag tror att det kan hjälpa människor, särskilt oss människor som inte är belägna i strömmar som bearbetar på stort djup tidigare.
Behandling av strömmar har funnits länge. Vi brukade kalla det CEP. Det fanns realtidssystem innan det. De ursprungliga processkontrollsystemen behandlade faktiskt informationsströmmar - givetvis gick ingenting så långt som det är idag. Den här grafiken som du ser på bilden här; det pekar på mycket saker faktiskt, men det pekar utöver allt annat - det faktum att det finns ett spektrum av latenser som visas i olika färger här nere. Det som faktiskt hände sedan uppfinningen av datoranläggning eller kommersiell datoranläggning som kom fram ungefär 1960 är att allt just har blivit snabbare och snabbare. Vi brukade kunna bero på hur detta faktiskt skulle komma ut om du gillar i vågor, för det är så det ser ut. Detta beror faktiskt på det.Eftersom allt drivs av Moores lag och Moores lag skulle ge oss en faktor på cirka tio gånger högre hastighet under en period av cirka sex år. Sedan när vi faktiskt kom till ungefär 2013 bröt det hela och vi började plötsligt accelerera i en takt som vi aldrig har gjort, vilket är konstigt enastående. Vi fick en faktor på cirka tio i termer av ökad hastighet och därför en minskning av latensen cirka var sjätte år. Under de sex åren sedan cirka 2010 har vi fått en multipel på minst tusen. Tre storleksordningar snarare än en.
Det är vad som har pågått och det är därför som industrin på ett eller annat sätt verkar gå i fantastiska hastigheter - för det är det. Bara gå igenom innebörden av denna grafik, svarstiderna är förresten i algoritmisk skala ner den vertikala axeln. Realtid är datorhastighet, snabbare än människor. Interaktiva tider är orange. Det är när du interagerar med datorn där du verkligen vill ha en tiondel till ungefär en sekund av latens. Ovanför finns det transaktioner där vi faktiskt tänker på vad du gör i datorn men om det går ut på cirka femton sekunder blir det oacceptabelt. Människor skulle faktiskt bara inte vänta på datorn. Allt gjordes i batch. Många saker som gjordes i parti kommer nu ner i transaktionsutrymmet, rakt in i det interaktiva utrymmet eller till och med i realtidsutrymmet. Medan tidigare, en vågig med mycket små mängder data vi kunde göra något av detta, kan vi nu göra med mycket stora mängder data med enormt utskalad miljö.
Så i princip säger allt detta verkligen transaktion och interaktiva mänskliga responstider. En hel del av det som görs med strömmar just nu är att informera människor om saker. En del av det går snabbare än så och det informerar om saker så det är realtid. Då tar vi en licens för att bara släppa som en sten, vilket gör omedelbar analys möjlig och förresten ganska prisvärd. Det är inte bara hastigheten har sjunkit och toppen har bara kollapsat också. Förmodligen den största effekten i alla dessa bland alla de olika applikationerna, du kan göra alla dessa prediktiva analyser. Jag ska berätta varför om en minut.
Detta är bara hårdvaruhandeln. Du har parallell programvara. Vi pratar om 2004. Skala ut arkitektur, multicore chips, minneökning, konfigurerbar CPU. SSD: er går nu så mycket snabbare än snurrdisken. Du kan ganska mycket vågspinnande disken adjö. SSD: er finns också i flera kärnor, så igen snabbare och snabbare. Snart kommer vi att få memristorn från HP. Vi har fått 3D XPoint från Intel och Micron. Löfte för dem är att det kommer att göra att allt går snabbare och snabbare ändå. När du verkligen tänker på två nya minneteknologier, som båda kommer att göra hela den grundläggande lilla biten, det enskilda kretskortet går mycket snabbare, har vi inte ens sett slutet på det.
Streams-tekniken, som verkligen är nästa, är här för att stanna. Det måste bli en ny arkitektur. Jag menar att Dez har nämnt detta i flera punkter i sin presentation. I årtionden såg vi på arkitektur som en kombination av datahögar och datapipor. Vi tenderade att bearbeta högarna och vi tenderade att leda data mellan högen. Vi går nu grundläggande mot det vi kallar Lambda-dataarkitekturen som kombinerar behandlingen av dataflöden med datahögen. När du faktiskt bearbetar en ström av händelser som kommer in mot historiska data som ett dataflöde eller en datahöja, det är vad jag menar med Lambda-arkitekturen. Detta är i sin barndom. Det är bara en del av bilden. Om du betraktar något så komplicerat som Internet of Everything som Dez också har nämnt, kommer du faktiskt att inse att det finns alla möjliga problem med dataläge - beslut om vad du ska behandla i strömmen.
Det som jag verkligen säger här är att när vi bearbetade i batch bearbetade vi faktiskt strömmar. Vi kunde bara inte göra det en åt gången. Vi väntar bara tills det finns en stor massa saker och sedan bearbetar vi allt på en gång. Vi flyttar till en situation där vi faktiskt kan behandla saker i strömmen. Om vi kan bearbeta saker i strömmen, kommer datahögarna som vi har att vara de statiska data som vi behöver referera för att bearbeta data i strömmen.
Detta tar oss till just denna sak. Jag har nämnt detta tidigare i en presentation med den biologiska analogin. Det sätt som jag skulle vilja att du tänker på är för närvarande vi människor. Vi har tre distinkta nätverk för förutsägbar behandling i realtid. De kallas somatiska, autonoma och enteriska. Enteric är din mage. Det autonoma nervsystemet tar hand om strider och flygningar. Det ser faktiskt efter snabba reaktioner på miljön. Somatikern som tar hand om kroppens rörelse. Det är system i realtid. Det intressanta med det - eller jag tycker är lite intressant - är mycket av det mer förutsägbart än du någonsin skulle föreställa dig. Det är som om du verkligen tittar på en skärm cirka 18 tum från ditt ansikte. Allt du kan se tydligt, allt som din kropp kan se tydligt handlar i själva verket om en 8 × 10 rektangel. Allt utanför detta är faktiskt suddigt när det gäller din kropp, men ditt sinne fyller faktiskt luckorna och gör att det inte blir suddigt. Du ser inte någon oskärpa alls. Du ser det tydligt. Ditt sinne gör faktiskt en prediktiv metod för dataströmmen för att du ska kunna se den tydligheten. Det är typ av nyfikenhet, men du kan faktiskt titta på hur nervsystemet fungerar och hur vi lyckas komma runt och uppträda rimligt - åtminstone några av oss - rimligt trevligt och inte stöta på saker hela tiden.
Det hela görs av en serie neurala analysskalor här inne. Det som kommer att hända är att organisationer kommer att ha samma typ av saker och kommer att bygga samma typ av saker och det kommer att bli behandlingen av strömmar inklusive organisationens interna strömmar - de saker som händer inom det, de saker som händer utanför det, de omedelbara svar som faktiskt måste göras är naturligtvis att mata människan att fatta beslut, att få alla dessa att hända. Det är där vi ska, så vitt jag kan se.
En av de saker som är en följd av det är att nivån på streamingapplikationen går bra. Det kommer att bli väldigt mycket mer än vi ser nu. Just nu väljer vi den låghängande frukten att göra saker som är uppenbara.
Så i alla fall är det slutsatsen här. Streaming analytics är en gång en nisch men det håller på att bli mainstream och det kommer snart att antas generellt.
Med det kommer jag att skicka tillbaka det till Rebecca.
Rebecca Jozwiak: Tack så mycket, Robin. Fantastisk presentation som vanligt.
Anand, du är nästa. Golvet är ditt.
Anand Venugopal: Fantastisk. Tack.
Jag heter Anand Venugopal och jag är produktchef för StreamAnalytix. Det är en produkt som erbjuds av Impetus Technologies från Los Gatos, Kalifornien.
Impetus har faktiskt haft en stor historia i att vara en leverantör av stora datalösningar för stora företag. Så vi har faktiskt gjort ett antal strömningsanalysimplementeringar som ett tjänsteföretag och vi lärde oss många lektioner. Vi tog också en övergång till att bli ett produktföretag och lösningsdrivet företag under de senaste åren och strömanalys leder kursen för att förvandla Impetus till ett till stor del produktdrivet företag. Det finns några kritiska, väldigt mycket viktiga tillgångar som Impetus rensade tack vare vår exponering för företag och StreamAnalytix är en av dem.
Vi har 20 år i branschen och det finns en fantastisk blandning av produkter och tjänster som gör oss till en enorm fördel. Och StreamAnalytix föddes av alla lärdomar från våra första fem eller sex implementeringar av streaming.
Jag kommer att beröra några saker, men analytikerna, Dez och Robin, har gjort ett fantastiskt jobb med att täcka utrymmet övergripande så jag kommer att hoppa över mycket innehåll som överlappar varandra. Jag kommer förmodligen att gå snabbt. Vi ser förutom verkliga streamingfall som använder en hel del bara batchacceleration där det bokstavligen finns mycket, mycket viktiga batchprocesser i företag. Som ni kan se kan hela cykeln att avkänna en händelse och analysera och agera på det faktiskt ta veckor i stora företag och de försöker alla krympa den till minuter och ibland sekunder och millisekunder. Så någonting snabbare än alla dessa batchprocesser är kandidater för förvärv av företag och det säger mycket väl att värdet på data dramatiskt minskar med dess ålder, så desto mer värde finns det i den initiala delen på de sekunder som det just hände. Idealt, om du kunde förutsäga vad som skulle hända, är det det högsta värdet. Det beror dock på noggrannhet. Det näst högsta värdet är när det är där när det händer kan du analysera det och svara. Naturligtvis minskar värdet dramatiskt efter det, den huvudsakliga restriktiva BI som vi är i.
Det är intressant. Du kan förvänta dig något dramatiskt vetenskapligt svar på varför streaming analytics. I många fall är det vi ser att det är nu möjligt och eftersom alla vet att parti är gammalt, parti är tråkigt och parti är inte coolt. Det finns tillräckligt med utbildning som alla har fått nu om att det är möjligt att strömma och alla har Hadoop nu. Nu har Hadoop-distributioner en strömningsteknologi inbäddad i den, oavsett om det är Storm- eller Spark-strömning och naturligtvis köer, som Kafka, etc.
Företag vi ser hoppar in i det och börjar experimentera med dessa fall och vi ser två breda kategorier. Det ena har något att göra med kundanalys och kundupplevelse och den andra operativa intelligensen. Jag kommer in på några detaljer om det lite senare. Hela kundservicen och kundupplevelsevinkeln och vi på Impetus StreamAnalytix har gjort det här på många olika sätt handlar egentligen egentligen om, verkligen fånga konsumentens flerkanaliga engagemang i realtid och ge dem väldigt, mycket känsliga upplevelser som inte är vanliga idag. Om du surfar på webben, på Bank of America-webbplatsen och du undersöker vissa produkter och du ringer bara till callcenter. Skulle de säga: "Hej Joe, jag vet att du forskade på vissa bankprodukter, vill du att jag ska fylla i dig?" Du förväntar dig inte det idag, men det är den typ av upplevelse som verkligen är möjlig med strömningsanalys. I många fall gör det en stor skillnad, särskilt om kunden började undersöka sätt att komma ur sitt kontrakt med dig genom att titta på klausuler om tidig uppsägning eller villkor för tidig uppsägning på din webbplats och sedan ringa in och du inte kan direkt konfrontera dem om det men bara indirekt göra ett erbjudande om någon form av första marknadsföring eftersom systemet vet att den här personen tittar på tidig uppsägning och du gör det erbjudandet vid den punkten, du kan mycket väl skydda den ostörda kunden och skydda den tillgången .
Det skulle vara ett exempel, plus många kundservice är alla mycket bra exempel. Vi implementerar idag sänker kostnaderna i callcenter samt ger dramatiska förtjusande kundupplevelser. Dez gjorde ett bra jobb med att sammanfatta några av användningsfallen. Du kan stirra på detta diagram i ett par minuter. Jag klassificerade det som vertikaler, horisontella och kombinationsområden, IoT, mobilapp och callcenter. De är alla vertikala och horisontella. Det beror på hur du ser på det. Sammanfattningsvis ser vi en hel del horisontella användningar som är ganska vanliga i branschens vertikala och det finns ett vertikalt specifikt användningsfall inklusive finansiella tjänster, sjukvård, telekom, tillverkning osv. Om du verkligen ställer dig själv frågan eller säger dig själv det, ”åh, jag vet inte vilka användningsfall det finns. Jag är inte säker på om det verkligen finns något affärsvärde i att strömma analyser för mitt företag eller för vårt företag, "tänk hårt, tänk två gånger. Prata med fler människor eftersom det finns användningsfall som i ditt företag är relevanta idag. Jag kommer in på affärsvärdet på hur exakt affärsvärdet härleds.
Längst ner i pyramiden här har du förutsägbart underhåll, säkerhet, kärnskydd etc. Dessa typer av användningsfall utgör skydd för intäkter och tillgångar. Om Target skyddade deras säkerhetsbrott som hände över timmar och veckor, kunde CIO ha räddat sitt jobb. Det kan spara tiotals eller hundratals miljoner dollar, osv. Realtidsströmningsanalyser hjälper verkligen till att skydda dessa tillgångar och skydda förluster. Det är direkt mervärde där.
Nästa kategori blir mer lönsamt, sänker dina kostnader och får mer intäkter från nuvarande verksamhet. Det är effektiviteten hos det nuvarande företaget. Det är alla kategorier av användningsfall som vi kallar realtid operationell underrättelse där du får djup insikt i hur nätverket uppför sig, hur din kundverksamhet uppför sig, hur din affärsprocess fungerar och du kan justera allt detta i realtid eftersom du får feedback, får du varningar. Du får avvikelser, avvikelser i realtid och du kan snabbt agera och skilja processen som går utanför gränserna.
Du kan eventuellt också spara mycket pengar i dyra kapitaluppgraderingar och saker som du tycker är nödvändiga och som kanske inte är nödvändiga om du optimerade nätverkstjänsten. Vi hörde talas om ett fall där en större telco uppskjuts en uppgradering av 40 miljoner dollar i sin nätverksinfrastruktur eftersom de fann att de hade tillräckligt med kapacitet för att hantera sin nuvarande trafik, vilket är genom att optimera och bättre göra den intelligenta dirigeringen av deras trafik och sådant. Dessa är alla möjliga endast med någon realtidsanalys och handlingsmekanism som verkar på dessa insikter i realtid.
Nästa nivå av mervärde är uppsäljning, korsförsäljning där det finns möjligheter att göra mer intäkter och vinster från nuvarande erbjudanden. Detta är ett klassiskt exempel som många av oss vet om att de har upplevt var, du tänker på i ditt liv där du är villig att faktiskt köpa en produkt idag som inte erbjuds dig. I många, många fall händer det faktiskt. Du har saker i åtanke som du gillar att köpa som du vet att du vill köpa, att du har en att göra-lista eller något, som din fru sa till dig eller om du inte har en hustru men du verkligen ville köpa och du går antingen och shoppar på en webbplats eller interagerar i en butik, butiken har bara inte nackdelarna, har inte intelligensen för att beräkna vad du kan behöva. Därför blir de inte säkra för deras verksamhet. Om strömningsanalyser skulle kunna distribueras för att verkligen göra exakta förutsägelser och som verkligen är möjliga på vad som bäst passar just denna nackdel, den här kunden just nu på den här platsen, det finns en hel del uppsäljning och korsäljning och det kommer igen från strömningsanalys - att kunna fatta ett benägenhetsbeslut av vad den här kunden sannolikt kommer att köpa eller svara på i det ögonblick av sanningen när det finns en möjlighet. Det är därför jag älskar den bilden som Dez visade med björnen nästan att äta den fisken. Det är ganska mycket det.
Vi tror också att det finns en stor kategori där av dramatiska, förändringsförändringar i ett företag med att erbjuda helt nya produkter och tjänster helt enkelt baserade på observation av kundbeteende, allt baserat på observation av ett annat företags beteende. Om, låt oss säga, ett telco eller ett kabelföretag som verkligen observerar användningsmönstren hos kunder i vilket segment av marknaden han tittar på, vilket program vid vilken tidpunkt etc., så slutar de faktiskt att skapa produkter och tjänster som nästan tiggas för på något sätt. Så hela konceptet med flera skärmar beteende just nu där vi nu nästan tar det för givet att vi kan se TV eller kabelinnehåll på våra mobilappar. Några av dessa exempel kommer från de nya produkter och tjänster som erbjuds oss.
Jag kommer in på "Vad är arkitekturhänsynen till strömningsanalys?" Det är i slutändan vad vi försöker göra. Det här är Lambda-arkitekturen där du blandar historiska data och insikter i realtid och ser det samtidigt. Det är vad Sigma möjliggör. Vi har alla batcharkitekturen och företagsbilden idag. Vi skenar in i någon form av en BI-stack och användningsstapel och Lambda-arkitekturen har lagts till. Eftersom hastighetslagret eller behovet och Lambda handlar om att slå samman dessa två insikter och se det på ett kombinerat sätt, på ett rikt sätt som kombinerar båda insikter.
Det finns ett annat paradigm som heter Kappa-arkitekturen som föreslås där antagandet är att hastighetsskiktet är den enda inmatningsmekanismen som kommer att kvarstå på längre sikt. Allt kommer att komma igenom detta hastighetslager. Det kommer inte ens att bli en offline ETL-mekanism. Allt ETL kommer att hända. Rengöring, rengöring av data, ETL av kvalitet - allt detta kommer att hända på kabeln, eftersom tänk på att all data föddes i realtid. Vid någon tidpunkt var det realtid. Vi har blivit så vana att lägga detta på sjöar, på floder och hav och sedan göra det på statisk analys att vi glömde att uppgifterna föddes vid någon tidpunkt i realtid. All data är faktiskt född som en realtidshändelse som inträffade i tidpunkten och de flesta data idag på sjön just sattes i databasen för en senare analys och vi har nu fördelen i Lambda och Kappa arkitektur av faktiskt se det, analysera det, förbehandla det och reagera på det när det kommer. Det är vad som möjliggörs av dessa tekniker. När du ser på det som en helhetsbild ser det ut som något så här där det finns Hadoop inuti, det finns MPP och datalager som du redan har.
Vi lägger upp detta eftersom det är viktigt att inte bara prata om ny teknik på en ö. De måste integreras. De måste vara vettiga i det nuvarande företaget, och som lösningsleverantörer som betjänar företag, är vi mycket känsliga för detta. Vi hjälper företag att integrera hela saken. Det finns datakällor på vänster sida som matar in både Hadoop och datalagerlagren såväl som i realtidskiktet ovanpå och var och en av dessa enheter är lagerdatorer som du kan se och datakonsumtionslagret är till höger sida. Det finns en ständig ansträngning för att flytta majoriteten av efterlevnad, styrning, säkerhet, livscykelhantering, etc., som finns tillgängliga idag har alla samlats in i denna nya teknik.
En av de saker som strömmar analytik försöker göra, om man tittar på landskapet idag, det finns många saker som händer i strömningsteknologilandskapet och från företagets synvinkel är det så mycket att förstå. Det finns så mycket att hålla jämna steg med. Det finns datainsamlingsmekanismer på vänster sida - NiFi, Logstash, Flume, Sqoop. Självklart har jag lagt fram en ansvarsfriskrivning som säger att den inte är uttömmande. Kommer i köerna och kommer sedan in i open source-strömmotorerna - Storm, Spark Streaming, Samza, Flink, Apex, Heron. Heron är förmodligen inte öppen källkod ännu. Jag är inte säker på om det är, från. Dessa strömmande motorer leder sedan in i eller stöder en installationsanalysskomponent för kompositioner som komplex händelsehantering, maskininlärning, prediktiv analys, varningsmodul, streaming ETL, berikningsfilter för statistiska operationer. Det är allt vi kallar nu operatörer. Uppsättningen av de operatörerna när de strängas samman skulle eventuellt också en del anpassade till stor del om nödvändigt bli en strömningsapplikation som körs på en strömmaskin.
Som en del av den kedjan av komponenter måste du också lagra och indexera informationen i din favoritdatabas, ditt favoritindex. Du kanske också måste distribuera cache och igen som leder in i datavisualiseringsskiktet på höger sida på den övre delen till kommersiella produkter eller open source-produkter, men i slutändan behöver du någon sorts produkt för att visualisera dessa data i realtid. Dessutom måste du ibland hitta andra applikationer. Vi har alla sett att värdena härleds endast av den åtgärd som du gör på insikten, att åtgärden kommer att bli en utlösare från en analytisk stack till en annan applikationsstack som kanske har ändrats som är något på IVR-sidan eller utlöser ett callcenter utgående samtal eller något liknande. Vi måste ha dessa system integrerade och någon mekanism för ditt strömningskluster för att utlösa andra applikationer för ing data nedströms.
Det är den totala stacken från att gå från vänster till höger. Sedan har du servicelagren, mellanövervakning, säkerhetslager för allmän service osv. Kommer till vilka produkter som finns ute i företagets utrymme som kunder ser som Hadoop-distributioner som alla har streaming som jag sa och det finns kommersiella eller enstaka -vendor-lösningar som uppenbarligen finns i våra konkurrenter. Det finns många fler i landskapet som vi kanske inte har nämnt här.
Det du ser där är i stort sett företagets användare ser. Ett komplext och snabbt utvecklande tekniklandskap för strömbehandling, som du ser. Vi måste förenkla valet och deras användarupplevelse. Vad vi tror att företag verkligen behöver är den funktionella abstraktionen av allt detta i en enda butik, lättanvänt gränssnitt som förenar alla dessa tekniker som gör det riktigt enkelt att använda och inte avslöjar alla rörliga delar och nedbrytningsproblemen och prestationsfrågorna och livscykelunderhållsfrågorna till företaget.
Funktionsabstraktionen är en. Den andra delen är abstraktionen för strömmaskiner. Streamingmotorerna och open source-domänerna kommer upp en gång var tredje, fyra eller sex månader nu. Det var Storm länge. Samza kom upp och nu är det Spark Streaming. Flink lyfter huvudet och börjar uppmärksamma. Till och med Spark Streaming-färdplanen, de gör ett sätt att potentiellt använda en annan motor för ren händelsehantering eftersom de också inser att Spark var designad för batch och de gör ett sätt i sin arkitekturvision och sin färdplan för att potentiellt ha en annan motor för strömbehandling utöver det nuvarande mikrobatchmönstret i gnistströmning.
Det är en verklighet som du måste kämpa med att det kommer att bli mycket evolution. Du måste verkligen skydda dig från det teknologiflödet. Eftersom du som standard måste välja en och sedan leva med den, vilket inte är optimalt. Om du tittar på det på ett annat sätt kämpar du mellan, "okej, jag måste köpa en egen plattform där det inte finns ett lock-in, det finns ingen hävstång av öppen källkod, kan vara mycket höga kostnader och begränsade flexibilitet gentemot alla dessa open source-stackar där du måste göra det själv. ”Återigen, som sagt, är det mycket kostnader och förseningar för att komma ut på marknaden. Vad vi säger är StreamAnalytix är ett exempel på en fantastisk plattform som drar ihop företagsklass, pålitlig, enda leverantör, professionell service som stöds - allt det du verkligen behöver som företag och kraften i flexibilitet i öppen källkods ekosystem där en enda plattform sammanför dem - Ingest, CEP, analys, visualisering och allt detta.
Det gör också en mycket, mycket unik sak, som förenar många olika teknikmotorer under en enda användarupplevelse. Vi tror verkligen att framtiden handlar om att kunna använda flera strömmande motorer eftersom olika användningsfall verkligen kräver olika strömningsarkitekturer. Som Robin sa, det finns ett helt spektrum av latenser. Om du verkligen talar om millisekundens latensnivå, tiotals eller till och med hundratals millisekunder, behöver du verkligen Storm för tillfället tills det finns en annan lika mogen produkt för mindre lättnad eller lättare tidsram och latenser på kanske på några sekunder, tre, fyra, fem sekunder, det intervallet, så kan du använda gnistströmning. Potentiellt finns det andra motorer som kan göra båda. Kort sagt, i ett stort företag kommer det att finnas användningsfall av alla slag. Du vill verkligen att åtkomst och allmänhet ska ha flera motorer med en användarupplevelse och det är vad vi försöker bygga i StreamAnalytix.
Bara en snabb vy över arkitekturen. Vi kommer att omarbeta detta lite, men i princip finns det flera datakällor som kommer in på vänster sida - Kafka, RabbitMQ, Kinesis, ActiveMQ, alla dessa datakällor och köer kommer in till strömbearbetningsplattformen där du få montera en app, där du får dra och släppa från operatörer som ETL: er, allt det vi pratade om. Under det finns flera motorer. Just nu har vi Storm och Spark Streaming som branschens enda och första streaming-plattform för företagsklass som har flera motorstöd. Det är en mycket unik flexibilitet som vi erbjuder förutom all annan flexibilitet med att ha realtidspaneler. CET-motor inbäddad. Vi har sömlös integration med Hadoop- och NoSQL-index, Solr- och Apache-index. Du kan landa till din favoritdatabas oavsett vad det är och bygga applikationer riktigt snabbt och få marknadsföra riktigt snabbt och förbli framtidssäker. Det är hela vårt mantra i StreamAnalytix.
Med det tror jag att jag kommer att avsluta mina kommentarer. Kom gärna till oss för fler frågor. Jag skulle vilja hålla ordet öppet för frågor och svar och paneldiskussioner.
Rebecca, över till dig.
Rebecca Jozwiak: Bra, okej. Tack så mycket. Dez och Robin, har du några frågor innan vi överlämnar det till publikens frågor och svar?
Robin Bloor: Jag har en fråga. Jag sätter på mina hörlurar så att du kan höra mig. En av de intressanta sakerna, om du vänligen skulle kunna berätta för mig detta, ser mycket av det jag har sett i open source-utrymmet vad jag skulle säga omogna till mig. På något sätt kan du göra olika saker. Men det ser ut som om vi tittar på programvara i dess första eller andra utgåva i verkligheten och jag undrade bara med din erfarenhet som en organisation, hur mycket ser du ommjukheten i Hadoop-miljön som problematisk eller är det något som inte gör det t skapa för många problem?
Anand Venugopal: Det är en verklighet, Robin. Du har helt rätt. Omogenheten ligger inte nödvändigtvis inom området bara funktionell stabilitet och saker, men kanske vissa fall också. Men omogenheten är mer beredd på användning. Öppna källkodsprodukterna när de kommer ut och även när de erbjuds av Hadoop-distributionen, är de alla en mängd olika kapabla produkter, komponenter som bara släpps ihop. De fungerar inte sömlöst och är inte utformade för en smidig sömlös användarupplevelse som väl blir som Bank of America eller Verizon eller AT&T, för att distribuera en strömningsanalysapplikation inom veckor. De är inte designade för det med säkerhet. Det är anledningen till att vi kommer in. Vi förenar det och gör det riktigt enkelt att förstå, distribuera etc.
Den funktionella mognaden för det, tror jag i hög grad, är där. Många stora företag använder till exempel Storm idag. Många stora företag spelar med Spark Streaming idag. Var och en av dessa motorer har sina begränsningar vad de kan göra, det är därför det är viktigt att veta vad du kan och vad du inte kan göra med varje motor och det är ingen mening att bryta huvudet mot väggen och säga: "Se jag valde Spark Streaming och det fungerar inte för mig inom den här branschen. ”Det kommer inte att fungera. Det kommer att vara fall där Spark Streaming kommer att vara det bästa alternativet och det kommer att vara fall där Spark Streaming kanske inte fungerar alls för dig. Det är därför du verkligen behöver flera alternativ.
Robin Bloor: Du måste ha expertteam ombord för det mesta av detta. Jag menar att jag inte ens vet var jag ska börja med det här heller. En förnuftig samverkan av skickliga individer. Jag är intresserad av hur det engagemang du engagerar dig och hur det händer. Är det för att ett visst företag är efter en specifik applikation eller ser du något av det jag skulle kalla strategisk adoption där de vill ha en hel plattform för att göra en hel del saker.
Anand Venugopal: Vi ser exempel på båda, Robin. Några av de tio bästa märkena som alla känner kommer till på det på ett mycket strategiskt sätt. De vet att de kommer att ha en mängd olika användningsärenden så de utvärderar plattformar som passar det behovet, vilket är en mängd olika användningsfall på flera hyresgäster som ska distribueras i ett företag. Det finns enskilda fallhistorier som också börjar. Det finns ett speciellt fall för användning av övervakning av affärsaktiviteter i ett hypoteksföretag som vi arbetar med som du inte skulle föreställa dig som första användningsfall men det är affärslösningen eller användningsfallet som de kom på och sedan kopplade vi punkterna till streaming . Vi sa: "Vet du vad? Det här är ett bra fall för strömningsanalyser och det är så vi kan implementera det. ”Det var så det började. Sedan, i den processen, blir de utbildade och säger, "Åh wow, om vi kan göra detta och om detta är en generisk plattform, så kan vi dela upp applikationen, lager dem i plattformen och bygga många olika applikationer på detta plattform."
Robin Bloor: Dez, har du några frågor?
Anand Venugopal: Dez är förmodligen på stum.
Dez Blanchfield: Ursäkt, stum. Jag hade bara ett bra samtal själv. Bara efter den ursprungliga observationen av Robin har du helt rätt. Jag tror att utmaningen nu är att företag har ett ekosystem och en kulturell och beteendemiljö där gratis och öppen källkodsprogram är något som är känt för dem och de kan använda verktyg som Firefox som en webbläsare och det har haft en anständig livslängd tills den blir stabil och säker. Men några av dessa väldigt stora plattformar som de använder är företagsklassiga egna plattformar. Så antagandet av vad jag anser som öppna källkodsplattformar är inte alltid något som är lätt för dem att kulturellt eller känslomässigt komma över. Jag har sett detta bara inför antagandet av små program som var lokala projekt för att bara spela med big data och analys som ett grundläggande koncept. Jag tror att en av de viktigaste utmaningarna, jag är säker på att du har sett dem nu över hela organisationerna, är deras önskan att få resultatet men samtidigt ha sin ena fot fast i den gamla burk där de bara kunde köpa detta från "Infoga ett stort märke" Oracle, IBM och Microsoft. Dessa nya och kända varumärken kommer med Hadoop-plattformar och ännu mer. Fler spännande varumärken kommer igenom som har ledande teknik som ström.
Vilka är de slags konversationer du har haft den typen av få eller klippa igenom det? Jag vet att vi har ett massivt närvaro i morse och en sak som jag är säker på är allas sinne: ”Hur skär jag igenom hela det utmanande lagret från styrelse ner till ledningsnivå, det är för öppen källkod och för blödande kant? "Hur går det med samtal du har med klienter och hur går du igenom till den punkten där du på ett slags sätt tappar dessa typer av rädsla för att överväga att anta sådana som StreamAnalytix?
Anand Venugopal: Vi tycker faktiskt att det är ganska enkelt att sälja vårt värdeförslag eftersom kunder naturligtvis går mot open source som ett föredraget alternativ. De är inte lätt bara att ge upp och säga, "Okej, jag kommer nu att gå open source." De går faktiskt genom en mycket engagerad utvärdering av en viktig produkt, låt oss säga att det är en IBM eller en typisk produkt, eftersom de har dessa leverantörsrelationer. De skulle inte behandla oss eller open source-motorn mot den produkten. De kommer att gå igenom sex till åtta till tolv veckors utvärdering. De kommer att övertyga sig själva om att det finns en viss prestanda och stabilitet här som jag vill ha och sedan bestämmer de sig och säger: "Wow, du vet vad, jag kan faktiskt göra det."
Idag har vi till exempel ett stort telco som har strömanalys som går i produktion ovanpå en hel del av stacken och de utvärderar det mot en annan mycket, mycket stor känd leverantör och de var övertygade först efter att vi bevisat alla prestanda, stabilitet och alla dessa saker. De tar det inte för givet. De fick reda på att open source är kompetent genom sina utvärderingar och de inser att i värsta fall: "Kanske finns det de två användningsfallen som jag kanske inte kan göra, men de flesta av mina företag med accelerationsanvändningsfall idag är mycket möjliga med open-source stack. ”Och vi möjliggör användning av det. Så det är den stora söta platsen där. De ville ha öppen källkod. De är verkligen ute efter att komma ur leverantörens inlåningssituation som de har varit vana vid i många, många år. Sedan kommer vi och säger: "Du vet vad, vi kommer att göra open source mycket, mycket lättare och vänligare att använda för dig."
Dez Blanchfield: Jag tror att den andra utmaningen som företagen upplever är när de tar in den traditionella befogenheten som de ofta är en generation bakom några av de blödande kanten på de spännande saker vi pratar om här och jag menar inte det som ett negativt litet. Det är bara att verkligheten är att de har fått en generation och resa att gå igenom för att släppa vad de anser som stabila plattformar att genomgå, old school-utveckling och UATN-integrationscykler och testningar och dokumentation och marknadsföring och försäljning. Medan den typen du gör tror jag att det jag är intresserat att tänka på är att titta på några av dina senaste utgåvor i går kväll som gör något slags forskningsarbete, du har den här blandningen där du har kompetens ur ett konsultperspektiv och en implementering men du har också en bunt som du kan rulla i. Jag tror att det är här som de befintliga kommer att kämpa under en tid. Vi har sett många av dem som jag gjorde på marknaden. De ligger ofta i vad jag kallar för att fånga upp noder medan från vad du berättar när du är ute och håller på att göra de konversationerna och du är ute och implementerar.
Kan du ge oss ett par exempel på några av de gränsen vertikala som du har antagit? Till exempel finns det verkligen nichey-miljö som raketvetenskap och att sätta satelliter i rymden och samla in data från Mars. Det finns bara en handfull människor som gör det på planeten. Men det finns stora vertikaler som hälsa till exempel inom luftfart, inom sjöfart och logistik, inom tillverkning och teknik, vad är ett par exempel på de större och bredare industrisektorerna som du har varit så långt att du har sett riktigt bra antagande i?
Anand Venugopal: Telco är ett stort exempel.
Jag kommer bara att fixa mina bilder här. Kan du se bilden här, fallstudie 4?
Detta är fallet med en stor telco som intar set-top-boxdata och gör flera saker med det. De tittar på vad kunder verkligen gör i realtid. De tittar på var fel inträffar i realtid i set-top boxar. De försöker informera callcenter om, om den här kunden ringer in just nu, kodlänkinformationen från den här kundens set-top box, information om underhållsbiljetter snabbt korrelerar om den specifika kundens set-top box har problem eller inte tidigare kunden talar ett ord. Varje kabelföretag, varje större telco försöker göra detta. De tar upp set-top box-data, gör analys i realtid, gör kampanjanalys så att de kan placera sina annonser. Det finns ett enormt användningsfall.
Som jag sa, det finns det här bolån som återigen är ett generiskt mönster där stora system är involverade i bearbetning av data från. Uppgifterna som flyter genom system A till system B till system C och dessa är reglerade företag som allt behöver vara konsekvent. Ofta är systemen synkroniserade med varandra, ett system säger: "Jag behandlar hundra lån till ett totalt värde av 10 miljoner dollar." Systemet säger, "Nej, jag bearbetar 110 lån av någon annan olika nummer. ”De måste lösa det riktigt snabbt eftersom de faktiskt bearbetar samma data och gör olika tolkningar.
Oavsett om det är ett kreditkort, lånebehandling, affärsprocess eller om det är en hypoteksaffärsprocess eller något annat, hjälper vi dem att göra korrelation och försoning i realtid för att se till att dessa affärsprocesser förblir synkroniserade. Det är ett annat intressant användningsfall. Det finns en stor amerikansk regeringsentreprenör som tittar på DNS-trafik för att upptäcka avvikelser. Det finns en offline träningsmodell som de byggde och de gör poängsättningen baserad på den modellen i realtidstrafik. Några av dessa intressanta användningsfall. Det finns ett stort flygbolag som tittar på säkerhetskö och de försöker ge dig den informationen som "Hej, det är din port för ditt flyg för din flygning. TSA-kön idag är ungefär 45 minuter kontra två timmar kontra något annat. ”Du får den uppdateringen i förväg. De arbetar fortfarande med det. Intressant IoT-användningsfall men bra fall av strömmande analyser på väg till kundupplevelsen.
Rebecca Jozwiak: Det här är Rebecca. Medan du är i fråga om användningsfall finns det en stor fråga från en publikmedlem som undrar: "Är dessa fallstudier, drivs dessa initiativ från informationssystemets analytiska sida av huset eller är de mer drivna från företaget som har specifika frågor eller behov i åtanke? ”
Anand Venugopal: Jag tror att vi ser ungefär 60 procent, 50 procent till 55 procent, till stor del mycket proaktiva, entusiastiska teknikinitiativ som råkar vet, som råkar vara ganska kunniga och förstår vissa affärskrav och de har förmodligen en sponsor som de identifierade men dessa är teknologiteam som är redo för angrepp av ärenden om affärsanvändning som kommer igenom och sedan när de bygger kapaciteten vet de att de kan göra detta och sedan går de till affärer och säljer aggressivt detta. I 30 till 40 procent av fallen ser vi att företaget redan har ett speciellt användningsfall som ber om en strömningsanalysfunktion.
Rebecca Jozwiak: Det känns logiskt. Jag har fått en annan lite mer teknisk fråga från en publikmedlem. Han undrar om dessa system stöder både strukturerade och ostrukturerade dataströmmar, som sedimenter av strömmar eller inlägg i realtid, eller måste det först filtreras?
Anand Venugopal: De produkter och teknologier som vi pratar om är mycket nära förestående stöd för både strukturerad och ostrukturerad data. De kan konfigureras. All data har någon form av struktur oavsett om det är en eller en XML eller något alls. Det finns en viss struktur i termer av att det finns ett tidstämpelflöde. Det finns kanske en annan klump som måste analyseras så att du kan injicera parser i strömmen för att analysera datastrukturerna. Om det är strukturerat, berättar vi bara för systemet, "Okej, om det finns kommaseparerade värden och den första är en sträng, den andra är ett datum." Så vi kan spruta in den som analyserar intelligens i upp-skärmlagren och bearbeta enkelt både strukturerad och ostrukturerad data.
Rebecca Jozwiak: Jag har fått en ny fråga från publiken. Jag vet att vi har kört lite förbi timmen. Denna deltagare vill veta, det verkar som att realtidsströmningsapplikationer kan utveckla både ett behov och en möjlighet att integrera tillbaka i transaktionssystem, bedrägeribekämpningssystem som de tar upp till exempel. I så fall måste transaktionssystem justeras för att passa på det?
Anand Venugopal: Det är en sammanslagning, eller hur? Det är en sammanslagning av transaktionssystem. De blir ibland källan till data där vi analyserar transaktioner i realtid och i många fall där vi låter säga att det finns ett applikationsflöde och här försöker jag visa en statisk datauppsökningssida och sedan i vårt fall där någon slags strömning i och du letar upp en statisk databas som en HBase eller en RDBMS för att berika strömningsdata och statiska data tillsammans för att fatta ett beslut eller en analytisk insikt.
Det finns en annan stor branschtrend som vi också ser - konvergensen mellan OLAP och OLTP - och det är därför du har databaser som Kudu och databaser i minnet som stöder både transaktioner och analysbehandling samtidigt. Strömbearbetningsskiktet skulle vara helt i minnet och vi tittar på eller gränsar till några av dessa transaktionsdatabaser.
Rebecca Jozwiak: Blandad arbetsbelastning har varit ett av de sista hinder att hoppa, tror jag. Dez, Robin, har ni två fler frågor?
Dez Blanchfield: Jag kommer att hoppa in i en sista fråga och ta bort det om du inte har något emot. Den första utmaningen som organisationerna som jag har jobbat med under det senaste decenniet eller som ledde till denna spännande utmaning med strömanalys, det första de tenderar att sätta tillbaka på bordet när vi började konversationen kring hela denna utmaning är där gör får vi kompetensuppsättningen? Hur omskolar vi kompetensuppsättningen och hur får vi den kapaciteten internt? Att ha Impetus som kommer in och hand håller oss genom resan och sedan implementerar som ett fantastiskt första steg och det är mycket meningsfullt att göra det.
Men för medel till stor organisation, vad är det för slags saker du ser för tillfället för att förbereda dig för detta, att bygga upp denna förmåga internt, att få allt från bara ett grundläggande ordförråd kring det och vad kan de göra med organisation kring övergången till denna typ av ramverk och återupplösa sin befintliga tekniska personal från IT från VD så att de kan driva detta själva när du bygger och implementerar det? Bara mycket kort, vilken typ av utmaningar och hur löser de dem, kunderna du hanterar, vilka typer av utmaningar de hittade och hur de går igenom att lösa den omskolning och återfå erfarenhet och kunskap för att bli redo för detta och att vara kunna gå runt operationellt?
Anand Venugopal: Ofta är den lilla uppsättningen människor som försöker gå ut och köpa en strömmande analysplattform redan rimligt smart eftersom de är Hadoop medvetna, de har redan fått sina Hadoop MapReduce-färdigheter och eftersom de arbetar nära med Hadoop distributionsförsäljare, de är antingen bekanta. Allt får Kafka till exempel. De gör någonting med det och antingen Storm- eller Spark-streaming är i deras open source-domän. Definitivt är människor bekanta med det eller bygger färdigheter kring det. Men det börjar med en liten uppsättning människor som är tillräckligt skickliga och smarta nog. De deltar i konferenser. De lär sig och att de ställer intelligenta frågor till leverantörerna och i vissa fall lär de sig med leverantörerna. När leverantörerna kommer och presenterar vid det första mötet kanske de inte känner till saker men de läser upp och sedan börjar de leka med det.
Den lilla gruppen människor är kärnan och sedan börjar den växa och alla inser nu att det första fallet med affärsanvändning blir operativt. Det börjar en våg och vi såg i Spark-toppmötet förra veckan där ett stort företag som Capital One var där ute och i full styrka. De valde Spark. De pratade om det. De utbildar många av sina människor i Spark eftersom de bidrar till det också i många fall som användare. Vi ser detsamma med många, många stora företag. Det börjar med några små uppsättningar med mycket smarta människor och sedan börjar det en våg av övergripande utbildning och folk vet att en gång en senior VP eller en gång en senior director är i linje och de vill satsa på den här saken och ordet kommer runt och de börjar alla ta upp dessa färdigheter.
Dez Blanchfield: Jag är säker på att du har en fantastisk tid att bygga de mästarna också.
Anand Venugopal: Ja. Vi gör mycket utbildning när vi arbetar med de ursprungliga mästarna och vi håller utbildningskurser och många, många för våra stora kunder har vi gått tillbaka och haft vågor och vågor av utbildning för att föra många användare till mainstream-användningsfasen, särskilt i Hadoop MapReduce webbplats. Vi fann att vi i ett stort kreditkortsföretag som är kund hos oss har levererat minst fem till åtta olika utbildningsprogram. Vi har också gratis community-utgåvor av alla dessa produkter inklusive våra, sandlådor som människor kan ladda ner, vänja sig och utbilda sig på så sätt också.
Dez Blanchfield: Det är allt jag har i morgon åt dig. Tack så mycket. Jag tycker det är oerhört intressant att se vilka typer av modeller och använda fall som du har för oss idag. Tack.
Anand Venugopal: Bra. Tack så mycket folkens.
Rebecca Jozwiak: Tack alla för att du gick med i denna Hot Technologies webcast. Det har varit fascinerande att höra från Dez Blanchfield, Dr. Robin Bloor och från Impetus Technologies, Anand Venugopal. Tack presentatörer. Tack talare och tack publik. Vi har en annan Hot Technologies nästa månad, så leta efter det. Du kan alltid hitta vårt innehåll arkiverat på Insideanalysis.com. Vi lägger också upp mycket innehåll på SlideShare och några intressanta bitar på YouTube också.
Det är allt folk. Tack igen och ha en bra dag. Hejdå.