Innehåll
Källa: Jakub Jirsak / Dreamstime.com
Hämtmat:
Värd Eric Kavanagh diskuterar big data-analys med branschexperter.
Eric: Mina damer och herrar, det är slutet på året 2014 - åtminstone nästan. Det är vår sista webcast på året, folkens! Välkommen till TechWise! Ja verkligen! Jag heter Eric Kavanagh. Jag kommer att vara din moderator för en fantastisk webcast, folkens. Jag är verkligen väldigt upphetsad. Vi har två fantastiska analytiker på nätet och två fantastiska företag - verkliga innovatörer i hela detta Big Data-ekosystem. Och vi kommer att prata allt om nyckeln till big data-analys är att förstå skillnaden. Så låt oss gå vidare och dyka direkt in, folk.
Vi har flera presentatörer. Som du kan se finns det verkligen ditt i toppen. Mike Ferguson ringer hela vägen från Storbritannien, där han var tvungen att få speciella privilegier att stanna i sin kontorsbyggnad så sent. Det är så sent det är för honom. Vi har Dr. Robin Bloor, vår helt egna Chief Analyst här på Bloor Group. Och vi kommer att ha George Corugedo, VD och medgrundare av RedPoint Global, och Keith Renison, Senior Solutions Architect från SAS Institute. Det här är fantastiska företag, folkens. Det här är företag som verkligen är innovativa. Och vi kommer att gräva in några av de bra sakerna av det som händer ute just nu i hela världen av big data. Och låt oss inse det, de små uppgifterna har inte försvunnit. Och till det, låt mig ge min verkställande sammanfattning här.
Så det finns ett gammalt franska uttryck: "Ju fler saker förändras, desto mer förblir de samma." Och låt oss möta några fakta här - big data kommer inte att lösa problemen med små data. Företags små data finns fortfarande ute. Det är fortfarande överallt. Det är bränslet i verksamheten för dagens informationsekonomi. Och big data erbjuder en komplimang till dessa så kallade små företagsdata, men det ersätter inte små data. Det kommer fortfarande att vara kvar. Jag gillar mycket saker om big data, särskilt saker som maskingenererade data.
Och idag pratar vi förmodligen lite om data från sociala medier, som också är mycket kraftfulla grejer. Och om du tänker på till exempel hur socialt har förändrat affärer, tänk bara på tre snabba webbplatser här:, LinkedIn och. Tänk på det faktum att för fem år sedan var det ingen som gjorde den typen av saker. är en absolut juggernaut dessa dagar. , naturligtvis, är enormt. Det är gargantuan. Och sedan är LinkedIn de facto-standarden för företagsnätverk och kommunikation. Dessa webbplatser är humongösa, och för att kunna utnyttja de data som finns i dem kommer det att återuppliva en viss speländringsfunktion. Det kommer verkligen att göra mycket bra för många organisationer - åtminstone de som drar nytta av det.
Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
Du kan inte förbättra dina programmeringsfärdigheter när ingen bryr sig om mjukvarukvalitet.
Så styrning - styrning är fortfarande viktig. Återigen upphäver inte big data behovet av styrning. Helt uppriktigt sagt finns det ett helt nytt behov att fokusera på hur man ska styra big data-världen. Hur ser du till att du har dina rutiner och policyer på plats; att rätt personer får tillgång till rätt data; att du har kontakter, har du anknytning här? Du vet faktiskt var data kommer från, vad som har hänt med dem. Och det förändras allt.
Jag är uppriktigt riktigt imponerad av något av det jag har sett där ute i denna helt nya värld som utnyttjar Hadoop-ekosystemet, vilket naturligtvis är mycket mer än lagring när det gäller funktionalitet. Hadoop är också en beräkningsmotor. Och företaget måste ta reda på hur man utnyttjar den beräknade kraften, den parallella processfunktionen. De kommer att göra riktigt, riktigt coola saker. Vi får lära oss om det idag.
Det andra att nämna, detta är något som Dr Bloor har pratat om det senaste tiden, är att innovationsvågen inte är över. Så vi har naturligtvis sett en hel del uppmärksamhet kring Hadoop. Vi har sett företag som Cloudera och Hortonworks, du vet, verkligen gör några vågor. Och de utvecklar partnerskap med, ja, företag som ringer idag, helt uppriktigt. Och de utvecklar partnerskap med många människor. Men innovationsvågen är inte över. Det finns fler projekt som snurrar ut från Apache Foundation som inte bara ändrar slutpunkten, om du vill - applikationerna som människor använder - utan själva infrastrukturen.
Så hela denna utveckling av YARN - ännu en resursförhandlare - är verkligen som ett operativsystem för big data. Och det är en stor, stor sak. Så vi ska lära oss hur det förändrar också saker. Så, bara ett par uppenbara råd här, var försiktig med långa kontrakt framöver, du vet, fem-, tioårskontrakt kommer att bli vågen, den väg som verkar för mig. Du kommer att vilja undvika låsning till varje pris. Vi kommer att lära oss om allt detta idag.
Så vår första analytiker som talar idag - vår första talare för hela programmet är Mike Ferguson, som ringer in från Storbritannien. Med det kommer jag att lämna nycklarna, Mike, och låta dig ta bort det. Mike Ferguson, golvet är ditt.
Mike, du där? Du kanske är på stum. Jag hör inte honom. Vi kan behöva ringa honom tillbaka. Och vi hoppar bara upp till Robin Bloors slides. Robin, jag tänker få fattiga Mike Ferguson här. Jag ska gå en sekund.
Är det du, Mike? Kan du höra oss? Nah. Jag tror att vi måste gå vidare och gå med Robin först. Så håll en sekund, folkens. Jag tar några länkar till bilderna här om några minuter också. Så med det, låt mig överlämna nycklarna till Robin Bloor. Robin, du kan gå först istället för Mike, så ringer jag Mike om en sekund.
Robin: Okej.
Eric: Håll fast, Rob. Låt mig gå vidare och få din bild här, Rob. Det kommer att ta en sekund.
Robin: Okej.
Eric: Ja. Du kan dock prata om vad vi har att göra med här, vad gäller styrning. Jag vet att du kommer att prata om styrning. Det är vanligtvis tänkt på när det gäller små företagsdata. Så nu har jag tagit upp bilden, Robin. Flytta inte någonting. Och här går du. Golvet är ditt. Ta bort det.
Robin: Okej. Ja. Jag menar, vi ordnade i förväg, Mike skulle prata om den analytiska sidan och jag kommer att prata om styrningssidan. I viss mån följer styrningen analysen i en mening att det är en anledning till att du gör big data-grejer, och anledningen till att du monterar all mjukvara för att göra analysen är, det är där värdet är.
Det finns ett problem. Och frågan är att, du vet, uppgifterna måste kränkas. Uppgifterna måste marscheras. Uppgifterna måste sammanföras och hanteras på ett sätt som gör det möjligt för analysen att ske med fullt förtroende - jag antar att det är ordet. Så jag trodde att jag skulle prata om var regeringssidan av ekvationen. Jag antar att saken att säga, verkligen, är att, du vet, styrning redan var en fråga. Styrning var redan en fråga, och det börjar bli en fråga i hela datalagerets spel.
Det som faktiskt har hänt är att det har förvandlats till en mycket större fråga. Och anledningen till att det har förvandlats till en mycket större fråga liksom mer data, men jag menar, det här är orsakerna, verkligen. Antalet datakällor har expanderat dramatiskt. Tidigare definierades de datakällor vi har i stort sett av vad som gett datalageret. Datavaruhuset skulle normalt matas av RTP-system. Det är möjligt lite extern data, inte mycket.
Nu har vi gått till en värld där, du vet, en datamarknad kommer att existera just nu, och därför kommer det att handlas med data. Du har redan fått massor av olika strömningskällor för data som du faktiskt kan ta med till organisationen. Vi har uppgifter om sociala medier som har tagit dem, tagits av för eget konto, så att säga. Jag menar, mycket fruktansvärt av, värdet på sociala mediesidor är faktiskt den information de samlar in och därför kan göra tillgängliga för människor.
Vi har också upptäckt att du vet att det redan har existerat. Vi hade redan dessa loggfiler, du vet, i tillkomsten av Splunk. Och snart blev det uppenbart att det finns värde i en loggfil. Så det fanns data inom organisationen som var - som vi kunde kalla nya datakällor såväl som externa källor. Så det är en sak. Och det betyder verkligen att, du vet, vilka regler för hantering av data vi hade på plats tidigare, de kommer att behöva, på ett eller annat sätt utvidgas, och kommer att fortsätta att behöva utvidgas för att faktiskt styra data. Men vi börjar nu samlas på ett eller annat sätt.
Och genom att gå ner i den här listan har vi streaming och hastigheten på datorns ankomst. En av, tror jag, orsakerna till populariteten hos Hadoop är att det kan ganska mycket användas för att fånga mycket data. Det kan också ta in datahastighet, att om du inte faktiskt behöver använda den omedelbart är det en trevlig parallell enorm enorm parallellmiljö. Men du har också fått det faktum att det finns en hel del strömningsanalyser som pågår nu. Det brukade bara vara banksektorerna som var intresserade av strömmande applikationer, men nu har det gått typ av globalt. Och alla tittar på streaming-applikationer på ett eller annat sätt eller så, ett potentiellt sätt att hämta värde från data och göra analyser för organisationen.
Vi har ostrukturerade data. Statistiken, vanligtvis en del av de bara 10% av världens data, var i relationsdatabaser. Nu, en av de viktigaste orsakerna till detta var mestadels att den faktiskt var ostrukturerad, och det var - en hel del av det fanns där ute på webben, men ganska mycket strödda om olika webbplatser. Dessa uppgifter har visat sig vara analyserbara, även användbara. Och med tillkomsten av Symantec-tekniken som gradvis kryper in i situationen, blir det mer och mer.Så det finns ett behov av att faktiskt samla in och hantera ostrukturerad data, och det betyder att det är mycket större än vad som var tidigare. Vi har sociala uppgifter som jag redan nämnde, men poängen med det, huvudpoängen med det, är att det troligen behöver rengöras.
Vi har uppgifter om Internet of Things. Det är en sorts situation. Det kommer sannolikt att finnas så mycket av det, men mycket av det kommer att behöva stanna distribuerat någonstans nära det ställe den driver. Men du kommer också att vilja på ett eller annat sätt dra in det för att göra analyser inom organisationen på data. Så det har lagt till ytterligare en faktor. Och att data kommer att struktureras på olika sätt, eftersom de förmodligen kommer - de kommer förmodligen att formateras i JSON eller i XML, så att de förklarar sig själv. Och inte bara, på ett eller annat sätt, att vi faktiskt drar in data och kan göra ett slags schema när du läser på den specifika datadelen.
Vi har frågan om härkomst, och detta är en analytisk fråga. Resultaten i någon analys som du gör data kan verkligen inte - om du vill - godkännas av, anses vara giltiga, såvida du inte vet datorns ursprung. Jag menar, det är bara professionalism när det gäller datavetenskaparnas aktivitet. Men du vet, för att få uppkomst av data, betyder det att vi faktiskt måste styra data och hålla en not till dess släkt.
Vi har frågan om datorkraft och paralleller och vad allt som gör är att allt går snabbare. Problemet är att naturligtvis vissa processer som vi har på plats kan vara för långsamma för allt annat. Så det finns möjligen missförhållanden vad gäller hastighet.
Vi har kommit till maskininlärning. Maskininlärningen har verkligen att göra analyser till ett annat spel än det var tidigare. Men du kan bara använda det verkligen om du har makten.
Vi har fått nya faktiska belastningar. Vi har en parallellvärld och några analytiska algoritmer måste köras parallellt för maximal effekt. Och därför är problemet faktiskt att reglera hur du faktiskt, på ett eller annat sätt, skjuter upp data, gör informationen om de är tillgängliga. Och där du faktiskt utför de analytiska arbetsbelastningarna, eftersom du kanske gör det i databasen. Så du kanske gör det inom analytiska applikationer.
Så det finns en hel serie styrutmaningar. Vad vi gjorde i år - den forskning vi gjorde i år handlade verkligen om big data-arkitektur. Och när vi faktiskt försöker generalisera det såg slutsatsen att vi kom till - diagrammet som vi kom med så mycket ut.
Jag tänker inte gå in på detta, särskilt eftersom Mike kommer att göra en hel del på dataarkitektur för analys. Men vad jag faktiskt vill att människor bara ska fokusera på är det här nedre området där vi på ett eller annat sätt samlar in data. Vi har något som jag vill hänvisa till är datafraffinaderiet eller databehandlingsnavet. Och det är där styrningen äger rum. Så, du vet, om vi är i fokus så ser det ut så. Du vet att den matas av data från interna och externa källor. Navet bör i teorin ta all information som genereras. Det bör antingen strömmas och hanteras som det strömmas om du behöver göra analyser och strömningsdata och sedan skickas till navet. Annars kommer allt in i navet. Och det finns ett antal saker som pågår - som pågår i navet. Och du kan inte ha en viss mängd analys och SQL på gång i navet. Men du har också behovet av datavirtualisering i varje cell för att driva data till andra områden. Men innan något av detta händer, behöver du faktiskt på ett eller annat sätt göra förädlingen av dataförberedelsen. Du kan kalla det förberedelse för data. Det är mycket större än så. Det här är de saker som jag tror att det inkluderar.
Vi har systemhantering och serviceledning, på ett sätt att detta är den största delen av dataskiktet, då måste vi faktiskt tillämpa alla system som hanterar operativa systemhanteringsinsatser som vi traditionellt har gjort för nästan alla operativa system. Men vi behöver också, på ett eller annat sätt, övervaka andra saker som händer för att se till att dessa olika servicenivåer uppfylls, för det finns säkert definierade servicenivåer eller någon form av analys som som handlingar, eller BI-data är att agera.
Vi behöver övervakning och hantering av prestanda. Om något annat behöver vi det för att veta vilka ytterligare datorresurser vi kan behöva tilldela vid olika tidpunkter. Men också är väldigt mycket av arbetsbelastningen här faktiskt ganska komplex och konkurrerar med varandra om resurser. Det finns något ganska sofistikerat som måste göras inom det området.
Vi har nu fått en livscykel på ett sätt som vi aldrig haft det förut. Affären här är verkligen utöver allt annat, att vi inte samlade in data och kastade dem förut. Vi tenderade att samla in data som vi behövde och förvarade förmodligen den, och sedan arkiverar vi den. Men mycket fruktansvärt av det vi kommer att göra härifrån är att utforska data. Och om du inte vill ha data, låt oss begrava dem. Så, livscyklerna för data är olika saker beroende på situationen, men kommer också att vara en väldigt mer sammanfattning av data. Därför vet du, att veta var ett aggregerat kom från vad ... vad källan till aggregering är, och så vidare. Det är allt nödvändigt.
Dataslinjen lånar naturligtvis ut. Utan det måste du veta problemen, så uppgifterna ... Vi måste veta att uppgifterna är giltiga, men med hur tillförlitliga de faktiskt är.
Vi har också datakartläggning, för mycket av datan kommer faktiskt att bli på ett eller annat sätt. Och detta är, om du vill, det hänger i viss utsträckning på MDM. Det är bara att det är mycket mer komplicerat nu, för när du har en väldigt mycket data definierad av JSON eller baserat på vårt XML-schema på läst, då kommer du att behöva på ett eller annat sätt ha mycket aktiva datakortaktivitet pågår.
Det finns en metadatahanteringssituation som är mer än MDM, eftersom det på ett eller annat sätt är nödvändigt att bygga det jag skulle vilja tänka på nu som ett slags metadatavaru av allt du har intresse av. Det finns metadata upptäckt, eftersom en del av uppgifterna inte nödvändigtvis har deklarerade metadata, och vi vill använda dem omedelbart. Och sedan finns det data rensning, vilket är en enorm sak som hur serie saker man kan göra där. Och det finns datasäkerhet också. All denna information måste säkras till en acceptabel nivå, och det kan till och med betyda i vissa fall - till exempel att kryptera en hel del av värdena.
Så all denna arbetsbelastning är faktiskt styringsimperiet. Allt detta på ett eller annat sätt måste pågå samtidigt eller tidigare, all vår analytiska aktivitet. Detta är ett stort antal samordnade applikationer. Det är ett system i sin egen rätt. Och sedan kommer de som inte gör det vid olika tidpunkter att drabbas av brist på det när de går framåt, för mycket av dessa saker är inte riktigt frivilliga. Du slutar bara med att öka entropin om du inte gör dem.
Så när det gäller dataanalys och styrning är det jag säger att den ena handen tvättar den andra. Utan styrning kommer analytics och BI inte att flyta i tid. Och utan analys och BI skulle det inte behövas något reglering av data ändå. Så de två sakerna verkligen går hand i hand. Som de säger i Mellanöstern: "Den ena handen tvättar den andra." Och det är faktiskt allt jag har att säga. Jag hoppas - förhoppningsvis har vi nu fått Mike tillbaka.
Eric: Det gör vi. Mike, jag antar att du är där. Jag kommer att skjuta upp din bild.
Mike: Det är jag. Okej, kan du höra mig?
Eric: Ja, jag kan höra dig. Du låter underbart. Så låt mig presentera ... Där går du. Och du är nu presentatören. Ta bort det.
Mike: Okej, tack! God morgon, god eftermiddag, god kväll till er alla där ute. Förlåt hickan i början. Av någon anledning dämpade jag mig och kan se alla men de kunde inte höra mig.
OK. Så det jag vill göra snabbt är att prata om, vet du, det stora dataanalysiska ekosystemet. Om du vill ställa mig frågor, säger jag, under den här sessionen eller senare, kan du få tag på mig i min kontaktinformation här. Som sagt mitt på natten här i Storbritannien.
Låt mig komma till det jag vill prata om. Det är uppenbart att vi under de senaste åren har sett framväxten av alla typer av nya data som företag nu vill analysera - allt från klickströmdata för att förstå onlinebeteenden, sociala mediedata som Eric talade om vid början av programmet här. Jag tror att Robin nämnde JSON, BSON, XML - så semi-strukturerade data som är självbeskrivande. Naturligtvis har vi en hel massa andra grejer också - allt från ostrukturerad data, IT-infrastrukturloggar, sensordata. Allt detta relativt nya datakällor som företag nu har intresserat sig för eftersom det innehåller värdefull insikt som potentiellt kan fördjupa det vi vet.
Så det innebär i princip att det analytiska landskapet har gått utöver traditionell datalagring. Vi strukturerar fortfarande data in i världen av en kombination av strukturerade och multistrukturerade data, där de multistrukturerade uppgifterna kan komma inifrån eller på utsidan av företaget i många fall. Och som ett resultat av dessa nya datatyper och nya behov att analysera, har vi sett uppkomsten av nya analytiska arbetsbelastningar - allt från att analysera data i rörelse, vilken typ som vänder den traditionella datalagringsarkitekturen på sitt huvud, där vi , i traditionella kretsar, integrera data, rengör den, omvandlade den, lagrade den och analyserade den. Men analyserar data i rörelse, vi fångar in data, integrerar dem, förbereder dem genom att analysera dem och sedan lagra dem. Så det finns en analys på data innan den lagras någonstans.
Vi komplicerar analys av strukturerade data, kanske för modellutveckling, statistisk och prediktiv modellutveckling, det är inget nytt för vissa människor i ett traditionellt datalagerutrymme. Vi har en undersökande analys av data från modellen. Det är mängden strukturerad data där. Vi har fått nya arbetsbelastningar i form av grafanalys som för mina kunder inom finansiella tjänster inkluderar saker som bedrägeri. Det inkluderar också cybersäkerhet. Det inkluderar naturligtvis sociala nätverk, förstå influenser och sådant där. Jag behärskade till och med det i förvaltningen, har några års grafanalys.
Vi har datalageroptimering eller avlastning av ETL-bearbetning, vilket är mer ett slags IT-användningsfall, CIO kan finansiera det. Och till och med arkivering av data och datalager för att hålla dem online i saker som Hadoop. Så alla dessa nya analytiska arbetsbelastningar har lagt till nya plattformar, nya lagringsplattformar, till det analytiska landskapet. Så snarare än att bara ha traditionella datalager, datamark, vad vi nu har är Hadoop. Vi har NoSQL-databaser som grafdatabaser som ofta används för analytiska arbetsbelastningar. Naturligtvis kan vi göra grafanalys nu på Hadoop själv såväl som i ett NoSQL-diagram DBMS. Vi har strömningsanalyser som Robin nämnde. Och vi har - om du vill - att bygga modeller, kanske även på analytiska datalagerapparater. Men allt detta har komplicerat det analytiska landskapet och nu behövs flera plattformar. Och jag antar att utmaningen, för alla företag med ett front office eller back office, eller ekonomi, upphandling, HR och någon typ av verksamhet, är att ta reda på vilka analytiska projekt som är associerade med en traditionell datalagerplats. Och när du väl vet att analytiska projekt är associerade med dessa nya big data-plattformar och var du ska köra, vet du vilken analytisk arbetsbelastning, men inte förlorar synen på affärer i den meningen att det är - du kommer nu att se att det är en kombination av stora dataanalysprojekt och traditionella big data warehousing-projekt som tillsammans behövs för att stärka inne i kunden eller runt verksamheten, kring risk eller finansiering eller hållbarhet. Och därför vill vi att alla dessa anpassas till våra strategiska affärsprioriteringar, att vi håller oss på rätt spår för, du vet, skjuter in nålarna som måste skjutas in, du vet, för att förbättra affärsresultatet, för att minska kostnaderna, för att minska risker osv. vet du för vårt företag som helhet. Så det är inte så att en ersätter den andra här med big data och traditionell. Det används båda tillsammans. Och det förändrar arkitekturen dramatiskt, du vet.
Så det jag har här är en relativt ny arkitektur som jag kommer att använda med mina klienter. Och så, som ni ser nu längst ner, ett stort antal datakällor, inte bara strukturerade längre. Några av dessa strömmar livedata som sensorer, som marknadsdata, den typen. Det kan till och med vara direkta klickströmdata. Det kan vara direktuppspelade videoströmningsdata. Så det behövde inte vara strukturerat. Så vi kan göra strömbearbetning av den datan för att vidta automatiska åtgärder i realtid, och all data av intresse kan filtreras och överföras till ett företag för informationshanteringsverktyg som kan användas för att fylla analytiska datalagrar. Såvida du inte kan se blandningen här, har vi nu traditionella datalager, Hadoop och NoSQL-databaser. Vi har även masterdatahantering i mixen. Och det sätter mer press på hela datahanteringsverktygssatsen, inte bara för att fylla dessa datalagrar utan för att flytta data mellan dem.
Dessutom måste vi förenkla åtkomstverktygen. Vi kan inte bara vända oss till användaren och säga "få alla dessa datalagrar, håll dessa API: er - ditt problem." Det du måste göra är att förenkla åtkomsten. Och så, i de prickade linjerna där, kommer du att se datav virtualisering och optimering dölja typ av komplexitet för flera datalagring, försöka göra det enklare för slutanvändare att komma åt detta. Och naturligtvis finns det en rad verktyg på toppen, du vet - allt från traditionella BI-verktyg som på något sätt har börjat på toppen av datalagring, som gradvis rör sig mot vänster om ditt diagram för att ansluta till Hadoops och sedan NoSQL-databaser i världen.
Vi har sökt för att få ett nytt livslån till särskilt runt kroppsstrukturerade, icke-strukturerade data som ofta lagras i Hadoop. Vi har anpassade analytiska applikationer som kan göras på en Hadoop-plattform med MapReduce, så till exempel Spark-ramverket. Vi har grafiska analysverktyg för att, du vet, fokusera på mycket specifika arbetsbelastningar där. Så ett antal verktyg och dataflödena är också mer komplexa. Det är inte längre bara en envägsgata i datalageret. Det är naturligtvis nu stamdata.
Vi har nya datakällor som kommer in, antingen fångas i NoSQL, du vet, datalagrar som MongoDB, som Cassandra, som HBase. Vi har fått data direkt in i Hadoop för analys och förberedelse av data där. Vi har fått nya insikter från Hadoop och datalagren. Vi har arkiv som kommer från datalagren till Hadoop. Nu har vi datafeeds till, du vet, alla NoSQL-databaser och datamarkeringar också. Så det du kan se här är att det finns mycket mer aktivitet inom datahantering. Och det betyder att det sätter datahanteringsprogramvaran under stort tryck. Det är inte längre bara en enkelriktad gata. Det är tvåvägs datarörelse. Det är mycket mer aktivitet som pågår, och därför är skalbarhet viktig på datahanteringsverktygets front och på datakällan.
Så detta diagram går tillbaka till den arkitekturen jag nämnde för ett ögonblick sedan. Det visar dig de olika analytiska arbetsbelastningarna som körs i olika delar av denna arkitektur. Sorterar du längst ner till vänster där, du har strömning i realtid, strömbehandling pågår på data som kommer ut från, du vet, någon form av live datalager. Vi har klassanalyser på NoSQL-grafidatabaser. Det kan också hända på Hadoop. Med Spark-ramverket, till exempel, och GraphX där, har vi en undersökningsanalys och datafinaderiet som Robin talade om som händer på Hadoop. Vi har traditionella arbetsbelastningar som fortfarande pågår och datalagring, du vet, kraftanvändare som bygger statistiska och förutsägbara modeller, kanske på datalagerapparater. Och vi försöker fortfarande förenkla åtkomsten till allt detta för att göra det enkelt för slutanvändare.
Så framgång kring hela installationen är mer än bara den analytiska sidan. Du vet, vi kan sätta in de analytiska plattformarna, men om vi inte kan fånga upp och intagas av, du vet, hög hastighet och hög volymdata, på skalan, finns det inte mycket poäng. Du vet, jag har inget att analysera. Och så kräver framgång för big data-analys att operativa system ska skalas upp. Det betyder att du kan stötta nya transaktioner, du vet, toppar. Du vet, alla icke-transaktionsdata som fångas där kan vara, du vet, alla nya ankomsthastigheter väldigt, mycket höga ankomsthastigheter på höghastighetsdata som sensorer eller något annat. Vi måste kunna tillgodose allt detta - att kunna fånga den här typen av data och ta med dem för analys. Vi måste också skala själva analysen, förenkla tillgången till data som jag nämnde redan. Och sedan, knyt det. Du måste, vi måste kunna förfina tillbaka till de operativa systemen för att ge det en sluten slinga.
Så, att skala den operativa sidan av huset för att fånga data, du vet, tar in i världen av NoSQL-databasen. Jag menar, här ser du fem kategorier av NoSQL-databasen. Denna kategori kommer att modelleras bara som en kombination av de andra fyra ovan. I allmänhet, du vet, dess nyckelvärden, lagrade dokument och kolumnfamiljedatabaser - de tre första där - som används typ för mer typ av transaktions- och icke-transaktionsdata.
Några av de databaser som stöder som egenskaper; några av dem inte. Men ändå, du vet, vi ser introduktionen av dem för att skala den typen av applikationer. Och så, till exempel, när vi har flyttat bort från bara anställda som skriver in transaktioner på tangentbord till nu kunder och massorna som använder nya enheter för att kunna göra det. Vi har sett en enorm ökning av antalet transaktioner som genomförs i företag. Och så måste vi skala transaktionsapplikationer för att göra det.
Generellt sett kan det göras på NewSQL-databaser som en relationsdatabas som NuoDB och VoltDB som visas här. Eller några av NoSQL-databaserna som kanske stöder ACID-egenskaper som kan garantera transaktionsbehandling kan vara i spel. Detta gäller också för icke-transaktionsdata som data om kundvagn innan en transaktion, du vet, innan människor köper saker, sensordata, du vet, eftersom jag tappar en sensoravläsning bland hundratals miljoner sensoravläsningar. Det är ingen stor grej. Klick, du vet, i klickströmvärlden - om jag använder ett klick, är det ingen större sak.Så du vet, vi behöver inte nödvändigtvis ha ACID-egenskaper där, och det är ofta där NoSQL-databaser spelar in, det var där - den förmågan att göra mycket hög, rätt bearbetning i skala för att fånga dessa nya typer av data.
Samtidigt vill vi att analyserna ska skalas. Och så att dra data från datalagren till analytiska plattformar kommer inte längre att hacka det eftersom uppgifterna är för stora. Det vi verkligen vill är att driva analysen åt andra hållet, ner i företagets datalager till Hadoop, till strömbehandling för att kunna driva analysen till data. Men bara för att någon säger att det finns i databasanalys eller i Hadoop-analys betyder det inte nödvändigtvis att analysen körs parallellt. Och ärligt talat, om du kommer att investera i dessa nya massivt parallella skalbara teknologier som Hadoop, som datalagerapparater och vad som inte, liksom de grupperade strömbearbetningsmotorerna, behöver vi analysen för att köras parallellt.
Så det är bara utcheckningen. Du vet, om vi har analyser för att förutsäga saker för kunder, för operationer, för risker etc. vill vi att de ska köras parallellt, inte bara köras i plattformen. Vi vill ha båda. Och det beror på att du vet att teknik liknar dessa nya verktyg för visuell upptäckt som SAS också. Det är faktiskt en av våra sponsorer här.
En sak vad folk vill är att åtminstone utnyttja dem i Hadoop och sedan i databasanalys. Och vi vill att de ska gå parallellt för att kunna leverera den prestanda som krävs på så höga datavolymer. Samtidigt försöker vi förenkla tillgången till allt detta. Och så är SQL nu tillbaka på dagordningen. Du vet, SQL är - SQL på Hadoop är het just nu. Jag spårar det i 19 SQL- och Hadoop-initiativ just nu. Dessutom kan du se, vi kan få fram den här informationen, du vet, på ett antal sätt så att direkt åtkomst till SQL på Hadoop själv kan vi gå SQL till ett sökindex. På det sättet, som du vet, några av sökleverantörerna i det utrymmet, kan vi ha SQL-åtkomst till analytiska relationella databaser som har Excel-tabeller till Hadoop.
Vi kan nu ha SQL-åtkomst till en datavirtualiseringsserver som själv kan anslutas till ett datalager på Hadoop. Jag börjar till och med nu se uppkomsten av SQL-åtkomst till live streaming-data. Så, SQL-åtkomst till allt detta växer snabbt. Och en del av utmaningen är bara för att SQL-åtkomst marknadsförs där ute. Frågan är, kan SQL hantera komplexa data? Och det är inte nödvändigtvis enkelt. Det finns alla typer av komplikationer här, inklusive det faktum att JSON-data kan kapslas. Vi kan ha scheman variant poster. Så den första posten har ett schema. Den andra posten har ett annat schema. Dessa saker skiljer sig mycket från vad som händer i en relationell värld.
Så vi måste ställa frågor om vilken typ av data det är som vi försöker analysera och vilken typ av analytiska egenskaper. Är det, du vet, panelen som du vill göra? Är det maskininlärning? Är det grafanalys? Kan du göra det från SQL? Vet du, är det okallabart från SQL? Hur många samtidiga användare har vi gjort detta? Du vet, vi har hundratals samtidiga användare. Är det möjligt med komplexa data? Du vet, alla dessa saker är viktiga frågor. Så jag har gjort en lista över några här som jag tycker att du borde överväga. Du vet, vilken typ av filformat? Vilken typ av datatyper pratar vi om? Vilken typ av analytiska funktioner kan vi påkalla från SQL för att få komplexa data? Och typ av funktioner körs parallellt. Jag menar, de måste springa parallellt om vi måste kunna skala detta. Och kan jag gå med data i Hadoop idag utanför det, vet du, eller är det inte möjligt? Och vad ska jag göra med alla dessa olika typer av frågeställningar?
Och som vi ser, vet du, från vad jag har sett, det finns många skillnader mellan SQL och Hadoop-distributionen. Det här är alla jag spårar. Och förresten, det är ren SQL på Hadoop. Det inkluderar inte ens datavirtualisering vid denna punkt. Och så, mycket där ute och mycket utrymme för konsolidering, vilket jag tror kommer att hända under nästa år, arton månader eller så. Men det öppnar också en annan sak, som är att jag kan ha flera SQL-motorer på samma data i Hadoop. Och det är något du inte kunde göra i relation.
Naturligtvis betyder det att du måste veta, du vet, vilken typ av fråga arbetsbelastning kör jag? Ska jag köra det i batch på en viss SQL på Hadoop-initiativ? Ska jag köra interaktiva fråga-arbetsbelastningar via ett annat SQL på Hadoop-initiativ, etc., så att jag vet till vilken jag ska ansluta till? Helst bör vi naturligtvis inte göra det. Vi borde bara, du vet, ställa en fråga om det. Vet du, vissa optimisatorer räknar ut det bästa sättet att göra det. Men vi är inte helt där ännu, enligt min mening.
Men ändå också, datav virtualisering, nämnde jag tidigare, har en mycket viktig roll för att förenkla åtkomsten till flera datalagrar. Och om vi skapar ny insikt om Hadoop, är det säkert troligt att vi går med i dessa data-till-data och traditionella datalager genom datavirtualisering, till exempel utan att nödvändigtvis flytta data från Hadoop till traditionella datalager. Naturligtvis kan du göra det också. Det är också troligt om jag arkiverar data från traditionella datalager till Hadoop. Jag kan fortfarande komma åt det och gå tillbaka till det som finns i vårt datalager till datavirtualisering. Så för mig tror jag datavirtualisering har en stor framtid i denna övergripande arkitektur och förenklar tillgången till alla dessa datalagrar.
Och inte att glömma att när vi skapar dessa nya insikter, oavsett om det är i relation eller NoSQL-system, vi fortfarande vill driva tillbaka dessa insikter i våra verksamheter, så att vi kan maximera värdet på det vi har hittat, så att vi kan utnyttja det för mer effektiva och snabbare beslut i den miljön för att optimera vår verksamhet.
Så för att samla in det, vad jag ser, är det att vi behöver, du vet, nya datakällor dyker upp. Vi har fått nya plattformar för en mer komplicerad arkitektur, om du vill, för att hantera det. Och Hadoop blev väldigt, väldigt viktigt, tillräckligt för dataförberedelser för våra flytande sandlådor, för arkivfråga, arkiv från datalager, datahantering som sprider sina vingar för att gå utöver datalager till att hantera data över alla dessa plattformar och nya verktyg kunna analysera och få tillgång till data i dessa miljöer, kunna ha skalbar teknik för att göra bättre intag av data och skala analysen genom att trycka ner dem i plattformarna för att göra dem mer parallella. Och förhoppningsvis också för att förenkla tillgången till det hela genom den framväxande SQL som kommer in över toppen. Så det ger dig en uppfattning om vart vi är på väg. Så med det kommer jag att gå tillbaka till, antar jag, Eric nu, är det?
Eric: Okej, det är fantastiskt. Och folkens, jag måste säga, mellan vad du just har fått från Robin och Mike, det är förmodligen ungefär lika omfattande och kortfattat i översikt över hela landskapet från att titta på som du kommer att hitta någonstans. Låt mig gå vidare och köa George Corugedo först. Och där är det. Låt mig ta detta en kort sekund. Okej, George, jag håller på att lämna nycklarna till dig och ta bort dem. Golvet är ditt.
George: Fantastiskt! Tack så mycket, Eric, och tack, Rob och Mike. Det var bra information och mycket som vi instämmer i. Så, tillbaka till Robin's diskussion, för, du vet, det är inte en slump att RedPoint är här och SAS är här. Eftersom RedPoint fokuserar vi verkligen på datasidan av det på styrningen, på behandlingen av uppgifterna och förberedelserna för användning i analys. Så låt mig bara pramma igenom dessa två bilder. Och verkligen prata om och plocka upp på Robins punkt om MDM och hur viktigt det är och hur användbart, tror jag - och vi tror - Hadoop kan vara i världen av MDM och datakvalitet.
Du vet, Robin pratade lite om, du vet hur det är relaterat till företagets datalagervärld och jag kommer - du vet, jag har tillbringat ett antal år på Accenture. Och det som var intressant där är hur många gånger vi var tvungna att gå in i företag och försöka ta reda på vad vi skulle göra med datalageret som i princip hade övergivits. Och mycket av det hände för att datalagerteamet inte riktigt anpassade sin byggnad till företagets användare eller konsumenterna av uppgifterna. Eller så tog det bara så darn lång tid att när de har byggt saken, affärsanvändningen eller affärsrationalen för det hade utvecklats.
Och en av de saker som jag tror är, jag är så upphetsad över, idén att använda Hadoop för masterdatahantering, för datakvalitet och för att förbereda data, är det faktum att du alltid kan gå tillbaka till atomdata i en Hadoop-datasjön eller datareservoar, eller datalagring, eller nav, eller vad som helst surrformen du vill använda. Men eftersom du alltid behåller den atombaserade informationen, har du alltid en möjlighet att anpassa sig till företagets användare. För som analytiker - för att jag faktiskt började min karriär som statistiker - vet du, ingenting är värre än, du vet, företagets datalager är underbara för att driva rapporterna, men om du vill göra riktigt prediktiv analys, är de verkligen inte så användbart, för det du verkligen vill ha är de granulära beteendedata som på något sätt sammanfattades och aggregerades i datalageret. Så jag tror att det verkligen är en viktig funktion, och det är en sak som jag tror att jag kanske inte håller med Robin om är att jag personligen skulle lämna data i datasjön eller datahuben så länge som möjligt, för så länge som data finns där och det är rent, du kan titta på dem från en riktning, en annan riktning. Du kan slå samman den med andra data. Du har alltid den möjligheten att komma tillbaka till det och omstrukturera och sedan anpassa dig till en affärsenhet och behovet som den här enheten kan ha.
En av de andra intressanta sakerna med detta är att eftersom det är en så kraftfull beräkningsplattform, mycket av den arbetsbelastningen som vi har pratat om, ser vi att allt kommer direkt in i Hadoop. Och medan jag tror, Mike pratade om alla de olika teknikerna som finns ute i världen - i denna typ av big data-ekosystem, tror vi att Hadoop verkligen är arbetshäst att göra så stor skala i beräkningsintensiv behandling som masterdata och datakvalitet kräver. För om du kan göra det där, du vet, bara den rena ekonomin att flytta data från dina dyra databaser och till ekonomiska databaser, detta verkligen driver så mycket av upptaget just nu i stora företag.
Nu finns det naturligtvis några utmaningar, eller hur? Det finns utmaningar kring teknologierna. Många av dem är mycket omogna. Jag skulle säga, du vet, jag vet inte hur många, men ett antal tekniker som Mike nämnde finns fortfarande på nollpunkt-något släpper, eller hur? Så dessa tekniker är mycket unga, mycket omogna, fortfarande kodbaserade. Och det skapar verkligen en utmaning för företagen. Och vi fokuserar verkligen på att lösa problem på företagsnivå. Och så tror vi att det måste finnas ett annat sätt, och det är vad vi föreslår är ett annat sätt att gå igenom några saker i att använda några av dessa mycket framväxande tekniker.
Och så, och sedan den andra intressanta frågan här, som har nämnts tidigare, som är, när du har data som du fångar i en Hadoop-miljö av vilken typ som helst, du vet, det är vanligtvis schema på läst snarare än schema på skriv med några undantag. Och att läsningen, mycket av det görs av statistiker. Och så måste statistikerna ha verktyg som gör det möjligt för dem att strukturera informationen korrekt för analytiska ändamål, för i slutet av dagen, för att göra data användbara, måste de struktureras i någon form för att se några eller besvara en fråga eller ett företag, någon typ av verksamhet, skapar affärsvärde.
Så, där vi kommer in, är att vi har mycket bredbaserad och mogen EPL, ELT datakvalitet masternyckel och hanteringsapplikation. Det har funnits på marknaden i många, många år. Och det har all funktionalitet eller mycket av funktionaliteten som Robin listade i den cirkulära grafen - allt från bara ren rådatafångst i en mängd olika format och XML-strukturer och vad som inte är, till förmågan att göra all rengöring, färdigställande av data, korrigering av data, geospatiala kärnbitar av data. Det är något som blir mer och mer viktigt i dag med Internet of Things. Du vet, det finns geografi kopplat till mycket av det vi gör eller mycket av den informationen. Och så, allt parsing, tokenization, rensning, korrigering, formatering, strukturering, etc., allt detta görs på vår plattform.
Och då, och kanske, vi tänker på det viktigaste är idén om deduplicering. Du vet, i kärnan, om du tittar på någon definition av stamdatahantering, är kärnan i det deduplicering. Det kan identifiera enheter över olika datakällor och sedan skapa en masterpost för den enheten. Och den enheten kan vara en person. Enheten kan till exempel vara en del av ett flygplan. Enheten kan vara en mat som vi har gjort för en av våra hälsoklubbs kunder. Vi har skapat en huvudmatdatabas för dem. Så oavsett vilka enheter som vi arbetar med - och naturligtvis i allt högre grad finns det människor och ombud för deras identiteter som är saker som sociala handtag eller konton, oavsett enheter som är associerade med människor, vissa saker som bilar och telefoner och vad du än kan tänka dig.
Du vet, vi arbetar med en klient som lägger in alla typer av sensorer i sportkläder. Så data kommer från alla håll. Och på ett eller annat sätt är det en återspegling eller representation av kärnenheten. Och allt mer, det är människor och förmågan att identifiera förhållandena mellan alla dessa datakällor och hur de relaterar till den kärnenheten, och sedan kunna spåra den kärnenheten över tid så att du kan analysera och förstå förändringarna mellan den enheten och alla de andra elementen som finns i representationerna av den enheten, en riktigt kritisk för långsiktig och longitudinell analys av människor, till exempel. Och det är verkligen en av de riktigt viktiga fördelarna som, tror jag, big data kan ge oss är mycket bättre förståelse för människor, och på lång sikt, och förstå con och hur människor uppför sig när de uppför sig genom vilka enheter, etc. .
Så låt mig gå igenom här snabbt. Eric nämnde YARN. Vet du, jag kastar in det här bara för lite sekund, för medan YARN - folk pratar om YARN. Jag tror fortfarande mycket okunnighet om YARN. Och inte många människor verkligen - det finns fortfarande mycket missförstånd om YARN. Och faktum är att om din applikation har arkitekterats på rätt sätt, och du har rätt nivå eller parallellisering i din applikationsarkitektur, kan du dra nytta av YARN för att använda Hadoop som din skalplattform. Och det är exakt vad vi har gjort.
Du vet igen, bara för att påpeka några av definitionerna kring YARN. För oss har verkligen vad YARN är gjort det möjligt för oss själva och andra organisationer att bli kamrater till MapReduce och Spark, och alla andra verktyg som finns där ute. Men faktum är att våra applikationer kör optimerad kod direkt till YARN till Hadoop. Och det finns en riktigt intressant kommentar som Mike har nämnt, eftersom, du vet, frågan om analys och vår analys, bara för att de är i klustret, kör de verkligen parallellt? Du kan ställa samma fråga om många av datakvalitetsverktygen som finns där ute.
För det mesta måste kvalitetsverktygen som finns där antingen ta ut data eller så skjuter de in kod. Och i många fall är det en enda dataström som behandlas på grund av hur du måste jämföra poster, ibland i datakvalitetstyp. Och faktum är att eftersom vi använder YARN har vi kunnat dra fördel av parallelliseringen.
Och bara för att ge dig en snabb översikt, eftersom en annan kommentar görs om vikten av att kunna utöka traditionella databaser, nya databaser etc., implementerar vi eller installerar vi utanför klustret. Och vi driver våra binärer direkt in i resurschefen, YARN. Och det, och sedan distribuerar YARN det över noderna i klustret. Och vad det gör är att YARN - vi tillåter YARN att hantera och göra sitt jobb, vilket är att räkna ut var data är och ta arbetet till data, koden till data och inte flytta data runt. När du hör datakvalitetsverktyg och de säger att bästa praxis är att flytta data från Hadoop, springa för ditt liv, för det är inte så som det är. Du vill ta arbetet till data. Och det är vad YARN gör först. Det tar våra binärer ut till de noder där data finns.
Och också för att vi är utanför klustret, kan vi också komma åt alla de traditionella och relationella databaserna så att vi kan ha jobb som är 100% klientserver på en traditionell databas, 100% Hadoop eller hybridjobb som går över Hadoop klientserver , Oracle, Teradata - vad du än vill och alla i samma jobb, eftersom den ena implementeringen kan komma åt båda sidor av världen.
Och när du går tillbaka till hela idén om verktygets obehag, ser du här, detta är bara en enkel representation. Och vad vi försöker göra är att förenkla världen. Och hur vi gör det är genom att föra en mycket bred uppsättning funktioner runt HDFS för att göra det ... Och det är inte för att vi försöker eliminera alla innovativa teknologier där ute. Det är bara företag som behöver stabilitet och de gillar inte kodbaserade lösningar. Och det vi försöker göra är att ge företagen en välbekant, repeterbar, konsekvent applikationsmiljö som ger dem möjlighet att bygga och bearbeta data på ett mycket förutsägbart sätt.
Snabbt är det den typen av påverkan vi får med vår applikation. Du ser MapReduce vs. Pig vs. RedPoint - inga kodrader i RedPoint. Sex timmars utveckling på MapReduce, tre timmars utveckling i Pig och 15 minuters utveckling i RedPoint. Och det är där vi verkligen har en enorm inverkan. Bearbetningstiden är också snabbare, men folketiden, folkets produktivitetstid ökas avsevärt.
Och min sista bild här, jag vill gå tillbaka till den här idén, eftersom det här är vårt arbete med att använda en datasjö eller ett datahub, eller ett dataraffinaderi som den centrala punkten för intag. Kunde inte hålla mer med den idén. Och vi är för närvarande i diskussioner med många av de viktigaste datatjänstemännen för stora globala banker, och det är den arkitekturen du väljer.Datainsamling från alla källor gör datakvalitetsbehandlingen och masterdatahantering inuti datasjön, och skjut sedan data dit det behöver gå för att stödja applikationer, för att stödja BI, vad som än kan vara. Och sedan, om du har analyser i BI, kan de springa direkt inuti datasjön, där allt bättre, som kan börja direkt. Men mycket ombord med denna idé. Den här topologin här är en som är - som vi finner på att få mycket dragkraft på marknaden. Och det är allt.
Eric: Okej, bra. Låt oss gå här. Jag ska gå vidare och överlämna det till Keith. Och, Keith, du har cirka 10, 12 minuter att gunga huset här. Vi tog oss lite lång tid i dessa shower. Och vi annonserade 70 minuter för den här. Så bara gå vidare och klicka var som helst på bilden och använd pilen nedåt och ta bort den.
Keith: Visst. Inga problem, Eric. Jag uppskattar det. Jag kommer att gå vidare och träffa bara ett par stycken om SAS, sedan kommer jag att gå in, precis in i teknikarkitekturer där SAS korsar varandra med big data-världen. Det finns mycket att förklara i allt det här. Vi kunde spendera timmar på att gå igenom det i detalj, men tio minuter - du borde kunna gå bort med bara en kort förståelse för var SAS har tagit analys-, datahantering och business intelligence-teknologier till denna big data-värld.
Först bara lite om SAS. Om du inte känner till den här organisationen har vi under de senaste 38 åren gjort avancerad analys, affärsinformation och datahantering med inte bara big data, utan små data och dataförmögenhet under de senaste 38 åren. Vi har en enorm befintlig kundfot, cirka 75 000 webbplatser över hela världen, som arbetar med några av de bästa organisationerna där ute. Vi är en privat organisation med cirka 13 000 anställda och intäkter på 3 miljarder dollar. Och egentligen, antar jag, den viktiga delen är att vi traditionellt har haft en lång historia av att återinvestera betydande mängder av våra intäkter tillbaka till vår FoU-organisation, som verkligen har gett många av dessa fantastiska tekniker och plattformar du ". kommer att se idag.
Så jag kommer att hoppa rätt in i dessa riktigt skrämmande arkitekturdiagram. Vi arbetar från vänster till höger i mina bilder. Så det finns bekanta saker som du kommer att se på den här plattformen. På vänster sida är alla de datakällor som vi pratar om att ta in i dessa big data-plattformar. Och sedan har du den här stora dataplattformen.
Jag har inte bara lagt ordet Hadoop där högst upp, för i slutändan är exemplen jag kommer att ge idag specifikt kring all teknik där vi korsar dessa stora dataplattformar. Hadoop råkar bara vara en av de där vi har några av de mest robusta distributionsalternativen, men vi korsar också en hel del och har utvecklat en hel del av dessa teknologier under en tid med några av våra andra företag dataprodukter lagringspartners som Teradata, Oracle, Pivotal och liknande. Så jag kan inte gå in på stora detaljer när det gäller alla olika tekniker som stöds på vilken plattform, men bara vara säker på att alla de som jag beskriver idag är mestadels allt som Hadoop och en stor mängd av dem korsar varandra med andra teknikpartners som vi har. Så vi har den stora plattformen som sitter där.
Nästa till höger, vi har vår SAS LASR analytiska server. Nu är det i huvudsak en massivt parallell i minnesanalytisk applikationsserver. Vi är tydliga att det inte är en databas i minnet. Det är verkligen designat från grunden. Det är inte frågeställningsmotorn, utan utformad för att betjäna analytiska förfrågningar i massiv skala på ett massivt parallellt sätt. Så det är de applikationsnyckelapplikationer du ser där på höger sida.
Vi kommer att få lite mer till, du vet hur människor använder dessa saker. Men i huvudsak är applikationen - ser du där - den första, vår SAS högpresterande analys. Det kommer att bli - jag använder mycket av vår befintliga teknik och plattformar som Enterprise Miner eller bara ett SAS, och gör inte bara multitrådning med några av de algoritmer som vi har byggt in i de verktyg som vi har gjort för år, men också för att massivt parallella dem. Så för att flytta data från den stora dataplattformen till minnesutrymmet till den LASR analytiska servern, så att vi kan utföra analytiska algoritmer - du vet, en hel del av den nya maskininlärningen, nervnät, slumpmässiga skogsregressioner, sådana typer av saker - igen, data som sitter i minnet. Så att bli av med den vissa MapReduce-flaskhalsen där vi laddas ner till dessa plattformar, det är inte så du vill göra analytiskt arbete. Så vi vill kunna lyfta uppgifterna en gång till minnesutrymmet och iterera igenom det, du vet, ibland tusentals gånger. Så det är begreppet att använda den högpresterande analytiska LASR-servern.
Vi också - de andra applikationerna under den, den visuella analysen, som gör att vi kan fortsätta att data i minnet och tjäna upp en större population på samma data. Så att låta människor göra big data-utforskning. Så innan vi utför vår modellutveckling, undersöker vi data, förstår det, kör korrelationer, gör prognoser eller trender beslutsträd - sådana saker - men på ett mycket visuellt, interaktivt sätt på data som sitter i minnet plattform. Det tjänar också vårt BI-community så långt som att de har en mycket bred bas av användare som kan träffa den plattformen för att göra standardtyper av inspelningar som du skulle se - vilket stort sett alla, du vet, BI-leverantör där ute.
Nästa steg, vi går sedan i tjänst. Och för att hjälpa våra statistiker och våra analytiker att kunna göra den typen av ad-hoc-modellering med data som sitter i minnet, tas bort från visuell analys och utforskning i vår visuella statistikapplikation. Detta är en möjlighet för människor att ta, att inte köra statistik i partier som brukade typ av iterera igenom, köra modellerna, se resultaten. Så det kan köra modellen, se resultaten. Detta är för att dra och släppa visuellt till interaktiv statistisk modellering. Så detta tjänar våra statistiker och våra datavetare för att göra mycket av det tidiga undersökande visuella statistikarbetet.
Och då har vi inte glömt bort våra kodare - de som verkligen vill ha, kunna dra bort gränssnittslagren mittemot, är att skriva applikationer och skriva sin egen kodbas i SAS. Och det är vår statistik i minnet för Hadoop. Och det är det - i huvudsak kodskiktet som tillät oss att interagera med den analytiska LASR-servern för att utfärda kommandon direkt och anpassa dessa applikationer baserat på vår begäran. Det är den analytiska delen.
Hur dessa saker skapas ... Oj, jag är ledsen killar. Där går vi.
Så det finns verkligen ett par sätt att göra detta på. Det ena är att göra det med big data - i detta fall med Hadoop. Och det är där vi har den SAS LASR Analytic Server som körs i ett separat kluster av maskiner som är optimerade för hardcore-analys. Detta ligger trevligt och nära upp till big data-plattformen, så att vi kan skala det separat från big data-plattformen. Så vi ser människor som gör detta när de inte vill ha något som jag kännetecknar som vampyrprogramvara som äter iväg vid var och en av noderna i deras Hadoop-kluster. Och de skalar inte nödvändigtvis den big data-plattformen som är lämplig för att göra tunga lyftanalyser i minnet. Så du kanske har 120 noder i deras Hadoop-kluster, men de kan ha 16 noder för analytiska servrar som är utformade för att göra den typen av arbete.
Vi får fortfarande behålla den parallellen från stordataplattformen för att dra data in i minnet. Så det är verkligen ett att använda SAS med Hadoop-plattformen. En annan utnämningsmodell är då att säga, ja, vi kan också använda den varuplattformen och trycka på det - i princip köra Analytic LASR-servern på Hadoop-plattformarna. Så det är där vi är ... du arbetar i big data-plattformen. Det är också några av våra andra leverantörer av apparater. Så det har gjort det möjligt för oss att använda den varuplattformen för att göra det arbetet.
Vi ser att oftare med saker som högpresterande analyser där det är en enstaka serverings- eller engångsform av analytisk körning, mer slags batchorienterad där du är - du vill inte nödvändigtvis konsumera minnesutrymmet på Hadoop plattform. Vi är väldigt flexibla med den här typen av implementeringsmodell, definitivt i vårt arbete med YARN i många av dessa fall för att se till att vi spelar trevliga kluster.
Okej, så det är den analytiska världen, bara för att vara tydlig där med den analytiska applikationen. Men jag nämnde att SAS i början också är en datahanteringsplattform. Och det finns saker som är lämpliga för att driva logik till den plattformen där det är lämpligt. Så det finns några sätt att göra det på. Det ena är i dataintegrationsvärlden, att göra dataomvandlingsarbete på data kanske inte är vettigt att dra tillbaka det som vi har hört tidigare och kör datakvalitetsrutiner som är stora. Vi vill definitivt skjuta saker som datakvalitetsrutiner ner till den plattformen. Och sedan saker som modellpoäng. Så jag har fått min modell utvecklad. Jag vill inte skriva om det i MapReduce och göra det svårt och tidskrävande för mig att göra om det som fungerar i den ursprungliga databasplattformen.
Så om du till exempel tittar på vår poängaccelerator för Hadoop, som gör att vi i princip kan ta en modell och skjuta SAS matematiska logik ner i Hadoop-plattformen och köra den där med hjälp av parallellen som finns i den stora dataplattformen. Sedan har vi vår kodaccelerator för olika plattformar inklusive Hadoop, och det gör att vi i huvudsak kan köra SAS-datastegskod inuti plattformen på ett massivt parallellt sätt - så genom att göra datatransformeringsarbete på plattformen. Och sedan vår SAS datakvalitetsaccelerator som tillåter oss att ha en kunskapsbas av kvalitet som sitter där som kan göra saker som könsmatchning, standardisering matchningskod - alla de olika datakvalitetssaker som du har hört redan idag.
Och sedan, sista delen, finns det Data Loader. Vi vet att våra affärsanvändare kommer att behöva kunna inte behöva skriva kod, arbeta med dataomvandling i dessa big data-plattformar. Data Loader är en trevlig WYSIWYG GUI som gör att vi kan samla in de andra teknologierna tillsammans. Det är som en genomgångsguide för att säga, köra en Hive-fråga eller köra en datakvalitetsrutin och inte behöva skriva kod i så fall.
Det sista jag kommer att nämna är den främre delen. Vi har - som jag nämnde tidigare - en massiv SAS-fot där ute i världen. Och detta, vi kan inte bara nödvändigtvis göra alla de plattformar som finns ute för att vara i detta utrymme omedelbart. Så vi har definitivt en befintlig fot av användare som behöver få en data som sitter i dessa big data-plattformar som att få data ur Teradata och sätta tillbaka dem i Hadoop, och vice versa. När jag kör modellerna vet jag redan hur jag kör på mina SAS-servrar, men jag måste få en data som nu placeras i Hadoop-plattformen. Så det finns denna andra lilla ikon som heter "från", och som gör att vi kan ansluta med våra SAS-åtkomstmotorer - åtkomstmotorer till Hadoop till Cloudera i Pola, till Teradata, till Greenplum till ... Och listan fortsätter. Detta gör att vi kan använda våra befintliga mogna SAS-plattformar som redan finns för att hämta data från dessa plattformar, göra det arbete som vi behöver för att göra och skjuta resultaten tillbaka till dessa områden.
Det sista jag kommer att nämna är att alla dessa tekniker du ser styrs av samma vanliga metadata. Så vi pratar om att få transformationsarbetet, datakvalitetsregeln på jobbet, flytta det till minnet för att kunna göra analys, modellutveckling i poäng. Vi har fått hela den analytiska livsstilen, livscykeln styrs av vanliga metadata, av styrning, av säkerhet, av alla de saker som vi pratade om tidigare i dag.
Så, bara en sammanfattning, det finns verkligen de tre stora sakerna att ta bort där. Den ena är att vi kan behandla dataplattformen precis som alla andra datakällor, dra ifrån dem, trycka till dem när det är lämpligt och bekvämt. Vi kan arbeta med de stora dataplattformarna och lista upp data i en specialbyggd avancerad analys i minnesplattformen. Så det är LASR-servern.
Och senast kan vi arbeta direkt i de stora dataplattformarna och utnyttja deras distribuerande bearbetningsmöjligheter utan att flytta data.
Eric: Det är fantastiska grejer, folkens. Ja, det här är jättebra! Så låt oss dyka rätt in på några frågor. Vi går vanligtvis cirka 70 minuter eller lite längre på dessa händelser. Så jag ser att vi fortfarande har en stor publik som sitter där ute. George, jag antar att jag kommer att kasta vår första fråga till dig. Om du pratar om att driva ditt binära ljud till Hadoop, tror jag att det låter för mig som om du verkligen har optimerat det beräknade arbetsflödet. Och det är hela nyckeln för att kunna göra dessa typer av datainsamling i realtid, datakvalitetsstilar, för det är det värde du vill få, eller hur? Om du inte vill gå tillbaka till den gamla världen av MDM där det är väldigt besvärligt och det är mycket tidskrävande och du verkligen måste tvinga människor att agera på vissa sätt, som nästan aldrig fungerar. Och så, vad du har gjort är att du kondenserade cykeln för vad som var. Låt oss kalla det dagar, veckor, ibland till och med månader ner till sekunder, eller hur? Är det det som händer?
George: Det är exakt rätt, för den skala vi får och den prestanda vi får ut ur ett kluster är verkligen häpnadsväckande när det gäller, bara, du vet, jag är alltid lite tveksam till riktmärken. Men bara för storleksordningen, när vi skulle driva en miljard, 1,2 miljarder poster och göra en fullständig adressstandardisering - jag säger HP: s mellanslag - det skulle ta, som du vet, åtta processormaskiner, du vet , 2 spelningar RAM per kärna, du vet, det skulle ta 20 timmar att köra. Vi kan göra det på cirka åtta minuter nu på ett, du vet, kluster med 12 noder. Och så är omfattningen på behandlingen som vi kan göra nu så dramatiskt annorlunda att - och det går väldigt bra med tanken att du har all denna information till ditt förfogande. Så det är inte lika riskabelt att bearbeta. Om du gjorde det fel kan du göra om det. Du har tid, du vet. Det ändrade verkligen omfattningen av detta där, du vet, de typer av risker verkligen blev verkliga affärsproblem för människor när de försökte använda MDM-lösningar. Du måste ha 30 personer offshore som gör datastyring och allt. Och så måste du fortfarande ha något av det, men hastigheten och skalan du kan bearbeta det nu ger dig verkligen mycket mer andningsrum.
Eric: Ja, det är en riktigt, riktigt bra poäng. Jag älskar den kommentaren. Så du har tid att göra om det igen. Det är fantastiskt.
George: Ja.
Eric: Det ändrar dynamiken, eller hur? Det ändrar hur du tänker på vad du ska prova. Jag menar, jag minns det här för 18 år sedan i branschen att göra specialeffekter, eftersom jag hade en klient som var i det utrymmet. Och du skulle trycka på knapparna för att göra det och du skulle gå hem. Och du kom tillbaka, kanske på lördag eftermiddag, för att se hur det gick. Men om du tog fel, det var väldigt, mycket, mycket smärtsamt. Och nu är det inte nära - det är inte ens nära att vara så smärtsamt så att du har möjlighet att prova fler saker. Jag måste säga, jag tycker att det är en riktigt bra riktning.
George: Det är exakt rätt. Ja, och du blåser ditt extra ben. Du vet, du kommer halvvägs genom ett jobb i gamla dagar och det misslyckas, du har blåst din SOS. Det är allt.
Eric: Rätt. Och du har stora problem, ja. Det är rätt.
George: Det stämmer. Det är rätt.
Eric: Keith, låt mig kasta en till dig. Jag minns att jag gjorde en intervju med din CIL, Keith Collins, tror jag, tillbaka, tror jag, 2011. Och han talade mycket om riktningen som SAS tog specifikt när det gäller att arbeta med kunder för att bädda in analysen från SAS i operativa system. Och naturligtvis hörde vi Mike Ferguson prata om vikten av att komma ihåg. Hela idén här är att du vill kunna binda det här i dina operationer. Du vill inte analysera i ett vakuum, kopplad från företaget. Det är inget värde alls.
Om du vill ha analys som direkt kan påverka och optimera verksamheten. Och om jag ser tillbaka - och jag måste säga, jag tyckte att det är en bra idé då - det verkar som en riktigt, riktigt smart idé i efterhand. Och jag antar att det är en riktig fördel som ni har. Och naturligtvis den här stora arven, den här enorma installationsbasen och det faktum att du har varit fokuserad på att bädda in denna analys i operativa system, vilket betyder nu - och beviljat, det kommer att ta lite arbete - jag är säker på att du " Vi har jobbat med det ganska hårt. Men nu kan du utnyttja alla dessa nya innovationer och verkligen vara i termer av att kunna operationella allt det där med dina kunder. Är det en rättvis bedömning?
Keith: Ja, absolut. Konceptet är att du får den här idén om beslutsdesign eller beslutsvetenskap, som du känner till i viss utsträckning det är utforskande, vetenskapligt slags. Om du inte kan göra ingenjör på processen för att verkligen ... Om du funderar på att utveckla en bil, har du designers som gör denna vackra bil, men det är inte förrän ingenjörer sätter den planen på plats och gör en verklig livskraftig produkt framför dig kan faktiskt sätta saker på plats, och det är i huvudsak vad SAS har gjort. Det har sammanfogat besluten - beslutsprocess med processen för beslutsteknik tillsammans, så att när du pratar om acceleratorerna, specifika poängacceleratorerna, vet du om du tar en modell som du utvecklade och kan driva ut den till Teradata, eller skjut ut den till Oracle eller till Hadoop, med noll driftstopp för modellutveckling, till modellinstallation. Det är nyckeln, eftersom modeller försämras med tiden, noggrannheten för dessa modeller. Så ju längre tid det tar för dig att ta det och lägga det i produktion, det är modellens noggrannhetsförlust.
Och den andra delen är att du vill kunna övervaka och hantera processen över tid. Du vill avskriva modeller när de blir gamla och felaktiga. Du vill titta på det, kontrollera noggrannheten hos dem över tid och bygga om dem igen. Och så har vi modellhanteringsverktyg som också sitter ovanpå det som verkligen spårar metadata kring den modellerade processen. Och människor har sagt att modellering, du vet, den typen av koncept är som en modellfabrik, eller vad du än vill kalla det. Saken är att det är att sätta metadata och hantering i process och det är där de tre stora sakerna vi träffar - vi hjälper människor att tjäna pengar, spara pengar och hålla dem ur fängelse.
Eric: Den sista är också ganska stor. Jag vill undvika allt detta. Så låt oss prata om ...Jag ger en sista fråga, kanske ni alla båda kan hoppa på det här. Vår världs heterogenitet kommer bara att öka, verkar jag. Jag tror att vi definitivt kommer att se en del kristallisation kring hybridmolnmiljöer. Men ändå kommer du att se många av de stora spelarna som sticker runt. IBM går inte någonstans. Oracle kommer inte någonstans. SAP går inte någonstans. Och det finns så många andra leverantörer som är involverade i det här spelet.
På operativ sida, där du bokstavligen har tusentals och tusentals olika typer av applikationer. Och jag hörde - de flesta av er pratar om detta, men jag tror att ni båda skulle vara överens med det jag har sagt. Vi har sett denna trend nu när det gäller bara beräkningskraft i analytiska motorer, arkitektur. Företag har talat i flera år nu om att kunna utnyttja de andra motorerna där ute och betjäna en slags orkestreringspunkt. Och jag antar att George, jag kommer att kasta det till dig först. Det verkar för mig att det är något som inte kommer att förändras. Vi kommer att ha den här heterogena miljön som innebär att det finns saker som realtids CRM och datakvalitet och datastyring. Du behöver som leverantör att gränssnittet med alla dessa olika verktyg. Och det är vad kunderna vill ha. De kommer inte att vilja ha något som gör det okej med dessa verktyg och inte så okej med de verktygen. De kommer att vilja ha MDM och CRM Schweiz, eller hur?
George: Det stämmer. Och det är intressant, för det har vi mycket omfamnat. En del av det är historien vi hade i rymden. Och uppenbarligen arbetade vi redan med alla andra databaser, Teradatas och världens delar. Och sedan gjorde du - i implementeringsprocessen, specifikt som vi gjorde, bara så att det - du har det spännvidden över alla dessa olika databaser. En av de saker som jag tycker är intressant är att vi har några klienter som bara är helvete för att eliminera alla relationsdatabaser. Och det är intressant. Du vet, jag menar, det är bra. Det är intressant. Men jag ser inte att det verkligen händer i en stor företagsskala. Jag ser det inte hända på länge. Så jag tror att hybrid är här länge och på andra sidan vår applikation där vi har vår meddelandeplattform i vår kampanjhanteringsplattform. Vi har faktiskt utformat det specifikt. Nu har vi släppt en version som gör det och som nu kan ansluta till hybriddatamiljön och fråga Hadoop, eller fråga vilken databas som helst, vilken analytisk databas som helst. Så jag tror att det bara är framtidens våg. Och jag håller med om att virtualisering säkert kommer att spela en stor roll i det här, men vi är bara - vi kommer direkt till data om alla våra applikationer.
Eric: Okej, bra. Och Keith, jag kommer att kasta det till dig. Vad tycker du om den heterogena världen vi står inför när vi agerar som en fot av olika slag?
Keith: Ja, det är väldigt fascinerande. Jag tror att det vi hittar mer - inte bara i datahanteringens sida - men det som verkligen är fascinerande just nu är analysbasen med öppen källkod. Så vi ser organisationer som eller tekniker som Spark kommer ombord och människor som använder Python och R och alla dessa andra open source-teknologier. Jag tror att det kan tolkas som en slags konflikt eller ett hot i viss mån. Men verkligheten är att vi har några riktigt underbara komplimanger med alla dessa open source-teknologier. Jag menar, för en, vi arbetar på toppen av open source-plattformar, för Guds skull.
Men också, som att kunna till exempel integrera en R-modell i ett SAS-paradigm, låter dig använda det bästa från båda världarna, eller hur? Som, så vi vet att några av de experimentella sakerna i den akademiska världen och en del av modellutvecklingsarbetet är extraordinära och superhjälpsamma i modellutvecklingsprocessen. Men också, om du kan koppla ihop det med en typ av verktyg i produktionsklass, gör det mycket av rengöringen och kvaliteten och kontrollerar och ser till att data som lämnas in till modellen är, det har förberedts ordentligt så att det inte misslyckas vid körning. Och sedan kunna göra saker som mästare utmanare modeller med öppen källkod modeller. Det är de saker vi tittar på för att möjliggöra, och som en del av detta verkligen heterogena ekosystem av alla dessa tekniker. Ja, så det är mer - för oss handlar det mer om att omfatta teknologierna och leta efter komplimangerna.
Eric: Det här har varit fantastiska grejer, folkens. Vi gick lite länge här, men vi skulle vilja komma till så många frågor som möjligt. Vi kommer att vidarebefordra Q & A-filen till våra presentatörer idag. Så om du inte besvarar någon fråga kommer vi att se till att den besvaras. Och folkens, det här försvinner för 2014. Ni är verkligen på DM-radion imorgon och nästa vecka, och sedan är det klart och det är en semester.
Så mycket tack till er alla för er tid och uppmärksamhet, för att ha stickit igenom alla dessa underbara webbsändningar. Vi har fått ett fantastiskt år upp för 2015. Och vi kommer snart att prata med er, folkens. Tack igen. Vi tar hand. Hejdå.