Conţinut
Sursa: Jakub Jirsak / Dreamstime.com
La pachet:
Gazda Eric Kavanagh discută analize de date mari cu experți din industrie.
Eric: Doamnelor și domnilor, este sfârșitul anului 2014 - cel puțin, aproape. Este ultima noastră transmisie web a anului, oameni buni! Bine ați venit la TechWise! Da, întradevăr! Ma numesc Eric Kavanagh. Voi fi moderatorul dvs. pentru un webcast minunat, oameni buni. Sunt foarte entuziasmat. Avem doi analiști nemaipomeniți online și două mari companii - inovatori reali în acest întreg ecosistem de date mari. Și vom vorbi totul despre cheia analizei de date mari este diferența de înțelegere. Deci, hai să mergem mai departe și să ne scufundăm corect, oameni buni.
Avem mai mulți prezentatori. După cum vedeți, există dvs. cu adevărat în vârf. Mike Ferguson apelează tot din Marea Britanie, unde a trebuit să obțină privilegii speciale pentru a rămâne în clădirea de birouri până târziu. La fel de târziu este pentru el. Îl avem pe Dr. Robin Bloor, propriul nostru analist șef aici, la Bloor Group. Și îi vom avea pe George Corugedo, CEO și co-fondator al RedPoint Global, și pe Keith Renison, arhitectul de soluții senior de la SAS Institute. Acestea sunt companii fantastice, oameni buni. Acestea sunt companii care chiar inovează. Și vom explora câteva dintre lucrurile bune din ceea ce se întâmplă acum în toată lumea cu date mari. Și să ne confruntăm, datele mici nu au dispărut. Și la asta, permiteți-mi să dau rezumatul meu executiv aici.
Deci, există o expresie franceză veche: „Cu cât se schimbă mai multe lucruri, cu atât rămân la fel”. Și să ne confruntăm cu unele fapte aici - datele mari nu vor rezolva problemele datelor mici. Datele mici ale companiilor sunt încă acolo. Este încă peste tot. Este combustibilul operațiunilor pentru economia informațională de astăzi. Iar datele mari oferă un compliment acestor așa-numite date corporative mici, dar nu înlocuiesc datele mici. Tot va fi în preajmă. Îmi plac o mulțime de lucruri despre datele mari, în special lucruri precum datele generate de mașini.
Și astăzi, vom vorbi probabil puțin despre datele din social media, care sunt și lucruri foarte puternice. Și dacă vă gândiți, de exemplu, la modul în care socialul a schimbat afacerile, bine gândiți-vă aici la trei site-uri web rapide:, LinkedIn și. Gândiți-vă la faptul că acum cinci ani, nimeni nu făcea așa ceva. este un jonglernaut absolut în aceste zile. , desigur, este imens. Este gargantuan. Și apoi, LinkedIn este standardul de facto pentru rețea și comunicare corporativă. Aceste site-uri sunt puternice și, pentru a putea folosi datele care se află în ele, va renaște o funcționalitate care schimbă jocul. Va face foarte mult bine pentru o mulțime de organizații - cel puțin pentru cele care profită.
Fără bug-uri, fără stres - Ghidul dvs. pas cu pas pentru crearea de software care poate schimba viața fără a vă distruge viața
Nu îți poți îmbunătăți abilitățile de programare atunci când nimeni nu îi pasă de calitatea software-ului.
Deci, guvernanța - guvernanța încă mai contează. Din nou, datele mari nu anulează nevoia de guvernare. Sincer, există o nevoie cu totul nouă de a ne concentra asupra modului de a guverna lumea datelor mari. Cum vă asigurați că aveți procedurile și politicile dvs. în vigoare; că oamenii potriviți au acces la datele corecte; că aveți persoane de contact, aveți implicit un fir de discuri aici? Știți de fapt de unde provin datele, ce s-a întâmplat cu acestea. Și totul se schimbă.
Sunt sincer într-adevăr impresionat de ceea ce am văzut acolo, în această lume nouă, care se bazează pe ecosistemul Hadoop, care este, desigur, mult mai mult decât stocare în ceea ce privește funcționalitatea. Hadoop este și un motor de calcul. Și compania trebuie să își dea seama cum să valorifice acea putere de calcul, acea capacitate de procesare paralelă. Vor face lucruri cu adevărat mișto. Vom afla astăzi despre asta.
Celălalt lucru de menționat, despre acest lucru despre care a vorbit dr. Bloor în trecutul recent, este că valul de inovație nu s-a terminat. Așadar, am văzut foarte multă atenție în jurul lui Hadoop. Am văzut companii precum Cloudera și Hortonworks, știi, făcând cu adevărat valuri. Și dezvoltă parteneriate cu companii de astăzi, chiar sincer. Și dezvoltă parteneriate cu mulți oameni. Dar valul de inovație nu s-a terminat. Există mai multe proiecte care se derulează din Fundația Apache care se schimbă nu doar punctul final, dacă veți dori - aplicațiile pe care le folosesc oamenii - ci infrastructura în sine.
Deci, toată această dezvoltare a YARN - încă un negociator de resurse - este într-adevăr ca un sistem de operare pentru date mari. Și este o afacere mare, mare. Deci, vom învăța cum schimbă și lucrurile. Așadar, doar câteva sfaturi evidente aici, aveți grijă ca contractele lungi să meargă înainte, știți, contractele pe cinci și zece ani vor fi valul, calea care mi se pare. Veți dori să evitați blocarea cu orice preț. Vom învăța despre toate acestea astăzi.
Așadar, primul nostru analist care vorbește astăzi - primul nostru vorbitor al întregului program este Mike Ferguson, apelând din Marea Britanie. Cu asta, îți voi înmâna cheile, Mike și te voi lăsa să iei. Mike Ferguson, podea este a ta.
Mike, tu acolo? S-ar putea să fii mut. Nu-l aud. Poate că trebuie să-l sunăm înapoi. Și vom sări doar pe diapozitivele lui Robin Bloor. Robin, o să-l ocup pe bietul Mike Ferguson aici. O să merg pentru o secundă.
Ești tu, Mike? Poti sa ne auzi? Nah. Cred că va trebui să mergem înainte cu Robin. Deci, țineți o secundă, oameni buni. Voi trage câteva link-uri către diapozitive aici în câteva minute. Așa că, cu asta, permiteți-mi să predau cheile lui Robin Bloor. Robin, poți merge mai întâi în locul lui Mike și îl voi suna pe Mike într-o secundă.
Robin: Bine.
Eric: Stai, Rob. Lasă-mă să merg înainte și să-ți aduc diapozitivul aici, Rob Va dura o secundă.
Robin: Bine.
Eric: Da. Puteți discuta despre ce avem de-a face, totuși, aici în ceea ce privește guvernanța. Știu că veți vorbi despre guvernare. Acest lucru este, de obicei, gândit în conținutul de date corporative mici. Acum, am prezentat, Robin. Nu mișcați nimic. Și aici te duci. Etajul este al tău. Ia-o de aici.
Robin: Bine. Da. Vreau să spun, bine, am fost aranjați în prealabil, Mike va vorbi despre partea analitică și voi vorbi despre partea de guvernare. Într-o anumită măsură, guvernanța urmărește analizele într-un sens că este un motiv pentru care efectuați lucrările de date mari, iar motivul pentru care reuniți toate softurile pentru a face analiza este acela care este valoarea.
Este o problemă. Și problema este că, știți, datele trebuie șterse. Datele trebuie preluate. Datele trebuie reunite și gestionate într-un mod care să permită analizelor să aibă loc cu încredere deplină - cred că este cuvântul. Așadar, am crezut că despre care am vorbit este partea de guvernanță a ecuației. Bănuiesc, lucrul de spus, într-adevăr, este că, știți, guvernarea era deja o problemă. Guvernanța era deja o problemă și începe să devină o problemă în întregul joc de stocare a datelor.
Ceea ce s-a întâmplat de fapt este că s-a transformat într-o problemă mult mai mare. Și motivul pentru care s-a transformat într-o problemă mult mai mare, precum și mai multe date, dar vreau să spun, acestea sunt motivele, într-adevăr. Numărul surselor de date s-a extins dramatic. Anterior, sursele de date pe care le aveam erau definite în mare măsură de orice serviciu de alimentare a datelor. Depozitul de date ar fi în mod normal alimentat de sisteme RTP. Este posibil câteva date externe, nu foarte multe.
Acum, am plecat într-o lume în care, știți, o piață de date apare acum și, prin urmare, va fi tranzacționare de date. Deja ai încărcături și o mulțime de surse de date diferite pe care le poți aduce în mod efectiv organizației. Avem date de social media care le-au luat, luate în considerare, ca să zic așa. Adică, o mare parte din valoarea, pe site-urile de socializare sunt de fapt informațiile pe care le agregă și, prin urmare, le pot pune la dispoziția oamenilor.
Am descoperit, de asemenea, parcă au existat deja. Aveam deja acele fișiere de jurnal, în viața lui Splunk. Și în curând, a devenit evident că există valoare într-un fișier jurnal. Deci, au existat date în cadrul organizației care au fost - pe care le-am putea numi noi surse de date, precum și surse externe. Deci, acesta este un lucru. Și asta înseamnă într-adevăr că, știți, indiferent de regulile de gestionare a datelor pe care le aveam înainte, acestea vor trebui să fie, într-un fel sau altul, extinse și vor trebui să fie extinse în continuare pentru a guverna efectiv date. Dar acum începem să ne asamblăm într-un fel sau altul.
Și coborând această listă avem streaming și viteza de sosire a datelor. Cred că unul dintre motivele popularității Hadoop este că poate fi folosit destul de mult pentru a prinde o mulțime de date. De asemenea, poate ingera viteza datelor, că, dacă nu este necesar să o utilizați imediat, este un mediu paralel, imens, paralel. Dar, de asemenea, ați obținut faptul că acum există o cantitate corectă de analize de streaming. Era doar sectoare bancare care erau interesate de aplicații de streaming, dar acum a fost un fel de global. Și toată lumea se uită la streaming de aplicații într-un fel sau altul, sau un mijloc potențial de a obține valoare din date și de a face analize pentru organizație.
Avem datele nestructurate. Statistica, de obicei o parte din numai 10% din datele lumii se găsea în baze de date relaționale. Acum, unul dintre motivele majore ale acestui fapt a fost cel mai mult, acesta a fost de fapt nestructurat și a fost - o mare parte a fost acolo pe Web, dar destul de mult despre diverse site-uri web. Aceste date s-au dovedit a fi, de asemenea, analizabile, de asemenea utilizabile. Și odată cu apariția tehnologiei Symantec, care trece treptat în situație, devine din ce în ce mai mult.Deci, este nevoie să colectăm și să gestionăm datele nestructurate și asta înseamnă că sunt mult mai mari decât au fost înainte. Avem o informație socială pe care am menționat-o deja, dar ideea despre asta, principalul lucru despre aceasta, este că este nevoie de curățare.
Avem date despre Internet of Things. Acesta este un fel de situație diferită. Este probabil să existe atât de multe, dar multe dintre ele vor trebui să rămână distribuite undeva în apropierea locului pe care îl conduce. Dar, de asemenea, veți dori, într-un fel sau altul, să o trageți pentru a face analizele din cadrul organizației cu privire la date. Deci, s-a adăugat încă un factor. Și aceste date vor fi structurate în mod diferit, pentru că probabil vor fi - probabil vor fi formatate în JSON sau în XML, astfel încât să se declare. Și nu numai, într-un fel sau altul, că tragem date într-adevăr și putem face un fel de schemă pe citirea acelei date particulare.
Avem problema provenienței și aceasta este o problemă de analiză. Rezultatele oricărei analize pe care le efectuați date nu pot fi - dacă doriți - aprobate, considerate valabile, cu excepția cazului în care cunoașteți proveniența datelor. Adică, acesta este doar profesionalismul în ceea ce privește activitatea oamenilor de știință de date. Dar știi, pentru a avea proveniența datelor, asta înseamnă că trebuie să guvernăm datele și să păstrăm o notă cu privire la linia lor.
Avem problema puterii computerului și a paralelelor și tot ceea ce face este ca totul să meargă mai repede. Problema este că, în mod evident, anumite procese pe care le-am pus în aplicare pot fi prea lente pentru orice altceva. Deci, există nepotriviri în ceea ce privește viteza.
Avem apariția învățării automate. Învățarea automată are efectul de a face din analitică un joc diferit decât era înainte. Dar puteți folosi cu adevărat doar dacă aveți puterea.
Am obținut faptul că avem noi sarcini analitice. Avem o lume paralelă și unii algoritmi analitici trebuie să fie executați în paralel pentru un efect maxim. Și, prin urmare, problema este guvernarea modului în care, într-un fel sau altul, împingeți datele din jur, faceți datele dacă sunt disponibile. Și acolo unde executați de fapt sarcinile de lucru analitice, deoarece este posibil să faceți asta în baza de date. Deci, este posibil să o efectuați în aplicații analitice.
Deci, există o serie întreagă de provocări de guvernare. Ce am făcut anul acesta - cercetările pe care le-am făcut în acest an au fost cu adevărat în jurul arhitecturii de date mari. Și când de fapt încercăm să o generalizăm, concluzia la care am ajuns - diagrama la care am ajuns arăta foarte mult.
Nu o să mă ocup de asta, mai ales că Mike va face o sumă echitabilă pentru arhitectura de date pentru analiză. Dar ceea ce îmi place de fapt ca oamenii să se concentreze doar pe acea zonă de jos în care ne reunim, într-un fel sau altul, date. Avem ceva la care aș dori să fac referire este rafinăria de date sau centrul de procesare a datelor. Și de acolo are loc guvernanța. Deci, știi, dacă ne concentrăm într-un fel, arată așa. Știi, este alimentat de date din surse interne și externe. În teorie, hub-ul ar trebui să ia toate datele care sunt generate. Ar trebui fie transmis și gestionat, deoarece este transmis în flux, dacă trebuie să faceți date de analiză și date în flux, apoi să treceți la hub. Sau, altfel, totul vine în hub. Și există o serie de lucruri care se desfășoară - care se întâmplă în hub. Și nu puteți avea o anumită cantitate de analize și SQL care se desfășoară în hub. Dar, de asemenea, ai nevoie de virtualizarea datelor din fiecare celulă pentru a împinge datele în alte zone. Dar înainte de a se întâmpla orice dintre acestea, aveți nevoie, într-un fel sau altul, de a face rafinarea pregătirii datelor. Îl poți numi pregătirea datelor. Este mult mai mare decât atât. Acestea sunt lucrurile pe care cred că le include.
Avem un management al sistemului și un serviciu, într-un anumit sens, că aceasta este porțiunea majoră a stratului de date, atunci trebuie să aplicăm toate sistemele care gestionează eforturile de gestionare a sistemului operațional, pe care le-am făcut în mod tradițional la aproape toate sistemele operaționale. Dar, de asemenea, trebuie să monitorizăm, într-un fel sau altul, alte lucruri care să se asigure că aceste niveluri de servicii diferite sunt îndeplinite, deoarece sunt obligate să fie definite niveluri de servicii sau orice fel de analiză ca fiind acționate sau datele BI fiind acționat.
Avem nevoie de monitorizare și gestionare a performanței. Dacă există altceva, avem nevoie de asta pentru a cunoaște ce resurse informatice suplimentare ar putea avea nevoie să alocăm în diverse momente în timp. Dar, de asemenea, o mare parte din volumul de muncă este aici, de fapt, destul de complex și concurează unul cu celălalt pentru resurse. Există ceva destul de sofisticat care trebuie făcut în zona respectivă.
Acum avem ciclul de viață al datelor într-un mod pe care nu l-am avut niciodată înainte. Acordul aici este într-adevăr mai presus de orice altceva, că nu am adunat date și nu le-am aruncat înainte. Am avut tendința să adunăm datele de care aveam nevoie și probabil să le păstrăm, apoi le arhivăm. Dar multe lucruri groaznice din ceea ce vom face de aici înainte explorează date. Și dacă nu doriți datele, îngropați-le. Deci, ciclurile de viață ale datelor sunt diferite, în funcție de situație, dar va fi și o agregare mult mai mare de date. Prin urmare, știți, știind de unde provine un agregat care este… care este sursa de agregare și așa mai departe și așa mai departe. Acest lucru este necesar.
Linia de date împrumută în mod natural. Fără asta, trebuie să știți problemele, deci datele ... Trebuie să știm că datele sunt valabile, dar cu cât de fiabile sunt ele de fapt.
De asemenea, avem o mapare a datelor, deoarece o mulțime de date vor fi într-un fel sau altul. Și aceasta este, dacă doriți, acest lucru se referă într-o anumită măsură la MDM. Doar că acum este mult mai complicat, pentru că atunci când veți obține o mulțime de date groaznice definite de JSON sau bazate pe schema noastră XML pe citire, atunci va trebui să aveți, într-un fel sau altul, foarte activ activitatea de cartografiere a datelor se desfășoară.
Există o situație de gestionare a metadatelor care este mai mult decât MDM, pentru că este nevoie, într-un fel sau altul, de a construi ceea ce mi-ar plăcea să cred acum ca un fel de depozit de metadate pentru tot ceea ce vă interesează. Există metadate descoperire, deoarece unele date nu vor avea în mod necesar metadatele sale declarate și dorim să le folosim imediat. Și apoi, există o curățare a datelor, ceea ce este un lucru uriaș în ceea ce privește seria de lucruri pe care le putem face acolo. Și există și securitatea datelor. Toate aceste date trebuie să fie securizate la un nivel acceptabil și asta ar putea însemna chiar și în anumite cazuri - de exemplu, criptarea multor valori.
Deci, toată această sarcină este de fapt imperiul guvernării. Toate acestea, într-un fel sau altul, trebuie să se desfășoare în același timp sau înainte, toată activitatea noastră analitică. Acesta este un număr mare de aplicații coordonate. Este un sistem în sine. Apoi, cei care nu o fac în diferite momente vor suferi din cauza lipsei lor, pe măsură ce merg înainte, pentru că multe dintre aceste lucruri nu sunt cu adevărat opționale. Încercați doar cu creșterea entropiei dacă nu le faceți.
Deci, în ceea ce privește analiza datelor și guvernanța, ceea ce aș spune este că, într-adevăr, o mână spală pe cealaltă. Fără guvernare, analitica și BI-ul nu vor pătrunde în timp. Și fără analize și BI, nu ar fi oricum nevoie mare de guvernare a datelor. Deci, cele două lucruri merg cu adevărat mână în mână. După cum se spune în Orientul Mijlociu, „O mână spală pe cealaltă”. Și asta este de fapt tot ce am de spus. Sper că, sper, îl vom primi acum pe Mike.
Eric: Da. Mike, presupun că ești acolo. Voi împinge diapozitivul în sus.
Mike: Eu sunt. Bine, mă auzi?
Eric: Da, te pot auzi. Pare minunat. Așadar, permiteți-mi să vă prezint ... Acolo vă duceți Și acum ești prezentatorul. Ia-o de aici.
Mike: Bine, mulțumesc! Bună dimineața, bună după-amiază, seară bună tuturor celor de acolo. Iertați sughițul la început. Într-un anumit motiv, m-am înțepenit și pot vedea pe toată lumea, dar ei nu m-au putut auzi.
În regulă. Așadar, ceea ce vreau să fac rapid este să vorbesc despre ecosistemul analitic de date mari. Dacă doriți să-mi puneți întrebări, vă voi spune că, în această sesiune sau mai târziu, puteți să mă puneți la curent cu datele mele de contact aici. După cum am spus, în miezul nopții aici, în Marea Britanie.
Ei bine, hai să ajung la ceea ce vreau să vorbesc. În mod clar, în ultimii ani, am observat apariția de tot felul de tipuri de date nou-găsite pe care acum companiile doresc să le analizeze - totul, de la date clickstream pentru a înțelege comportamentele online, datele despre social media despre care Eric vorbea la începutul programului aici. Cred că Robin a menționat JSON, BSON, XML - deci date semi-structurate care se auto-descriu. Desigur, avem și o mulțime de alte lucruri - de la date nestructurate, jurnalele infrastructurii IT, date ale senzorilor. Toate aceste surse de date relativ noi pe care companiile le-au interesat acum, deoarece conțin informații valoroase care ar putea aprofunda ceea ce știm.
Deci, asta înseamnă practic că peisajul analitic a trecut dincolo de depozitarea tradițională a datelor. Structuram în continuare datele în lumea unei combinații de date structurate și multi-structurate, în care datele multi-structurate ar putea veni din interior sau din exteriorul întreprinderii în multe cazuri. Și ca urmare a acestor noi tipuri de date și a noilor nevoi de analizat, am observat apariția unor noi sarcini de lucru analitice - totul, de la analizarea datelor în mișcare, care transformă arhitectura tradițională de depozitare a datelor pe capul său, undeva, unde , în cercurile tradiționale, integrați datele, le-ați curățat, transformat, stocat și analizat. Analizând datele în mișcare, capturăm datele, le integrăm, le pregătim prin analiza și apoi le stocăm. Așadar, există analize cu privire la date înainte de a fi stocate oriunde.
Analizăm complexe datele structurate, poate pentru dezvoltarea modelelor, elaborarea modelelor statistice și predictive, care nu este nimic nou pentru unii oameni dintr-un spațiu tradițional de depozitare a datelor. Avem o analiză exploratorie a datelor din model. Aceasta este cantitatea de date structurate acolo. Avem noi sarcini de muncă sub formă de analiză grafică, care pentru clienții mei din serviciile financiare include lucruri precum frauda. De asemenea, include securitatea cibernetică. Cuprinde rețelele sociale, desigur, care înțeleg influențarii și chestii de genul acesta. Am stăpânit-o chiar în management, are câțiva ani de analiză grafică.
Avem optimizarea sau descărcarea depozitului de date a procesării ETL, care este mai mult un fel de caz de utilizare a IT, CIO ar putea finanța asta. Și chiar arhivarea datelor și a depozitelor de date pentru ao păstra online, în lucruri precum Hadoop. Deci, toate aceste noi sarcini de lucru analitice au adăugat noi platforme, noi platforme de stocare, peisajului analitic. Deci, în loc să avem doar depozite de date tradiționale, marts de date, ceea ce avem acum este Hadoop. Avem baze de date NoSQL, cum ar fi baze de date grafice, care sunt adesea utilizate pentru sarcini analitice. Desigur, putem face acum o analiză a graficului atât pe Hadoop însuși, cât și într-un SGBD grafice NoSQL. Avem analize de streaming pe care le-a menționat Robin. Și avem - dacă doriți - construirea de modele, probabil și pe dispozitivele analitice ale depozitului de date. Dar toate acestea au complicat peisajul analitic, fiind necesare acum mai multe platforme. Și cred că, pentru orice afacere cu o birou sau birou sau finanțe, achiziții, resurse umane și un fel de operațiuni, este să descopăr care sunt proiectele analitice asociate unei scene tradiționale de depozitare a datelor. Și după ce știți că proiectele analitice sunt asociate cu aceste noi platforme de date mari și unde să rulați, știți, care este volumul de muncă analitic, dar să nu pierdeți din vedere afacerea în sensul că acum - veți vedea acum că este o combinație de mari proiecte analitice de date și proiecte tradiționale de depozitare de date mari, care împreună sunt necesare pentru a consolida în interiorul clientului sau în jurul operațiunilor, în jurul riscului, finanțare sau sustenabilitate. Și, prin urmare, dorim ca toate acestea să fie aliniate la prioritățile noastre strategice de afaceri, să rămânem pe direcția, să știți, să împingeți ace care trebuie să fie împingute, știți, pentru a îmbunătăți performanțele afacerii, pentru a reduce costurile, pentru a reduce riscurile etc., știți, pentru compania noastră în ansamblu. Așadar, nu este unul care îl înlocuiește pe celălalt aici cu date mari și tradiționale. Ambele sunt folosite împreună. Și asta schimbă dramatic arhitectura, știi.
Deci, ceea ce am aici este o arhitectură relativ nouă pe care o voi folosi cu clienții mei. Și uite, așa cum puteți vedea acum pe partea de jos, o gamă vastă de surse de date, nu doar structurate. Unele dintre acestea transmit date live precum senzori, cum ar fi datele piețelor, așa ceva. Ar putea fi chiar date în flux live. Ar putea fi date live streaming de video. Deci nu a trebuit să fie structurat. Deci, putem efectua procesarea fluxului pe aceste date pentru a lua măsuri automate în timp real și orice date de interes ar putea fi filtrate și transmise într-o unealtă de instrumente de gestionare a informațiilor care poate fi folosită pentru popularea stocurilor de date analitice. Cu excepția cazului în care puteți vedea în mix aici, acum avem baze de date tradiționale de depozitare a datelor, Hadoop și NoSQL. Avem și managementul principal al datelor în mix. Și asta pune mai multă presiune asupra întregului set de instrumente de gestionare a datelor, nu numai pentru a popula aceste depozite de date, ci pentru a muta datele între ele.
În plus, trebuie să simplificăm instrumentele de acces. Nu putem doar să apelăm la utilizator și să spunem: „obțineți toate aceste stocuri de date, țineți aceste API-uri - problema dvs.”. Ceea ce trebuie să faci este să simplifici accesul. Și, astfel, în liniile punctate de acolo, veți vedea că virtualizarea și optimizarea datelor ascunde complexitatea mai multor stocări de date, încercați să faciliteze accesul utilizatorilor finali la acestea. Și, desigur, există o gamă de instrumente în partea de sus, știi - totul, de la instrumentele tradiționale de BI, care au început să înceapă în partea de sus a depozitării de date, trecând treptat spre stânga graficului tău pentru a te conecta la Hadoops și apoi baze de date NoSQL ale lumii.
Am căutat să obținem un nou contract de închiriere a vieții, în special în jurul datelor structurate, nestructurate ale corpului, care sunt adesea stocate în Hadoop. Avem aplicații analitice personalizate care trebuie realizate pe o platformă Hadoop cu MapReduce, de exemplu cadrul Spark, de exemplu. Avem la dispoziție instrumente de analiză grafică pentru a vă concentra pe sarcini de lucru foarte specifice acolo. Deci, o serie de instrumente și fluxurile de date sunt, de asemenea, mai complexe. Nu mai este doar o stradă unică în depozitul de date. Acum sunt datele de bază, desigur.
Avem noi surse de date, fie că sunt capturate în NoSQL, știți, magazine de date precum MongoDB, precum Cassandra, precum HBase. Avem date aduse direct în Hadoop pentru analiză și pregătirea datelor acolo. Avem informații noi despre Hadoop și depozitele de date. Avem arhivă care vine din depozitele de date în Hadoop. Acum, avem, de asemenea, fluxuri de date, la toate bazele de date NoSQL și marts de date. Așadar, ceea ce puteți vedea aici este, există mult mai multe activități în gestionarea datelor. Și înseamnă că pune software-ul de gestionare a datelor sub presiune considerabilă. Nu mai este doar o stradă unică. Este mișcarea de date cu două sensuri. Se desfășoară mult mai multe activități și, prin urmare, scalabilitatea este importantă atât pe partea de gestionare a datelor, cât și pe sursa de date.
Deci, această diagramă se întoarce la acea arhitectură de care am menționat în urmă cu o clipă. Vă arată diferitele sarcini de lucru analitice care rulează în diferite părți ale acestei arhitecturi. Un fel de din partea de jos stânga, aveți în timp real streaming, procesarea fluxului continuând pe datele care apar, știți, orice fel de magazin de date live. Analiza claselor se întâmplă în bazele de date grafice NoSQL. Se poate întâmpla și pe Hadoop. Cu cadrul Spark, de exemplu, și GraphX acolo, am obținut o analiză investigativă și rafinăria de date despre care Robin vorbea despre întâmplări pe Hadoop. Avem în continuare sarcini tradiționale de lucru și depozitare de date, știți, utilizatorii de energie electrică construind modele statistice și predictive, poate pe aparate de depozit de date. Și încă încercăm să simplificăm accesul la toate acestea pentru a facilita utilizatorii finali.
Deci, succesul în jurul întregii configurații este mai mult decât doar partea analitică. Știți, putem pune platformele analitice la locul lor, dar dacă nu putem capta și ingera, știți, date de mare viteză și volum mare, la scară, nu prea are rost. Știi, nu am nimic de analizat. Așadar, succesul analizelor de date mari necesită o îmbunătățire a sistemelor operaționale. Asta înseamnă că, pentru a putea susține noi tranzacții, știți, vârfuri. Știți, orice date non-tranzacționale capturate acolo ar putea, să știți, noi rate de sosire foarte mari, rate de sosire foarte mari pe date cu viteză mare, precum senzori sau orice ingest. Trebuie să putem să ne ocupăm de toate acestea - pentru a putea capta acest tip de date și pentru a le analiza. De asemenea, trebuie să scalăm analizele în sine, să simplificăm accesul la datele pe care le-am menționat deja. Și apoi, legă asta. Știi, trebuie să putem să ne perfecționăm înapoi la aceste sisteme operaționale pentru a-i oferi o buclă închisă.
Așadar, scalarea laturii operaționale a casei pentru a capta date, știi, intră în lumea bazei de date NoSQL. Adică, aici vedeți cinci categorii de baze de date NoSQL. Aceasta este categoria care va fi modelată doar fiind o combinație a celorlalte patru de mai sus. În general, știți, valorile sale cheie, documentele stocate și bazele de date ale familiilor de coloane - primele trei de acolo - care sunt utilizate pentru mai multe tipuri de date tranzacționale și non-tranzacționale.
Unele dintre bazele de date care susțin ca proprietăți; unii dintre ei nu. Cu toate acestea, știți, vedem introducerea acestora pentru a pune la scară acele tipuri de aplicații. Și, de exemplu, pe măsură ce ne-am îndepărtat doar de angajații care efectuează tranzacții la tastaturi, clienții de acum și masele care folosesc dispozitive noi pentru a putea face acest lucru. Am observat o creștere extraordinară a numărului de tranzacții efectuate în întreprinderi. Și deci, trebuie să scalăm aplicațiile tranzacționale pentru a face acest lucru.
Acum, în general, se poate realiza pe bazele de date NewSQL ca bază de date relațională precum NuoDB și VoltDB prezentată aici. Sau unele dintre bazele de date NoSQL care acceptă proprietățile ACID care pot garanta procesarea tranzacțiilor pot fi în joc. Acest lucru este valabil și pentru datele non-tranzacționale, cum ar fi datele despre coșul de cumpărături înainte de o tranzacție, știți, înainte ca oamenii să cumpere chestii, date despre senzori, știți, deoarece pierd o lectură a senzorului printre sute de milioane de lecturi ale senzorilor. Nu e mare lucru. Clienți, știți, în lumea clickstream - dacă folosesc un clic, nu este mare lucru.Deci, știți, nu avem nevoie neapărat să avem proprietăți ACID acolo și, adesea, acolo unde intră în joc bazele de date NoSQL, a fost acolo - această capacitate de a face o procesare foarte mare, corectă la scară, pentru a capta aceste noi tipuri de date.
În același timp, dorim ca analitica să mărească. Și deci, tragerea datelor din depozitele de date către platformele analitice nu va mai fi afectat, deoarece datele sunt prea mari. Ceea ce ne dorim cu adevărat este să împingem analitica pe de altă parte, în depozitul de date al companiei în Hadoop, în procesarea fluxului pentru a putea împinge analitica către date. Cu toate acestea, doar pentru că cineva spune că se află în analiza bazelor de date sau în analiza Hadoop, nu înseamnă neapărat că analiza se execută în paralel. Și sincer, dacă veți investi în aceste noi tehnologii scalabile masiv paralele, cum ar fi Hadoop, cum ar fi aparatele pentru depozitul de date și, nu, precum motoarele de procesare a fluxurilor în grup, avem nevoie ca analizele să funcționeze în paralel.
Deci, acesta este doar check-out-ul. Știi, dacă avem la dispoziție analize care să ajute la prezicerea lucrurilor pentru clienți, pentru operațiuni, pentru riscuri etc., dorim ca acestea să funcționeze în paralel, nu doar să ruleze în platformă. Ne dorim amândoi. Și asta pentru că, știți, tehnologia este ca și aceste noi instrumente de descoperire vizuală, precum SAS. Este de fapt unul dintre sponsorii noștri aici.
Un lucru pe care oamenii îl doresc este cel puțin să-i exploateze pe cei din Hadoop și apoi în analiza bazelor de date. Și dorim ca acestea să funcționeze în paralel pentru a putea oferi performanța necesară pe volumele de date atât de mari. În același timp, încercăm să simplificăm accesul la toate acestea. Și deci, SQL este din nou pe ordinea de zi. Știi, SQL este - SQL pe Hadoop este fierbinte chiar acum. Îl urmăresc în 19 inițiative SQL și Hadoop în acest moment. În plus, puteți vedea, putem obține la aceste date, știți, într-o serie de moduri, astfel încât accesând direct SQL chiar Hadoop, putem merge SQL la un index de căutare. În acest fel, cum ar fi, unii dintre furnizorii de căutare din spațiul respectiv, putem avea acces SQL la baze de date relaționale analitice care au tabele Excel către Hadoop.
Acum putem avea acces SQL la un server de virtualizare a datelor care poate fi conectat el însuși la un depozit de date de pe Hadoop. Chiar acum încep să văd apariția accesului SQL la date live streaming. Deci, accesul SQL la toate acestea crește rapid. Și o parte a provocării este, doar pentru că accesul SQL este comercializat acolo. Întrebarea este: SQL poate face față cu date complexe? Și acest lucru nu este neapărat simplu. Există tot felul de complicații aici, inclusiv faptul că datele JSON ar putea fi cuibate. Putem avea înregistrări de variante de schemă. Deci, prima înregistrare a primit o schemă. A doua înregistrare a primit o schemă diferită. Aceste lucruri sunt foarte diferite de ceea ce se întâmplă într-o lume relațională.
Deci, trebuie să ne punem întrebări despre ce tip de date încercăm să analizăm și care sunt tipurile de caracteristici analitice. Panoul pe care vrei să-l faci? Este învățare automată? Este analiză grafică? Poți face asta din SQL? Știi, este invocabil din SQL? Câți utilizatori concurenți am făcut acest lucru? Știi, avem sute de utilizatori simultan. Este posibil acest lucru pe date complexe? Știi, toate aceste lucruri sunt întrebări cheie. Deci, am făcut o listă cu câteva pe care cred că ar trebui să le iei în considerare. Știi, ce fel de formate de fișiere? Despre ce tipuri de date vorbim? Ce fel de funcții analitice putem invoca din SQL pentru a obține date complexe? Și felul de funcții funcționează în paralel. Adică, trebuie să funcționeze în paralel dacă trebuie să reușim să le scalăm. Și pot alătura date în Hadoop astăzi în afara acestora, știți, sau asta nu este posibil? Și ce voi face cu toate aceste tipuri diferite de sarcini de lucru?
Și așa cum vom vedea, știți, din ceea ce am văzut, există o mulțime de diferențe între distribuția SQL și Hadoop. Acestea sunt toate cele pe care le urmăresc. Și, apropo, acesta este SQL pur pe Hadoop. Aceasta nu include chiar virtualizarea datelor în acest moment. Și uite, există multe locuri de consolidare, ceea ce cred că se va întâmpla în următorul an, optsprezece luni. Dar, de asemenea, se deschide un alt lucru, care este că pot avea potențial mai multe motoare SQL pe aceleași date din Hadoop. Și asta este ceva ce nu ai putea face în relațional.
Desigur, asta înseamnă că trebuie să știi, ce știu, ce fel de volum de muncă de interogare rulez? Ar trebui să o execut pe lot pe un anumit SQL din inițiativa Hadoop? Ar trebui să rulez sarcini de lucru interactive de interogare printr-un alt SQL din inițiativa Hadoop etc., astfel încât să știu la care să mă conectez? În mod ideal, desigur, nu ar trebui să facem asta. Ar trebui să punem doar o întrebare în acest sens. Știi, unele optimizatoare sunt cele mai bune modalități de a face acest lucru. În opinia mea, nu suntem încă pe deplin acolo.
Dar, totuși, și virtualizarea datelor, am menționat anterior, are un rol foarte important în simplificarea accesului la mai multe magazine de date. Și dacă creăm noi informații despre Hadoop, este cu siguranță plauzibil pentru noi să ne alăturăm acele date-la-date și depozite de date tradiționale prin virtualizarea datelor, de exemplu, fără a ne deplasa neapărat datele de la Hadoop în depozitele de date tradiționale. Desigur, puteți face și asta. De asemenea, este plauzibil dacă arhivez date din depozitele de date tradiționale în Hadoop. Încă pot să mă accesez și să mă alătur lucrurilor din depozitul nostru de date pentru virtualizarea datelor. Deci, pentru mine, cred că virtualizarea datelor are un viitor mare în această arhitectură de ansamblu și simplificarea accesului la toate aceste magazine de date.
Și să nu uităm că atunci când creăm aceste idei noi, indiferent dacă este vorba de sisteme relaționale sau NoSQL, totuși vrem să readucem aceste informații în operațiunile noastre, astfel încât să putem maximiza valoarea a ceea ce am găsit, astfel încât să putem susțineți acest lucru pentru a lua decizii mai eficiente și mai oportune în acel mediu pentru a ne optimiza activitatea.
Deci, pentru a încheia, ceea ce văd, atunci, avem nevoie, știți, de noi surse de date care apar. Avem noi platforme pe o arhitectură mai complicată, dacă doriți, să ne descurcăm. Iar Hadoop devine foarte, foarte important, suficient pentru pregătirea datelor pentru cutiile noastre de nisip lichide, pentru interogarea de arhivă, arhiva din depozitul de date, managementul de date care își întinde aripile pentru a depăși stocarea de date în gestionarea datelor pe toate aceste platforme și instrumente noi pentru a fi capabil să analizeze și să acceseze datele din aceste medii, să poată avea tehnologii scalabile pentru a face mai bine ingerarea datelor și scalarea analizelor prin împingerea lor în jos pe platforme pentru a le face mai paralele. Și, sperăm, să simplificăm și accesul la toate prin intermediul SQL-ului emergent care vine din partea de sus. Așadar, vă oferă o idee despre felul în care ne îndreptăm. Deci, cu asta, voi trece înapoi, cred, Eric acum, nu?
Eric: Bine, este fantastic. Și oameni, trebuie să spun, între ceea ce tocmai ați obținut de la Robin și Mike, este probabil la fel de cuprinzător și concis în prezentarea generală a întregului peisaj, de la a privi cum veți găsi oriunde. Lasă-mă să merg mai departe și să fac coadă la început pe George Corugedo. Și acolo este. Lasă-mă să iau asta pentru o secundă rapidă. Bine, George, sunt pe cale să vă predau cheile și să o iau. Etajul este al tău.
George: Grozav! Mulțumesc foarte mult, Eric, și mulțumesc, Rob și Mike. Aceasta a fost o informație excelentă și o mulțime de care suntem de acord. Deci, revenind la discuția lui Robin, pentru că, știți, nu este o coincidență că RedPoint este aici și SAS este aici. Deoarece RedPoint, ne concentrăm cu adevărat pe partea de date a acesteia pe guvernare, pe prelucrarea datelor și pregătirea pentru utilizare în analiză. Așadar, permiteți-mi să bargez prin aceste două diapozitive. Și vorbim cu adevărat despre punctele lui Robin despre MDM și despre cât de important este acesta, și cât de util, cred și credem că Hadoop poate fi în lumea MDM și a calității datelor.
Știi, Robin vorbea un pic despre, știi, cum se leagă asta de lumea depozitului de date despre întreprinderi și vin - știi, am petrecut câțiva ani la Accenture. Și ceea ce a fost interesant este de câte ori a trebuit să intrăm în companii și să încercăm să ne dăm seama ce să facem cu depozitul de date care practic fusese abandonat. Și o mulțime de lucruri s-au întâmplat deoarece echipa de la depozitul de date nu și-a aliniat construirea cu utilizatorii de afaceri sau cu consumatorii de date. Sau, a durat atât de mult, încât până la momentul în care au construit lucrul, utilizarea afacerii sau rațiunea de business pentru aceasta a evoluat.
Și unul dintre lucrurile care cred că este, sunt atât de entuziasmat, ideea de a utiliza Hadoop pentru managementul datelor master, pentru calitatea datelor și pentru pregătirea datelor, este faptul că puteți întoarce întotdeauna la datele atomice într-o Lacul de date Hadoop sau rezervorul de date, sau depozitul de date, sau hub-ul, sau orice alt mod de buzz pe care doriți să îl utilizați. Dar pentru că păstrați întotdeauna aceste date atomice, atunci aveți întotdeauna ocazia să vă aliniați cu utilizatorii companiei. Pentru că, ca analist - pentru că de fapt am început cariera mea de statisticist - știi, nimic nu este mai rău decât, știi, depozitele de date ale întreprinderii sunt minunate pentru conducerea rapoartelor, dar dacă vrei să faci analize cu adevărat predictive, acestea sunt într-adevăr nu este atât de util, pentru că ceea ce dorești cu adevărat sunt datele comportamentale granulare, care cumva au fost rezumate și agregate în depozitul de date. Așadar, cred că aceasta este într-adevăr o caracteristică importantă, iar un lucru pe care cred că l-aș putea fi în dezacord cu Robin este acela că personal aș lăsa datele în lacul de date sau în centrul de date cât mai mult timp, deoarece datele sunt acolo și sunt curate, îl puteți privi dintr-o direcție, o altă direcție. Îl puteți contopi cu alte date. Aveți întotdeauna această ocazie să vă întoarceți la ea și să vă restructurați, apoi să vă aliniați cu o unitate de afaceri și cu nevoia pe care o poate avea această unitate.
Unul dintre celelalte tipuri de lucruri interesante în acest sens este că, deoarece este o platformă de calcul atât de puternică, o mulțime de volumul de lucru despre care am vorbit, vedem că totul vine direct în Hadoop. Și, în timp ce, cred, Mike vorbea despre toate diferitele tehnologii care există în lumea - în acest tip de ecosistem de date mari, credem că Hadoop este într-adevăr pasul de lucru pentru a face acea scară largă în procesarea intensivă a calculului care calitatea principală a datelor și calitatea datelor necesită. Pentru că, dacă o puteți face acolo, știți, doar economia pură a mutării datelor din bazele de date scumpe și către bazele de date economice, acest lucru este cu adevărat cel care conduce la o mare parte a absorbției chiar acum în întreprinderile mari.
Acum, desigur, există câteva provocări, nu? Există provocări în jurul tehnologiilor. Mulți dintre ei sunt foarte imaturi. V-aș spune, știți, nu știu câte, dar o serie de tehnologii pe care le-a menționat Mike sunt încă pe versiuni zero, ceva nu, nu? Deci, aceste tehnologii sunt foarte tinere, foarte imature, încă bazate pe coduri. Și asta creează într-adevăr o provocare pentru întreprinderi. Și ne concentrăm cu adevărat pe rezolvarea problemelor la nivelul întreprinderii. Și deci, credem că trebuie să existe un mod diferit, iar ceea ce propunem noi este un mod diferit de a aborda unele dintre lucrurile în folosirea unor tehnologii foarte născute.
Și uite, și apoi cealaltă problemă interesantă aici, care a fost menționată anterior, care este, atunci când aveți date pe care le capturați într-un mediu Hadoop de orice tip, știți, de obicei, aceasta este schema pe citit, mai degrabă decât pe schema pe scriere cu unele excepții. Și această lectură, o mare parte din ea este realizată de statisticieni. Și, astfel, statisticienii trebuie să aibă instrumente care să le permită structurarea corectă a datelor în scopuri analitice, deoarece la sfârșitul zilei, pentru a face datele utile, trebuie structurate într-o formă pentru a vedea unele sau a răspunde la o întrebare sau o afacere, un tip de afacere, creează valoare de afaceri.
Așadar, acolo unde intrăm, este faptul că avem o aplicație EPL foarte bazată și matură, cu cheie de management al calității datelor și ELT. Este pe piață de mulți, mulți ani. Și are toată funcționalitatea sau o mare parte din funcționalitățile pe care Robin le-a enumerat în acel grafic circular - totul, de la doar captarea pură a datelor brute într-o varietate întreagă de formate și structuri XML și ce nu, până la capacitatea de a face toate curățările, completarea datelor, corectarea datelor, biții de bază geospatiali ai datelor. Acest lucru este din ce în ce mai important în aceste zile cu Internet of Things. Știi, există o geografie asociată cu mare parte din ceea ce facem sau o mare parte din aceste date. Și tot așa, toate procesarea, tokenizarea, curățarea, corectarea, formatarea, structurarea, etc., toate acestea se fac în platforma noastră.
Și atunci, și poate, ne gândim cel mai important este ideea deduplicării. Știi, în esență, dacă te uiți la orice definiție a managementului datelor master, nucleul acesteia este deduplicarea. Este capabil să identifice entitățile din diferite surse de date și apoi să creeze o înregistrare principală pentru entitatea respectivă. Iar entitatea respectivă ar putea fi o persoană. Entitatea ar putea face parte dintr-un avion, de exemplu. Entitatea ar putea fi un aliment așa cum am făcut-o pentru unul dintre clienții clubului nostru de sănătate. Am creat o bază de date cu produse alimentare principale. Deci, oricare ar fi entitățile cu care lucrăm - și, desigur, din ce în ce mai mult, există oameni și reprezentanți pentru identitățile lor, care sunt lucruri precum mânerele sociale sau conturile, indiferent de dispozitive care sunt asociate cu oameni, unele lucruri precum mașinile și telefoane și orice altceva v-ați putea imagina.
Știi, lucrăm cu un client care pune tot felul de senzori în îmbrăcăminte sport. Deci, datele provin din toate direcțiile. Și într-un fel sau altul, este o reflecție sau o reprezentare a entității de bază. Și din ce în ce mai mult, acesta este oamenii și capacitatea de a identifica relațiile dintre toate aceste surse de date și modul în care se raportează la acea entitate de bază, și apoi să poți urmări acea entitate de bază în timp, astfel încât să poți analiza și înțelege schimbările dintre acea entitate și toate celelalte elemente care sunt în reprezentările acelei entități, o analiză cu adevărat critică pentru analiza pe termen lung și longitudinal a oamenilor, de exemplu. Și acesta este într-adevăr unul dintre avantajele cu adevărat importante pe care ni le pot oferi datele mari este o mai bună înțelegere a oamenilor și, pe termen lung, și să înțelegem con și cum se comportă oamenii atunci când se comportă prin ce dispozitive etc. .
Deci, permiteți-mi să trec aici rapid. Eric a menționat YARN. Știi, arunc asta doar pentru un pic de o secundă, pentru că în timp ce YARN - oamenii vorbesc despre YARN. Există încă o mulțime de ignoranță, cred eu, despre FILAT. Și nu o mulțime de oameni cu adevărat - încă există o mulțime de neînțelegeri cu privire la fire. Cert este că, dacă aplicația dvs. a fost arhivată în mod corect și aveți un nivel sau o paralelizare adecvată în arhitectura aplicației dvs., atunci puteți profita de YARN pentru a utiliza Hadoop ca platformă de scalare. Și asta este exact ceea ce am făcut.
Știi, din nou, doar pentru a sublinia unele dintre definițiile din jurul YARN. Pentru noi, ceea ce este YARN ne-a permis pentru noi și alte organizații să devenim colegi la MapReduce și Spark și la toate celelalte instrumente care există. Cert este că aplicațiile noastre conduc cod optimizat direct în YARN în Hadoop. Și există un comentariu cu adevărat interesant, pe care Mike l-a menționat, pentru că, știți, întrebarea despre analiză și analitica noastră, doar pentru că sunt în cluster, funcționează într-adevăr în paralel? Puteți pune aceeași întrebare despre o mulțime de instrumente de calitate a datelor aflate acolo.
În cea mai mare parte a zilei, instrumentele de calitate care sunt acolo trebuie să scoată datele fie că împing codul. Și, în multe cazuri, este un singur flux de date care este procesat din cauza modului în care trebuie comparați înregistrările, uneori în tipul de activități de calitate a datelor. Cert este că, deoarece folosim YARN, am putut profita cu adevărat de paralelizare.
Și doar pentru a vă oferi o imagine de ansamblu rapidă, deoarece se face un alt comentariu despre importanța de a putea extinde bazele de date tradiționale, noi baze de date etc., le implementăm sau instalăm în afara clusterului. Și ne împingem binarele direct în managerul de resurse, YARN. Și asta, apoi YARN o distribuie pe nodurile din cluster. Și ceea ce face este faptul că YARN - permitem YARN să-și gestioneze și să-și facă treaba, care este să ne dăm seama unde se află datele și să preia munca la date, codul la date și să nu mișcă datele. Când auziți instrumente de calitate a datelor și vă spun că cea mai bună practică este să mutați datele din Hadoop, să alergați pentru viața dvs., deoarece nu este așa cum este. Doriți să duceți lucrările la date. Și asta face în primul rând YARN. Ne duce binarele către nodurile unde se află datele.
Și, de asemenea, pentru că ne aflăm în afara clusterului, putem accesa și toate bazele de date tradiționale și relaționale, astfel încât să putem avea joburi care sunt 100% server client pe o bază de date tradițională, 100% Hadoop sau joburi hibride care trec pe serverul client Hadoop. , Oracle, Teradata - orice doriți și toate în același job, deoarece acea implementare poate accesa ambele părți ale lumii.
Și apoi, revenind la întreaga idee a nașterii instrumentelor, vedeți aici, aceasta este doar o simplă reprezentare. Și ceea ce încercăm să facem este să simplificăm lumea. Și modul în care facem asta este prin aducerea unui set foarte larg de funcționalități în jurul HDFS pentru a-l face ... Și nu pentru că încercăm să eliminăm toate tehnologiile inovatoare de acolo. Doar că întreprinderile au nevoie de stabilitate și nu le plac soluțiile bazate pe coduri. Și deci, ceea ce încercăm să facem este să oferim întreprinderilor un mediu de aplicație familiar, repetabil și consistent, care să le ofere capacitatea de a construi și prelucra date într-un mod foarte previzibil.
Repede, acesta este tipul de impact pe care îl obținem cu aplicația noastră. Puteți vedea MapReduce vs. Pig vs. RedPoint - fără linii de cod în RedPoint. Șase ore de dezvoltare la MapReduce, trei ore de dezvoltare în Pig și 15 minute de dezvoltare în RedPoint. Și acolo avem un impact foarte mare. Timpul de procesare este de asemenea mai rapid, dar timpul oamenilor, timpul de productivitate al oamenilor, este semnificativ crescut.
Și ultima mea diapozitivă aici, vreau să mă întorc la această idee, deoarece aceasta este preluarea noastră folosind un lac de date sau un hub de date, sau o rafinărie de date ca punct central de ingerare. Nu puteam fi de acord mai mult cu această idee. Și suntem în prezent în discuții cu o mulțime de ofițeri șef de date ale marilor bănci globale, iar aceasta este arhitectura aleasă.Ingestia de date din toate sursele realizează procesarea calității datelor și gestionarea datelor master din lacul de date, apoi împinge datele unde trebuie să meargă pentru aplicații de asistență, pentru a suporta BI, orice ar fi. Și atunci, dacă aveți analize în BI, acestea pot rula direct în interiorul lacului de date, unde este mai bine, care poate începe imediat. Dar foarte mult la bord cu această idee. Această topologie este una care este - pe care o constatăm că câștigă multă tracțiune pe piață. Si asta e.
Eric: Bine, bine. Să mergem chiar aici. O să merg înainte și o predau lui Keith. Și, Keith, ai vreo 10, 12 minute să stângi casa aici. Ne-am luat să mergem un pic mai mult în aceste spectacole. Și am făcut reclamă pentru 70 de minute pentru acesta. Așadar, pur și simplu mergeți înainte și faceți clic pe oriunde pe acest diapozitiv și folosiți săgeata în jos și scoateți-o.
Keith: Sigur. Nicio problemă, Eric. Apreciez asta. Voi merge înainte și voi ajunge doar câteva bucăți despre SAS, apoi mă voi muta în direct în arhitecturile tehnologice în care SAS se intersectează cu lumea datelor mari. Sunt multe de explicat în toate aceste lucruri. Am putea petrece ore întregi parcurgând-o în mare detaliu, dar zece minute - ar trebui să fiți capabili să vă îndepărtați doar de o scurtă înțelegere a locului în care SAS a preluat analiza, managementul datelor și tehnologiile de business intelligence în această lume de date.
În primul rând, doar un pic despre SAS. Dacă nu sunteți familiarizați cu această organizație, în ultimii 38 de ani, efectuăm analize avansate, informații de afaceri și gestionare a datelor, nu numai cu date mari, ci cu date mici și bogăție de date în ultimii 38 de ani. Avem un picior enorm de client existent, aproximativ 75.000 de site-uri din întreaga lume, care lucrează cu unele dintre cele mai importante organizații de acolo. Suntem o organizație privată cu aproximativ 13.000 de angajați și venituri de 3 miliarde de dolari. Și chiar cred, partea importantă este că am avut, în mod tradițional, o istorie de lungă durată a reinvestirii unor sume importante din veniturile noastre în organizația noastră de cercetare și dezvoltare, ceea ce a adus într-adevăr o mare parte din aceste tehnologii și platforme uimitoare pe care le aveți ” o să văd astăzi.
Deci, voi sări direct în aceste diagrame de arhitectură cu adevărat înfricoșătoare. Vom lucra de la stânga la dreapta în diapozitivele mele. Deci, există lucruri familiare pe care le veți vedea în această platformă. În partea stângă, toate acele surse de date despre care vorbim despre ingerarea în aceste platforme de date mari. Și atunci, ai această platformă de date mare.
Nu am pus doar cuvântul Hadoop acolo în vârf, pentru că, în cele din urmă, exemplele pe care le voi oferi astăzi se referă în special la toate tehnologiile în care ne intersectăm cu aceste platforme de date mari. Hadoop se întâmplă să fie unul dintre cele în care avem unele dintre cele mai robuste opțiuni de implementare, dar, de asemenea, ne intersectăm destul de mult și am dezvoltat o mulțime de aceste tehnologii de ceva timp cu unii dintre ceilalți parteneri ai noștri de la depozitul de date, precum Teradata, Oracle, Pivotal și altele asemenea. Așadar, nu pot intra în detalii grozave, deoarece toate tehnologiile diferite sunt acceptate pe platforma, dar sunt sigur că toate cele pe care le descriu astăzi sunt în mare parte tot ceea ce Hadoop și o mare parte dintre ele se intersectează cu alți parteneri tehnologici care noi avem. Deci, avem platforma atât de mare care stă acolo.
Următorul, la dreapta, avem serverul nostru analitic SAS LASR. Acum, asta este în esență un paralel masiv în serverul de aplicații analitice de memorie. Vom fi clar că nu este o bază de date în memorie. Este într-adevăr proiectat de la început. Nu este motorul de interogare, ci proiectat pentru a furniza cereri analitice la scară masivă într-un mod masiv paralel. Deci, acestea sunt aplicațiile cheie de serviciu pe care le vedeți acolo pe partea dreaptă.
Vom încerca un pic în cum ar fi, cum știi, modul în care oamenii desfășoară aceste lucruri. Dar în esență, aplicația - vedeți voi acolo - prima, este analiza noastră SAS de înaltă performanță. Asta va fi - folosesc o mulțime de tehnologii și platforme existente, cum ar fi Enterprise Miner sau doar un SAS, și nu fac doar multithreading cu unii dintre acei algoritmi pentru care am integrat aceste instrumente pentru care am făcut ani, dar și să le paralelez masiv pe cele. Deci, pentru a muta datele din acea mare platformă de date în spațiul de memorie către serverul LASR Analytic, astfel încât să putem executa algoritmi analitici - știți, o mulțime de noi sisteme de învățare a mașinilor, plase neuronale, regresii aleatoare de pădure, tipuri de lucruri - din nou, datele care stau în memorie. Așadar, a scăpa de acel anumit blocaj de paradigmă MapReduce unde ne-am înaintat în acele platforme, acesta nu este modul în care doriți să faceți lucrări analitice. Așadar, dorim să putem să ridicăm datele o dată în spațiul de memorie și să îl repetăm prin ele, știți, uneori de mii de ori. Deci, acesta este conceptul de a folosi acel server LASR Analitic de înaltă performanță.
De asemenea, noi - celelalte aplicații de sub acesta, analitica vizuală, care ne permite să persistăm acele date în memorie și să oferim o populație mai mare pe aceleași date. Așadar, permițându-le oamenilor să facă explorări de date mari. Deci, înainte de a face lucrările noastre de dezvoltare a modelelor, explorăm date, înțelegem, rulăm corelații, facem previziuni sau trending arbori de decizie - acele tipuri de lucruri - dar într-un mod foarte vizual, interactiv, pe datele care stau în memorie. platformă. Aceasta oferă, de asemenea, comunității noastre de BI în măsura în care au o bază foarte largă de utilizatori care pot atinge acea platformă pentru a face tipuri de înregistrare standard pe care le vedeți - ceea ce este aproape, știți, vânzător de BI acolo.
Următorul pas, vom trece apoi în serviciu. Și pentru a-i ajuta pe statistici și pe oamenii noștri de analiză să poată face acest tip de modelare ad-hoc cu date așezate în memorie, eliminate din analitice vizuale și explorare în aplicația noastră de statistici vizuale. Aceasta este o oportunitate pentru oameni de a lua, de a nu rula statistici în loturi care obișnuiau să repete, să ruleze modelele, să vadă rezultatele. Deci, asta poate rula modelul, vezi rezultatele. Acest lucru înseamnă să trageți și să vă încadrați vizual în modelarea statistică interactivă. Deci, acest lucru oferă statisticienilor noștri și oamenilor de știință ai datelor noastre să facă o mulțime din acea muncă de statistică vizuală exploratorie timpurie.
Și atunci nu ne-am uitat codificatorii - oamenii care doresc cu adevărat să aibă, să fie capabili să curgă straturile de interfață opuse, este să scrie aplicații și să scrie propria bază de cod în SAS. Și acestea sunt statisticile noastre în memoria pentru Hadoop. Și acesta este - în esență, stratul de cod care ne-a permis să interacționăm cu acel server LASR Analitic pentru a emite comenzi direct și personaliza acele aplicații pe baza solicitării noastre. Aceasta este piesa analitică.
Cum se instalează aceste lucruri ... Oh, îmi pare rău. Acolo mergem.
Deci, există într-adevăr câteva moduri în care facem acest lucru. Una dintre ele este să o faci cu date mari - în acest caz, cu Hadoop. Și de acolo avem acel server SAS LASR Analytic care rulează într-un grup separat de mașini care sunt optimizate pentru analiza hardcore. Acest lucru este amplasat frumos și apropiat de platforma de date mare, permițându-ne să o scalăm separat de platforma de date mare. Deci, vedem oamenii care fac acest lucru atunci când nu vor să aibă un fel de ceea ce caracterizez ca un software vampir care mănâncă la fiecare dintre nodurile din clusterul Hadoop. Și nu fac neapărat o scară a acelei platforme de date mari adecvate pentru realizarea de analize de memorie grele. Așadar, este posibil să aveți 120 de noduri din clusterul Hadoop, dar acestea ar putea avea 16 noduri de servere analitice care sunt proiectate pentru a face acest tip de lucru.
Încă avem voie să menținem acel paralelism din marea platformă de date pentru a trage datele în memorie. Deci, este cu adevărat o utilizare a SAS cu platforma Hadoop. Un alt model de numire este să spunem, bine, putem folosi și acea platformă de mărfuri și împingem asta - în mod esențial, rulăm Serverul LASR Analitic pe platformele Hadoop. Așadar, acolo suntem unde… operați în interiorul platformei de date mari. Acesta este, de asemenea, unii dintre alți furnizori de aparate. Deci, aceasta ne-a permis să folosim în esență acea platformă de marfă pentru a face acest lucru.
Vedem că, mai des, cu lucruri precum analitice de înaltă performanță, unde este vorba de un tip de analiză cu o singură servire sau de o singură utilizare, mai mult un lot orientat unde sunteți - nu doriți să consumați neapărat spațiul de memorie de la Hadoop platformă. Suntem foarte flexibili la acest tip de model de implementare, cu siguranță în colaborarea cu YARN în multe din aceste cazuri pentru a ne asigura că jucăm clustere frumoase.
Bine, deci asta este lumea analitică, doar pentru a fi clar acolo cu aplicația analitică. Am menționat însă că SAS este de asemenea o platformă de gestionare a datelor. Și există lucruri potrivite pentru a împinge logica în acea platformă, acolo unde este cazul. Deci, există câteva moduri în care facem asta. Unul se află în lumea integrării datelor, este posibil ca lucrările de transformare a datelor pe date să nu aibă sens să le retragem așa cum am mai auzit, rulând rutine de calitate a datelor, care sunt mari. Vrem să împingem cu siguranță lucrurile precum rutinele calității datelor în acea platformă. Și apoi, lucruri precum punctarea modelelor. Deci, mi-am dezvoltat modelul. Nu vreau să rescriu acel lucru în MapReduce și să-mi fac dificil și consumat timp să refac acea lucrare în platforma de baze de date native.
Așadar, dacă te uiți, de exemplu, la acceleratorul nostru de punctaj pentru Hadoop, care ne permite să luăm în esență un model și să împingem logica matematică SAS în acea platformă Hadoop și să o executăm acolo, folosind paralelismul din interiorul acelei mari platforme de date. Avem apoi acceleratorul nostru de cod pentru diverse platforme, inclusiv Hadoop, și asta ne permite să rulăm în esență codul pasului de date SAS în interiorul platformei într-un mod masiv paralel - deci, făcând lucrări de transformare a datelor în platformă. Și apoi acceleratorul nostru de calitate a datelor SAS, care ne permite să avem o bază de cunoștințe de calitate așezată acolo, care poate face lucruri precum potrivirea de gen, codul de potrivire de standardizare - toate lucrurile diferite de calitate a datelor pe care le-ați auzit deja azi.
Și apoi, ultima piesă, există Data Loader. Știm că utilizatorii noștri de afaceri vor trebui să fie capabili să nu fie nevoiți să scrie cod, transformarea datelor funcționează în aceste platforme de date mari. Data Loader este un GUI WYSIWYG frumos, care ne permite să împachetăm aceste alte tehnologii împreună. Este ca un vrăjitor care să explice, să spună, să execute o interogare Hive sau să ruleze o rutină de calitate a datelor și să nu fie necesar să scrie cod în acest caz.
Ultimul lucru pe care îl menționez este această piesă din față. Avem - așa cum am menționat anterior - un masiv SAS de acolo, în lume. Și asta, nu putem face în mod necesar ca toate acele platforme care sunt acolo să se afle imediat în acest spațiu. Deci, cu siguranță avem un picior de utilizatori existenți care trebuie să obțină date care stau în aceste platforme de date mari, cum ar fi scoaterea datelor din Teradata și refacerea acestora în Hadoop și invers. Rularea modelelor deja știu să rulez pe serverele SAS, dar trebuie să obțin date care sunt acum plasate în platforma Hadoop. Așadar, există această altă pictogramă numită „de la” și care ne permite să ne conectăm folosind motoarele noastre de acces SAS - motoarele de acces către Hadoop la Cloudera în Pola, Teradata, Greenplum până la… Și lista continuă. Acest lucru ne permite să folosim platformele noastre SAS mature, existente deja pentru a obține date de pe aceste platforme, să facem munca pe care trebuie să o realizăm, să împingem rezultatele în aceste domenii.
Ultimul lucru pe care îl menționez este că toate aceste tehnologii pe care le vedeți sunt toate guvernate de același metadat comun standard. Așadar, vorbim despre obținerea lucrărilor de transformare, regula calității datelor la locul de muncă, mutarea acesteia în memorie pentru a putea face analize, dezvoltarea modelului în notare. Avem acolo întregul stil de viață analitic, ciclul de viață fiind guvernat de metadate comune, de guvernare, de securitate, de toate lucrurile despre care am vorbit mai devreme astăzi.
Deci, doar o recapitulare, există într-adevăr aceste trei lucruri mari de îndepărtat acolo. Primul lucru este că putem trata platforma de date la fel ca oricare altă sursă de date, trăgând de la ele, apăsând spre ele atunci când este potrivit și convenabil. Putem lucra cu acele mari platforme de date, listând datele într-o analiză avansată construită special în platforma de memorie. Deci, acesta este serverul LASR.
Și apoi, în sfârșit, putem lucra direct în acele platforme de date mari, valorificând capacitățile de procesare distributivă fără a muta datele.
Eric: Ei, sunt lucruri fantastice, oameni buni. Da, este minunat! Așadar, să ne scufundăm corect la unele întrebări. De obicei mergem cu aproximativ 70 de minute sau puțin mai mult la aceste evenimente. Deci, văd că avem încă o audiență grozavă care stă acolo. George, cred că îți voi trimite prima întrebare. Dacă vorbești despre împingerea sunetului tău binar în Hadoop, cred că asta mi se pare că ai optimizat cu adevărat fluxul de lucru computațional. Și aceasta este întreaga cheie pentru a putea face aceste tipuri de guvernare a datelor în timp real, realizări ale stilului de calitate a datelor, deoarece aceasta este valoarea pe care doriți să o obțineți, nu? Dacă nu doriți să vă întoarceți la vechea lume a MDM, unde este foarte greoaie și necesită foarte mult timp, și trebuie să forțați oamenii să acționeze în anumite moduri, ceea ce aproape că nu funcționează niciodată. Și deci, ceea ce ai făcut este, ai condensat ciclul a ceea ce a fost. Să o numim zile, săptămâni, uneori chiar luni până la secunde, nu? Asta se întâmplă?
George: Așa este corect, deoarece amploarea pe care o obținem și performanțele pe care le obținem dintr-un cluster este într-adevăr uluitor în ceea ce privește, doar știi, întotdeauna sunt puțin șovăitor în ceea ce privește punctele de referință. Dar doar pentru ordinea de amploare, când am rula un miliard, 1,2 miliarde de înregistrări și am face o standardizare completă a adreselor - spun mașina HP de gamă mijlocie - ar fi nevoie, ca să știi, opt mașini procesoare, știi Știi, 2 tranșe de memorie RAM pe nucleu ar trebui să dureze 20 de ore. Putem face asta în aproximativ opt minute acum pe un cluster cu 12 noduri. Și deci, amploarea procesării pe care o putem face acum este atât de dramatică diferită - și merge foarte bine cu ideea că aveți toate aceste date la dispoziție. Deci, nu este atât de riscant să faci procesarea. Dacă ai făcut-o greșit, o poți reface. Ai timp, știi. S-a schimbat într-adevăr amploarea acestei situații în care, știți, aceste tipuri de riscuri au devenit cu adevărat probleme de afaceri pentru oameni atunci când încercau să opereze soluții MDM. Trebuie să aveți 30 de oameni în larg, care fac guvernarea datelor și tot. Și deci, mai trebuie să aveți o parte din asta, dar viteza și scara la care o puteți prelucra acum, vă oferă într-adevăr mult mai mult spațiu de respirație.
Eric: Da, acesta este un punct foarte bun. Îmi place acest comentariu. Așadar, aveți timp să o refăți din nou. Este fantastic.
George: Da.
Eric: Ei bine, schimbă dinamica, nu? Se schimbă modul în care gândiți ce veți încerca. Adică, îmi amintesc de asta acum 18 ani în industria de a face efecte speciale, pentru că am avut un client care se afla în acel spațiu. Și ar apăsa butoanele pentru al reda și ai pleca acasă. Și te-ai întors, poate sâmbătă după-amiază, pentru a vedea cum merge. Dar dacă ai greșit, a fost foarte, foarte, foarte dureros. Și acum, nu este aproape - nici măcar nu e aproape de a fi atât de dureros, așa că ai ocazia să încerci mai multe lucruri. Trebuie să spun, cred că este un punct cu adevărat bun.
George: Este exact corect. Da, și îți sufli piciorul în plus. Știi, ai trecut la jumătatea unui loc de muncă pe vremuri și nu reușește, ți-ai aruncat SOS-ul. Asta e.
Eric: Corect. Și aveți mari probleme, da. Asta e corect.
George: Așa este. Asta e corect.
Eric: Keith, lasă-mă să arunc unul peste tine. Îmi amintesc că am făcut un interviu cu CIL-ul tău, Keith Collins, cred că, din 2011, cred că poate. Și a vorbit foarte mult despre direcția pe care SAS a luat-o în special în ceea ce privește colaborarea cu clienții pentru a integra analiticele derivate din SAS în sistemele operaționale. Și, desigur, l-am auzit pe Mike Ferguson vorbind despre importanța amintirii. Întreaga idee aici este că doriți să puteți lega aceste lucruri în operațiunile dvs. Nu doriți analiza în vid, deconectat de la întreprindere. Aceasta nu are nicio valoare.
Dacă doriți o analiză care să poată influența și optimiza direct operațiunile. Și dacă mă uit în urmă - și trebuie să spun, am crezut că este o idee bună în acel moment - pare o idee cu adevărat inteligentă în retrospectivă. Și ghicesc, acesta este un avantaj real pe care îl aveți. Și, desigur, această moștenire excelentă, această bază de instalare uriașă și faptul că v-ați concentrat pe încorporarea acestor analize în sisteme operaționale, ceea ce înseamnă acum - și acordat, va trebui să funcționeze - sunt sigur că ” Am lucrat destul de mult la asta. Însă acum, poți folosi toate aceste noi inovații și te afli într-adevăr în condițiile în care poți operaționaliza toate aceste lucruri cu clienții tăi. Este o evaluare corectă?
Keith: Da, absolut. Conceptul este că aveți această idee despre proiectarea deciziilor sau științele deciziei, care este, știți, într-un anumit grad care este un lucru exploratoriu, științific. Cu excepția cazului în care puteți face inginerie în acest proces pentru a ... într-adevăr ... Dacă vă gândiți să dezvoltați o mașină, aveți designeri care să facă această mașină frumoasă, dar nu este până când inginerii nu pun acest plan și să facă un produs viabil efectiv înaintea dvs. poate de fapt pune lucrurile la punct și asta este în esență ceea ce a făcut SAS. A îmbinat deciziile - procesul de proiectare a deciziei cu procesul de decizie, astfel încât, atunci când vorbești despre acceleratoare, acceleratoare cu punctaj specific, știi, dacă iei un model pe care l-ai dezvoltat și poți să-l împingi afară către Teradata sau împingeți-l către Oracle sau către Hadoop, cu zero dezactivare pentru dezvoltarea modelului, pentru implementarea modelului. Aceasta este cheia, deoarece modelele degradează în timp, exactitatea acestor modele. Așadar, cu cât durează mai mult să o iei și să o pui în producție, asta înseamnă pierderea de acuratețe a modelului.
Și apoi, cealaltă piesă este, vrei să poți monitoriza și gestiona procesul în timp. Vrei să depreciezi modelele când devin vechi și inexacte. Vrei să te uiți la ea, verifică acuratețea acestora în timp și reconstruiește-le. Și, astfel, avem instrumente de gestionare a modelelor care se află deasemenea, care urmăresc cu adevărat metadatele din jurul procesului modelat. Și oamenii au spus că modelarea, știți, acel tip de concept este ca o fabrică de modele sau orice doriți să o numiți. Chestia este că punem în practică metadatele și managementul și acolo sunt cele trei lucruri mari pe care le lovim - îi ajutăm pe oameni să câștige bani, să economisească bani și să îi ținem în pușcărie.
Eric: Și ultimul este destul de mare. Caut să evit toate astea. Să vorbim despre ...Îmi dau o ultimă întrebare, poate că fiecare poate sări peste asta. Eterogenitatea lumii noastre va crește doar, mi se pare. Cred că cu siguranță vom vedea unele cristalizări în jurul mediilor cloud hibride. Dar, totuși, veți vedea o mulțime de jucători importanți. IBM nu merge nicăieri. Oracle nu merge nicăieri. SAP nu merge nicăieri. Și există atât de mulți alți furnizori care sunt implicați în acest joc.
De asemenea, pe partea operațională, unde ai literalmente mii și mii de tipuri diferite de aplicații. Și am auzit - majoritatea dintre voi vorbesc despre asta, dar cred că amândoi ar fi de acord cu ceea ce spuneam. Am văzut această tendință acum în ceea ce privește puterea de calcul doar în motoarele analitice, arhitectură. Companiile vorbesc de ani buni despre posibilitatea de a atinge celelalte motoare de acolo și de a servi un fel de punct de orchestrare. Și cred, George, o să vă arunc mai întâi. Mi se pare că ceva nu se va schimba. Vom avea acest mediu eterogen, ceea ce înseamnă că există lucruri precum CRM-ul în timp real, calitatea datelor și guvernanța datelor. Veți avea nevoie, ca furnizor, de a interfața cu toate aceste instrumente diferite. Și asta doresc clienții. Nu vor dori ceva care să fie în regulă cu aceste instrumente și nici nu să fie în regulă cu aceste instrumente. Vor dori Elveția MDM și CRM, nu?
George: Așa este. Și este interesant, pentru că am adoptat foarte mult acest lucru. O parte din ea este istoria pe care am avut-o în spațiu. Și, evident, lucram deja la toate celelalte baze de date, la Teradatas și la piesele lumii. Și apoi, a făcut - în procesul de implementare, în mod specific modul în care am făcut-o, tocmai pentru ca acesta - să aveți această distanță în toate aceste baze de date diferite. Unul dintre lucrurile pe care mi le pare interesant este că, avem unii clienți care sunt pur și simplu aplecați să elimine toate bazele de date relaționale. Și este interesant. Știi, vreau să spun, este în regulă. E interesant. Dar nu văd că se întâmplă cu adevărat la o scară largă de întreprinderi. Nu văd că se întâmplă de multă vreme. Așadar, cred că hibridul este aici de mult timp și de cealaltă parte a aplicației noastre, unde avem platforma de mesagerie în platforma noastră de gestionare a campaniilor. Noi l-am proiectat în mod special. Acum, am lansat o versiune care face asta și care se poate conecta acum la mediul de date hibrid și la interogarea Hadoop sau la interogarea oricărei baze de date, a oricărei baze de date analitice. Deci, cred că acesta este doar valul viitorului. Și sunt de acord că virtualizarea va juca, cu siguranță, un rol important în acest sens, dar noi suntem doar - vom merge direct la datele din toate aplicațiile noastre.
Eric: Bine, minunat. Și, Keith, o să-l arunc. Ce părere aveți despre lumea eterogenă cu care ne confruntăm pentru a acționa ca un picior de fel?
Keith: Da, este într-adevăr fascinant. Cred că, ceea ce găsim mai mult - nu doar în ceea ce privește gestionarea datelor, dar ceea ce este cu adevărat fascinant în acest moment este natura open-source a bazei de analiză. Deci, vedem organizații precum sau tehnologii precum Spark la bord și oameni care folosesc Python și R și toate aceste alte tehnologii open-source. Cred că ar putea fi interpretat ca un fel de conflict sau o amenințare într-un anumit grad. Dar realitatea este că avem câteva complimente cu adevărat minunate cu toate aceste tehnologii open-source. Vreau să spun, pentru unul dintre noi, operăm pe platformele open-source, pentru Dumnezeu.
Dar, de asemenea, cum ar fi capabil să integrezi, de exemplu, un model R într-o paradigmă SAS îți permite să folosești cel mai bun din ambele lumi, nu? Ca și așa, știm că unele dintre lucrurile experimentale din lumea academică și unele din lucrările de dezvoltare a modelului sunt extraordinare și super utile în procesul de dezvoltare a modelului. Dar, de asemenea, dacă o puteți asocia cu un fel de instrument de clasă de producție, face o mulțime de curățare și de calitate și verificare și asigurându-vă că datele care dau la model sunt, au fost pre-corectate, astfel încât să nu eșueze la executare. Și apoi, să poți face lucruri precum modelele de contestator campion cu modele open-source. Acestea sunt lucrurile pe care le căutăm să le permitem și ca parte a acestui ecosistem cu adevărat eterogen al tuturor acestor tehnologii. Da, deci este mai mult - pentru noi, este vorba mai mult despre îmbrățișarea acestor tehnologii și căutarea complimentelor.
Eric: Ei, au fost lucruri fantastice, oameni buni. Am mers un pic aici, dar am dori să ajungem la cât mai multe întrebări. Vom transmite astăzi fișierul Q&A prezentatorilor noștri. Deci, dacă orice întrebare pe care ați adresat-o nu a primit un răspuns, ne vom asigura că va primi răspuns. Și oameni buni, acest lucru este completat pentru 2014. Cu adevărat la DM Radio mâine și săptămâna viitoare, apoi totul a fost făcut și este o pauză de vacanță.
Multe mulțumiri tuturor pentru timpul și atenția acordată, pentru că ați accesat toate aceste webcast-uri minunate. Avem un an minunat aliniat pentru 2015. Vom vorbi în curând, oameni buni. Multumesc din nou. Vom avea grijă. Pa! Pa.