Inhoud
Bron: Jakub Jirsak / Dreamstime.com
Afhaal:
Gastheer Eric Kavanagh bespreekt big data-analyse met experts uit de industrie.
Eric: dames en heren, het is het einde van het jaar 2014 - althans bijna. Het is onze laatste webcast van het jaar, mensen! Welkom bij TechWise! Ja inderdaad! Mijn naam is Eric Kavanagh. Ik zal je moderator zijn voor een geweldige webcast, mensen. Ik ben echt heel erg opgewonden. We hebben twee geweldige analisten online en twee geweldige bedrijven - echte innovators in dit hele big data-ecosysteem. En we gaan het hebben over de sleutel tot big data-analyse is het begrijpen van verschil. Dus laten we doorgaan en er meteen in duiken, mensen.
We hebben verschillende presentatoren. Zoals je ziet, staat die van jou helemaal bovenaan. Mike Ferguson belt helemaal vanuit het VK, waar hij speciale privileges moest krijgen om zo laat in zijn kantoor te blijven. Dat is hoe laat het voor hem is. We hebben Dr. Robin Bloor, onze eigen Chief Analyst hier bij de Bloor Group. En we hebben George Corugedo, CEO en mede-oprichter van RedPoint Global, en Keith Renison, Senior Solutions Architect van SAS Institute. Dit zijn fantastische bedrijven, mensen. Dit zijn bedrijven die echt innoveren. En we gaan dieper ingaan op enkele van de goede dingen van wat er nu gebeurt in de hele wereld van big data. En laten we eerlijk zijn, de kleine gegevens zijn niet verdwenen. En daarom wil ik hier mijn samenvatting geven.
Dus er is een oude Franse uitdrukking: "Hoe meer dingen veranderen, hoe meer ze hetzelfde blijven." En laten we hier enkele feiten onder ogen zien - big data zal de problemen van kleine data niet oplossen. Kleine bedrijfsgegevens zijn er nog steeds. Het is nog steeds overal. Het is de brandstof voor operaties voor de informatie-economie van vandaag. En big data biedt een compliment aan deze zogenaamde kleine bedrijfsgegevens, maar vervangt kleine gegevens niet. Het zal er nog steeds zijn. Ik hou van veel dingen over big data, vooral dingen zoals machinaal gegenereerde data.
En vandaag zullen we waarschijnlijk een beetje praten over sociale media-gegevens, wat ook erg krachtige dingen zijn. En als je bijvoorbeeld nadenkt over hoe sociaal de business is veranderd, denk dan eens aan drie snelle websites hier: LinkedIn en. Denk aan het feit dat vijf jaar geleden niemand dat soort dingen deed. is tegenwoordig een absolute juggernaut. is natuurlijk enorm. Het is gigantisch. En dan is LinkedIn de de facto standaard voor bedrijfsnetwerken en communicatie. Deze sites zijn gigantisch en om de gegevens die erin staan te kunnen benutten, zal het een aantal spelveranderende functionaliteit nieuw leven inblazen. Het gaat echt veel goed doen voor veel organisaties - althans degenen die ervan profiteren.
Geen bugs, geen stress - Uw stapsgewijze handleiding voor het creëren van levensveranderende software zonder uw leven te vernietigen
U kunt uw programmeervaardigheden niet verbeteren als niemand om softwarekwaliteit geeft.
Dus, governance - governance is nog steeds belangrijk. Nogmaals, big data doet de noodzaak van governance niet teniet. Eerlijk gezegd is er een hele nieuwe behoefte om te focussen op hoe de wereld van big data te besturen. Hoe zorgt u ervoor dat u over uw procedures en beleid beschikt; dat de juiste mensen toegang krijgen tot de juiste gegevens; dat je contacten hebt, heb je hier afkomst bij betrokken? Je weet eigenlijk waar de gegevens vandaan komen, wat ermee is gebeurd. En dat is allemaal aan het veranderen.
Eerlijk gezegd ben ik echt onder de indruk van sommige dingen die ik heb gezien in deze hele nieuwe wereld met het Hadoop-ecosysteem, wat natuurlijk veel meer is dan opslag qua functionaliteit. Hadoop is ook een computationele motor. En het bedrijf moet uitzoeken hoe die rekenkracht, die parallelle verwerkingscapaciteit kan worden benut. Ze gaan echt hele gave dingen doen. Daar zullen we vandaag over leren.
Het andere ding om te vermelden, dit is iets waar Dr. Bloor in het recente verleden over heeft gesproken, is dat de innovatiegolf nog niet voorbij is. We hebben natuurlijk veel aandacht gezien rond Hadoop. We hebben gezien dat bedrijven als Cloudera en Hortonworks echt wat golven maken. En ze ontwikkelen momenteel eerlijk gezegd partnerschappen met, nou ja, bedrijven die op afroep zijn. En ze ontwikkelen partnerschappen met veel mensen. Maar de innovatiegolf is nog niet voorbij. Er komen meer projecten uit de Apache Foundation die niet alleen het eindpunt veranderen, als u wilt - de applicaties die mensen gebruiken - maar de infrastructuur zelf.
Dus deze hele ontwikkeling van YARN - nog een andere onderhandelaar voor bronnen - lijkt echt op een besturingssysteem voor big data. En het is een groot probleem. Dus we gaan leren hoe dat ook dingen verandert. Dus, slechts een paar voor de hand liggende adviezen hier, wees op uw hoede voor lange contracten in de toekomst, weet u, contracten van vijf of tien jaar worden de golf, het pad dat mij lijkt. U wilt koste wat het kost vastlopen voorkomen. Daar gaan we vandaag alles over leren.
Dus onze eerste analist die vandaag spreekt - onze eerste spreker van het hele programma is Mike Ferguson, die vanuit het VK belt. Daarmee ga ik je de sleutels overhandigen, Mike, en je laten meenemen. Mike Ferguson, de vloer is van jou.
Mike, ben je daar? U kunt het geluid dempen. Ik hoor hem niet. Misschien moeten we hem terugbellen. En we springen gewoon recht naar de dia's van Robin Bloor. Robin, ik ga hier voor de arme Mike Ferguson staan. Ik ga even.
Ben jij dat, Mike? Kun je ons horen? Nah. Ik denk dat we door moeten gaan en eerst met Robin moeten gaan. Dus wacht even, mensen. Ik zal hier ook een paar links naar de dia's plaatsen. Laat me daarmee de sleutels overhandigen aan Robin Bloor. Robin, jij kunt als eerste gaan in plaats van Mike, en ik bel Mike meteen.
Robin: Oké.
Eric: Wacht even, Rob. Laat me doorgaan en je dia hier krijgen, Rob. Het gaat even duren.
Robin: Oké.
Eric: Ja. Je kunt hier echter wel praten over waar we het hier over hebben op het gebied van governance. Ik weet dat je over governance gaat praten. Dat wordt meestal gedacht in de con van kleine bedrijfsgegevens. Dus nu heb ik de dia naar boven, Robin. Niets verplaatsen. En hier ga je. De vloer is van jou. Haal het weg.
Robin: Oké. Ja. Ik bedoel, nou, we hadden van tevoren afgesproken dat Mike zou praten over de analytische kant, en ik zal praten over de governance-kant. Tot op zekere hoogte volgt de governance de analyse in die zin dat het een reden is dat u big data doet, en dat de reden is dat u alle software verzamelt om de analyse uit te voeren.
Er is een probleem. En het probleem is dat, weet je, de gegevens moeten worden gerangschikt. De gegevens moeten worden opgesteld. De gegevens moeten worden samengebracht en beheerd op een manier die ervoor zorgt dat de analyses vol vertrouwen kunnen worden uitgevoerd - denk ik, dat is het woord. Dus ik dacht dat ik het over de bestuurlijke kant van de vergelijking zou hebben. Ik denk dat het ding om te zeggen echt is dat, weet je, governance al een probleem was. Governance was al een probleem en het wordt een probleem in het hele datawarehouse-spel.
Wat er feitelijk is gebeurd, is dat het een veel groter probleem is geworden. En de reden waarom het een veel groter probleem is geworden en meer gegevens, maar ik bedoel, dit zijn echt de redenen. Het aantal gegevensbronnen is enorm toegenomen. Voorheen werden de gegevensbronnen die we hebben grotendeels bepaald door wat het gegevensmagazijn voedde. Het datawarehouse wordt normaal gevoed door RTP-systemen. Het is mogelijk een beetje externe gegevens, niet veel.
Nu zijn we naar een wereld gegaan waar, weet je, op dit moment een datamarkt ontstaat, en daarom zal er worden gehandeld in data. Je hebt al heel veel verschillende streaming gegevensbronnen die je daadwerkelijk naar de organisatie kunt brengen. We hebben sociale media-gegevens die ze hebben weggehaald, om zo te zeggen voor eigen rekening. Ik bedoel, heel veel van de, de waarde in de sociale mediasites is eigenlijk de informatie die ze verzamelen en daarom beschikbaar kunnen stellen aan mensen.
We hebben ook de ontdekking van, weet je, het is alsof ze al bestonden. We hadden die logbestanden al, weet je, in de komst van Splunk. En al snel werd duidelijk dat een logbestand waarde heeft. Er waren dus gegevens binnen de organisatie die we konden noemen, zowel nieuwe gegevensbronnen als externe bronnen. Dus dat is één ding. En dat betekent echt dat, weet u, welke regels voor het beheer van gegevens die we eerder hadden, ze op een of andere manier moeten worden uitgebreid en moeten worden uitgebreid om daadwerkelijk de gegevens. Maar we beginnen nu op de een of andere manier te assembleren.
En naar beneden deze lijst hebben we streaming en de snelheid van aankomst van gegevens. Een van, denk ik, de redenen voor de populariteit van Hadoop is dat het vrijwel kan worden gebruikt om veel gegevens te verzamelen. Het kan ook datasnelheid opnemen, als het niet echt meteen nodig is, het is een mooie parallelle, enorme parallelle omgeving. Maar je hebt ook het feit dat er nu een behoorlijke hoeveelheid streaming-analyses plaatsvindt. Vroeger waren het alleen de banksectoren die geïnteresseerd waren in streaming-applicaties, maar nu is het een beetje mondiaal. En iedereen kijkt op een of andere manier naar streaming-applicaties, een potentieel middel om waarde uit data te halen en analyses voor de organisatie te doen.
We hebben de ongestructureerde gegevens. De statistiek, meestal onderdeel van de enige 10% van de gegevens in de wereld, was in relationele databases. Nu, een van de belangrijkste redenen daarvoor was dat het eigenlijk ongestructureerd was, en dat was het ook - een groot deel ervan stond op het web, maar vrijwel verspreid over verschillende websites. Die gegevens zijn ook analyseerbaar gebleken, ook bruikbaar. En met de komst van de Symantec-technologie die geleidelijk in de situatie kruipt, wordt dit steeds meer en meer.Het is dus nodig om ongestructureerde gegevens te verzamelen en te beheren, en dat betekent dat het veel groter is dan voorheen. We hebben sociale gegevens die ik al heb genoemd, maar het belangrijkste punt is dat het waarschijnlijk moet worden schoongemaakt.
We hebben gegevens over Internet of Things. Dat is een ander soort situatie. Daar zal waarschijnlijk zoveel van zijn, maar veel ervan zal ergens in de buurt van de plaats waar het wordt gedistribueerd moeten blijven. Maar je zult het ook op een of andere manier willen binnenhalen om de analyse van de gegevens binnen de organisatie te doen. Dus dat is nog een andere factor toegevoegd. En die gegevens zullen op een andere manier worden gestructureerd, omdat het waarschijnlijk - het zal waarschijnlijk worden geformatteerd in JSON of in XML, zodat het zichzelf verklaart. En niet alleen, op de een of andere manier, dat we feitelijk gegevens binnenhalen en in staat zijn om een soort schema te maken bij het lezen van dat specifieke stuk gegevens.
We hebben het probleem van de herkomst en dit is een analyseprobleem. De resultaten in elke analyse die u doet, kunnen echt niet - als u dat wilt - worden goedgekeurd, als geldig worden beschouwd, tenzij u de herkomst van de gegevens kent. Ik bedoel, dat is gewoon professionaliteit in termen van de activiteit van datawetenschappers. Maar weet je, om data herkomst te hebben, betekent dat dat we eigenlijk data moeten regeren en een aantekening moeten houden in de afstamming.
We hebben het probleem van computerkracht en parallellen en alles wat dat doet is alles sneller maken. Het probleem is natuurlijk dat bepaalde processen die we hebben opgezet voor al het andere te traag kunnen zijn. Er is dus mogelijk sprake van mismatches in termen van snelheid.
We hebben de komst van machine learning. De machine learning heeft echt tot gevolg dat analytics een ander spel wordt dan voorheen. Maar je kunt het alleen echt gebruiken als je de kracht hebt.
We hebben nieuwe analytische workloads gekregen. We hebben een parallelle wereld en sommige analytische algoritmen moeten parallel worden uitgevoerd voor een maximaal effect. En daarom is het probleem eigenlijk de manier waarop je de gegevens op de een of andere manier rondstuurt, de gegevens maakt als ze beschikbaar zijn. En waar u de analytische werkbelastingen daadwerkelijk uitvoert, omdat u dat mogelijk binnen de database doet. Dus je doet het misschien binnen analytische toepassingen.
Er is dus een hele reeks bestuurlijke uitdagingen. Wat we dit jaar hebben gedaan - het onderzoek dat we dit jaar hebben gedaan, ging echt over big data-architectuur. En wanneer we het proberen te veralgemenen, zag de conclusie waar we uit kwamen - het diagram dat we bedachten heel erg zo.
Ik ga hier niet op in, vooral omdat Mike behoorlijk wat gaat doen aan data-architectuur voor analyse. Maar waar ik eigenlijk van hou dat mensen zich gewoon concentreren, is dit onderste gedeelte waar we op de een of andere manier gegevens verzamelen. We hebben iets waarnaar ik zou willen verwijzen, de gegevensraffinaderij of de gegevensverwerkingshub. En dat is waar de governance plaatsvindt. Dus, weet je, als we ons ergens op concentreren, ziet het er zo uit. Weet je, het wordt gevoed door gegevens uit interne en externe bronnen. De hub moet in theorie alle gegevens bevatten die worden gegenereerd. Het moet ofwel worden gestreamd en beheerd als het wordt gestreamd als u analyses en streaminggegevens moet uitvoeren en vervolgens aan de hub worden doorgegeven. Of anders komt het allemaal in de hub. En er zijn een aantal dingen die gaande zijn - die gaande zijn in de hub. En u kunt niet een bepaalde hoeveelheid analyses en SQL laten plaatsvinden in de hub. Maar u hebt ook de behoefte aan datavirtualisatie in elke cel om gegevens naar andere gebieden te pushen. Maar voordat dit gebeurt, moet u op de een of andere manier de gegevens voorbereiden. Je kunt het gegevensvoorbereiding noemen. Het is veel groter dan dat. Dit zijn de dingen die ik denk dat het omvat.
We hebben systeembeheer en servicebeheer, in zekere zin dat dit het grootste deel van de gegevenslaag is, en dan moeten we alle systemen voor het beheer van operationele systeembeheer die we traditioneel hebben gedaan, toepassen op vrijwel alle operationele systemen. Maar we moeten ook op een of andere manier andere dingen in de gaten houden om ervoor te zorgen dat aan deze verschillende serviceniveaus wordt voldaan, omdat er gebonden zijn aan gedefinieerde serviceniveaus of enige vorm van analyse als actie of BI-gegevens in actie komen.
We hebben prestatiebewaking en -beheer nodig. Als er iets anders is, hebben we dat nodig om te weten welke verdere computerbronnen we op verschillende tijdstippen moeten toewijzen. Maar ook, heel veel van de werklast is hier feitelijk vrij complex en concurreert met elkaar om middelen. Er is iets behoorlijk geavanceerd dat op dat gebied moet worden gedaan.
We hebben nu de gegevenslevenscyclus op een manier die we nog nooit eerder hadden. De deal hier gaat echt boven alles, dat we geen gegevens hebben verzameld en eerder weggegooid. We hadden de neiging om gegevens te verzamelen die we nodig hadden en die waarschijnlijk hebben bewaard en die we vervolgens archiveren. Maar heel veel van wat we vanaf nu gaan doen, is gegevens verkennen. En als u de gegevens niet wilt, laten we ze begraven. Dus, de datalevenscycli zijn iets anders, afhankelijk van de situatie, maar zullen ook een veel meer aggregatie van gegevens zijn. Daarom weet je, wetende waar een aggregaat vandaan kwam, wat de ... wat de bron van aggregatie is, enzovoort enzovoort. Dat is allemaal nodig.
Datalijn leent natuurlijk. Zonder dat moet je de problemen kennen, dus de gegevens ... We moeten weten dat de gegevens geldig zijn, maar hoe betrouwbaar ze eigenlijk zijn.
We hebben ook datamapping, omdat veel van de data op de een of andere manier daadwerkelijk zullen zijn. En dit is, als je wilt, dit tot op zekere hoogte bij MDM. Het is alleen dat het nu veel gecompliceerder is, want als je heel veel gegevens hebt gedefinieerd door JSON of op basis van ons XML-schema bij lezen, dan moet je op de een of andere manier zeer actief zijn data mapping activiteit gaande.
Er is een metadatabeheersituatie die meer is dan MDM, omdat er op de een of andere manier behoefte is om te bouwen wat ik nu zou willen zien als een soort metadata-magazijn van alles waar je interesse in hebt. Er is metadata ontdekking, omdat voor sommige gegevens niet noodzakelijkerwijs de metagegevens zijn gedeclareerd en we deze onmiddellijk willen gebruiken. En dan is er het opschonen van gegevens, wat een enorm ding is hoe een reeks dingen die men daar kan doen. En er is ook gegevensbeveiliging. Al deze gegevens moeten op een acceptabel niveau worden beveiligd, en dat kan zelfs in bepaalde gevallen betekenen - bijvoorbeeld het coderen van veel van de waarden.
Dus al deze werklast is eigenlijk het bestuursimperium. Dit alles, op de een of andere manier, moet tegelijkertijd of eerder aan de gang zijn, al onze analytische activiteiten. Dit is een groot aantal gecoördineerde applicaties. Het is een systeem op zichzelf. En dan zullen degenen die het niet op verschillende tijdstippen doen, aan een gebrek eraan lijden naarmate ze verder gaan, omdat heel veel van deze dingen niet echt optioneel zijn. Je krijgt alleen maar meer entropie als je ze niet doet.
Dus, in termen van data-analyse en governance, is het ding dat ik zou zeggen dat, echt, de ene hand de andere wast. Zonder governance zullen analytics en BI niet op tijd bot zijn. En zonder analyse en BI, zou er toch niet veel behoefte zijn om de gegevens te beheren. De twee dingen lopen dus echt hand in hand. Zoals ze in het Midden-Oosten zeggen: "De ene hand wast de andere." En dat is eigenlijk alles wat ik te zeggen heb. Ik hoop - hopelijk hebben we nu Mike terug.
Eric: Dat doen we. Mike, ik neem aan dat je er bent. Ik ga je dia omhoog duwen.
Mike: Ik ben het. Oké, kun je me horen?
Eric: Ja, ik kan je horen. Je klinkt geweldig. Dus, laat me even voorstellen ... Daar ga je. En jij bent nu de presentator. Haal het weg.
Mike: Oké, bedankt! Goedemorgen, goedemiddag, goedenavond allemaal. Vergeef de hik in het begin. Om een of andere reden heb ik mezelf gedempt en kan ik iedereen zien, maar ze konden me niet horen.
Alright. Dus, wat ik snel wil doen, is praten over het analytische ecosysteem van big data. Als je me vragen wilt stellen, zeg ik dat je in deze sessie of later mijn contactgegevens hier kunt vinden. Zoals ik zei, midden in de nacht hier in het VK.
Nou, laat me komen tot waar ik het over wil hebben. Het is duidelijk dat we de afgelopen jaren de opkomst zijn van allerlei nieuwe soorten gegevens die bedrijven nu willen analyseren - alles van clickstream-gegevens om online gedrag te begrijpen, sociale mediagegevens waarover Eric het had over de begin van het programma hier. Ik denk dat Robin JSON, BSON, XML noemde - dus semi-gestructureerde gegevens die zichzelf beschrijven. Natuurlijk hebben we ook nog een heleboel andere dingen - alles van ongestructureerde gegevens, logboeken van IT-infrastructuur, sensorgegevens. Al deze relatief nieuwe gegevensbronnen waar bedrijven nu belangstelling voor hebben, omdat het waardevol inzicht bevat dat mogelijkerwijs kan verdiepen in wat we weten.
Dat betekent dus dat het analytische landschap verder is gegaan dan de traditionele datawarehousing. We structureren nog steeds gegevens in de wereld van een combinatie van gestructureerde en multi-gestructureerde gegevens, waarbij de multi-gestructureerde gegevens in veel gevallen van binnen of van buiten de onderneming kunnen komen. En als gevolg van deze nieuwe gegevenstypen en nieuwe behoeften om te analyseren, hebben we de opkomst van nieuwe analytische werkbelastingen gezien - alles van het analyseren van gegevens in beweging, die de traditionele architectuur voor gegevensopslag enigszins op zijn kop zet, enigszins, waar we , in traditionele kringen, gegevens integreren, opschonen, transformeren, opslaan en analyseren. Maar terwijl we bewegende gegevens analyseren, leggen we de gegevens vast, integreren deze, bereiden deze voor door ze te analyseren en vervolgens op te slaan. Er is dus een analyse van gegevens voordat deze ergens worden opgeslagen.
We complexe analyse van gestructureerde gegevens, misschien voor modelontwikkeling, statistische en voorspellende modelontwikkeling, dat is niets nieuws voor sommige mensen in een traditionele datawarehouse-ruimte. We hebben een verkennende analyse van gegevens op het model. Dat is de hoeveelheid gestructureerde gegevens daar. We hebben nieuwe workloads in de vorm van grafiekanalyse die voor mijn klanten in financiële dienstverlening zaken als fraude omvat. Het omvat ook cyberbeveiliging. Het omvat sociale netwerken, natuurlijk, het begrijpen van beïnvloeders en dat soort dingen daar. Ik heb het zelfs beheerst, heeft enkele jaren grafische analyse.
We hebben de optimalisatie van het datawarehouse of offloading van ETL-verwerking, wat meer een soort IT-use case is, CIO zou dat kunnen financieren. En zelfs archivering van gegevens en datawarehouses om ze online te houden in dingen zoals Hadoop. Dus al deze nieuwe analytische workloads hebben nieuwe platforms, nieuwe opslagplatforms, aan het analytische landschap toegevoegd. Dus, in plaats van dat we alleen traditionele datawarehouses hebben, hebben we nu ook Hadoop. We hebben NoSQL-databases zoals grafische databases die vaak worden gebruikt voor analytische workloads. Natuurlijk kunnen we nu grafiekanalyse uitvoeren op Hadoop zelf en in een NoSQL-grafiek-DBMS. We hebben streaming-analyses die Robin noemde. En we hebben - als u wilt - het bouwen van modellen, misschien ook op analytische datawarehouse-apparaten. Maar dat alles heeft het analytische landschap gecompliceerd, er zijn nu meerdere platforms nodig. En ik denk dat de uitdaging van, voor elk bedrijf met een frontoffice of backoffice, of financiën, inkoop, HR en een soort van operaties, is om erachter te komen welke analytische projecten worden geassocieerd met een traditionele scène voor gegevensopslag. En als u eenmaal weet dat analytische projecten zijn gekoppeld aan deze nieuwe big data-platforms en waar ze moeten worden uitgevoerd, weet u, welke analytische werklast, maar om de zaken niet uit het oog te verliezen in die zin dat het - u zult nu zien dat het een combinatie is van grote data-analytische projecten en traditionele big data warehousing-projecten die samen nodig zijn om binnen de klant of rondom de activiteiten, rond risico, of financiën of duurzaamheid te versterken. En daarom willen we dat al deze worden afgestemd op onze strategische zakelijke prioriteiten, dat we op koers blijven om, weet u, de naalden in te drukken die moeten worden ingedrukt, weet u, om de bedrijfsprestaties te verbeteren, om de kosten te verlagen, om risico's te verminderen, enz., weet u, voor ons bedrijf als geheel. Het is dus niet zo dat de een hier de ander vervangt door big data en traditioneel. Het wordt allebei samen gebruikt. En dat verandert de architectuur drastisch, weet je.
Wat ik hier heb, is een relatief nieuwe architectuur die ik met mijn klanten zal gebruiken. En dus, zoals u nu onderaan kunt zien, een enorm scala aan gegevensbronnen, niet alleen meer gestructureerd. Sommige daarvan streamen live gegevens zoals sensoren, zoals marktgegevens, dat soort dingen. Het kunnen zelfs live clickstream-gegevens zijn. Het kunnen live videostreaminggegevens zijn. Het hoefde dus niet gestructureerd te zijn. We kunnen dus stroomverwerking van die gegevens uitvoeren om automatische acties in realtime te ondernemen, en alle relevante gegevens kunnen worden gefilterd en doorgegeven aan een enterprise information management tools die kunnen worden gebruikt om analytische gegevensopslag te vullen. Tenzij u hier in de mix kunt zien, hebben we nu traditionele datawarehousing-, Hadoop- en NoSQL-databases. We hebben ook stamgegevensbeheer in de mix. En dat legt meer druk op de hele toolset voor gegevensbeheer, niet alleen om deze datastores te vullen, maar om gegevens ertussen te verplaatsen.
Bovendien moeten we toegangstools vereenvoudigen. We kunnen ons niet alleen tot de gebruiker wenden en zeggen: "haal al die gegevensopslagplaatsen op, houd deze API's vast - uw probleem." Wat u moet doen, is de toegang vereenvoudigen. En dus, soort van in de stippellijnen daar, zul je zien dat datavirtualisatie en optimalisatie de complexiteit van meerdere gegevensopslag verbergen, probeer het eindgebruikers gemakkelijker toegang te geven. En natuurlijk is er een reeks tools bovenaan, weet je - alles van traditionele BI-tools die een beetje opnieuw zijn begonnen aan de bovenkant van datawarehousing, geleidelijk naar links van je grafiek om een soort verbinding te maken met de Hadoops en dan NoSQL-databases van de wereld.
We hebben een zoektocht om een nieuw leven te krijgen, met name rond het lichaam gestructureerde, niet-gestructureerde gegevens die vaak worden opgeslagen in Hadoop. We hebben aangepaste analytische toepassingen die moeten worden uitgevoerd op een Hadoop-platform met MapReduce, dus het Spark-framework bijvoorbeeld. We hebben grafische analysehulpmiddelen om u te concentreren op zeer specifieke workloads daar. Dus een reeks tools en de datastromen zijn ook complexer. Het is niet langer een eenrichtingsverkeer in het datawarehouse. Het zijn nu natuurlijk stamgegevens.
Er komen nieuwe gegevensbronnen binnen, ofwel vastgelegd in NoSQL, weet je, gegevenswinkels zoals MongoDB, zoals Cassandra, zoals HBase. We hebben gegevens rechtstreeks naar Hadoop gebracht voor analyse en gegevensvoorbereiding daar. We hebben nieuwe inzichten uit Hadoop en de datawarehouses. Er komt een archief uit de datawarehouses naar Hadoop. Nu hebben we datafeeds voor, weet je, ook alle NoSQL-databases en datamarts. Wat u hier kunt zien, is dat er veel meer activiteit gaande is in gegevensbeheer. En het betekent dat het de software voor gegevensbeheer aanzienlijk onder druk zet. Het is niet langer een eenrichtingsverkeer. Het is tweerichtingsgegevensbeweging. Er is veel meer activiteit gaande, en daarom is schaalbaarheid belangrijk op het vlak van gegevensbeheer en op de gegevensbron.
Dus deze grafiek gaat terug naar die architectuur die ik zojuist heb genoemd. Het toont u de verschillende analytische workloads die in verschillende delen van deze architectuur worden uitgevoerd. Zoiets onderaan links, je hebt real-time streaming, streamverwerking aan de hand op gegevens die uit, je weet wel, elke vorm van live gegevensopslag komen. We hebben klasseanalyses uitgevoerd op NoSQL-grafische databases. Het kan ook gebeuren op Hadoop. Met bijvoorbeeld het Spark-framework en GraphX hebben we een onderzoeksanalyse en de gegevensraffinaderij waar Robin het over had op Hadoop. We hebben nog steeds traditionele workloads en data warehousing, weet je, power users die statistische en voorspellende modellen bouwen, misschien op datawarehouse-apparatuur. En we proberen nog steeds de toegang tot dit alles te vereenvoudigen om het eindgebruikers gemakkelijk te maken.
Succes rond deze hele opstelling is dus meer dan alleen de analytische kant. Weet je, we kunnen de analytische platforms op zijn plaats zetten, maar als we geen gegevens kunnen vastleggen en opnemen, weet je, hoge snelheid en grote hoeveelheden gegevens, op de schaal, heeft het niet veel zin. Weet je, ik heb niets te analyseren. En dus vereist het succes van big data-analyse operationele systemen om op te schalen. Dat betekent, om nieuwe transacties te kunnen ondersteunen, weet u, pieken. Weet je, alle niet-transactionele gegevens die worden vastgelegd, kunnen nieuwe aankomsttarieven zijn, zeer hoge aankomsttarieven op gegevens met hoge snelheid, zoals sensoren of elke ingest. We moeten in staat zijn om dat allemaal te verzorgen - om dit soort gegevens te kunnen vastleggen en te analyseren. We moeten ook de analyses zelf schalen, de toegang tot gegevens vereenvoudigen die ik al heb genoemd. En bind dat dan vast. Weet je, we moeten in die operationele systemen kunnen verfijnen om het een gesloten lus te geven.
Dus, het opschalen van de operationele kant van het huis om gegevens vast te leggen, weet je, neemt deel aan de wereld van de NoSQL-database. Ik bedoel, hier zie je vijf categorieën NoSQL-database. Deze categorie wordt gemodelleerd als een combinatie van de andere vier hierboven. Over het algemeen, weet u, zijn sleutelwaarden, opgeslagen documenten en kolomfamiliedatabases - de eerste drie daar - die soort worden gebruikt voor de meer soort transactionele en niet-transactionele gegevens.
Sommige van die databases ondersteunen als eigenschappen; sommigen van hen niet. Maar toch, weet u, we zien de introductie ervan om dat soort toepassingen te schalen. En dus zijn we bijvoorbeeld weggegaan van alleen werknemers die transacties op toetsenborden invoeren voor klanten en de massa die nu nieuwe apparaten gebruiken om dat te kunnen doen. We hebben een enorme toename gezien van het aantal transacties dat bedrijven worden aangegaan. En dus moeten we transactionele applicaties opschalen om dat te doen.
In het algemeen kan dat op NewSQL-databases worden gedaan als een relationele database zoals NuoDB en VoltDB die hier worden getoond. Of sommige van de NoSQL-databases die misschien ACID-eigenschappen ondersteunen en die transactieverwerking kunnen garanderen, kunnen in het spel zijn. Dit is ook van toepassing op niet-transactionele gegevens zoals winkelwagengegevens vóór een transactie, weet je, voordat mensen dingen kopen, sensorgegevens, weet je, omdat ik een sensorwaarde verlies tussen honderden miljoenen sensorwaarden. Het is niet erg. Klikken, weet je, in de clickstream-wereld - als ik een klik gebruik, maakt het niets uit.Dus weet u, we hoeven daar niet noodzakelijk ACID-eigenschappen te hebben, en dat is vaak waar NoSQL-databases in het spel komen, het was er - die mogelijkheid om zeer hoge, juiste verwerking op schaal te doen om deze nieuwe soorten gegevens vast te leggen.
Tegelijkertijd willen we dat de analyses worden geschaald. En dus zal het niet langer hacken van de gegevens uit de gegevensopslag naar de analytische platforms omdat de gegevens te groot zijn. Wat we echt willen, is de analyse de andere kant op duwen, omlaag naar het enterprise datawarehouse in Hadoop, in stroomverwerking om de analyse naar de gegevens te kunnen pushen. Alleen omdat iemand zegt dat het in database-analyse of in Hadoop-analyse is, betekent dit niet noodzakelijkerwijs dat de analyse parallel wordt uitgevoerd. En eerlijk gezegd, als je gaat investeren in deze nieuwe, enorm parallelle schaalbare technologieën zoals Hadoop, zoals de datawarehouse-apparaten en wat dan ook, zoals de geclusterde stream-verwerkingsengines, hebben we de analyses nodig om parallel te lopen.
Dus dat is alleen het uitchecken. Weet u, als we analyses hebben om dingen te helpen voorspellen voor klanten, voor operaties, voor risico's, enz., Willen we dat ze parallel worden uitgevoerd, niet alleen op het platform. We willen beide. En dat komt omdat, weet je, technologie net zo goed is als deze nieuwe visuele ontdekkingstools zoals SAS. Het is eigenlijk een van onze sponsors hier.
Een ding wat mensen willen is in ieder geval om die in Hadoop te exploiteren en vervolgens in databaseanalyses. En we willen dat deze parallel worden uitgevoerd om de prestaties te kunnen leveren die nodig zijn op zulke grote datavolumes. Tegelijkertijd proberen we de toegang tot dit alles te vereenvoudigen. En dus staat SQL nu weer op de agenda. Weet je, SQL is - SQL op Hadoop is nu hot. Ik volg het nu in 19 SQL- en Hadoop-initiatieven. Plus, u ziet, we kunnen deze gegevens op een aantal manieren krijgen, zodat we rechtstreeks toegang krijgen tot SQL op Hadoop zelf, we kunnen SQL naar een zoekindex gaan. Op die manier, zoals u weet, sommige van de zoekleveranciers in die ruimte, kunnen we SQL-toegang krijgen tot analytische relationele databases die Excel-tabellen hebben voor Hadoop.
We kunnen nu SQL-toegang krijgen tot een datavirtualisatieserver die zelf kan worden verbonden met een datawarehouse op Hadoop. Ik begin nu zelfs de opkomst van SQL-toegang tot livestreaminggegevens te zien. Dus de SQL-toegang tot dit alles groeit snel. En een deel van de uitdaging is, alleen omdat SQL-toegang op de markt wordt gebracht. De vraag is, kan SQL omgaan met complexe gegevens? En dat is niet noodzakelijkerwijs eenvoudig. Er zijn hier allerlei complicaties, waaronder het feit dat JSON-gegevens kunnen worden genest. We kunnen schemavariantrecords hebben. Het eerste record heeft dus één schema. Het tweede record heeft een ander schema. Deze dingen zijn heel anders dan wat er gebeurt in een relationele wereld.
We moeten dus vragen stellen over wat voor soort gegevens we proberen te analyseren, en wat voor soort analytische kenmerken. Is het, weet u, paneel dat u wilt doen? Is het machine learning? Is het grafiekanalyse? Kun je dat doen vanuit SQL? Weet je, is dat aanroepbaar vanuit SQL? Hoeveel gelijktijdige gebruikers hebben we dit aan het doen? Weet je, we hebben honderden gelijktijdige gebruikers. Is dat mogelijk op complexe gegevens? Weet je, al deze dingen zijn belangrijke vragen. Dus heb ik hier een paar op een rijtje gezet waarvan ik denk dat je ze moet overwegen. Weet je, wat voor bestandsformaten? Over wat voor gegevenstypen hebben we het? Welke analytische functies kunnen we vanuit SQL gebruiken om tot complexe gegevens te komen? En soort van functies lopen parallel. Ik bedoel, ze moeten parallel lopen als we dit kunnen opschalen. En kan ik vandaag gegevens buiten Hadoop gebruiken, weet je, of dat kan niet? En wat zal ik doen met al deze verschillende soorten query-workloads?
En zoals we zullen zien, zijn er, wat ik heb gezien, veel verschillen in de SQL- en Hadoop-distributie. Dit zijn allemaal die ik volg. En trouwens, dat is pure SQL op Hadoop. Dat omvat op dit moment zelfs geen gegevensvirtualisatie. En dus, veel daar en veel ruimte voor consolidatie, wat volgens mij het komende jaar zal gebeuren, ongeveer achttien maanden. Maar het opent ook nog iets, namelijk dat ik potentieel meerdere SQL-engines op dezelfde gegevens in Hadoop kan hebben. En dat is iets wat je in relationeel opzicht niet zou kunnen doen.
Dat betekent natuurlijk dat je dan moet weten, weet je, wat voor soort query-werk ik aan het uitvoeren ben? Moet ik dat in batch uitvoeren op een bepaald SQL-initiatief op Hadoop? Moet ik interactieve queryworkloads uitvoeren via een andere SQL op Hadoop-initiatief, enz., Zodat ik weet met welke ik verbinding moet maken? Idealiter zouden we dat natuurlijk niet moeten doen. We hadden er gewoon een vraag over moeten stellen. Weet je, een aantal optimizer berekent de beste manier om dit te doen. Maar naar mijn mening zijn we er nog niet helemaal.
Maar toch, ook datavirtualisatie, die ik eerder heb genoemd, speelt een zeer belangrijke rol bij het vereenvoudigen van de toegang tot meerdere datastores. En als we nieuwe inzichten over Hadoop creëren, is het zeker aannemelijk dat we ons aansluiten bij die data-to-data en traditionele datawarehouses via bijvoorbeeld datavirtualisatie, zonder de data van Hadoop naar traditionele datawarehouses te verplaatsen. Natuurlijk kunt u dat ook doen. Het is ook aannemelijk als ik gegevens uit traditionele datawarehouses archiveer in Hadoop. Ik kan er nog steeds aan toe komen en het samenvoegen met de dingen in ons datawarehouse voor datavirtualisatie. Ik denk dus dat datavirtualisatie een grote toekomst heeft in deze algemene architectuur en het vereenvoudigen van de toegang tot al deze datastores.
En niet te vergeten dat wanneer we deze nieuwe inzichten creëren, of het nu gaat om relationele of NoSQL-systemen, we die inzichten nog steeds terug willen brengen in onze activiteiten, zodat we de waarde van wat we hebben gevonden kunnen maximaliseren, zodat we kunnen gebruik dat voor effectievere, meer tijdige beslissingen in die omgeving om ons bedrijf te optimaliseren.
Dus wat ik dan zie, is dat we nieuwe gegevensbronnen nodig hebben. We hebben nieuwe platforms op een meer gecompliceerde architectuur, als u dat wilt, om dat aan te pakken. En Hadoop werd heel, heel belangrijk, genoeg voor gegevensvoorbereiding voor onze vloeibare sandboxen, voor archiefquery, archief vanuit datawarehouse, datamanagement zijn vleugels spreidt om verder te gaan dan data warehousing in het beheren van gegevens op al deze platforms, en nieuwe tools om te worden in staat om gegevens in deze omgevingen te analyseren en te benaderen, om schaalbare technologieën te hebben om gegevens beter te kunnen opnemen en de analyses te schalen door ze naar de platforms te duwen om ze meer parallel te maken. En dan, hopelijk, ook om de toegang tot dit alles te vereenvoudigen door de opkomende SQL die over de top komt. Dus het geeft je een idee van waar we naartoe gaan. Dus daarmee ga ik terug naar, denk ik, Eric nu, toch?
Eric: Oké, dat is fantastisch. En mensen, ik moet zeggen, tussen wat je net van Robin en Mike hebt gekregen, is het waarschijnlijk ongeveer net zo uitgebreid en beknopt in overzicht van het hele landschap van kijken als je ergens zult vinden. Laat me doorgaan en eerst George Corugedo in de rij zetten. En daar is het. Laat me dit even nemen. Oké, George, ik sta op het punt je de sleutels te overhandigen en weg te nemen. De vloer is van jou.
George: Geweldig! Heel erg bedankt Eric en bedankt Rob en Mike. Dat was geweldige informatie en veel waar we het mee eens zijn. Dus, terugkomend op de discussie van Robin, want weet je, het is geen toeval dat RedPoint hier is en SAS hier is. Omdat RedPoint ons echt richt op de gegevenskant ervan op het beheer, op de verwerking van de gegevens en de voorbereiding op gebruik in analyses. Laat me dus gewoon door deze twee dia's schuiven. En praat echt over Robin's punt over MDM en hoe belangrijk het is, en hoe nuttig, denk ik - en wij denken - Hadoop in de wereld van MDM en datakwaliteit kan zijn.
Weet je, Robin had het een beetje over, weet je, hoe dit verband houdt met de enterprise datawarehouse-wereld en ik kom - weet je, ik heb een aantal jaren bij Accenture doorgebracht. En wat interessant was, is hoe vaak we naar bedrijven moesten gaan en moesten proberen te achterhalen wat we moesten doen met het datawarehouse dat eigenlijk was verlaten. En veel daarvan gebeurde omdat het datawarehouse-team hun build niet echt afstemde op de zakelijke gebruikers of op de consumenten van de data. Of het duurde gewoon zo lang dat tegen de tijd dat ze het ding hadden gebouwd, het zakelijke gebruik of de zakelijke reden daarvoor was geëvolueerd.
En een van de dingen waarvan ik denk dat ik er zo enthousiast over ben, is het idee om Hadoop te gebruiken voor stamgegevensbeheer, voor gegevenskwaliteit en voor gegevensvoorbereiding, is het feit dat je altijd terug kunt gaan naar de atoomgegevens in een Hadoop data lake of data reservoir, of data repository, of hub, of wat voor buzz-formulier je ook wilt gebruiken. Maar omdat u die atoomgegevens altijd bewaart, hebt u altijd de mogelijkheid om contact op te nemen met de zakelijke gebruikers. Omdat, als analist - omdat ik eigenlijk aan mijn carrière als statisticus ben begonnen - niets is erger dan, weet je, enterprise data warehouses zijn geweldig voor het genereren van rapporten, maar als je echt voorspellende analyses wilt doen, zijn ze echt niet zo handig, want wat je echt wilt, zijn de gedetailleerde gedragsgegevens die op de een of andere manier zijn samengevat en verzameld in het datawarehouse. Dus ik denk dat dat echt een belangrijke functie is, en dat is een ding waarvan ik denk dat ik het niet eens ben met Robin, is dat ik persoonlijk gegevens zo lang mogelijk in het gegevensmeer of de gegevenshub zou achterlaten, want zolang de data is er en het is schoon, je kunt ernaar kijken vanuit de ene richting, een andere richting. U kunt het samenvoegen met andere gegevens. Je hebt altijd die mogelijkheid om erop terug te komen en te herstructureren, en jezelf vervolgens opnieuw in te richten met een bedrijfsonderdeel en de behoefte die dit onderdeel zou kunnen hebben.
Een van de andere interessante dingen hieraan is dat omdat het zo'n krachtig rekenplatform is, veel van die werklast waar we het over hebben gehad, we het allemaal rechtstreeks naar Hadoop zien komen. En terwijl ik denk dat Mike het had over alle verschillende technologieën die er zijn in de wereld van - in dit soort big data-ecosysteem, denken we dat de Hadoop echt het werkpaard is om die grote schaal in computationeel intensieve verwerking te doen die stamgegevens en gegevenskwaliteit vereisen. Want als u het daar kunt doen, weet u, alleen al de pure economie van het verplaatsen van gegevens van uw dure databases naar economische databases, is dit nu echt een groot deel van de opname in grote ondernemingen.
Nu zijn er natuurlijk enkele uitdagingen, toch? Er zijn uitdagingen rond de technologieën. Veel van hen zijn erg onvolwassen. Ik zou zeggen, weet je, ik weet niet hoeveel, maar een aantal van de technologieën die Mike noemde zijn nog steeds op nul-punt-iets releases, toch? Deze technologieën zijn dus erg jong, erg onvolwassen, nog steeds op code gebaseerd. En dat is echt een uitdaging voor ondernemingen. En we richten ons echt op het oplossen van problemen op ondernemingsniveau. En dus denken we dat er een andere manier moet zijn, en dat is wat we voorstellen een andere manier te zijn om een aantal dingen te behandelen bij het gebruik van enkele van deze zeer opkomende technologieën.
En dus, en dan het andere interessante probleem dat eerder is genoemd, namelijk wanneer je gegevens hebt die je vastlegt in een Hadoop-omgeving van welk type dan ook, weet je, het is meestal schema bij lezen in plaats van schema bij schrijven met enkele uitzonderingen. En dat lezen, veel ervan wordt gedaan door statistici. En dus moeten de statistici over hulpmiddelen beschikken waarmee ze de gegevens voor analytische doeleinden goed kunnen structureren, omdat ze uiteindelijk, om gegevens nuttig te maken, in een bepaalde vorm moeten worden gestructureerd om sommige te zien of een vraag te beantwoorden of een bedrijf, een soort bedrijf, creëert bedrijfswaarde.
Dus waar we binnenkomen, is dat we een zeer brede en volwassen EPL-, ELT-datakwaliteitssleutel en beheertoepassing hebben. Het is al vele, vele jaren op de markt. En het heeft alle functionaliteit of een groot deel van de functionaliteit die Robin in die circulaire grafiek heeft vermeld - alles van alleen pure onbewerkte gegevensverzameling in een hele reeks formaten en XML-structuren en wat dan ook, tot de mogelijkheid om alle opruimingen te doen, de voltooiing van de gegevens, de correctie van de gegevens, de geospatiale kernbits van de gegevens. Dat is iets dat tegenwoordig steeds belangrijker wordt met Internet of Things. Weet je, er is geografie verbonden aan veel van wat we doen of veel van die gegevens. En dus, al het parseren, de tokenisatie, de opschoning, de correctie, de opmaak, de structurering, etc., dat alles gebeurt op ons platform.
En dan, en misschien, denken we vooral aan het idee van deduplicatie. Weet je, in de kern, als je kijkt naar een definitie van stamgegevensbeheer, is de kern daarvan deduplicatie. Het kan entiteiten uit verschillende gegevensbronnen identificeren en vervolgens een hoofdrecord voor die entiteit maken. En die entiteit kan een persoon zijn. De entiteit kan bijvoorbeeld een onderdeel van een vliegtuig zijn. De entiteit kan een voedingsmiddel zijn zoals we hebben gedaan voor een van onze klanten in de healthclub. We hebben voor hen een master-voedseldatabase gemaakt. Dus, ongeacht de entiteiten waarmee we werken - en natuurlijk zijn er steeds meer mensen en de proxy's voor hun identiteit, dingen zoals sociale handvatten of accounts, welke apparaten die worden geassocieerd met mensen, sommige dingen zoals auto's en telefoons en wat u zich ook maar kunt voorstellen.
Weet je, we werken samen met een klant die allerlei sensoren in sportkleding stopt. Dus de gegevens komen uit elke richting. En op de een of andere manier is het een weerspiegeling of representatie van de kernentiteit. En in toenemende mate zijn dat mensen en de mogelijkheid om de relaties tussen al deze gegevensbronnen te identificeren en hoe ze zich verhouden tot die kernentiteit, en die kernentiteit vervolgens in de tijd te kunnen volgen, zodat u de veranderingen tussen die entiteit kunt analyseren en begrijpen en al die andere elementen die deel uitmaken van die representaties van die entiteit, bijvoorbeeld een heel kritieke factor voor de langetermijn- en longitudinale analyse van mensen. En dat is echt een van de echt belangrijke voordelen die big data ons kan brengen, is een veel beter begrip van mensen, en op de lange termijn, en begrip voor con en hoe mensen zich gedragen wanneer ze zich gedragen via welke apparaten, enz. .
Dus laat me hier snel doorheen gaan. Eric noemde YARN. Weet je, ik gooi dit even in een seconde, want terwijl YARN - mensen praten over YARN. Ik denk dat er nog steeds veel onwetendheid is over YARN. En niet veel mensen echt - er is nog steeds veel misverstand over YARN. En het feit is dat als uw applicatie op de juiste manier is ontworpen en u het juiste niveau of de juiste parallellisatie in uw applicatie-architectuur heeft, u YARN kunt gebruiken om Hadoop als uw schaalplatform te gebruiken. En dat is precies wat we hebben gedaan.
Weet je, nogmaals, om maar even op enkele definities rond YARN te wijzen. Voor ons heeft YARN ons en onszelf en andere organisaties in staat gesteld om peers te worden van MapReduce en Spark en alle andere tools die er zijn. Maar het feit is dat onze applicaties geoptimaliseerde code rechtstreeks naar YARN naar Hadoop sturen. En er is een heel interessante opmerking die Mike heeft genoemd, omdat, weet je, de vraag over analyse en onze analyse, alleen omdat ze in het cluster zitten, lopen ze echt parallel? U kunt dezelfde vraag stellen over veel van de tools voor gegevenskwaliteit die er zijn.
Het grootste deel van de dag moeten de kwaliteitstools die er zijn, de gegevens verwijderen of ze pushen code in. In veel gevallen wordt het een enkele stroom gegevens die wordt verwerkt vanwege de manier waarop u vergelijk records, soms in datakwaliteitstype activiteiten. En het feit is dat omdat we YARN gebruiken, we echt hebben kunnen profiteren van de parallellisatie.
En alleen om u een snel overzicht te geven, omdat nog een opmerking wordt gemaakt over het belang van het kunnen uitbreiden van traditionele databases, nieuwe databases, enz. Die we implementeren of die we buiten het cluster installeren. En we duwen onze binaries rechtstreeks in de resource manager, YARN. En dat, en dan verdeelt YARN het over de knooppunten in het cluster. En wat dat doet is, is dat YARN - we staan toe dat YARN zijn werk beheert en doet, namelijk uitzoeken waar de gegevens zijn en het werk naar de gegevens, de code naar de gegevens brengen en de gegevens niet verplaatsen. Wanneer je datakwaliteitstools hoort en ze vertellen je dat het beste is om de data uit Hadoop te halen, ren voor je leven, want dat is gewoon niet zoals het is. U wilt het werk meenemen naar de gegevens. En dat is wat YARN eerst doet. Het brengt onze binaire bestanden naar de knooppunten waar de gegevens zich bevinden.
En ook omdat we ons buiten het cluster bevinden, hebben we ook toegang tot alle traditionele en relationele databases, zodat we jobs kunnen hebben die 100% clientserver zijn op een traditionele database, 100% Hadoop of hybride jobs die over Hadoop-clientserver gaan , Oracle, Teradata - wat u ook wilt en allemaal in dezelfde functie, omdat die ene implementatie toegang heeft tot beide kanten van de wereld.
En dan, terugkomend op het hele idee van de wendbaarheid van de tools, ziet u hier, dit is slechts een eenvoudige weergave. En wat we proberen te doen is de wereld vereenvoudigen. En de manier waarop we dat doen, is door een zeer brede set functionaliteit rond HDFS te brengen om het te maken ... En het is niet omdat we proberen alle innovatieve technologieën die er zijn te elimineren. Het is gewoon dat bedrijven stabiliteit nodig hebben, en ze houden niet van op code gebaseerde oplossingen. En dus proberen we ondernemingen een vertrouwde, herhaalbare, consistente applicatieomgeving te geven die hen de mogelijkheid biedt om gegevens op een zeer voorspelbare manier op te bouwen en te verwerken.
Snel, dit is het soort impact dat we krijgen met onze applicatie. U ziet MapReduce versus Pig versus RedPoint - geen regels code in RedPoint. Zes uur ontwikkeling bij MapReduce, drie uur ontwikkeling in Pig en 15 minuten ontwikkeling in RedPoint. En dat is waar we echt een enorme impact hebben. De verwerkingstijd is ook sneller, maar de tijd voor mensen, de tijd voor mensenproductiviteit, is aanzienlijk toegenomen.
En mijn laatste dia hier, ik wil teruggaan naar dit idee, omdat dit onze visie is op het gebruik van een datameer of een datahub, of een dataraffinaderij als het centrale punt van inname. Ben het daar helemaal mee eens. En we zijn momenteel in gesprek met veel van de belangrijkste gegevensfunctionarissen van grote wereldwijde banken, en dit is de architectuur bij uitstek.Gegevensopname van alle bronnen zorgt voor de verwerking van gegevenskwaliteit en master-gegevensbeheer binnen het datameer, en duwt gegevens vervolgens waar het nodig is om applicaties te ondersteunen, BI te ondersteunen, wat dat ook moge zijn. En dan, als u analyses in BI hebt, kunnen ze direct binnen het datameer worden uitgevoerd, waar des te beter, dat meteen kan beginnen. Maar heel veel aan boord met dit idee. Deze topologie hier is er een die is - die we vinden, wint veel aandacht op de markt. En dat is het.
Eric: Oké, goed. Laten we hierheen gaan. Ik ga door en geef het aan Keith. En, Keith, je hebt ongeveer 10, 12 minuten om het huis hier te schommelen. We hebben er een beetje lang over gedaan in deze shows. En we hebben 70 minuten geadverteerd voor deze. Dus, ga je gang en klik ergens op die dia en gebruik de pijl-omlaag en haal hem weg.
Keith: Natuurlijk. Geen probleem, Eric. Ik waardeer dat. Ik ga door en ga slechts een paar stukjes over SAS bespreken, en dan ga ik naar technologiearchitecturen waar SAS de big data-wereld kruist. In al deze dingen valt veel uit te leggen. We kunnen uren gedetailleerd doornemen, maar tien minuten - je zou in staat moeten zijn om weg te lopen met slechts een kort begrip van waar SAS analyse-, gegevensbeheer- en business intelligence-technologieën in deze big data-wereld heeft gebracht.
Allereerst een klein beetje over SAS. Als u niet bekend bent met deze organisatie, doen we de afgelopen 38 jaar geavanceerde analyses, bedrijfsinformatie en gegevensbeheer met niet alleen big data, maar ook kleine data en gegevensrijkdom in de afgelopen 38 jaar. We hebben een enorme bestaande klantenkring, ongeveer 75.000 sites over de hele wereld, die samenwerken met enkele van de beste organisaties die er zijn. Wij zijn een particuliere organisatie met ongeveer 13.000 werknemers en een omzet van $ 3 miljard. En echt, denk ik, het belangrijke deel is dat we van oudsher een lange geschiedenis hebben gehad met het herinvesteren van aanzienlijke hoeveelheden van onze inkomsten terug in onze R & D-organisatie, die echt heeft geleid tot veel van deze verbazingwekkende technologieën en platforms ga vandaag zien.
Dus ik ga meteen in deze echt enge architectuurdiagrammen. We werken van links naar rechts in mijn dia's. Er zijn dus bekende dingen die je op dit platform zult zien. Aan de linkerkant, al die gegevensbronnen waar we het over hebben in deze big data-platforms. En dan heb je dit big data-platform.
Ik heb het woord Hadoop er niet alleen bovenaan geplaatst, want uiteindelijk gaan de voorbeelden die ik vandaag ga geven specifiek over alle technologieën waar we deze big data-platforms kruisen. Hadoop is toevallig een van de landen waar we enkele van de meest robuuste implementatie-opties hebben, maar we kruisen ook nogal wat en hebben al een tijdje veel van deze technologieën ontwikkeld met enkele van onze andere enterprise datawarehouse-partners zoals Teradata, Oracle, Pivotal en dergelijke. Dus ik kan niet ingaan op grote details met betrekking tot alle verschillende technologieën die op welk platform worden ondersteund, maar wees gerust dat alles wat ik vandaag beschrijf, meestal alles is dat Hadoop heeft en een groot aantal ervan kruist met andere technologiepartners die we hebben. Dus we hebben dat grote platform daar zitten.
De volgende rechts, we hebben onze SAS LASR Analytic Server. Nu is dat in wezen een enorm parallel in de geheugenanalysetoepassingsserver. We zouden duidelijk zijn dat het geen database in het geheugen is. Het is echt helemaal opnieuw ontworpen. Het is niet de query-engine, maar ontworpen om analytische aanvragen op een massale schaal op een massaal parallelle manier te bedienen. Dus dat zijn de servicesleuteltoepassingen die u daar aan de rechterkant ziet.
We gaan wat dieper in op, weet je, hoe mensen deze dingen inzetten. Maar in wezen is de applicatie - zie je daar - de eerste, onze krachtige analyse van SAS. Dat zal zijn - ik gebruik veel van onze bestaande technologie en platforms zoals Enterprise Miner of gewoon een SAS, en niet alleen multithreading doen met enkele van die algoritmen die we hebben ingebouwd in die tools die we hebben gedaan voor jaren, maar ook om die massaal parallel te laten lopen. Dus, om de gegevens van dat big data-platform naar de geheugenruimte te verplaatsen naar die LASR Analytic Server, zodat we analytische algoritmen kunnen uitvoeren - weet je, veel van de nieuwe machine learning, neurale netten, willekeurige bosregressies, dat soort dingen - nogmaals, de gegevens zitten in het geheugen. Dus het wegwerken van dat bepaalde knelpunt van het MapReduce-paradigma waar we worden neergelegd bij die platforms, dat is niet de manier waarop u analytisch werk wilt doen. We willen de gegevens dus één keer in de geheugenruimte kunnen opnemen en er duizenden keren doorheen kunnen gaan. Dus dat is het concept van het gebruik van die krachtige analytische LASR-server.
Wij ook - de andere toepassingen eronder, de visuele analyse, waarmee we die gegevens in het geheugen kunnen bewaren en een grotere populatie op dezelfde gegevens kunnen bedienen. Dus, waardoor mensen big data-exploratie kunnen doen. Dus voordat we onze modelontwikkelingswerken doen, onderzoeken we gegevens, begrijpen we deze, voeren we correlaties uit, doen we voorspellingen of doen we beslissingsbomen - dat soort dingen - maar op een zeer visuele, interactieve manier over gegevens die in het geheugen staan platform. Dat bedient ook onze BI-gemeenschap voor zover het heeft een zeer brede basis van gebruikers die dat platform kunnen bereiken om standaard soorten opnames te maken die je zou zien - die vrijwel elke, weet je, BI-verkoper daar.
De volgende stap gaan we vervolgens in gebruik. En om onze statistici en onze analytische mensen te helpen om dat soort ad-hocmodellering te doen met gegevens die in het geheugen zijn opgeslagen, verwijderd uit visuele analyse en verkenning naar onze toepassing voor visuele statistieken. Dit is een kans voor mensen om statistieken uit te voeren in batches die er vroeger doorheen liepen, de modellen uit te voeren, de resultaten te bekijken. Dus, dat kan het model uitvoeren, zie de resultaten. Dit is om visueel te slepen en neer te zetten in interactieve statistische modellering. Dit biedt onze statistici en onze datawetenschappers dus veel van dat vroege verkennende visuele statistiekwerk.
En dan zijn we onze coders niet vergeten - de mensen die echt de tegenovergestelde lagen van de interface willen hebben, zijn toepassingen schrijven en hun eigen codebasis schrijven in SAS. En dat zijn onze in-memory-statistieken voor Hadoop. En dat is de - in wezen de codelaag waarmee we met die Analytic LASR-server konden communiceren om direct opdrachten te geven en die applicaties aan te passen op basis van ons verzoek. Dat is het analytische stuk.
Hoe deze dingen worden opgezet ... Oeps, het spijt me jongens. Daar gaan we.
Dus er zijn echt een paar manieren waarop we dit doen. Eén is om het met big data te doen - in dit geval met Hadoop. En dat is waar we die SAS LASR Analytic Server op een apart cluster van machines hebben die zijn geoptimaliseerd voor hardcore analyse. Dit ligt mooi dicht bij het big data-platform, waardoor we het los van het big data-platform kunnen schalen. Dus we zien mensen dit doen wanneer ze niet willen hebben wat ik karakteriseer als vampiersoftware die weg eet op elk van de knooppunten in hun Hadoop-cluster. En ze schalen niet noodzakelijk dat big data-platform dat geschikt is voor het uitvoeren van zware analyses in het geheugen. Dus je hebt misschien 120 knooppunten van hun Hadoop-cluster, maar ze kunnen 16 knooppunten van analytische servers hebben die zijn ontworpen om dat soort werk te doen.
We mogen nog steeds dat parallellisme van het big data-platform handhaven om de gegevens in het geheugen op te halen. Het is dus echt een SAS met het Hadoop-platform. Een ander afspraakmodel is dan te zeggen dat we dat basisproduct ook kunnen gebruiken en dat kunnen pushen - in wezen de Analytic LASR-server op de Hadoop-platforms uitvoeren. Dus daar zijn we ... u werkt binnen het big data-platform. Dat zijn ook enkele van onze andere verkopers van apparaten. Dat heeft ons dus in staat gesteld dat basisproductplatform in wezen te gebruiken om dat werk te doen.
We zien dat vaker met dingen als hoogwaardige analyse waarbij het een eenmalige of eenmalige analytische run is, meer batchgericht waar u bent - u wilt niet noodzakelijkerwijs de geheugenruimte bij Hadoop verbruiken platform. We zijn erg flexibel in dit soort implementatiemodel, zeker in onze samenwerking met YARN in veel van deze gevallen om ervoor te zorgen dat we leuke clusters spelen.
Oké, dus dat is de analytische wereld, gewoon om duidelijk te zijn met de analytische toepassing. Maar ik heb gezegd dat SAS in het begin ook een platform voor gegevensbeheer is. En er zijn dingen die geschikt zijn om logica waar nodig in dat platform te duwen. Er zijn dus een aantal manieren waarop we dat doen. Een daarvan is in de wereld van data-integratie, het doen van datatransformatie-werk op data is misschien niet logisch om het terug te trekken zoals we eerder hebben gehoord, het uitvoeren van datakwaliteitsroutines die groot zijn. We willen zaken als datakwaliteitsroutines zeker naar dat platform duwen. En dan, dingen als het scoren van modellen. Dus ik heb mijn model ontwikkeld. Ik wil dat ding in MapReduce niet herschrijven en het moeilijk en tijdrovend voor mij maken om dat werk opnieuw te doen naar het native databaseplatform.
Dus als je bijvoorbeeld kijkt naar onze scoreversneller voor Hadoop, waarmee we in wezen een model kunnen nemen en de wiskundige logica van SAS naar dat Hadoop-platform kunnen duwen en het daar kunnen uitvoeren, met behulp van het parallellisme dat zich binnen dat grote dataplatform bevindt. We hebben dan onze codeversneller voor verschillende platforms, waaronder Hadoop, en dat stelt ons in staat om SAS-gegevensstapcode in het platform op een massaal parallelle manier in te voeren - dus, datatransformatie-soorten werk op het platform. En dan onze SAS-datakwaliteitsversneller waarmee we een kwaliteitskennisbank kunnen hebben die dingen kan doen zoals gendermatching, standaardisatie-matchcode - alle verschillende dingen voor datakwaliteit die u vandaag al hebt gehoord.
En dan, laatste stuk, is er de Data Loader. We weten dat onze zakelijke gebruikers niet in staat moeten zijn om code te schrijven, datatransformatiewerk te doen in deze big data-platforms. Data Loader is een mooie WYSIWYG GUI waarmee we die andere technologieën samen kunnen afronden. Het is als een doorloopwizard om bijvoorbeeld een Hive-query uit te voeren of een routine voor gegevenskwaliteit uit te voeren en in dat geval geen code te hoeven schrijven.
Het laatste wat ik zal noemen is dit voorstuk. We hebben - zoals ik al eerder zei - een enorme SAS-voet die er is in de wereld. En dit, we kunnen niet noodzakelijkerwijs al die platforms doen die er zijn om meteen in deze ruimte te zijn. We hebben dus zeker een bestaand aantal gebruikers dat gegevens op deze grote dataplatforms moet plaatsen, zoals gegevens uit Teradata halen en terugplaatsen in Hadoop en vice versa. De modellen uitvoeren Ik weet al hoe ik op mijn SAS-servers moet werken, maar ik moet gegevens ophalen die nu in het Hadoop-platform worden geplaatst. Dus, er is een ander klein pictogram dat "van" wordt genoemd en waarmee we verbinding kunnen maken met behulp van onze SAS-toegangsmotoren - toegangsmotoren tot Hadoop tot Cloudera in Pola, Teradata, tot Greenplum tot ... En de lijst gaat maar door. Dit stelt ons in staat om onze bestaande volwassen SAS-platforms die al aanwezig zijn om gegevens van deze platforms te krijgen, het werk te doen dat we moeten doen, resultaten terug te duwen naar deze gebieden.
Het laatste wat ik zal vermelden is dat al deze technologieën die u ziet, allemaal onder dezelfde standaard gemeenschappelijke metadata vallen. Dus we praten over het laten werken van de transformatie, de datakwaliteitsregel op het werk, het naar het geheugen verplaatsen om te kunnen analyseren, modelontwikkeling in scoren. We hebben daar de hele analytische levensstijl, de levenscyclus wordt bepaald door gemeenschappelijke metadata, door governance, door beveiliging, door alle dingen waar we eerder vandaag over hebben gesproken.
Dus even een samenvatting, er zijn echt die drie grote dingen die je daar weg kunt nemen. Eén is, we kunnen het dataplatform net als elke andere gegevensbron behandelen, van hen trekken, naar hen pushen wanneer het gepast en handig is. We kunnen met die big data-platforms werken en gegevens in een speciaal gebouwde geavanceerde analyse in geheugenplatform opnemen. Dus dat is de LASR-server.
En dan, ten slotte, kunnen we rechtstreeks in die big data-platforms werken en hun distributieve verwerkingsmogelijkheden benutten zonder de gegevens te verplaatsen.
Eric: Nou, dat is fantastisch spul, mensen. Ja, dit is geweldig! Dus laten we meteen ingaan op enkele vragen. We gaan meestal ongeveer 70 minuten of een beetje langer mee aan deze evenementen. Ik zie dus dat we nog steeds een geweldig publiek hebben. George, ik denk dat ik onze eerste vraag aan jou zal overhandigen. Als je het hebt over het pushen van je binaire geluid in Hadoop, denk ik dat het klinkt alsof je de computationele workflow echt hebt geoptimaliseerd. En dat is de hele sleutel om dit soort realtime data governance, datakwaliteitstijlprestaties te kunnen doen, want dat is de waarde die je wilt krijgen, toch? Als je niet terug wilt naar de oude wereld van MDM, waar het erg omslachtig en erg tijdrovend is, en je mensen echt moet dwingen om op bepaalde manieren te handelen, wat bijna nooit werkt. En dus heb je de cyclus van wat was gecondenseerd. Laten we het dagen, weken, soms zelfs maanden tot seconden noemen, toch? Is dat wat er aan de hand is?
George: Dat klopt precies, want de schaal die we krijgen en de prestaties die we uit een cluster halen, is echt onthutsend in termen van, gewoon, weet je, ik ben altijd een beetje aarzelend over benchmarks. Maar alleen voor de orde van grootte, wanneer we een miljard, 1,2 miljard records zouden draaien en een volledige adresstandaardisatie zouden doen - ik zeg mid-range HP-machines - zou je, zoals je weet, acht processormachines nodig hebben, weet je , 2 optredens RAM per kern, weet je, dat zou 20 uur duren. We kunnen dat nu in ongeveer acht minuten doen op een cluster met 12 knooppunten. En dus is de schaal van de verwerking die we nu kunnen doen zo dramatisch anders dat - en het past heel goed bij het idee dat je al deze gegevens tot je beschikking hebt. Het is dus niet zo riskant om de verwerking uit te voeren. Als je het verkeerd hebt gedaan, kun je het opnieuw doen. Je hebt tijd, weet je. Het veranderde echt de schaal hiervan, weet je, dat dit soort risico's echt echte bedrijfsproblemen werden voor mensen toen ze probeerden MDM-oplossingen te bedienen. Je moet 30 mensen offshore hebben die data governance en alles doen. En dus moet je daar nog wat van hebben, maar de snelheid en de schaal waarmee je het nu kunt verwerken, geeft je echt veel meer ademruimte.
Eric: Ja, dat is een heel, heel goed punt. Ik ben dol op die opmerking. Dus je hebt de tijd om het opnieuw te doen. Dat is fantastisch.
George: Ja.
Eric: Nou, het verandert de dynamiek, toch? Het verandert hoe je denkt over wat je gaat proberen. Ik bedoel, ik herinner me dit 18 jaar geleden in de industrie van het doen van speciale effecten, omdat ik een klant had die in die ruimte was. En je zou op de knoppen drukken om het weer te geven en je zou naar huis gaan. En je zou terugkomen, misschien op zaterdagmiddag, om te zien hoe het ging. Maar als je het fout had, was dat heel, heel, heel pijnlijk. En nu is het lang niet zo dicht bij dat het pijnlijk is, dus je hebt de mogelijkheid om meer dingen te proberen. Ik moet zeggen, ik denk dat dat een heel, heel goed punt is.
George: Dat klopt precies. Ja, en je blaast je extra been. Weet je, je bent halverwege een taak in de oude dagen en het mislukt, je hebt je SOS opgeblazen. Dat is het.
Eric: Juist. En je zit in grote problemen, ja. Dat klopt.
George: Dat klopt. Dat klopt.
Eric: Keith, laat me er een naar je overgooien. Ik herinner me dat ik een interview heb gedaan met je CIL, Keith Collins, denk ik, misschien terug in, denk ik, 2011. En hij sprak veel over de richting die SAS specifiek insloeg met betrekking tot het samenwerken met klanten om de analyses afgeleid van SAS in operationele systemen te integreren. En natuurlijk hoorden we Mike Ferguson praten over het belang van herinneren. Het hele idee hier is dat je dit soort dingen aan je activiteiten wilt kunnen koppelen. U wilt geen analyse in een vacuüm, losgekoppeld van de onderneming. Dat is geen enkele waarde.
Als u een analyse wilt die rechtstreeks van invloed kan zijn op de activiteiten en deze kan optimaliseren. En als ik terugkijk - en ik moet zeggen dat ik het toen een goed idee vond - lijkt het achteraf een heel, heel slim idee. En ik gok, dat is een echt voordeel dat jullie hebben. En natuurlijk, deze geweldige erfenis, deze enorme installatiebasis, en het feit dat je je hebt gericht op het inbedden van deze analyses in operationele systemen, wat betekent dat het nu - en toegegeven, gaat werken - ik weet zeker dat je ' heb er behoorlijk hard aan gewerkt. Maar nu kunt u al deze nieuwe innovaties benutten en bent u er echt op uit om al die dingen met uw klanten te operationaliseren. Is dat een eerlijke beoordeling?
Keith: Ja, absoluut. Het concept is, je krijgt dit idee van beslissingsontwerp of beslissingswetenschappen, dat weet je, tot op zekere hoogte, dat is een verkennend, wetenschappelijk soort zaak. Tenzij je het proces echt kunt ontwikkelen om ... Als je overweegt een auto te ontwikkelen, heb je ontwerpers die deze prachtige auto maken, maar het is pas als ingenieurs dat plan hebben opgesteld en een echt levensvatbaar product voor je hebben gemaakt kan dingen op zijn plaats zetten, en dat is in wezen wat SAS heeft gedaan. Het heeft de beslissingen samengevoegd - het besluitvormingsproces met het besluitvormingsproces samengevoegd, zodat wanneer je het hebt over de versnellers, de scoreversnellers specifiek, weet je, als je een model neemt dat je hebt ontwikkeld en in staat bent om het eruit te duwen naar Teradata, of push het naar Oracle of Hadoop, zonder downtime voor modelontwikkeling, naar modelimplementatie. Dat is belangrijk, omdat modellen na verloop van tijd verslechteren, de nauwkeurigheid van die modellen. Dus, hoe langer het duurt voordat je dat neemt en in productie neemt, dat is modelverliesverlies.
En dan, het andere is, dat u dat proces in de loop van de tijd wilt kunnen volgen en beheren. U wilt modellen afschaffen als ze oud en onnauwkeurig worden. U wilt ernaar kijken, de nauwkeurigheid ervan na verloop van tijd controleren en opnieuw opbouwen. En dus hebben we ook modelbeheertools die daar bovenop zitten, die echt de metadata rond het gemodelleerde proces volgen. En mensen hebben gezegd dat modellering, weet je, dat soort concept is als een modelfabriek, of hoe je het ook wilt noemen. Het ding is, het zet metadata en beheer in proces en dat is waar de drie grote dingen die we raken - we helpen mensen om geld te verdienen, geld te besparen en ze uit de gevangenis te houden.
Eric: Die laatste is ook behoorlijk groot. Ik wil dat allemaal vermijden. Laten we het hebben over ...Ik geef nog een laatste vraag, misschien kunnen jullie hier allebei op springen. De heterogeniteit van onze wereld zal alleen maar toenemen, lijkt mij. Ik denk dat we zeker wat kristallisatie gaan zien rondom hybride cloudomgevingen. Maar toch zul je veel grote spelers zien rondhangen. IBM gaat nergens heen. Oracle gaat nergens heen. SAP gaat nergens heen. En er zijn zoveel andere leveranciers die bij dit spel betrokken zijn.
Aan de operationele kant, waar je letterlijk duizenden en duizenden verschillende soorten applicaties hebt. En ik hoorde - de meesten van jullie praten hierover, maar ik denk dat jullie het beiden eens zouden zijn met wat ik zei. We hebben deze trend nu gezien in termen van alleen rekenkracht in analytische motoren, architectuur. Bedrijven praten al jaren over de mogelijkheid om andere motoren aan te boren en een soort orkestratiepunt te bedienen. En ik neem aan, George, ik zal het je eerst geven. Het lijkt mij dat dit niet gaat veranderen. We hebben deze heterogene omgeving, wat betekent dat er dingen zijn zoals realtime CRM en gegevenskwaliteit en gegevensbeheer. U moet als verkoper communiceren met al die verschillende tools. En dat is wat de klanten willen. Ze zullen niet iets willen dat het goed doet met deze tools en niet zo goed met die tools. Ze willen het Zwitserland van MDM en CRM, toch?
George: Dat klopt. En het is interessant, omdat we dat heel erg hebben omarmd. Een deel ervan is de geschiedenis die we in de ruimte hadden. En uiteraard werkten we al aan alle andere databases, de Teradatas en de stukjes van de wereld. En vervolgens maakte u - in het implementatieproces, specifiek de manier waarop we het deden, alleen zodat het - die overspanning heeft voor al deze verschillende databases. Een van de dingen die ik interessant vind, is dat we sommige clients hebben die er gewoon op uit zijn alle relationele databases te verwijderen. En dat is interessant. Weet je, ik bedoel, het is goed. Het is interessant. Maar ik zie het gewoon niet op grote schaal gebeuren. Ik zie het al lang niet meer gebeuren. Ik denk dus dat hybride hier al heel lang is en aan de andere kant van onze applicatie waar we ons berichtenplatform hebben in ons campagnebeheerplatform. We hebben het eigenlijk specifiek ontworpen. Nu hebben we een versie uitgebracht die dat doet en die nu verbinding kan maken met de hybride gegevensomgeving en Hadoop, of elke database, elke analytische database kan opvragen. Dus ik denk dat dat gewoon de golf van de toekomst is. En ik ben het ermee eens dat virtualisatie hier zeker een grote rol in zal spelen, maar we gaan gewoon - we gaan rechtstreeks naar de gegevens van al onze applicaties.
Eric: Oké, geweldig. En, Keith, ik geef het aan jou. Wat vind je van de heterogene wereld waarmee we worden geconfronteerd als een soort voet?
Keith: Ja, het is echt fascinerend. Ik denk dat wat we meer vinden - niet alleen op het gebied van gegevensbeheer - maar wat nu echt fascinerend is, het open-source karakter van de analysebasis is. We zien dus organisaties zoals, of technologieën zoals Spark aan boord komen, en mensen die Python en R gebruiken en al deze andere open-source technologieën. Ik denk dat het tot op zekere hoogte als een soort conflict of een bedreiging kan worden geïnterpreteerd. Maar de realiteit is dat we echt geweldige complimenten hebben met al die open-source technologieën. Ik bedoel, ten eerste, we werken in godsnaam op open-source platforms.
Maar ook, zoals het kunnen integreren van bijvoorbeeld een R-model in een SAS-paradigma, stelt u in staat om het beste van beide werelden te gebruiken, toch? Zoals, dus we weten dat sommige van de experimentele dingen in de academische wereld en een deel van het modelontwikkelingswerk buitengewoon en super behulpzaam zijn in het modelontwikkelingsproces. Maar ook, als je dat zou kunnen combineren met een soort productietool, doet het veel van de opschoning en kwaliteit en controleert en zorgt ervoor dat de gegevens die aan het model toegeven, het goed is voorbereid, zodat het niet faalt bij uitvoering. En dan dingen als champion challenger-modellen met open-source modellen te kunnen doen. Dat zijn de dingen die we willen inschakelen, en als onderdeel van dit echt heterogene ecosysteem van al deze technologieën. Ja, dus het is meer - voor ons gaat het meer om het omarmen van die technologieën en het zoeken naar complimenten.
Eric: Nou, dit zijn fantastische dingen geweest, mensen. We zijn hier een beetje lang gebleven, maar we willen graag zoveel mogelijk vragen beantwoorden. We zullen het Q & A-bestand vandaag aan onze presentatoren doorsturen. Dus als een vraag die u stelde niet werd beantwoord, zullen we ervoor zorgen dat deze wordt beantwoord. En mensen, dit maakt het af voor 2014. Met vriendelijke groeten bij DM Radio morgen en volgende week, en dan is het allemaal klaar en is het een vakantie.
Heel erg bedankt voor jullie tijd en aandacht, voor het doornemen van al deze prachtige webcasts. We hebben een geweldig jaar voor 2015. En we zullen snel met je praten, mensen. Nogmaals bedankt. Nou, pas goed op jezelf. Tot ziens.