Door Techopedia Staff, 24 februari 2016
Afhaalmaaltijd: gastheer Rebecca Jozwiak bespreekt streaminganalyse met experts uit de topsector.
Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.
Rebecca Jozwiak: dames en heren, hallo en welkom bij Hot Technologies van 2016! De titel van vandaag is "De brandweer gebruiken: bedrijfswaarde halen uit Streaming Analytics." Dit is Rebecca Jozwiak. Ik ben de tweede in opdracht voor webcasthost wanneer onze lieve Eric Kavanagh hier niet kan zijn, dus het is leuk om zoveel van jullie daar vandaag te zien.
Deze aflevering is een beetje anders dan onze andere. We hebben het eerder gehad over wat hot is en natuurlijk is dit jaar hot. De laatste jaren zijn hot geweest. Er komen altijd nieuwe dingen uit. Vandaag hebben we het over streaming-analyse. Streaming-analyse is op zichzelf al een beetje nieuw. Natuurlijk streaming, center data, RFID data, die zijn niet noodzakelijkerwijs nieuw. Maar in de context van data-architecturen zijn we al tientallen jaren zo gefocust op data in rust. Databases, bestandssystemen, gegevensrepository's - allemaal hoofdzakelijk voor batchverwerking. Maar nu met de verschuiving om waarde te creëren uit streaming data, data-emoties, sommigen noemen het levende streams, hebben ze echt een stream-gebaseerde architectuur nodig, niet de data in rust-architecturen die we gewend zijn en die in staat moet zijn om verwerking van snelle inname, realtime of bijna realtime verwerking. Het moet niet alleen kunnen zorgen voor het internet der dingen, maar ook voor het internet van alles.
In het ideale geval zou het natuurlijk fijn zijn als de twee architecturen naast elkaar zouden leven, de ene hand bij de andere om zo te zeggen. Terwijl de dagen oude gegevens, weken oude gegevens, jaren oude gegevens natuurlijk nog steeds waarde hebben, historische analyse, trendanalyse, zijn het de live gegevens die tegenwoordig de live intelligentie aansturen en daarom is streaming analyse zo belangrijk geworden.
Ik heb het daar vandaag meer over. Onze gegevenswetenschapper, Dez Blanchfield, belt vanuit Australië. Het is nu vroeg in de ochtend voor hem. We hebben onze hoofdanalist, Dr. Robin Bloor. We worden vergezeld door Anand Venugopal, producthoofd voor StreamAnalytix bij Impetus Technologies. Ze zijn echt gericht op het streaming-analyseaspect van deze ruimte.
Daarmee ga ik door en geef het door aan Dez.
Dez Blanchfield: Bedankt. Ik moet de besturing van het scherm hier pakken en naar voren springen.
Rebecca Jozwiak: Alsjeblieft .
Dez Blanchfield: Terwijl we de dia's pakken, laat me even het kernonderwerp behandelen.
Ik ga het redelijk hoog houden en ik houd het ongeveer 10 minuten. Dit is een heel groot onderwerp. Ik heb deelgenomen aan een evenement waar we twee tot drie dagen hebben gedoken in de details van wat streamverwerking is en de huidige frameworks die we ontwikkelen en wat het doen van analyses in die high-volume streams zou moeten betekenen.
We gaan gewoon verduidelijken wat we bedoelen met streaming-analyse en vervolgens onderzoeken of bedrijfswaarde kan worden afgeleid, want dat is echt waar bedrijven naar op zoek zijn. Ze willen dat mensen hen heel snel en bondig uitleggen, waar kan ik waarde aan ontlenen door een vorm van analyse toe te passen op onze streamgegevens?
Wat is streaminganalyse?
Streaming-analyse geeft organisaties een manier om waarde te halen uit gegevens met een hoog volume en hoge snelheid die ze in verschillende vormen door het bedrijf hebben gehaald. Het grote verschil hier is dat we een lange geschiedenis hebben gehad in het ontwikkelen van analyses en lenzen en weergaven van gegevens die we al tientallen jaren in rust verwerken sinds het mainframe is uitgevonden. De enorme paradigmaverschuiving die we de afgelopen drie tot vijf jaar hebben gezien bij wat we 'webschaal' noemen, is het aanboren van de gegevensstromen die in realtime of bijna realtime binnenkomen en niet alleen verwerken en zoeken naar correlatie van gebeurtenissen of gebeurtenis triggers maar het uitvoeren van echt gedetailleerde, diepgaande analyses op die streams. Het is een belangrijke verschuiving naar wat we eerder hebben gedaan, namelijk het verzamelen van gegevens, het in een soort repository plaatsen, traditioneel grote databases nu, grote big data-frameworks zoals het Hadoop-platform en daarop batch-modusverwerking uitvoeren en krijgen een soort inzicht.
We zijn er erg goed in om dat heel snel te doen en veel ijzer te proberen, maar we zijn nog steeds echt gegevens aan het verzamelen, opslaan en vervolgens bekijken en krijgen er een soort van inzichten of analyses over. De verschuiving naar het uitvoeren van die analyses terwijl de gegevens worden gestreamd, is een heel nieuw en opwindend groeigebied voor de soorten dingen die gebeuren rond big data. Het vereist een compleet andere aanpak om alleen analyses vast te leggen, op te slaan en te verwerken en uit te voeren.
Een van de belangrijkste drijfveren voor de verschuiving en focus op het uitvoeren van analyses in de stream is dat u aanzienlijke bedrijfswaarde kunt behalen door deze inzichten sneller en gemakkelijker te krijgen naarmate de gegevens naar u toekomen, omdat informatie voor het bedrijf beschikbaar wordt gesteld. Het idee om aan het eind van de dag te verwerken is nu niet langer relevant in bepaalde industrieën. We willen de analyses snel kunnen uitvoeren. Tegen het einde van de dag weten we al wat er is gebeurd zoals het is gebeurd in plaats van aan het einde van de dag te komen en een 24-uurs batch-taak uit te voeren en die inzichten te krijgen.
De streaming-analyse gaat over het aanboren van die stroom, terwijl datastromen meestal meerdere stromen zijn van zeer grote hoeveelheden gegevens en gegevens die heel, heel snel naar ons toe komen en inzichten of analyses over die stromen krijgen, in tegenstelling tot ons om toe te staan dat het in rust uitkomt en analyses op hen uitvoert.
Zoals ik al zei, hebben we tientallen jaren gewerkt met wat ik batchanalyse noem. Ik heb hier een hele gave foto geplaatst. Dit is een foto van een heer die voor een bespotte computer staat die een leven geleden door RAND Corporation is gemaakt en zo zagen ze een computer in een huis eruit zien. Wat interessant is, is dat ze toen al dit concept hadden van al deze kleine wijzerplaten en deze wijzerplaten vertegenwoordigden informatie die vanuit het huis binnenkwam en in realtime werd verwerkt en je vertelde wat er aan de hand was. Een eenvoudig voorbeeld is een reeks barometrische druk en temperatuur die we kunnen zien waar we zien wat er in realtime gebeurt. Maar ik kan me voorstellen dat toen RAND Corporation toen al die kleine mockup in elkaar zette, ze eigenlijk al aan het nadenken waren over het verwerken van gegevens en het uitvoeren van analyses daar deze binnenkomen in stream-formaat. Ik ben niet helemaal zeker waarom ze een stuurwiel op de computer zetten, maar dat is best cool.
Sinds de uitvinding van de printer hebben we het oogmerk gehad gegevens vast te leggen en hierop batchanalyses uit te voeren. Zoals ik met de grote verschuiving nu heb gezegd en we hebben dit gezien van spelers van de webschaal die we allemaal kennen, het zijn allemaal huishoudelijke merken zoals Twitter, Facebook en LinkedIn, dat interactieve gedrag dat we hebben met die sociale platforms vereisen niet alleen vastleggen, opslaan en vervolgens verwerken in batch-modus, maar ze zijn in feite vastleggen en analyseren van gegevens uit de gegevensstromen die binnenkomen. Als ik iets tweet, moeten ze niet alleen iets vastleggen en opslaan en later iets doen, maar ze moeten het ook meteen weer in mijn updates kunnen plaatsen en delen met andere mensen die me volgen. Dat is een batchverwerkingsmodel.
Waarom zouden we deze route volgen? Waarom zouden organisaties tijd, moeite en geld investeren om zelfs maar de uitdaging te overwegen om het pad van stroomanalyse te volgen? Organisaties hebben een enorme wens om een prestatiewinst te behalen ten opzichte van hun concurrenten in de bedrijfstakken waarin ze actief zijn en dat prestatiewinst snel kan worden geïmplementeerd via eenvoudige stroomanalyses en het kan beginnen met een eenvoudige realtime-tracking die we al hebben bekend met. Ik heb daar een kleine screenshot van Google Analytics. Dit is waarschijnlijk een van de eerste keren dat we echt hands-on analyses van consumentenkwaliteit hebben gekregen. Dus terwijl mensen je website bezochten en je het aantal hits behaalde, met een klein stukje JavaScript onderaan je webpagina in HTML ingebed in je website, werden deze kleine codes in realtime gemaakt terug naar Google en ze waren analyses uitvoeren op die gegevensstromen die van elke pagina op uw website, elk object op uw website in realtime binnenkomen en deze naar u terugsturen in deze echt schattige kleine webpagina in een dashboard met realtime grafieken, schattige kleine histogrammen en lijngrafiek met het X-aantal mensen dat uw pagina historisch heeft bezocht, maar hier zijn er hoeveel op dit moment.
Zoals je op die screenshot kunt zien, staat er nu 25 op. Dat zijn 25 mensen die op dat moment op dat moment op die pagina stonden. Dat is de eerste echte kans die we hebben gespeeld met de analyse-tool voor consumentenkwaliteit. Ik denk dat veel mensen het echt hebben. Ze begrepen gewoon de kracht van weten wat er aan de hand was en hoe ze daarop konden reageren. Als we denken aan de omvang van avionica, vliegtuigen die rondvliegen, zijn er alleen al in de VS al 18.700 binnenlandse vluchten. Ik las enige tijd geleden een krant - het was ongeveer zes of zeven jaar geleden - dat de hoeveelheid gegevens die door die vliegtuigen werd geproduceerd ongeveer 200 tot 300 megabytes bedroeg in het oude technische model. In de hedendaagse ontwerpen van vliegtuigen produceren deze vliegtuigen ongeveer 500 gigabyte aan gegevens of ongeveer een halve terabyte aan gegevens per vlucht.
Als je heel snel rekent, dan zijn die 18.700 binnenlandse vluchten elke 24 uur alleen al in het Amerikaanse luchtruim, als alle moderne vliegtuigen ongeveer een halve terabyte produceren, dat zijn 43 tot 44 petabytes aan gegevens die binnenkomen en het gebeurt terwijl de vliegtuigen in de lucht zijn. Het gebeurt wanneer ze landen en ze datadumps doen. Dat is wanneer ze de winkel binnengaan en een volledige gegevensdump van de engineeringteams krijgen om te kijken naar wat er gebeurt in de lagers, wielen en in de motoren. Sommige van die gegevens moeten in realtime worden verwerkt, zodat ze beslissingen kunnen nemen als er een echt probleem is terwijl het vliegtuig in de lucht was of terwijl het op de grond was. Dat kan je gewoon niet in batchmodus. In andere sectoren die we zien rond financiën, gezondheid, productie en engineering, kijken ze ook hoe ze met dit nieuwe inzicht kunnen krijgen wat er in realtime gebeurt, in tegenstelling tot wat er gewoon wordt opgeslagen in de databases op een termijn.
Er is ook dit concept van het omgaan met gegevens als wat ik een bederfelijk goed of een bederfelijke grondstof noem - dat veel gegevens na verloop van tijd waarde verliezen. Dit is meer en meer het geval met mobiliteits-apps en social media-tools, omdat wat mensen zeggen en wat nu trending is, is wat u wilt reageren. Als u denkt aan andere delen van ons leven met logistiek en verzending van voedsel, begrijpen we het concept van bederfelijke waar in die zin. Maar denk aan de gegevens die door uw organisatie gaan en de waarde ervan. Als iemand op dit moment zaken met u doet en u kunt in realtime met hen communiceren, wilt u niet een uur wachten zodat de gegevens kunnen worden vastgelegd en in een systeem zoals Hadoop kunnen worden geplaatst en vervolgens op deze knop drukken, u kunt u er nu niet mee omgaan en u wilt het op verzoek van de klant meteen kunnen doen. Er is een term die je nu veel zult zien opduiken waarin mensen praten over het hebben van deze realtime datastroom die je personalisatie kan geven, en dat personalisatie-afstemming in het systeem dat je gebruikt voor je individuele ervaring. Dus als u bijvoorbeeld op een tool zoals de Google Search-tool drukt en ik een zoekopdracht uitvoert en u dezelfde zoekopdracht uitvoert, krijgen we steevast niet exact dezelfde gegevens. We krijgen in wezen wat ik een ervaring van beroemdheden noem. Ik ben behandeld met een eenmalig. Ik krijg mijn eigen persoonlijke versie van wat er in deze systemen gebeurt op basis van de profielen en gegevens die ze over mij hebben verzameld en ik kon in realtime analyses uitvoeren in de stream.
Dit idee dat data een bederfelijke waar is, is voorlopig een realiteit en de waarde van data die in de loop van de tijd wordt verminderd, is iets waar we vandaag mee te maken hebben. Het is geen gisteren ding. Ik ben dol op deze foto van een beer die een zalm grijpt die uit de rivier springt omdat het echt precies schildert wat ik streaming analyse zie. Het is deze enorme rivier met gegevens die naar ons toekomt, een firehose als je wilt, en de beer zit in het midden van de kreek. Het gaat realtime analyses uitvoeren van wat er omheen gebeurt, zodat het daadwerkelijk zijn vermogen kan ontwikkelen om die vis in de lucht te vangen. Het is niet alsof je gewoon in de stroom duikt en er een grijpt. Dit ding springt in de lucht en het moet op het juiste moment op de juiste plaats zijn om die vis te vangen. Anders krijgt hij geen ontbijt of lunch.
Een organisatie wil hetzelfde doen met hun gegevens. Ze willen waarde halen uit wat nu enorme hoeveelheden gegevens in beweging zijn. Ze willen analyses uitvoeren op die gegevens en gegevens met hoge snelheid, dus het is niet alleen de hoeveelheid gegevens die naar ons toekomt, maar het is de snelheid waarmee het hier vandaan komt. In beveiliging bijvoorbeeld, zijn het al uw routers, switches, servers, firewalls en alle gebeurtenissen die hieruit voortkomen en tienduizenden, zo niet honderdduizenden apparaten, in sommige gevallen bederfelijke gegevens. Als we erover nadenken in het Internet of Things en het industriële internet, hebben we het uiteindelijk over miljoenen, zo niet miljarden sensoren, en terwijl de gegevens binnenkomen die analyses uitvoeren, zijn we nu bezig met het verwerken van complexe evenementen met orders van grootte en snelheid die we nog nooit eerder hebben gezien en waar we vandaag mee te maken hebben. Daar moeten we hulpmiddelen en systemen voor bouwen. Het is een echte uitdaging voor organisaties, omdat we aan de ene kant de zeer grote merken hebben die zelf maken, het zelf bakken, wanneer ze de capaciteit hebben om dat te doen en vaardigheden en de engineering. Maar voor de gemiddelde organisatie is dat niet het geval. Ze hebben niet de vaardigheden. Ze hebben niet de capaciteit of de tijd of zelfs het geld om te investeren in het uitzoeken. Ze streven allemaal naar dit concept van bijna realtime besluitvorming.
Gebruik cases die ik ben tegengekomen, en ze zijn in elk breed spectrum van elke sector die je je kunt voorstellen, mensen zitten rechtop en letten op en zeggen: hoe passen we wat analyses toe op onze streamgegevens? We hebben het over online services op webschaal. Er zijn de traditionele sociale mediaplatforms en online e-tailing en detailhandel - apps bijvoorbeeld. Ze proberen ons allemaal deze realtime beroemdheidservaring te geven. Maar als we meer in de technologie-stackservices, telefoondiensten, spraak en video belanden, zie ik mensen rondlopen FaceTime doen op telefoons. Het explodeert gewoon. Het verbaast me dat mensen de telefoon voor zich uitsteken en met een videostream van een vriend praten in plaats van hem meer tegen zijn oor te houden. Maar ze weten dat ze het kunnen en ze hebben zich aangepast en vonden die ervaring leuk. De ontwikkeling van deze applicaties en de platforms die deze leveren, moeten realtime analyses uitvoeren op dat verkeer en op de profielen van het verkeer, zodat ze eenvoudige dingen kunnen doen, zoals het perfect routeren van die video, zodat de kwaliteit van de stem in de video die je krijgt is voldoende om een goede ervaring te krijgen. Je kunt dat soort gegevens niet batch verwerken. Het zou de realtime videostream niet tot een functionele service maken.
Er is een bestuurlijke uitdaging in financiële transacties. Het is niet goed om aan het eind van de dag te komen en erachter te komen dat je de wet hebt overtreden en privégegevens verplaatst. In Australië hebben we een zeer interessante uitdaging waarbij het verplaatsen van privacygerelateerde gegevens naar zee een nee is. U kunt mijn PID, mijn persoonlijke persoonlijke identificatiegegevens niet offshore meenemen. Er zijn wetten in Australië om dat te voorkomen. Vooral aanbieders van financiële diensten, overheidsdiensten en agentschappen, moeten realtime analyses van hun gegevensstromen en instructies met mij maken om ervoor te zorgen dat wat zij mij bieden niet de kust verlaat. Alle spullen moeten lokaal blijven. Ze moeten het realtime doen. Ze kunnen de wet niet overtreden en later om vergeving vragen. Fraudedetectie - het is vrij voor de hand liggend dat we horen over creditcardtransacties. Maar aangezien de soorten transacties die we in financiële diensten doen heel, heel snel veranderen, zijn er dingen die PayPal nu eerst doet bij het detecteren van fraude in realtime waarbij geld niet van het ene naar het andere gaat, maar het is een financiële transactie tussen systemen. EBay-biedplatforms, het detecteren van fraude moet real-time worden gedaan in een streamingkantoor.
Er is een trend gaande naar het uitvoeren van extractie en het transformeren van belastingactiviteit in de streams, dus we willen niets vastleggen dat naar de stream gaat. Dat kunnen we niet echt doen. Mensen hebben geleerd dat gegevens heel snel worden verbroken als we alles vastleggen. De truc is nu om analyses uit te voeren op die streams en er ETL op te doen en gewoon vast te leggen wat je nodig hebt, mogelijk metadata, en vervolgens voorspellende analyses te sturen waar we dan daadwerkelijk kunnen vertellen wat er gaat gebeuren een beetje verder langs de paden op wat we heb zojuist in de stream gezien op basis van de analyses die we daarop hebben uitgevoerd.
Energie- en nutsbedrijven ervaren dit enorme verlangen van consumenten om vraagprijzen te hanteren. Ik zou kunnen besluiten dat ik op een bepaald moment van de dag groene stroom wil kopen, omdat ik gewoon alleen thuis ben en niet veel apparaten gebruik. Maar als ik een etentje heb, wil ik misschien al mijn apparaten aan hebben en wil ik geen goedkope stroom kopen en wachten tot deze wordt geleverd, maar bereid ben te betalen voor meer kosten om die stroom te krijgen. Deze vraagprijs, met name in nutsbedrijven en energieruimte, is al gebeurd. Uber is bijvoorbeeld een klassiek voorbeeld van dingen die je elke dag kunt doen en alles wordt aangedreven door vraagprijzen. Er zijn enkele klassieke voorbeelden van mensen in Australië die $ 10.000 krijgen vanwege de enorme vraag op oudejaarsavond. Ik weet zeker dat ze dat probleem hebben opgelost, maar streamanalyses die in realtime worden uitgevoerd terwijl ze in de auto vertellen hoeveel ik moet betalen.
Internet of Things en sensor streams - we hebben hier net de oppervlakte op ingeslagen en we hebben echt net het basisgesprek hierover gehad, maar we zullen een interessante verschuiving zien in hoe technologie daarmee omgaat, want als je praat niet zowat duizenden of tienduizenden maar honderdduizenden en mogelijk miljarden apparaten die naar u streamen, bijna geen van de technologiestacks die we nu hebben, is ontworpen om dat aan te kunnen.
Er zijn een aantal zeer actuele onderwerpen die we overal zullen zien, zoals beveiliging en cyberrisico. Ze zijn heel reële uitdagingen voor ons. Er is een heel handige tool met de naam North op het web, waar je op een webpagina verschillende cyberaanvallen in realtime kunt bekijken. Als je ernaar kijkt, denk je "oh het is een leuke schattige kleine webpagina", maar na ongeveer vijf minuten besef je dat de hoeveelheid gegevens die het systeem analyseert op alle verschillende streams van alle verschillende apparaten over de hele wereld die eraan worden toegevoerd. Het begint de geest van hoe ze dat uitvoeren aan de rand van die plaat in wezen te verbazen en biedt je dat eenvoudige kleine scherm dat je vertelt wat of wat anders het in realtime aanvalt en welke soorten aanvallen. Maar het is een heel nette manier om gewoon een goede indruk te krijgen van wat streamanalyses in realtime voor u kunnen doen door deze pagina te bekijken en alleen een idee te krijgen van het volume en de uitdaging van het nemen van streams, het verwerken van analysequery's op hen en dat in realtime vertegenwoordigen.
Ik denk dat het gesprek dat ik de rest van de sessie heb, al die dingen met één interessant uitzicht zal behandelen, vanuit mijn oogpunt, en dat is de uitdaging van DIY, zelf bakken, past bij enkele van de klassieke eenhoorns die zich dit soort dingen kunnen veroorloven. Ze hebben miljarden dollars om deze engineeringteams te bouwen en hun datacenters te bouwen. Maar voor 99, 9% van de organisaties die waarde willen stimuleren in hun bedrijf van stroomanalyse, moeten ze een kant-en-klare service krijgen. Ze moeten een product uit de doos kopen en ze hebben over het algemeen wat advies en professionele service nodig om het te helpen implementeren en ze krijgen die waarde terug in het bedrijf en verkopen het terug aan het bedrijf als een werkende oplossing.
Daarmee ga ik je teruggeven, Rebecca, omdat ik geloof dat we dat nu in detail gaan bespreken.
Rebecca Jozwiak: Uitstekend. Heel erg bedankt, Dez. Dat is een geweldige presentatie.
Nu geef ik de bal door aan Robin. Haal het weg.
Robin Bloor: Oké. Omdat Dez in de kern van het verwerken van streams is gegaan, leek het me niet logisch om het opnieuw te behandelen. Dus ik ga gewoon een volledig strategisch standpunt innemen. Bijna van een heel hoog niveau naar beneden kijkend naar wat er aan de hand is en het positioneren omdat ik denk dat het mensen kan helpen, vooral wij mensen die niet eerder zijn gekampeerd in streams die op grote diepte zijn verwerkt.
De verwerking van streams bestaat al lang. We noemden het CEP. Daarvoor waren er realtime-systemen. De oorspronkelijke procesbesturingssystemen waren eigenlijk informatiestromen aan het verwerken - natuurlijk ging er niets zo ver als tegenwoordig. Deze afbeelding die u hier op de dia ziet; het wijst eigenlijk op een heleboel dingen, maar het wijst boven alles uit - het feit dat er hier een spectrum van latenties is die in verschillende kleuren verschijnen. Wat er eigenlijk gebeurde sinds de uitvinding van computers of commerciële computers die rond 1960 arriveerde, is dat alles net sneller en sneller is geworden. Vroeger konden we afhangen van de manier waarop dit daadwerkelijk uitkwam als je van golven houdt, want zo ziet het eruit. Dit hangt er eigenlijk van af. Omdat het allemaal werd aangedreven door de wet van Moore en de wet van Moore ons een factor van ongeveer tien keer snelheid zou geven over een periode van ongeveer zes jaar. Toen we eigenlijk rond 2013 aankwamen, brak het allemaal, en we begonnen plotseling te versnellen met een snelheid die we nooit hebben gehad, wat vreemd ongekend is. We kregen een factor van ongeveer tien in termen van toename van de snelheid en daarom een vermindering van de latentie ongeveer om de zes jaar. In de zes jaar sinds ongeveer 2010 hebben we een veelvoud van minstens duizend. Drie orden van grootte in plaats van één.
Dat is wat er gaande is en daarom lijkt de industrie op de een of andere manier met fantastische snelheden te bewegen - omdat dat zo is. Als we alleen de betekenis van deze afbeelding doornemen, zijn de reactietijden trouwens op algoritmische schaal langs de verticale as. Real time is computersnelheid, sneller dan mensen. Interactieve tijden zijn oranje. Als je met de computer communiceert, wil je echt een tiende tot ongeveer een seconde latentie. Hierboven is er een transactie waarbij we eigenlijk nadenken over wat u op de computer doet, maar als dat na ongeveer vijftien seconden uitvalt, wordt het ondraaglijk. Mensen zouden eigenlijk gewoon niet wachten op de computer. Alles werd in batch gedaan. Veel dingen die in batch werden gedaan, komen nu rechtstreeks in de transactieruimte, rechtstreeks in de interactieve ruimte of zelfs in de realtime ruimte. Waar we voorheen een golf met zeer kleine hoeveelheden gegevens konden doen, kunnen we dit nu doen met zeer grote hoeveelheden gegevens in een enorm uitgebreide omgeving.
Dus eigenlijk is dit allemaal de transactie en de interactieve reactietijd van mensen. Heel veel van wat er nu met streams wordt gedaan, is mensen informeren over dingen. Een deel ervan gaat sneller dan dat en het informeert dingen goed dus het is realtime. Vervolgens nemen we een licentie om gewoon als een steen te vallen, waardoor directe analyse haalbaar en bovendien redelijk betaalbaar is. Het is niet alleen dat de snelheid is gedaald en de top is ook net ingestort. Waarschijnlijk de grootste impact op al deze van alle verschillende applicaties, kunt u al deze voorspellende analyses uitvoeren. Ik zal je zo vertellen waarom.
Dit is alleen de hardware store. Je hebt parallelle software. We hebben het over 2004. Uitschaalbare architectuur, multicore-chips, geheugenuitbreiding, configureerbare CPU. SSD's gaan nu zoveel sneller dan de draaiende schijf. Je kunt vrijwel afscheid nemen van de draaiende schijf. SSD's bevinden zich ook in meerdere cores, dus weer sneller en sneller. Binnenkort verschijnen we, de memristor van HP. We hebben de 3D XPoint van Intel en Micron. De belofte daarvan is dat het allemaal toch sneller en sneller zal gaan. Als je eigenlijk aan twee nieuwe geheugentechnologieën denkt, die beide het hele fundamentele stukje maken, gaat de individuele printplaat veel sneller, we hebben het einde nog niet eens gezien.
Streams-technologie, wat echt de volgende boodschap is, is er om te blijven. Er zal een nieuwe architectuur moeten komen. Ik bedoel, Dez heeft dit op verschillende punten in zijn presentatie genoemd. Decennia lang zagen we architectuur als een combinatie van datahops en datapijpen. We hadden de neiging om de hopen te verwerken en we hadden de neiging om de gegevens tussen de hopen door te leiden. We gaan nu fundamenteel op weg naar wat we de Lambda-gegevensarchitectuur noemen die de verwerking van gegevensstromen combineert met gegevenshopen. Als je eigenlijk een stroom van gebeurtenissen verwerkt die tegen historische gegevens aankomen als een gegevensstroom of een gegevenshoop, dan bedoel ik de Lambda-architectuur. Dit staat nog in de kinderschoenen. Het is slechts een deel van de foto. Als je iets complexs als Internet of Everything beschouwt, dat Dez ook heeft genoemd, zul je je realiseren dat er allerlei problemen met datalocaties zijn - beslissingen over wat je in de stream moet verwerken.
Wat ik hier echt zeg, is dat toen we in batch verwerkten, we eigenlijk streams aan het verwerken waren. We konden het gewoon niet één voor één doen. We wachten gewoon tot er een hoop dingen zijn en dan verwerken we alles in één keer. We gaan naar een situatie waarin we daadwerkelijk dingen in de stream kunnen verwerken. Als we dingen in de stream kunnen verwerken, worden de gegevenshopen die we in ons bezit hebben de statische gegevens waarnaar we moeten verwijzen om de gegevens in de stream te verwerken.
Dit brengt ons tot dit specifieke ding. Ik heb dit eerder genoemd in een presentatie met de biologische analogie. De manier waarop ik zou willen dat je nadenkt, is op het moment dat we mensen zijn. We hebben drie verschillende netwerken voor realtime voorspellende verwerking. Ze worden het somatische, autonome en enterische genoemd. De maag is je buik. Het autonome zenuwstelsel zorgt voor gevechten en vluchten. Het zorgt eigenlijk voor snelle reacties op de omgeving. De somatische die zorgt voor de beweging van het lichaam. Dat zijn realtime systemen. Het interessante eraan - of ik denk dat het best interessant is - is dat het veel voorspellend is dan je ooit zou denken. Het is alsof je eigenlijk naar een scherm kijkt op ongeveer 18 centimeter van je gezicht. Alles wat u duidelijk kunt zien, alles wat uw lichaam in staat is om duidelijk te zien, is in feite ongeveer een 8 × 10-rechthoek. Alles daarbuiten is eigenlijk wazig wat je lichaam betreft, maar je geest vult eigenlijk de gaten op en maakt het niet wazig. Je ziet helemaal geen vervaging. Je ziet het duidelijk. Je geest doet eigenlijk een voorspellende methode voor de gegevensstroom zodat je die duidelijkheid kunt zien. Dat is een beetje merkwaardig, maar je kunt eigenlijk kijken naar de manier waarop het zenuwstelsel werkt en de manier waarop we ons kunnen redden en ons redelijk kunnen gedragen - althans sommigen van ons - redelijk gezond en niet constant tegen dingen op botsen.
Het wordt allemaal gedaan door een reeks neurale analyseschalen hier. Wat er gaat gebeuren is dat organisaties hetzelfde soort dingen gaan hebben en hetzelfde soort dingen gaan bouwen en dat het de verwerking zal zijn van streams inclusief de interne streams van de organisatie - de dingen die binnen gebeuren het, de dingen die daarbuiten gebeuren, de onmiddellijke reacties die eigenlijk moeten worden gegeven, zijn natuurlijk de mens aan het voeden om beslissingen te nemen, om al deze dingen te laten gebeuren. Dat is waar we naartoe gaan, zover ik kan zien.
Een van de dingen die daar een gevolg van is, is dat het niveau van de streamingapplicatie goed gaat. Er gaat nog veel meer gebeuren dan we nu zien. Op dit moment plukken we de laaghangende vrucht van het doen van de dingen die voor de hand liggen.
Dus hoe dan ook, dat is hier de conclusie. Streaming-analyse is ooit een niche, maar wordt mainstream en zal binnenkort algemeen worden overgenomen.
Daarmee geef ik het terug aan Rebecca.
Rebecca Jozwiak: Heel erg bedankt, Robin. Geweldige presentatie zoals gewoonlijk.
Anand, jij bent de volgende. De vloer is van jou.
Anand Venugopal: Fantastisch. Dank je.
Mijn naam is Anand Venugopal en ik ben Product Head voor StreamAnalytix. Het is een product aangeboden door Impetus Technologies, uit Los Gatos, Californië.
Impetus heeft eigenlijk een grote geschiedenis in het zijn van een grote aanbieder van data-oplossingen voor grote ondernemingen. We hebben dus een aantal streaming-analyses geïmplementeerd als dienstverlenend bedrijf en we hebben veel lessen geleerd. We zijn de afgelopen jaren ook overgestapt op een product- en oplossingsgericht bedrijf en streamanalytics neemt de leiding over de transformatie van Impetus naar een grotendeels productgestuurd bedrijf. Er zijn enkele kritieke, zeer, zeer belangrijke activa die Impetus heeft gecleard dankzij onze blootstelling aan ondernemingen en StreamAnalytix is er een van.
We zijn 20 jaar actief en er is een geweldige mix van producten en diensten die ons een enorm voordeel maakt. En StreamAnalytix is geboren uit alle lessen die zijn geleerd uit onze eerste vijf of zes implementaties van streaming.
Ik zal een paar dingen bespreken, maar de analisten, Dez en Robin, hebben fantastisch werk geleverd om de ruimte in het algemeen te dekken, dus ik ga veel inhoud overslaan die overlapt. Ik ga waarschijnlijk snel. We zien naast echte streamingcases veel gebruik maken van alleen maar batchversnelling waarbij er letterlijk heel, heel belangrijke batchprocessen zijn in bedrijven. Zoals u kunt zien, kan deze hele cyclus van het waarnemen en analyseren en ernaar handelen in grote ondernemingen weken duren en ze proberen het allemaal terug te brengen tot minuten en soms seconden en milliseconden. Dus alles sneller dan al deze batchprocessen zijn kandidaten voor bedrijfsacquisitie en dat is heel goed gesteld dat de waarde van gegevens drastisch afneemt met de leeftijd, dus hoe meer waarde er is in het eerste deel in de seconden dat het net gebeurde. In het ideale geval, als je kon voorspellen wat er zou gebeuren, is dat de hoogste waarde. Dat hangt echter af van de nauwkeurigheid. De volgende hoogste waarde is wanneer het daar is wanneer het gebeurt, u kunt het analyseren en reageren. Natuurlijk neemt de waarde daarna dramatisch af, de belangrijkste beperkende BI waarin we ons bevinden.
Het is interessant. Je zou een dramatisch wetenschappelijk antwoord kunnen verwachten op waarom streaming analytics. In veel gevallen zien we dat het nu mogelijk is en omdat iedereen weet dat batch oud is, batch saai is en batch niet cool is. Er is genoeg voorlichting die iedereen nu heeft gehad over het feit dat streaming mogelijk is en iedereen heeft nu Hadoop. Nu hebben Hadoop-distributies een streamingtechnologie ingebed, of het nu Storm- of Spark-streaming is en natuurlijk berichtenwachtrijen, zoals Kafka, enz.
Ondernemingen die we zien springen erin en beginnen met deze gevallen te experimenteren en we zien twee brede categorieën. Men heeft iets te maken met klantanalyse en klantervaring en de tweede operationele intelligentie. Ik zal hier wat later op ingaan. De hele klantenservice en klantbelevingshoek en wij bij Impetus StreamAnalytix hebben dit op veel verschillende manieren gedaan, het gaat echt allemaal om het echt vastleggen van de multi-channel betrokkenheid van de consument in realtime en hen zeer, zeer contextgevoelige ervaringen te geven die tegenwoordig niet gebruikelijk zijn. Als u op internet surft, op de Bank of America-website, en u onderzoekt enkele producten en belt u gewoon het callcenter. Zouden ze zeggen: "Hé Joe, ik weet dat je wat bankproducten aan het onderzoeken was, wil je dat ik je invul?" Dat verwacht je vandaag niet, maar dat is het soort ervaring dat echt mogelijk is met streaming-analyse. In veel gevallen maakt het een enorm verschil, vooral als de klant is begonnen met het onderzoeken van manieren om uit zijn contract met u te komen door te kijken naar clausules voor vervroegde beëindiging of voorwaarden voor vervroegde beëindiging op uw website en vervolgens in te bellen en u niet in staat bent om confronteer hen er direct mee, maar doe gewoon indirect een bod over een soort van eerste promotie omdat het systeem weet dat deze persoon naar vroegtijdige beëindiging kijkt en u dat aanbod doet op dat moment, u die zeer goed draaiende klant heel goed kunt beschermen en dat activum kunt beschermen .
Dat zou een voorbeeld zijn, plus veel klantenservice zijn allemaal zeer goede voorbeelden. We implementeren vandaag brengt de kosten in het callcenter omlaag en biedt dramatische heerlijke klantervaringen. Dez heeft uitstekend werk geleverd in het samenvatten van enkele gebruiksscenario's. Je kunt een paar minuten naar deze grafiek staren. Ik heb het geclassificeerd als verticalen, horizontalen en combo-gebieden, IoT, mobiele app en callcenter. Het zijn allemaal verticale en horizontale. Het hangt ervan af hoe je het bekijkt. Het komt erop neer dat we een groot aantal horizontale toepassingen zien die vrij gebruikelijk zijn in verticale branches en er zijn verticale specifieke gebruiksscenario's, waaronder financiële dienstverlening, gezondheidszorg, telecom, productie, enz. Als u zichzelf echt de vraag stelt of uzelf de vraag stelt dat, "oh, ik weet niet welke use cases er zijn. Ik weet niet zeker of er echt enige zakelijke waarde is in streaming-analyse voor mijn bedrijf of voor onze onderneming, ”denk goed na, denk twee keer na. Praat met meer mensen omdat er use cases zijn die vandaag in uw bedrijf relevant zijn. Ik zal ingaan op de bedrijfswaarde van hoe precies de bedrijfswaarde wordt afgeleid.
Aan de onderkant van de piramide hier, heb je voorspellend onderhoud, beveiliging, churn-bescherming, enz. Dat soort use cases vormen bescherming van inkomsten en activa. Als Target hun inbreuk op de beveiliging, die uren en weken plaatsvond, zou hebben beschermd, had de CIO zijn baan kunnen redden. Het kan tientallen of honderden miljoenen dollars besparen, enz. Real-time streaming-analyses helpen echt bij het beschermen van die activa en het beschermen van verliezen. Dat is de directe toegevoegde waarde voor bedrijven.
De volgende categorie wordt winstgevender, verlaagt uw kosten en haalt meer inkomsten uit de huidige operatie. Dat is de efficiëntie van de huidige onderneming. Dat zijn allemaal gebruikscategorieën die we realtime operationele intelligentie noemen, waarbij u diep inzicht krijgt in hoe het netwerk zich gedraagt, hoe uw klantactiviteiten zich gedragen, hoe uw bedrijfsproces zich gedraagt en u in staat bent om te tweaken dat alles in realtime omdat je feedback krijgt, krijg je meldingen. Je krijgt afwijkingen, varianties in realtime en je kunt snel handelen en het proces dat buiten de grenzen valt scheiden.
U kunt mogelijk ook veel geld besparen bij dure kapitaalupgrades en dingen waarvan u denkt dat die nodig zijn, maar die misschien niet nodig zijn als u de netwerkdienst optimaliseert. We hoorden van een geval waarin een grote telco een upgrade van $ 40 miljoen in hun netwerkinfrastructuur uitstelde omdat ze ontdekten dat ze voldoende capaciteit hadden om hun huidige verkeer te beheren, namelijk door de intelligente routing van hun verkeer en dergelijke te optimaliseren en beter te doen. Dat is allemaal alleen mogelijk met een aantal realtime analyses en actiemechanismen die in realtime op die inzichten reageren.
Het volgende niveau van toegevoegde waarde is up-sell, cross-sell wanneer er mogelijkheden zijn om meer inkomsten en winst te maken uit het huidige aanbod. Dit is een klassiek voorbeeld dat velen van ons weten over waar ze hebben meegemaakt, waar je aan denkt in je leven waar je bereid bent om vandaag echt een product te kopen dat niet aan jou wordt aangeboden. In veel, veel gevallen gebeurt dat eigenlijk. Je hebt dingen in gedachten die je leuk vindt om te kopen, waarvan je weet dat je ze wilt kopen, dat je een takenlijst hebt of iets, dat je vrouw je heeft verteld of als je geen vrouw hebt, maar je echt wilde kopen en u gaat winkelen op een website of u communiceert in een winkel, de winkel heeft gewoon niet de context, heeft niet de intelligentie om te berekenen wat u nodig heeft. Daarom krijgen ze hun bedrijf niet veilig. Als streaming-analyse zou kunnen worden ingezet om echt nauwkeurige voorspellingen te doen en die echt mogelijk zijn over wat het meest geschikt is voor deze specifieke context, deze klant op dit moment op deze locatie, is er veel up-sell en cross-sell en dat komt weer van streaming analytics - in staat zijn om een propensity-beslissing te nemen over wat deze klant waarschijnlijk zal kopen of waarop zal reageren op dat moment van de waarheid wanneer er een mogelijkheid is. Daarom ben ik dol op die foto die Dez liet zien met de beer op het punt om die vis op te eten. Dat is het eigenlijk wel.
We denken ook dat er een grote categorie is van dramatische, transformationele veranderingen in een onderneming door volledig nieuwe producten en diensten aan te bieden, simpelweg gebaseerd op observatie van klantgedrag, allemaal gebaseerd op observatie van het gedrag van een andere onderneming. Als, laten we zeggen, een telco of een kabelbedrijf echt de gebruikspatronen van klanten observeert in welk segment van de markt hij bekijkt, welk programma op welk tijdstip, enz., Dan creëren ze uiteindelijk producten en diensten die bijna worden gesmeekt voor een of andere manier. Dus het hele concept van gedrag op meerdere schermen, waar we het nu bijna als vanzelfsprekend beschouwen, dat we tv- of kabelinhoud kunnen zien op onze mobiele apps. Sommige van die voorbeelden zijn afkomstig van die nieuwe producten en diensten die ons worden aangeboden.
Ik zal ingaan op: "Wat zijn de architectuuroverwegingen van streaminganalyse?" Het is uiteindelijk wat we proberen te doen. Dit is de Lambda-architectuur waarbij je de historische gegevens en de realtime inzichten combineert en tegelijkertijd ziet. Dat is wat Sigma mogelijk maakt. We hebben vandaag allemaal de batcharchitectuur en het bedrijfsbeeld. We verzamelen een soort BI-stack en gebruiksstack en de Lambda-architectuur is toegevoegd. Als de snelheidslaag of de behoefte en de Lambda draait het allemaal om het samenvoegen van die twee inzichten en dat op een gecombineerde manier te zien, op een rijke manier die beide inzichten combineert.
Er is een ander paradigma genaamd de Kappa-architectuur dat wordt voorgesteld, waarbij het vermoeden is dat de snelheidslaag het enige invoermechanisme is dat op de langere termijn zal blijven bestaan. Alles gaat door deze snelheidslaag komen. Er komt zelfs geen offline ETL-mechanisme. Alle ETL zal gebeuren. Opschonen, gegevens opschonen, kwaliteit ETL - dat gebeurt allemaal op de draad, want onthoud dat alle gegevens in realtime zijn geboren. Op een gegeven moment was het realtime. We zijn er zo aan gewend geraakt om dit op meren, rivieren en oceanen aan te brengen en het vervolgens op basis van statische analyse te doen, dat we vergaten dat de gegevens op een bepaald moment in realtime werden geboren. Alle gegevens zijn eigenlijk geboren als een real-time gebeurtenis die op het tijdstip plaatsvond en de meeste gegevens vandaag op het meer zijn net in de database gezet voor een latere analyse en we hebben nu het voordeel in Lambda en Kappa-architectuur van eigenlijk zien, analyseren, voorverwerken en erop reageren als het aankomt. Dat is wat mogelijk wordt gemaakt door deze technologieën. Als je het als een algemeen beeld ziet, ziet het er ongeveer zo uit, met Hadoop erin, MPP's en datawarehouses die je al hebt.
We zetten dit op omdat het belangrijk is om niet alleen over nieuwe technologieën op een eiland te praten. Ze moeten integreren. Ze moeten logisch zijn in de huidige bedrijfscontext, en als oplossingsleveranciers die ondernemingen bedienen, zijn we hier erg gevoelig voor. We helpen ondernemingen om het geheel te integreren. Er zijn gegevensbronnen aan de linkerkant die zowel de Hadoop- en datawarehouse-lagen als de real-time laag bovenaan voeden en elk van die entiteiten zijn stockcomputers zoals u kunt zien en de gegevensconsumelaag bevindt zich aan de rechterkant kant. Er is een constante inspanning om het merendeel van de compliance, governance, beveiliging, levenscyclusbeheer, enz. Die vandaag beschikbaar is, allemaal te hebben verzameld in deze nieuwe technologie.
Een van de dingen die stream-analyse probeert te doen, als je vandaag naar het landschap kijkt, is er veel gaande in het landschap van de streamingtechnologie en vanuit het perspectief van een zakelijke klant is er zoveel te begrijpen. Er is zoveel bij te houden. Er zijn mechanismen voor het verzamelen van gegevens aan de linkerkant - NiFi, Logstash, Flume, Sqoop. Vanzelfsprekend heb ik een disclaimer opgesteld die zegt dat deze niet uitputtend is. Komt in de berichtenwachtrijen en komt dan in de open-source streaming-engines - Storm, Spark Streaming, Samza, Flink, Apex, Heron. Heron is waarschijnlijk nog geen open source. Ik weet niet zeker of het van Twitter is. Die streaming-engines leiden dan naar of ondersteunen een set-up analytische applicatiecomponent zoals complexe gebeurtenisverwerking, machine learning, voorspellende analyse, waarschuwingsmodule, streaming ETL, filters voor verrijking van statistische bewerkingen. Dat zijn allemaal wat we nu operators noemen. De reeks van die operatoren zou, indien aan elkaar geplakt, mogelijk ook een aantal aangepaste grotendeels geconcludeerd indien nodig wordt een streaming-applicatie die op een streaming-engine draait.
Als onderdeel van die keten van componenten, moet u ook de gegevens opslaan en indexeren in uw favoriete database, uw favoriete index. Mogelijk moet u ook het cachegeheugen en opnieuw distribueren dat naar de datavisualisatielaag aan de rechterkant van het bovenste gedeelte leidt naar commerciële producten of open source-producten, maar uiteindelijk hebt u een soort product nodig om die gegevens in realtime te visualiseren. Ook moet u soms andere toepassingen uitzoeken. We hebben allemaal gezien dat de waarden alleen worden afgeleid door de actie die u uitvoert op basis van het inzicht, dat die actie een trigger zal worden van een analytische stapel naar een andere toepassingsstapel die misschien is veranderd, dat is iets in de IVR-kant of activeert een callcenter uitgaande oproep of zoiets. We moeten die systemen hebben geïntegreerd en een mechanisme voor uw streamingcluster om andere toepassingen voor het stroomafwaarts verzenden van gegevens te activeren.
Dat is de totale stapel van links naar rechts. Dan heb je de servicelagen, de middelste monitoring, algemene beveiligingslaag, enz. Komend tot welke producten die er zijn in de bedrijfsruimte die klanten zien zoals Hadoop-distributies die allemaal streaming hebben zoals ik al zei en er is commercieel of single -vendor oplossingen die duidelijk in onze concurrenten zijn. Er zijn er ook veel meer in het landschap dat we hier misschien niet hebben genoemd.
Wat u daar ziet, is in grote lijnen de zakelijke gebruiker te zien. Een complex en snel evoluerend technologielandschap voor streamverwerking, zoals u kunt zien. We moeten de keuze en hun gebruikerservaring vereenvoudigen. Wat we denken dat bedrijven echt nodig hebben, is de functionele abstractie van dat alles in een one-stop-shop, eenvoudig te gebruiken interface die al die technologieën samenbrengt die het echt eenvoudig te gebruiken maken en niet alle bewegende delen blootleggen en de degradatieproblemen en de prestatieproblemen en de levenscyclusonderhoudsproblemen voor de onderneming.
De functionele abstractie is één. Het tweede deel is de abstractie van de streaming-engine. De streaming-engines en de open-source domeinen verschijnen nu eens in de drie, vier of zes maanden. Het was lange tijd Storm. Samza kwam op en nu is het Spark Streaming. Flink steekt zijn kop op en begint aandacht te krijgen. Zelfs de Spark Streaming-routekaart, ze maken een manier om mogelijk een andere engine te gebruiken voor pure gebeurtenisverwerking, omdat ze zich ook realiseren dat Spark is ontworpen voor batch en ze een weg banen in hun architectuurvisie en hun routekaart voor mogelijk een andere engine voor streamverwerking naast het huidige microbatch-patroon in Spark Streaming.
Het is een realiteit waarmee je te kampen hebt dat er veel evolutie zal zijn. Je moet jezelf echt beschermen tegen die technologische stroom. Omdat je er standaard een moet kiezen en er dan mee moet leven, wat niet optimaal is. Als je het op een andere manier bekijkt, vecht je tussen: "Oké, ik moet een eigen platform kopen waar geen lock-in is, er is geen hefboomwerking van open source, kan zeer hoge kosten en beperkt zijn flexibiliteit versus al deze open source-stack waar je het zelf moet doen. ”Nogmaals, zoals ik al zei, het kost veel tijd en vertraging bij het op de markt brengen. Wat we zeggen is StreamAnalytix is een voorbeeld van een geweldig platform dat de enterprise-klasse combineert, betrouwbare, enkele leverancier, professionele service ondersteund - dat alles wat je echt nodig hebt als onderneming en de kracht van flexibiliteit van het open source ecosysteem waar een enkel platform ze samenbrengt - Ingest, CEP, analyse, visualisatie en dat alles.
Het doet ook een heel, heel uniek ding, dat veel verschillende technologische motoren samenbrengt onder één enkele gebruikerservaring. We denken echt dat de toekomst gaat over het gebruik van meerdere streaming-engines omdat verschillende use cases echt verschillende streaming-architecturen vereisen. Zoals Robin al zei, er is een heel spectrum van latenties. Als je het echt hebt over het latentieniveau van milliseconden, tientallen of zelfs honderden milliseconden, heb je Storm op dit moment echt nodig totdat er een ander even volwassen product is voor minder soepelheid of een soepel tijdschema en latenties van misschien in een paar seconden, drie, vier, vijf seconden, dat bereik, dan kun je Spark Streaming gebruiken. Potentieel zijn er andere motoren die beide zouden kunnen doen. Kortom, in een grote onderneming zullen er allerlei soorten use-cases zijn. U wilt echt dat de toegang en de algemeenheid meerdere motoren hebben met één gebruikerservaring en dat is wat we proberen te bouwen in StreamAnalytix.
Gewoon een snel overzicht van de architectuur. We gaan dit een beetje herwerken, maar in wezen komen er aan de linkerkant meerdere gegevensbronnen binnen - Kafka, RabbitMQ, Kinesis, ActiveMQ, al die gegevensbronnen en berichtenwachtrijen komen binnen op het platform voor stroomverwerking waar krijg je een app, waar je kunt slepen en neerzetten van operators zoals de ETL's, alle dingen waar we het over hadden. Hieronder zijn er meerdere motoren. Op dit moment hebben we Storm en Spark Streaming als het enige en eerste streamingplatform van enterprise-klasse dat ondersteuning biedt voor meerdere motoren. Dat is een zeer unieke, flexibiliteit die we bieden naast alle andere flexibiliteit van realtime dashboards. CET-motor ingebed. We hebben de naadloze integratie met Hadoop- en NoSQL-indexen, Solr- en Apache-indexen. U kunt naar uw favoriete database gaan, wat het ook is, en applicaties heel snel bouwen en heel snel op de markt komen en toekomstbestendig blijven. Dat is onze hele mantra in StreamAnalytix.
Daarmee denk ik dat ik mijn opmerkingen zal afsluiten. Kom gerust naar ons toe voor meer vragen. Ik wil graag het woord open houden voor Q&A en paneldiscussie.
Rebecca, naar jou toe.
Rebecca Jozwiak: Geweldig, oké. Heel erg bedankt. Dez en Robin, heb je nog een paar vragen voordat we het aan de vragen van het publiek overhandigen?
Robin Bloor: Ik heb een vraag. Ik zet mijn koptelefoon weer op zodat je me kunt horen. Een van de interessante dingen, als je me dit vriendelijk kunt vertellen, ziet veel van wat ik in de open-source ruimte heb gezien eruit wat ik onvolwassen tegen me zou zeggen. In zekere zin kun je verschillende dingen doen. Maar het lijkt erop dat we in de eerste of tweede versie van de software naar de realiteit kijken en ik vroeg me gewoon af met je ervaring als organisatie, hoeveel zie je de onvolwassenheid van de Hadoop-omgeving als problematisch of is het iets dat niet t teveel problemen veroorzaken?
Anand Venugopal: Het is een realiteit, Robin. Je hebt helemaal gelijk. De onvolwassenheid ligt niet noodzakelijk op het gebied van alleen functionele stabiliteit en dergelijke, maar misschien ook enkele gevallen daarvan. Maar de onvolwassenheid is meer in gereedheid voor gebruik. De open-sourceproducten zodra ze uitkomen en zelfs als ze worden aangeboden door de Hadoop-distributie, het zijn allemaal heel veel verschillende capabele producten, componenten die gewoon tegen elkaar worden geslagen. Ze werken niet naadloos samen en zijn niet ontworpen voor een soepele, naadloze gebruikerservaring die we zoals Bank of America of Verizon of AT&T binnen enkele weken kunnen inzetten om een streaming-analyse-applicatie te implementeren. Daar zijn ze zeker niet voor ontworpen. Dat is de reden waarom we binnenkomen. We brengen het samen en maken het heel gemakkelijk te begrijpen, te implementeren, etc.
Ik denk dat de functionele volwassenheid er grotendeels is. Veel grote ondernemingen gebruiken tegenwoordig bijvoorbeeld Storm. Veel grote ondernemingen spelen tegenwoordig met Spark Streaming. Elk van deze motoren heeft hun beperkingen in wat ze kunnen doen, daarom is het belangrijk om te weten wat je kunt en wat je niet kunt doen met elke motor en het heeft geen zin om je hoofd tegen de muur te breken en te zeggen: "Kijk ik heb voor Spark Streaming gekozen en het werkt voor mij niet in deze branche. ”Het gaat niet werken. Er zullen use cases zijn waarbij Spark Streaming de beste optie zal zijn en er zullen use cases zijn waarbij Spark Streaming helemaal niet voor u werkt. Daarom heb je echt meerdere opties nodig.
Robin Bloor: Nou, je hebt voor het grootste deel van dit team expertteams aan boord nodig. Ik bedoel, ik weet zelfs niet waar ik hiermee moet beginnen. Een verstandige samenwerking van bekwame personen. Ik ben geïnteresseerd in hoe je betrokken raakt en hoe het gebeurt. Is het omdat een bepaald bedrijf op zoek is naar een specifieke toepassing of zie je een soort van wat ik strategische adoptie zou noemen, waarbij ze willen dat een heel platform veel dingen doet.
Anand Venugopal: We zien voorbeelden van beide, Robin. Sommige van de top tien merken die iedereen kent, gaan er op een zeer strategische manier mee om. Ze weten dat ze verschillende gebruiksscenario's zullen hebben, dus evalueren ze platforms die geschikt zijn voor die behoefte, wat een aantal verschillende gebruiksscenario's is op een multi-tenant manier die in een onderneming kan worden ingezet. Er zijn case-use verhalen voor eenmalig gebruik die ook beginnen. Er is een specifieke use case van het type bedrijfsactiviteit in een hypotheekbedrijf waaraan we werken, die je je niet als eerste use case zou voorstellen, maar dat is de zakelijke oplossing of use case die ze hebben bedacht en toen hebben we de punten aan streaming gekoppeld . We zeiden: "Weet je wat? Dit is een goed geval voor streaming-analyse en dit is hoe we het kunnen implementeren. ”Zo begon het. Vervolgens worden ze in dat proces opgeleid en zeggen: "Oh wow, als we dit kunnen doen en als dit een generiek platform is, dan kunnen we de applicatie scheiden, ze in een platform plaatsen en hierop veel verschillende applicaties bouwen platform."
Robin Bloor: Dez, heb je nog vragen?
Anand Venugopal: Dez staat waarschijnlijk op mute.
Dez Blanchfield: Excuses, dempen. Ik had zelf net een goed gesprek. Als je de oorspronkelijke observatie van Robin volgt, heb je absoluut gelijk. Ik denk dat de uitdaging nu is dat bedrijven een ecosysteem en een culturele en gedragsomgeving hebben waar gratis en open-source software iets is dat hen bekend is en ze in staat zijn om tools zoals Firefox als browser te gebruiken en het heeft een behoorlijke levensduur totdat het stabiel en veilig wordt. Maar sommige van die zeer grote platforms die ze gebruiken, zijn bedrijfseigen platforms. Dus de acceptatie van wat ik als open-source platforms beschouw, is niet altijd iets dat ze gemakkelijk cultureel of emotioneel kunnen overbrengen. Ik heb dit alleen gezien bij de acceptatie van kleine programma's die lokale projecten waren om gewoon met big data en analyse te spelen als een fundamenteel concept. Ik denk dat een van de belangrijkste uitdagingen, ik weet zeker dat je ze nu in de organisaties hebt gezien, hun verlangen is om de uitkomst te krijgen, maar tegelijkertijd met één voet in het oude blikje te steken waar ze dit gewoon kunnen kopen van “Voeg een groot merk in” Oracle, IBM en Microsoft. Deze nieuwe en bekende merken komen door met Hadoop-platforms en nog veel meer. Er komen meer opwindende merken door die geavanceerde technologie zoals stream hebben.
Wat voor soort gesprekken heb je zo gehad of doorgekregen? Ik weet dat we vanmorgen massaal aanwezig zijn en ik weet zeker dat iedereen eraan denkt: "Hoe snijd ik die hele uitdagende laag door van bestuur tot managementniveau, oh het is te open source en te bloederig randje?" "Hoe gaan gesprekken die je met klanten hebt en hoe dring je door tot dat punt waarop je dat soort angsten een beetje wegneemt om te overwegen om StreamAnalytix te gebruiken?
Anand Venugopal: We vinden het eigenlijk vrij eenvoudig om onze waardepropositie te verkopen, omdat klanten van nature op weg zijn naar open source als voorkeursoptie. Ze geven niet zomaar op en zeggen: "Oké, ik ga nu open source." Ze ondergaan een zeer toegewijde evaluatie van een belangrijk product, laten we zeggen dat het een IBM of een typisch product is, omdat ze deze leveranciersrelaties. Ze zouden ons of de open-source engine niet tegen dat product behandelen. Ze zullen zes tot acht tot twaalf weken evaluatie ondergaan. Ze zullen zichzelf ervan overtuigen dat er een zekere mate van prestaties en stabiliteit is die ik wil en dan besluiten ze: "Wauw, weet je wat, ik kan dit echt doen."
Tegenwoordig hebben we bijvoorbeeld een belangrijke Tier 1-telco die streamanalyses op een groot deel van de stapel in productie heeft en ze evalueren dat tegen een andere zeer, zeer grote bekende leverancier en ze waren pas overtuigd nadat we alles hadden bewezen de prestaties, stabiliteit en al die dingen. Ze nemen het niet als vanzelfsprekend aan. Ze kwamen erachter dat open source competent is door hun evaluaties en ze beseffen dat, in het ergste geval, "misschien zijn er die twee use cases die ik misschien niet kan doen, maar de meeste van mijn zakelijke acceleratie use cases vandaag zijn bij uitstek mogelijk met de open-source stapel. ”En we maken het gebruik ervan mogelijk. Dus dat is de grote sweet spot daar. Ze wilden de open source. Ze zijn echt op zoek om uit de lock-in situatie van de verkoper te komen waaraan ze al vele, vele jaren gewend zijn. Dan komen we en zeggen: "Weet je, we zullen open source veel, veel gemakkelijker en gebruiksvriendelijker voor je maken."
Dez Blanchfield: Ik denk dat de andere uitdaging die de bedrijven vinden, is dat wanneer ze de traditionele gevestigde exploitant binnenhalen, ze vaak een generatie achter een paar van de bloedige kanten staan van de spannende dingen waar we het hier over hebben en dat bedoel ik niet als een negatief licht. Het is alleen zo dat de realiteit is dat ze een generatie en reis hebben moeten doorlopen om vrij te geven wat zij als stabiele platforms beschouwen, ouderwetse ontwikkeling en UATN-integratiecycli en -testen en -documentatie, en marketing en verkoop. Terwijl in het type dat je aan het doen bent, ik denk dat het ding dat ik wil overwegen, is dat als je naar een aantal van je nieuwste releases gisteravond kijkt om een soort van onderzoekswerk te doen, je deze mix nu hebt waar je de competentie vanuit een vooraf bepaald adviesperspectief en een implementatie, maar je hebt ook een stapel die je kunt invoeren. Ik denk dat dit de plek is waar de gevestigde exploitanten enige tijd mee worstelen. We hebben veel van hen gezien zoals ik dat op de markt deed. Ze zitten vaak in wat ik inhaalknooppunten noem, terwijl wat je ons vertelt wanneer je daar bent die die gesprekken voert en je daar bent aan het uitvoeren.
Kun je ons een paar voorbeelden geven van enkele van de grensverticalen die je hebt overgenomen? Er is bijvoorbeeld echt een nichey-omgeving zoals raketwetenschap en satellieten in de ruimte zetten en gegevens van Mars verzamelen. Er is maar een handvol mensen dat op de planeet doet. Maar er zijn grote verticale sectoren zoals gezondheid, bijvoorbeeld in de luchtvaart, in de scheepvaart en logistiek, in de productie en engineering, wat een paar voorbeelden zijn van de grotere en bredere industriële sectoren die je tot nu toe hebt gezien, dat je echt goed hebt gezien adoptie in?
Anand Venugopal: Telco is een groot voorbeeld.
Ik ga mijn dia's hier snel repareren. Kun je de dia hier zien, case study 4?
Dit is het geval van een grote telco die settopbox-gegevens binnenkrijgt en er meerdere dingen mee doet. Ze kijken naar wat klanten echt in realtime doen. Ze bekijken in real-time waar zich fouten voordoen in settopboxen. Ze proberen het callcenter te informeren over, als deze klant op dit moment belt, de codelinkinformatie uit de set-top box van deze klant, informatie over onderhoudstickets correleert snel of de set-top box van deze klant een probleem heeft of zelfs niet eerder de klant spreekt een woord. Elke kabelmaatschappij, elke grote telco probeert dit te doen. Ze nemen de settopbox-gegevens op, voeren realtime analyses uit, voeren campagneanalyses uit zodat ze hun advertenties kunnen plaatsen. Er is een enorme use case.
Zoals ik al zei, er is een hypotheekbedrijf dat weer een generiek patroon is waar grote systemen bij betrokken zijn bij het verwerken van gegevens van. De gegevens die door systeem A naar systeem B naar systeem C stromen en dit zijn gereguleerde bedrijven waarvan alles consistent moet zijn. Systemen lopen vaak niet synchroon met elkaar, een systeem zegt: "Ik verwerk honderd leningen met een totale waarde van $ 10 miljoen." Het systeem zegt: "Nee, ik verwerk 110 leningen van een andere ander aantal. 'Dat moeten ze heel snel oplossen, omdat ze in feite dezelfde gegevens verwerken en verschillende interpretaties maken.
Of het nu gaat om een creditcard, leningverwerking, bedrijfsproces of een hypotheekbedrijfsproces of iets anders, we helpen hen om in realtime correlatie en afstemming te doen om ervoor te zorgen dat die bedrijfsprocessen synchroon blijven. Dat is weer een interessante use case. Er is een grote Amerikaanse overheidscontractant die naar DNS-verkeer kijkt om afwijkingen op te sporen. Er is een offline trainingsmodel dat ze hebben gebouwd en ze scoren op basis van dat model op realtime verkeer. Enkele van die interessante use cases. Er is een grote luchtvaartmaatschappij die naar wachtrijen kijkt en ze proberen je die informatie te geven die zegt: "Hé, het is jouw gate voor je vliegtuig voor je vlucht. De wachtrij van TSA vandaag is ongeveer 45 minuten versus twee uur versus iets anders. ”Je krijgt die update vooraf. Ze zijn er nog steeds mee bezig. Interessante IoT-use case maar geweldige case van streaming-analyse op weg naar de klantervaring.
Rebecca Jozwiak: Dit is Rebecca. Terwijl je het hebt over use cases, is er een grote vraag van een publiekslid die zich afvraagt: "Zijn deze case studies, worden deze initiatieven gedreven vanuit de analytische kant van het informatiesysteem of worden ze meer gedreven vanuit het bedrijf dat specifieke vragen of behoeften in gedachten heeft? ”
Anand Venugopal: ik denk dat we ongeveer 60 procent of zo, 50 procent tot 55 procent, grotendeels zeer proactieve, enthousiaste technologie-initiatieven zien die toevallig weten, die redelijk slim zijn en bepaalde zakelijke vereisten begrijpen en ze hebben waarschijnlijk één sponsor die ze geïdentificeerd, maar dit zijn technologieteams die zich klaarmaken voor de aanval van zakelijke use cases die zich voordoen en wanneer ze eenmaal de capaciteit hebben opgebouwd, weten ze dat ze dit kunnen doen en gaan ze vervolgens naar het bedrijfsleven en verkopen dit agressief. In 30 tot 40 procent van de gevallen zien we dat bedrijven al een specifieke use case hebben die smeekt om streaming-analyse.
Rebecca Jozwiak: Dat is logisch. Ik heb nog een iets meer technische vraag van een publiekslid. Hij vraagt zich af of deze systemen zowel gestructureerde als ongestructureerde datastromen ondersteunen, zoals sedimenten van Twitter-streams of Facebook-berichten in realtime, of moet het in eerste instantie worden gefilterd?
Anand Venugopal: de producten en technologieën waarover we het hebben, ondersteunen zeer snel zowel gestructureerde als ongestructureerde gegevens. Ze kunnen worden geconfigureerd. Alle gegevens hebben een soort structuur, of het nu een tekst of een XML is of wat dan ook. Er is enige structuur in termen van er is een tijdstempelfeed. Er is misschien nog een blob die moet worden ontleed, zodat je parses in de stream kunt injecteren om de gegevensstructuren te ontleden. Als het gestructureerd is, vertellen we het systeem gewoon: "Oké, als er door komma's gescheiden waarden zijn en de eerste een string is, is de tweede een datum." Dus we kunnen die parsing-intelligentie in de lagen op het scherm injecteren en zowel gestructureerde als ongestructureerde gegevens gemakkelijk verwerken.
Rebecca Jozwiak: Ik heb nog een vraag van het publiek. Ik weet dat we een beetje voorbij de top van het uur zijn gelopen. Deze deelnemer wil weten, het lijkt erop dat realtime streamingapplicaties zowel een behoefte als een mogelijkheid ontwikkelen om terug te integreren in transactiesystemen, fraudepreventie-systemen die ze bijvoorbeeld introduceren. Moeten transactiesystemen in dat geval worden aangepast om daar enigszins bij te passen?
Anand Venugopal: Het is een samenvoeging, toch? Het is een samenvoeging van transactiesystemen. Ze worden soms de gegevensbron waar we transacties in realtime analyseren en in veel gevallen laten we zeggen dat er een applicatiestroom is en hier probeer ik een site voor het opzoeken van statische gegevens te tonen en dan in ons geval waar een soort streaming in en u zoekt een statische database zoals een HBase of een RDBMS om de streaminggegevens en de statische gegevens samen te verrijken om een beslissing of een analytisch inzicht te nemen.
Er is nog een andere grote bedrijfstrend die we ook zien - de convergentie van OLAP en OLTP - en daarom heb je databases zoals Kudu en in-memory-databases die tegelijkertijd transacties en analytische verwerking ondersteunen. De stroomverwerkingslaag zou volledig in het geheugen zijn en we zullen enkele van deze transactiedatabases bekijken of ermee communiceren.
Rebecca Jozwiak: Gemengde werklast is volgens mij een van de laatste hindernissen geweest. Dez, Robin, hebben jullie nog twee vragen?
Dez Blanchfield: Ik ga op een laatste vraag ingaan en die afronden als je het niet erg vindt. De eerste uitdaging waar de organisaties waar ik het afgelopen decennium mee bezig ben geweest, leidde tot deze opwindende uitdaging van stroomanalyse, het eerste wat ze weer op tafel leggen toen we het gesprek rond deze hele uitdaging begonnen, is waar krijgen we de vaardigheden? Hoe herschikken we de vaardigheden en hoe krijgen we die capaciteit intern? Impetus binnen laten komen en met de hand vasthouden, houdt ons tijdens de reis vast en implementeert het vervolgens als een geweldige eerste stap.
Maar voor middelgrote tot grote organisaties, wat zijn de soorten dingen die je op dit moment ziet om je hierop voor te bereiden, om die mogelijkheid intern op te bouwen, om iets te krijgen van alleen een basiswoordenschat eromheen en met wat voor soort boodschap kunnen ze doen de organisatie rond de overgang naar dit soort raamwerk en hun bestaande technische staf van IT van CEO veranderen, zodat ze dit zelf kunnen uitvoeren zodra u het bouwt en implementeert? Gewoon heel kort, wat voor soort uitdagingen en hoe lossen ze deze op, de klanten waarmee je te maken hebt, de soorten uitdagingen die ze hebben gevonden en hoe ze doorgaan met het oplossen van die omscholing en het herwinnen van ervaring en kennis om zich hierop voor te bereiden en te zijn in staat om operationeel rond te gaan?
Anand Venugopal: vaak is de kleine groep mensen die een streaming analyseplatform proberen te kopen al redelijk slim, omdat ze zich bewust zijn van Hadoop, ze hebben hun Hadoop MapReduce-vaardigheden al verworven en omdat ze nauw samenwerken met Hadoop distributieleverancier, ze zijn bekend. Alles krijgt Kafka bijvoorbeeld. Ze doen er iets mee en Storm- of Spark-streaming bevindt zich in hun open-source domein. Zeker, mensen zijn er bekend mee of bouwen er vaardigheden omheen. Maar het begint met een kleine groep mensen die vaardig genoeg zijn en slim genoeg zijn. Ze gaan naar conferenties. Ze zijn aan het leren en dat ze intelligente vragen stellen aan leveranciers en in sommige gevallen leren ze met de leveranciers. Omdat de leveranciers komen en presenteren tijdens de eerste vergadering, weten ze misschien niets, maar lezen ze samen en beginnen ze ermee te spelen.
Die kleine groep mensen is de kern en dan begint het te groeien en iedereen beseft nu dat de eerste business use case operationeel wordt. Er begint een golf en we zagen vorige week op de Spark-top waar een grote onderneming als Capital One daar op volle kracht was. Ze kozen voor Spark. Ze spraken erover. Ze leiden veel van hun mensen op in Spark omdat ze er in veel gevallen ook als gebruiker aan bijdragen. We zien hetzelfde met heel veel grote ondernemingen. Het begint met een paar kleine, zeer slimme mensen en dan begint het met een golf van algemene opleiding en mensen weten dat zodra een senior VP of eenmaal een senior directeur in lijn is en ze willen wedden op dit ding en het woord rondkomt en ze beginnen allemaal deze vaardigheden te leren.
Dez Blanchfield: Ik weet zeker dat je ook een fantastische tijd hebt om die kampioenen te bouwen.
Anand Venugopal: Ja. We doen veel onderwijs terwijl we werken met de eerste kampioenen en we geven trainingen en veel, veel voor onze grote klanten zijn we teruggegaan en hadden golven en golven van training om veel gebruikers in de mainstream gebruiksfase te brengen, vooral in Hadoop MapReduce site. We hebben geconstateerd dat we in een groot creditcardbedrijf dat een klant van ons is, minstens vijf tot acht verschillende trainingsprogramma's hebben geleverd. We hebben ook gratis community-edities van al deze producten, waaronder die van ons, sandboxen die mensen kunnen downloaden, wennen en ook op die manier kunnen leren.
Dez Blanchfield: Dat is alles wat ik vanmorgen voor je heb. Hartelijk dank. Ik vind het ongelooflijk interessant om de soorten modellen en use cases te zien die je vandaag voor ons hebt. Dank je.
Anand Venugopal: Geweldig. Heel erg bedankt mensen.
Rebecca Jozwiak: Bedankt iedereen voor het meedoen aan deze Hot Technologies-webcast. Het was fascinerend om te horen van Dez Blanchfield, Dr. Robin Bloor en van Impetus Technologies, Anand Venugopal. Bedankt presentatoren. Bedankt sprekers en bedankt publiek. We hebben volgende maand nog een Hot Technologies, dus kijk daarnaar. U kunt onze inhoud altijd gearchiveerd vinden op Insideanalysis.com. We hebben ook veel inhoud op SlideShare geplaatst en ook enkele interessante stukjes op YouTube.
Dat is alles Mensen. Nogmaals bedankt en nog een prettige dag gewenst. Tot ziens.
