Contenuto
Fonte: Jakub Jirsak / Dreamstime.com
Porta via:
L'host Eric Kavanagh discute dell'analisi dei big data con esperti del settore.
Eric: onorevoli colleghi, è la fine dell'anno 2014 - almeno, quasi. È il nostro ultimo webcast dell'anno, gente! Benvenuto in TechWise! si Certamente. Mi chiamo Eric Kavanagh. Sarò il tuo moderatore per un fantastico webcast, gente. Sono molto, molto eccitato. Abbiamo due fantastici analisti online e due grandi aziende: veri innovatori in questo intero ecosistema di big data. E parleremo della chiave per l'analisi dei big data è capire la differenza. Quindi, andiamo avanti e tuffiamoci dentro, gente.
Abbiamo diversi presentatori. Come puoi vedere, c'è davvero il tuo in alto. Mike Ferguson chiama dal Regno Unito, dove ha dovuto ottenere privilegi speciali per rimanere nel suo ufficio così tardi. È quanto è tardi per lui. Abbiamo il dottor Robin Bloor, il nostro Chief Analyst qui al Bloor Group. E avremo George Corugedo, CEO e co-fondatore di RedPoint Global, e Keith Renison, Senior Solutions Architect del SAS Institute. Queste sono aziende fantastiche, gente. Queste sono aziende che stanno davvero innovando. E approfondiremo alcune delle cose positive di ciò che sta accadendo là fuori proprio ora in tutto il mondo dei big data. E ammettiamolo, i piccoli dati non sono andati via. E a questo, lasciami dare il mio sommario esecutivo qui.
Quindi, c'è una vecchia espressione francese: "Più le cose cambiano, più rimangono le stesse". E affrontiamo alcuni fatti qui: i big data non risolveranno i problemi dei piccoli dati. I piccoli dati aziendali sono ancora disponibili. È ancora dappertutto. È il carburante delle operazioni per l'economia dell'informazione di oggi. E i big data offrono un complimento a questi cosiddetti piccoli dati aziendali, ma non soppiantano i piccoli dati. Ci sarà ancora. Mi piacciono molte cose sui big data, in particolare cose come i dati generati dalla macchina.
E oggi, probabilmente parleremo un po 'di dati sui social media, che sono anche cose molto potenti. E se, ad esempio, pensi a come i social hanno cambiato il tuo business, pensa solo a tre siti Web rapidi qui: LinkedIn e. Pensa al fatto che cinque anni fa nessuno faceva quel genere di cose. è un juggernaut assoluto in questi giorni. , ovviamente, è enorme. È gigantesco. E poi, LinkedIn è lo standard di fatto per le reti e le comunicazioni aziendali. Questi siti sono enormi e, per essere in grado di sfruttare i dati in essi contenuti, farà rivivere alcune funzionalità che cambiano il gioco. Farà davvero molto per molte organizzazioni, almeno quelle che ne approfittano.
Nessun bug, nessuno stress: la tua guida passo passo alla creazione di software che ti cambia la vita senza distruggere la tua vita
Non puoi migliorare le tue capacità di programmazione quando a nessuno importa della qualità del software.
Quindi, governance - governance è ancora importante. Ancora una volta, i big data non annullano la necessità di governance. Francamente, c'è una necessità completamente nuova di concentrarsi su come governare il mondo dei big data. Come assicurarsi di disporre delle procedure e delle politiche in atto; che le persone giuste ottengano l'accesso ai dati giusti; che hai contatti, hai un lignaggio coinvolto qui? In realtà sai da dove provengono i dati, cosa è successo a loro. E tutto sta cambiando.
Sono sinceramente molto colpito da ciò che ho visto là fuori in questo mondo completamente nuovo sfruttando l'ecosistema Hadoop, che ovviamente è molto più che archiviazione in termini di funzionalità. Anche Hadoop è un motore di calcolo. E la società deve capire come sfruttare quella potenza computazionale, quella capacità di elaborazione parallela. Faranno cose davvero fantastiche. Lo impareremo oggi.
L'altra cosa da ricordare, questo è qualcosa di cui il dottor Bloor ha parlato nel recente passato, è che l'ondata di innovazione non è finita. Quindi, abbiamo visto molta attenzione su Hadoop. Abbiamo visto aziende come Cloudera e Hortonworks, sai, fare davvero delle onde. E stanno sviluppando partnership con, beh, con le aziende in call oggi, francamente. E stanno sviluppando collaborazioni con molte persone. Ma l'ondata di innovazione non è finita. Ci sono altri progetti che nascono dalla Apache Foundation che stanno cambiando non solo il punto finale, se vuoi - le applicazioni che le persone usano - ma l'infrastruttura stessa.
Quindi, l'intero sviluppo di YARN - l'ennesimo negoziatore di risorse - è davvero come un sistema operativo per i big data. Ed è un grosso problema. Quindi, impareremo anche come questo cambia le cose. Quindi, solo un paio di ovvi consigli qui, diffidare dei lunghi contratti che vanno avanti, sai, i contratti di cinque, dieci anni saranno l'onda, il percorso che mi sembra. Vuoi evitare il blocco a tutti i costi. Oggi impareremo tutto questo.
Quindi, il nostro primo analista parla oggi - il nostro primo oratore dell'intero programma è Mike Ferguson, che viene dal Regno Unito. Detto questo, ti consegnerò le chiavi, Mike, e ti lascerò portare via. Mike Ferguson, il pavimento è tuo.
Mike, ci sei? Potresti essere muto. Non lo sento. Potremmo doverlo richiamare. E salteremo semplicemente alle diapositive di Robin Bloor. Robin, farò il rango sul povero Mike Ferguson qui. Vado per un secondo.
Sei tu, Mike? Puoi sentirci? Nah. Penso che dovremo andare avanti e andare prima con Robin. Quindi, aspetta un secondo, gente. Tra un paio di minuti tirerò anche alcuni link alle diapositive. Quindi, lasciami consegnare le chiavi a Robin Bloor. Robin, puoi andare per primo invece di Mike, e chiamerò Mike tra un secondo.
Robin: Ok.
Eric: Aspetta, Rob. Lasciami andare e porta qui la tua diapositiva, Rob. Ci vorrà un secondo.
Robin: Ok.
Eric: Sì. Puoi in qualche modo parlare di ciò con cui abbiamo a che fare qui, in termini di governance. So che parlerai di governance. Questo è in genere pensato nella truffa dei piccoli dati aziendali. Quindi ora ho alzato la diapositiva, Robin. Non spostare nulla. Ed eccoti qua. Il pavimento è tuo. Portalo via.
Robin: Ok. Si. Voglio dire, beh, in un certo senso ci siamo accordati in anticipo, Mike avrebbe parlato del lato analitico e parlerò del lato della governance. In una certa misura, la governance segue le analisi, nel senso che è una ragione per cui stai facendo le cose sui big data, e la ragione per cui assembli tutto il software per fare le analisi è quella che è il valore.
C'è un problema E il problema è che, sai, i dati devono essere distrutti. I dati devono essere sottoposti a marshalling. I dati devono essere riuniti e gestiti in un modo che consenta all'analitica di svolgersi con piena fiducia - credo sia la parola. Quindi, ho pensato di parlare del lato governance dell'equazione. Immagino che la cosa da dire, in realtà, sia che la governance era già un problema. La governance era già un problema e inizia a diventare un problema in tutto il gioco del data warehouse.
Quello che è realmente accaduto è che si è trasformato in un problema molto più grande. E la ragione per cui si è trasformata in un problema molto più grande e in più dati, ma voglio dire, questi sono i motivi, davvero. Il numero di fonti di dati è cresciuto notevolmente. In precedenza, le fonti di dati che avevamo erano generalmente definite da tutto ciò che alimentava il data warehouse. Il data warehouse sarebbe normalmente alimentato da sistemi RTP. È possibile un po 'di dati esterni, non molto.
Ora, siamo andati in un mondo in cui, sai, un mercato dei dati sta nascendo proprio ora, e quindi ci saranno scambi di dati. Hai già un sacco di diverse fonti di dati in streaming che puoi effettivamente portare all'organizzazione. Abbiamo i dati dei social media che li hanno prelevati, tolti per proprio conto, per così dire. Voglio dire, moltissimo, il valore nei siti di social media sono in realtà le informazioni che aggregano e possono quindi rendere disponibili alle persone.
Abbiamo anche scoperto che, sai, è come se esistessero già. Avevamo già quei file di registro, sai, nell'avvento di Splunk. E presto è diventato evidente che c'è un valore in un file di registro. Quindi, all'interno dell'organizzazione c'erano dati che potremmo chiamare nuove fonti di dati e fonti esterne. Quindi, questa è una cosa. Ciò significa che, a prescindere, qualunque siano le regole di gestione dei dati che avevamo in atto in precedenza, dovranno essere, in un modo o nell'altro, estese e continueranno a dover essere estese per governare dati. Ma ora stiamo cominciando a riunirci in un modo o nell'altro.
E scendendo questo elenco abbiamo lo streaming e la velocità di arrivo dei dati. Penso che uno dei motivi alla base della popolarità di Hadoop sia che può essere praticamente utilizzato per catturare molti dati. Può anche aumentare la velocità dei dati, che se in realtà non è necessario utilizzarli immediatamente, si tratta di un bell'ambiente parallelo parallelo. Ma hai anche il fatto che c'è una buona quantità di analisi di streaming in corso ora. Un tempo erano solo i settori bancari interessati alle applicazioni di streaming, ma ora è diventato un po 'globale. E tutti guardano le applicazioni di streaming in un modo o nell'altro, un potenziale mezzo per ricavare valore dai dati e fare analisi per l'organizzazione.
Abbiamo i dati non strutturati. La statistica, di solito parte del solo 10% dei dati del mondo, era contenuta in database relazionali. Ora, uno dei motivi principali era che in realtà non era strutturato, ed era - buona parte era sul Web, ma praticamente disseminata di vari siti Web. Tali dati si sono dimostrati analizzabili, anche utilizzabili. E con l'avvento della tecnologia Symantec che si insinua gradualmente nella situazione, sta diventando sempre più.Pertanto, è necessario raccogliere e gestire effettivamente dati non strutturati e ciò significa che è molto più grande di prima. Abbiamo un dato sociale che ho già menzionato, ma il punto a riguardo, il punto principale a riguardo, è che probabilmente ha bisogno di essere pulito.
Abbiamo dati sull'Internet of Things. È un tipo di situazione diversa. Probabilmente ci sarà così tanto, ma molto dovrà rimanere distribuito da qualche parte vicino al luogo in cui corre. Ma vorrai anche, in un modo o nell'altro, inserirlo per fare analisi all'interno dell'organizzazione sui dati. Quindi, questo ha aggiunto un altro fattore. E quei dati saranno strutturati in modo diverso, perché probabilmente - saranno probabilmente formattati in JSON o in XML, in modo da dichiararsi. E non solo, in un modo o nell'altro, che stiamo effettivamente inserendo i dati e siamo in grado di fare una sorta di schema sulla lettura di quel particolare pezzo di dati.
Abbiamo il problema della provenienza e questo è un problema di analisi. I risultati di qualsiasi analisi in cui stai eseguendo i dati non possono essere, se vuoi, approvati, considerati validi, a meno che tu non conosca la provenienza dei dati. Voglio dire, questa è solo professionalità in termini di attività dei data scientist. Ma sai, al fine di avere la provenienza dei dati, ciò significa che dobbiamo effettivamente governare i dati e tenere una nota sulla loro discendenza.
Abbiamo il problema della potenza del computer e dei parallelismi e tutto ciò che fa è rendere tutto più veloce. Il problema è che, ovviamente, alcuni processi che abbiamo avviato potrebbero essere troppo lenti per tutto il resto. Quindi, ci sono probabilmente discrepanze in termini di velocità.
Abbiamo avuto l'avvento dell'apprendimento automatico. L'apprendimento automatico ha davvero l'effetto di rendere l'analitica un gioco diverso rispetto a prima. Ma puoi davvero usarlo solo se hai il potere.
Abbiamo ottenuto il fatto di nuovi carichi di lavoro analitici. Abbiamo un mondo parallelo e alcuni algoritmi analitici devono essere eseguiti in parallelo per il massimo effetto. E quindi il problema in realtà è governare il modo in cui, in un modo o nell'altro, invii i dati e li rendi disponibili, se disponibili. E dove esegui effettivamente i carichi di lavoro analitici, perché potresti farlo all'interno del database. Quindi, potresti farlo all'interno di applicazioni analitiche.
Quindi, c'è un'intera serie di sfide di governance. Quello che abbiamo fatto quest'anno - la ricerca che abbiamo fatto quest'anno riguardava davvero l'architettura dei big data. E quando in realtà proviamo a generalizzarlo, la conclusione a cui siamo arrivati - il diagramma che ci è venuto in mente assomigliava molto a questo.
Non ho intenzione di approfondire questo aspetto, soprattutto perché Mike farà una buona dose sull'architettura dei dati per l'analisi. Ma ciò su cui in realtà mi piace che le persone si concentrino solo su questa area inferiore in cui, in un modo o nell'altro, stiamo assemblando i dati. Abbiamo qualcosa a cui vorrei fare riferimento è la raffineria di dati o l'hub di elaborazione dei dati. Ed è qui che si svolge la governance. Quindi, sai, se ci focalizziamo su, sembra così. Sai, è alimentato da dati provenienti da fonti interne ed esterne. L'hub dovrebbe, in teoria, prendere tutti i dati che vengono generati. Dovrebbe essere trasmesso in streaming e gestito come è in streaming se è necessario eseguire analisi e streaming dei dati e quindi passare all'hub. Altrimenti, tutto arriva nell'hub. E ci sono un certo numero di cose che stanno succedendo - che stanno succedendo nell'hub. E non è possibile avere una certa quantità di analisi e SQL in corso nell'hub. Ma hai anche bisogno della virtualizzazione dei dati in ogni cella per spingere i dati in altre aree. Ma prima che ciò accada, è necessario, in un modo o nell'altro, perfezionare la preparazione dei dati. Puoi chiamarlo preparazione dei dati. È molto più grande di così. Queste sono le cose che penso che includano.
Abbiamo in qualche modo la gestione dei sistemi e dei servizi che questa è la parte principale del livello dati, quindi dobbiamo effettivamente applicare tutti i sistemi che gestiscono gli sforzi di gestione dei sistemi operativi che tradizionalmente abbiamo fatto praticamente a tutti i sistemi operativi. Ma dobbiamo anche, in un modo o nell'altro, monitorare altre cose in corso per assicurarci che questi diversi livelli di servizio vengano rispettati, perché ci sono sicuramente livelli di servizio definiti o qualsiasi tipo di analisi in corso di azione, oppure i dati BI sono essere intervenuto.
Abbiamo bisogno di monitoraggio e gestione delle prestazioni. Semmai, ne abbiamo bisogno per sapere quali ulteriori risorse informatiche potremmo aver bisogno di allocare in vari momenti nel tempo. Ma, in realtà, una gran parte del carico di lavoro è qui, in effetti, abbastanza complesso e in competizione tra loro per le risorse. C'è qualcosa di abbastanza sofisticato che deve essere fatto in quella zona.
Ora abbiamo il ciclo di vita dei dati in un modo che non avevamo mai avuto prima. L'accordo qui è davvero al di là di ogni altra cosa, che non abbiamo raccolto dati e non li abbiamo buttati via prima. Tendevamo a raccogliere i dati di cui avevamo bisogno e probabilmente li abbiamo conservati, quindi li archiviamo. Ma molto di ciò che faremo da qui in poi è esplorare i dati. E se non vuoi i dati, nascondiamoli. Quindi, i cicli di vita dei dati sono diversi a seconda della situazione, ma saranno anche molto più aggregati di dati. Pertanto, sapete, sapendo da dove viene un aggregato da quale ... quale sia la fonte di aggregazione, e così via e così via. È tutto necessario.
La discendenza dei dati si presta naturalmente. Senza di essa, devi conoscere i problemi, quindi i dati ... Dobbiamo sapere che i dati sono validi, ma con quanto siano realmente affidabili.
Abbiamo anche una mappatura dei dati, perché molti di questi saranno effettivamente, in un modo o nell'altro. E questo è, se vuoi, questo si riferisce in una certa misura a MDM. È solo che ora è molto più complicato, perché quando hai un sacco di dati definiti da JSON o basati sul nostro schema XML in lettura, allora dovrai, in un modo o nell'altro, avere molto attivo attività di mappatura dei dati in corso.
C'è una situazione di gestione dei metadati che è più di MDM, perché c'è la necessità, in un modo o nell'altro, di costruire ciò che mi piacerebbe pensare ora come una sorta di magazzino di metadati di tutto ciò che ti interessa. Ci sono metadati scoperta, perché alcuni dei dati non avranno necessariamente i suoi metadati dichiarati e vogliamo usarli immediatamente. E poi, c'è la pulizia dei dati, che è una cosa enorme come una serie di cose che si possono fare lì. E c'è anche la sicurezza dei dati. Tutti questi dati devono essere protetti a un livello accettabile e ciò potrebbe anche significare in alcuni casi, ad esempio crittografando molti valori.
Quindi, tutto questo carico di lavoro è in realtà l'impero della governance. Tutto ciò, in un modo o nell'altro, deve avvenire contemporaneamente o prima, tutta la nostra attività analitica. Questo è un gran numero di applicazioni coordinate. È un sistema a sé stante. E poi, quelli che non lo fanno in vari momenti nel tempo ne soffriranno man mano che vanno avanti, perché moltissime di queste cose non sono davvero opzionali. Finisci per aumentare l'entropia se non li fai.
Quindi, in termini di analisi dei dati e governance, la cosa che direi è che, in realtà, una mano lava l'altra. Senza governance, analitica e BI non si romperanno nel tempo. E senza analisi e BI, non ci sarebbe comunque molto bisogno di governare i dati. Quindi, le due cose camminano davvero mano nella mano. Come si dice in Medio Oriente, "Una mano lava l'altra". E questo è in realtà tutto ciò che devo dire. Spero - si spera, ora abbiamo Mike indietro.
Eric: Lo facciamo. Mike, presumo che tu sia lì. Spingerò la tua diapositiva verso l'alto.
Mike: Lo sono. Ok, mi senti?
Eric: Sì, posso sentirti. Sembri meraviglioso. Quindi, lascia che ti presenti ... Ecco qua. E ora sei il presentatore. Portalo via.
Mike: Va bene, grazie! Buongiorno, buon pomeriggio, buona sera a tutti voi là fuori. Perdona il singhiozzo all'inizio. Per qualche motivo, mi sono ammutolito e riesco a vedere tutti ma non riescono a sentirmi.
Tutto a posto. Quindi, quello che voglio fare rapidamente è parlare dell'ecosistema analitico dei big data. Se vuoi farmi domande, ti dirò, in questa sessione o in seguito, puoi contattarmi sui miei dettagli di contatto qui. Come ho detto, nel cuore della notte qui nel Regno Unito.
Bene, lasciami arrivare a quello di cui voglio parlare. Chiaramente, negli ultimi anni, abbiamo visto emergere tutti i tipi di nuovi dati che le aziende ora vogliono analizzare - tutto, dai dati clickstream per comprendere i comportamenti online, i dati sui social media di cui Eric stava parlando al inizio del programma qui. Penso che Robin abbia menzionato JSON, BSON, XML, quindi dati semistrutturati che si autodescrivono. Ovviamente, abbiamo anche un sacco di altre cose, da dati non strutturati, registri dell'infrastruttura IT, dati dei sensori. Tutte queste fonti di dati relativamente nuove che le aziende hanno ora interessato perché contengono preziose informazioni che potrebbero potenzialmente approfondire ciò che sappiamo.
Quindi, ciò significa sostanzialmente che il panorama analitico è andato oltre il tradizionale data warehousing. Strutturiamo ancora i dati nel mondo di una combinazione di dati strutturati e multi-strutturati, in cui i dati multi-strutturati potrebbero provenire dall'interno o dall'esterno dell'azienda in molti casi. E come risultato di questi nuovi tipi di dati e nuove esigenze da analizzare, abbiamo assistito alla nascita di nuovi carichi di lavoro analitici: tutto dall'analisi dei dati in movimento, che in qualche modo trasforma la tradizionale architettura di data warehousing in qualche modo, dove , nei circoli tradizionali, integra i dati, li pulisce, li trasforma, li memorizza e li analizza. Ma analizzando i dati in movimento, stiamo acquisendo i dati, li integriamo, li prepariamo analizzandoli e quindi memorizzandoli. Quindi, ci sono analisi in corso sui dati prima che vengano archiviati ovunque.
Abbiamo un'analisi complessa di dati strutturati, forse per lo sviluppo di modelli, lo sviluppo di modelli statistici e predittivi, che non è una novità per alcune persone in uno spazio di data warehousing tradizionale. Abbiamo un'analisi esplorativa dei dati sul modello. Questa è la quantità di dati strutturati lì. Abbiamo nuovi carichi di lavoro sotto forma di analisi grafica che per i miei clienti nei servizi finanziari include cose come la frode. Include anche la sicurezza informatica. Include naturalmente i social network, la comprensione di influencer e cose del genere lì. L'ho persino imparato nella gestione, ha alcuni anni di analisi dei grafici.
Abbiamo l'ottimizzazione o l'offload del data warehouse dell'elaborazione ETL, che è più una sorta di caso d'uso IT, che il CIO potrebbe finanziare. E persino l'archiviazione di dati e data warehouse per tenerli online in cose come Hadoop. Pertanto, tutti questi nuovi carichi di lavoro analitici hanno aggiunto nuove piattaforme, nuove piattaforme di archiviazione al panorama analitico. Quindi, piuttosto che avere solo data warehouse tradizionali, data mart, quello che abbiamo ora è Hadoop. Abbiamo database NoSQL come database grafici che vengono spesso utilizzati per carichi di lavoro analitici. Ovviamente, ora possiamo fare analisi di grafici su Hadoop stesso e su un DBMS grafico NoSQL. Abbiamo analisi di streaming citate da Robin. E se vogliamo, abbiamo la costruzione di modelli, magari anche su dispositivi di data warehouse analitici. Ma tutto ciò ha complicato il panorama analitico, essendo ora necessarie più piattaforme. E immagino che la sfida, per qualsiasi azienda con front office o back office, o finanza, approvvigionamento, risorse umane e qualche tipo di operazione, sia quella di capire quali progetti analitici sono associati a una scena tradizionale di data warehousing. E una volta che sai che i progetti analitici sono associati a queste nuove piattaforme di big data e dove eseguire, sai, quale carico di lavoro analitico, ma non perdere di vista il business nel senso che è - ora vedrai che è una combinazione di grande progetti di analisi dei dati e progetti tradizionali di immagazzinamento di big data che insieme sono necessari per rafforzare all'interno dei clienti o delle operazioni, dei rischi, della finanza o della sostenibilità. Pertanto, desideriamo che tutti questi siano allineati con le nostre priorità aziendali strategiche, che manteniamo sulla buona strada per, sai, spingere gli aghi che devono essere spinti, sai, per migliorare le prestazioni aziendali, ridurre i costi, per ridurre i rischi, ecc., sai, per la nostra azienda nel suo insieme. Quindi, non è che uno sostituisca l'altro qui con big data e tradizionali. Sono entrambi usati insieme. E questo cambia radicalmente l'architettura, lo sai.
Quindi, quello che ho qui è un'architettura relativamente nuova che userò con i miei clienti. E così, come puoi vedere ora in fondo, una vasta gamma di origini dati, non solo più strutturate. Alcuni di questi stanno trasmettendo dati in diretta come sensori, come dati di mercato, quel genere di cose. Potrebbero anche essere dati clickstream live. Potrebbe trattarsi di dati di streaming video in diretta. Quindi non doveva essere strutturato. Quindi, possiamo eseguire l'elaborazione dei flussi su tali dati per eseguire azioni automatiche in tempo reale e tutti i dati di interesse potrebbero essere filtrati e passati a strumenti di gestione delle informazioni aziendali che possono essere utilizzati per popolare archivi di dati analitici. A meno che tu non riesca a vedere nel mix qui, ora abbiamo i tradizionali data warehousing, i database Hadoop e NoSQL. Nel mix abbiamo anche la gestione dei dati principali. E ciò mette più pressione sull'intera suite di strumenti di gestione dei dati, non solo per popolare questi archivi di dati, ma per spostare i dati tra di loro.
Inoltre, dobbiamo semplificare gli strumenti di accesso. Non possiamo limitarci a rivolgerci all'utente e dire "ottenere tutti questi archivi di dati, conservare queste API - il tuo problema". Quello che devi fare è semplificare l'accesso. Quindi, un po 'tra le linee tratteggiate lì, vedrai che la virtualizzazione e l'ottimizzazione dei dati nascondono in qualche modo la complessità dell'archiviazione multipla dei dati, provando a rendere più facile l'accesso agli utenti finali. E, naturalmente, c'è una gamma di strumenti in alto, sai - tutto, dagli strumenti di BI tradizionali che hanno ricominciato da capo in cima al data warehousing, spostandosi gradualmente verso la sinistra del grafico per collegarsi in qualche modo con gli Hadoops e poi i database NoSQL del mondo.
Abbiamo cercato di ottenere un nuovo contratto sulla vita, in particolare intorno al corpo dei dati strutturati e non strutturati che sono spesso memorizzati in Hadoop. Abbiamo applicazioni analitiche personalizzate da eseguire su una piattaforma Hadoop con MapReduce, quindi il framework Spark, ad esempio. Abbiamo a disposizione strumenti di analisi dei grafici per concentrarci su carichi di lavoro molto specifici lì. Quindi, una gamma di strumenti e i flussi di dati sono anche più complessi. Non è più solo una strada a senso unico nel data warehouse. Ora sono i dati anagrafici, ovviamente.
Abbiamo nuove fonti di dati in arrivo, o catturate in NoSQL, sai, archivi di dati come MongoDB, come Cassandra, come HBase. Abbiamo portato i dati direttamente in Hadoop per l'analisi e la preparazione dei dati lì. Abbiamo acquisito nuove informazioni da Hadoop e dai data warehouse. Abbiamo un archivio proveniente dai data warehouse in Hadoop. Ora abbiamo i feed di dati che vanno anche a tutti i database NoSQL e ai data mart. Quindi, quello che puoi vedere qui è che c'è molta più attività in corso nella gestione dei dati. E significa che sta mettendo a dura prova il software di gestione dei dati. Non è più solo una strada a senso unico. È un movimento di dati bidirezionale. Sono in corso molte più attività e, pertanto, la scalabilità è importante sia sul fronte dello strumento di gestione dei dati che sull'origine dei dati.
Quindi, questo grafico risale a quell'architettura che ho menzionato un momento fa. Mostra i diversi carichi di lavoro analitici in esecuzione in diverse parti di questa architettura. Una specie di in basso a sinistra lì, hai streaming in tempo reale, elaborazione del flusso in corso su dati provenienti da qualsiasi tipo di archivio di dati in tempo reale. Abbiamo analisi di classe in corso sui database dei grafici NoSQL. Può succedere anche su Hadoop. Con il framework Spark, ad esempio, e GraphX lì, abbiamo un'analisi investigativa e la raffineria di dati di cui Robin stava parlando accadendo su Hadoop. Abbiamo ancora carichi di lavoro tradizionali in corso e data warehousing, sai, utenti esperti che costruiscono modelli statistici e predittivi, forse su dispositivi di data warehouse. E stiamo ancora cercando di semplificare l'accesso a tutto questo per renderlo più semplice per gli utenti finali.
Quindi, il successo di tutto questo setup è molto più del solo lato analitico. Sai, possiamo mettere in atto le piattaforme analitiche, ma se non siamo in grado di catturare e ingerire, ad esempio, dati ad alta velocità e ad alto volume, su scala, non ha molto senso. Sai, non ho nulla da analizzare. E così, il successo dell'analisi dei big data richiede un aumento dei sistemi operativi. Ciò significa che, per essere in grado di supportare nuove transazioni, sai, picchi. Sai, qualsiasi dato non transazionale che viene catturato potrebbe esserci, sai, qualsiasi nuovo tasso di arrivo molto, molto alto tasso di arrivo su dati ad alta velocità come sensori o qualsiasi ingest. Dobbiamo essere in grado di soddisfare tutto ciò, per essere in grado di acquisire questo tipo di dati e portarli per l'analisi. Dobbiamo anche ridimensionare le analisi stesse, semplificare l'accesso ai dati di cui ho già parlato. E poi, legalo. Sai, dobbiamo essere in grado di affinare di nuovo quei sistemi operativi per dare un circuito chiuso.
Quindi, scalare il lato operativo della casa per acquisire dati, sai, porta nel mondo del database NoSQL. Voglio dire, qui vedi cinque categorie di database NoSQL. Questa categoria verrà modellata semplicemente essendo una combinazione delle altre quattro precedenti. In generale, sai, i suoi valori chiave, i documenti archiviati e i database delle famiglie di colonne - i primi tre lì - che sono usati per il tipo di dati transazionali e non transazionali.
Alcuni di quei database che supportano come proprietà; alcuni no. Tuttavia, sai, stiamo vedendo l'introduzione di quelli per ridimensionare questo tipo di applicazioni. E così, ad esempio, quando ci siamo allontanati dai soli dipendenti che accedevano alle transazioni con la tastiera, adesso i clienti e le masse utilizzano nuovi dispositivi per poterlo fare. Abbiamo assistito a un enorme aumento del numero di transazioni immesse nelle imprese. E quindi, per farlo dobbiamo ridimensionare le applicazioni transazionali.
Ora, in generale, ciò può essere fatto sui database NewSQL come un database relazionale come NuoDB e VoltDB mostrato qui. O alcuni dei database NoSQL che forse supportano le proprietà ACID che possono garantire l'elaborazione delle transazioni potrebbero essere in gioco. Questo vale anche per i dati non transazionali come i dati del carrello prima di una transazione, sai, prima che le persone acquistino cose, dati dei sensori, sai, poiché perdo una lettura del sensore tra centinaia di milioni di letture del sensore. Non è un grosso problema. Clic, sai, nel mondo dei clickstream: se uso un clic, non è un grosso problema.Quindi, sai, non abbiamo necessariamente bisogno di avere proprietà ACID lì, ed è spesso qui che entrano in gioco i database NoSQL, era lì - quella capacità di eseguire un'elaborazione molto elevata e corretta su scala per acquisire questi nuovi tipi di dati.
Allo stesso tempo, vogliamo che l'analitica si ridimensioni. Pertanto, il pull dei dati dagli archivi dati alle piattaforme analitiche non ha più intenzione di hackerarli perché i dati sono troppo grandi. Ciò che vogliamo veramente è di spingere l'analitica dall'altra parte, fino al data warehouse aziendale in Hadoop, nell'elaborazione del flusso per essere in grado di trasferire l'analitica ai dati. Tuttavia, solo perché qualcuno dice che è nell'analisi del database o nell'analisi di Hadoop non significa necessariamente che l'analisi sia eseguita in parallelo. E francamente, se hai intenzione di investire in queste nuove tecnologie scalabili in parallelo enormemente come Hadoop, come le apparecchiature di data warehouse e quant'altro, come i motori di elaborazione del flusso in cluster, abbiamo bisogno che le analisi funzionino in parallelo.
Quindi, questo è solo il check out. Sai, se abbiamo analisi per aiutare a prevedere le cose per i clienti, per le operazioni, per i rischi, ecc., Vogliamo che funzionino in parallelo, non solo nella piattaforma. Vogliamo entrambi. E questo perché, sai, la tecnologia è come questi nuovi strumenti di scoperta visiva come SAS. In realtà è uno dei nostri sponsor qui.
Una cosa che le persone vogliono è almeno sfruttare quelle di Hadoop e quindi dell'analisi dei database. E vogliamo che vengano eseguiti in parallelo per essere in grado di fornire le prestazioni necessarie su volumi di dati così elevati. Allo stesso tempo, stiamo cercando di semplificare l'accesso a tutto questo. E così, SQL è tornato all'ordine del giorno. Sai, SQL è - SQL su Hadoop è caldo in questo momento. Lo sto monitorando in 19 iniziative SQL e Hadoop in questo momento. Inoltre, puoi vedere, possiamo ottenere questi dati, sai, in diversi modi in modo che accedendo direttamente a SQL su Hadoop stesso, possiamo passare SQL a un indice di ricerca. In questo modo, come sapete, alcuni dei fornitori di ricerca in quello spazio, possiamo avere accesso SQL ai database relazionali analitici che hanno tabelle Excel su Hadoop.
Ora possiamo avere accesso SQL a un server di virtualizzazione dei dati che può quindi essere collegato a un data warehouse su Hadoop. Sto anche iniziando a vedere l'emergere dell'accesso SQL ai dati di streaming live. Quindi, l'accesso SQL a tutto questo sta crescendo rapidamente. E parte della sfida è, solo perché l'accesso SQL viene commercializzato là fuori. La domanda è: SQL può gestire dati complessi? E questo non è necessariamente semplice. Ci sono tutti i tipi di complicazioni qui, incluso il fatto che i dati JSON potrebbero essere nidificati. Possiamo avere record delle varianti dello schema. Quindi, il primo record ha uno schema. Il secondo record ha uno schema diverso. Queste cose sono molto diverse da ciò che accade in un mondo relazionale.
Pertanto, dobbiamo porre domande sul tipo di dati che stiamo cercando di analizzare e quali sono le caratteristiche analitiche. Sai, pannello, che vuoi fare? È l'apprendimento automatico? È un'analisi grafica? Puoi farlo da SQL? Sai, è invocabile da SQL? Quanti utenti simultanei lo abbiamo fatto? Sai, abbiamo centinaia di utenti simultanei. È possibile su dati complessi? Sai, tutte queste cose sono domande chiave. Quindi, ho fatto un elenco di alcuni qui che penso che dovresti prendere in considerazione. Sai, che tipo di formati di file? Di che tipo di tipi di dati stiamo parlando? Che tipo di funzioni analitiche possiamo invocare da SQL per ottenere dati complessi? E il tipo di funzioni viene eseguito in parallelo. Voglio dire, devono correre in parallelo se dobbiamo essere in grado di ridimensionarlo. E posso unire i dati in Hadoop oggi al di fuori di esso, sai, o non è possibile? E cosa farò con tutti questi diversi tipi di carichi di lavoro di query?
E come vedremo, sai, da quello che ho visto, ci sono molte differenze tra la distribuzione SQL e Hadoop. Questi sono tutti quelli che sto monitorando. E comunque, questo è puro SQL su Hadoop. Ciò non include nemmeno la virtualizzazione dei dati a questo punto. E così, molto là fuori e un sacco di spazio per il consolidamento, che penso accadrà nel prossimo anno, diciotto mesi circa. Ma apre anche un'altra cosa, che è che posso avere potenzialmente più motori SQL sugli stessi dati in Hadoop. E questo è qualcosa che non puoi fare in relazione.
Naturalmente, ciò significa che devi sapere, sai, che tipo di carico di lavoro di query sto eseguendo? Devo eseguirlo in batch su una particolare iniziativa SQL su Hadoop? Devo eseguire carichi di lavoro di query interattivi tramite un'altra iniziativa SQL su Hadoop, ecc., In modo da sapere a quale connettersi? Idealmente, ovviamente, non dovremmo farlo. Dovremmo solo fare una domanda al riguardo. Sai, alcuni ottimizzatori escogitano il modo migliore per farlo. Ma non siamo ancora del tutto lì, secondo me.
Tuttavia, anche la virtualizzazione dei dati, di cui ho parlato in precedenza, ha un ruolo molto importante per semplificare l'accesso a più archivi di dati. E se creiamo nuove intuizioni su Hadoop, è certamente plausibile per noi unire tali data-to-data e data warehouse tradizionali attraverso la virtualizzazione dei dati, ad esempio, senza necessariamente spostare i dati da Hadoop in data warehouse tradizionali. Certo, puoi farlo anche tu. È anche plausibile se archivi i dati dai tradizionali data warehouse in Hadoop. Posso ancora ottenerlo e ricollegarlo ai contenuti del nostro data warehouse per la virtualizzazione dei dati. Quindi, per me, penso che la virtualizzazione dei dati abbia un grande futuro in questa architettura complessiva e che semplifichi l'accesso a tutti questi archivi di dati.
E non dimenticare che quando creiamo queste nuove intuizioni, che si tratti di sistemi relazionali o NoSQL, vogliamo ancora riportare tali intuizioni nelle nostre operazioni, in modo da poter massimizzare il valore di ciò che abbiamo trovato, in modo che possiamo sfruttalo per decisioni più efficaci e tempestive in quell'ambiente per ottimizzare la nostra attività.
Quindi, per concludere, quello che sto vedendo, quindi, è che abbiamo bisogno di nuove fonti di dati emergenti. Abbiamo nuove piattaforme su un'architettura più complicata, se vuoi, per gestirlo. E Hadoop sta diventando molto, molto importante, sufficiente per la preparazione dei dati per i nostri sandbox liquidi, per le query di archivio, l'archivio dal data warehouse, la gestione dei dati che spalanca le ali per andare oltre il data warehousing nella gestione dei dati su tutte queste piattaforme e nuovi strumenti per essere in grado di analizzare e accedere ai dati in questi ambienti, di essere in grado di disporre di tecnologie scalabili per eseguire un migliore inserimento dei dati e di ridimensionare le analisi spingendole verso il basso nelle piattaforme per renderle più parallele. E poi, si spera, anche per semplificare l'accesso a tutto questo attraverso l'SQL emergente che arriva sopra le righe. Quindi, ti dà un'idea del tipo di dove siamo diretti. Quindi, con quello, tornerò a, suppongo, Eric ora, vero?
Eric: Okay, è fantastico. E la gente, devo dire, tra quello che hai appena ricevuto da Robin e Mike, probabilmente è tanto comprensiva e concisa in una visione d'insieme dell'intero paesaggio da guardare come troverai ovunque. Vorrei andare avanti e fare prima la coda a George Corugedo. Ed eccolo qui. Lasciami prendere questo per un secondo veloce. Bene, George, sto per consegnarti le chiavi e portartele via. Il pavimento è tuo.
George: Fantastico! Grazie mille, Eric, e grazie, Rob e Mike. Questa è stata un'ottima informazione e molte cose su cui siamo d'accordo. Quindi, tornando alla discussione di Robin, perché, sai, non è una coincidenza che RedPoint sia qui e SAS sia qui. Poiché RedPoint, ci concentriamo davvero sul lato dei dati relativi alla governance, all'elaborazione dei dati e alla preparazione per l'uso nell'analisi. Quindi, lasciami solo passare attraverso queste due diapositive. E parliamo davvero del punto di vista di Robin sull'MDM e su quanto sia importante, e quanto utile, penso - e pensiamo - che Hadoop possa essere nel mondo dell'MDM e della qualità dei dati.
Sai, Robin stava parlando un po 'di, sai, come questo è legato al mondo del data warehouse aziendale e io vengo - sai, ho trascorso un certo numero di anni in Accenture. E ciò che è stato interessante è quante volte abbiamo dovuto entrare in aziende e cercare di capire cosa fare con il data warehouse che in pratica era stato abbandonato. E molto è successo perché il team del data warehouse non ha allineato realmente la propria build agli utenti aziendali o ai consumatori dei dati. Oppure, ci è voluto così tanto tempo che, quando hanno costruito la cosa, l'uso aziendale o la logica aziendale per esso si sono evoluti.
E una delle cose che penso sia, sono così entusiasta, l'idea di utilizzare Hadoop per la gestione dei dati master, per la qualità dei dati e per la preparazione dei dati, è il fatto che puoi sempre tornare ai dati atomici in un Hadoop data lake o serbatoio di dati, o repository di dati, o hub, o qualunque sia la forma di buzz che si desidera utilizzare. Ma poiché conservi sempre quei dati atomici, hai sempre l'opportunità di riallineare con gli utenti aziendali. Perché, come analista - poiché ho effettivamente iniziato la mia carriera come statistico - sai, niente è peggio di, sai, i data warehouse aziendali sono meravigliosi per guidare i report, ma se vuoi fare analisi davvero predittive, sono non è poi così utile, perché quello che vuoi davvero sono i dati comportamentali granulari che in qualche modo sono stati riassunti e aggregati nel data warehouse. Quindi, penso che sia davvero una caratteristica importante, e questa è una cosa che penso che potrei non essere d'accordo con Robin su è che lascerei personalmente i dati nel data lago o nell'hub dati il più a lungo possibile, perché finché i dati sono lì ed è pulito, puoi guardarli da una direzione, un'altra direzione. Puoi unirlo con altri dati. Hai sempre l'opportunità di tornare su di essa e ristrutturare, quindi riallinearti con un'unità di business e la necessità che questa unità potrebbe avere.
Uno degli altri tipi di cose interessanti su questo è che, poiché si tratta di una piattaforma computazionale così potente, di gran parte del carico di lavoro di cui abbiamo parlato, vediamo tutto arrivare direttamente in Hadoop. E mentre, penso, Mike stava parlando di tutte le diverse tecnologie che sono là fuori nel mondo di - in questo tipo di ecosistema di big data, pensiamo che l'Hadoop sia davvero il cavallo di battaglia per fare quella larga scala nell'elaborazione computazionalmente intensiva che dati anagrafici e qualità dei dati richiesti. Perché se riesci a farlo lì, sai, solo l'economia pura di spostare i dati dai tuoi database costosi e in database economici, questo sta davvero guidando così tanto la diffusione in questo momento nelle grandi aziende.
Ora, naturalmente, ci sono alcune sfide, giusto? Ci sono sfide intorno alle tecnologie. Molti di loro sono molto immaturi. Direi che non so quante, ma un certo numero di tecnologie citate da Mike sono ancora in versione zero-point, giusto? Quindi, queste tecnologie sono molto giovani, molto immature, ancora basate sul codice. E questo crea davvero una sfida per le imprese. E ci concentriamo davvero sulla risoluzione di problemi a livello aziendale. E quindi, pensiamo che ci debba essere un modo diverso, ed è quello che proponiamo è un modo diverso di affrontare alcune cose usando alcune di queste tecnologie nascenti.
E così, e poi l'altro interessante problema qui, che è stato menzionato in precedenza che è, quando hai dati che stai acquisendo in un ambiente Hadoop di qualunque tipo, sai, di solito è lo schema in lettura piuttosto che lo schema in scrittura con alcune eccezioni. E quella lettura, molto è stata fatta dagli statistici. Quindi, gli statistici devono disporre di strumenti che consentano loro di strutturare correttamente i dati a fini analitici, perché alla fine della giornata, per rendere utili i dati, devono essere strutturati in qualche forma per vedere alcuni o rispondere a una domanda o un'azienda, un qualche tipo di attività, crea valore aziendale.
Quindi, dove entriamo, è che abbiamo una EPL molto ampia e matura, una chiave master di qualità dei dati ELT e un'applicazione di gestione. È sul mercato da molti, molti anni. E ha tutte le funzionalità o gran parte delle funzionalità che Robin ha elencato in quel grafico circolare - tutto dalla semplice acquisizione di dati grezzi in una varietà di formati e strutture XML e quant'altro, alla capacità di fare tutta la pulizia, il completamento dei dati, correzione dei dati, bit del nucleo geospaziale dei dati. È qualcosa che sta diventando sempre più importante in questi giorni con l'Internet of Things. Sai, c'è una geografia associata a gran parte di ciò che facciamo o gran parte di tali dati. E così, tutto il parsing, la tokenizzazione, la pulizia, la correzione, la formattazione, la strutturazione, ecc., Tutto ciò viene fatto nella nostra piattaforma.
E poi, e forse, pensiamo soprattutto alla deduplicazione. Sai, in sostanza, se si guarda a qualsiasi definizione di gestione dei dati master, il nucleo di esso è la deduplicazione. È in grado di identificare entità attraverso diverse fonti di dati e quindi creare un record master per quell'entità. E quell'entità potrebbe essere una persona. L'entità potrebbe far parte di un aereo, per esempio. L'entità potrebbe essere un alimento come abbiamo fatto per uno dei nostri clienti del centro benessere. Abbiamo creato per loro un database alimentare principale. Quindi, qualunque siano le entità con cui stiamo lavorando - e, naturalmente, sempre più spesso, ci sono persone e deleghe per le loro identità che sono cose come maniglie o account sociali, qualsiasi dispositivo associato alle persone, alcune cose come automobili e telefoni e qualsiasi altra cosa tu possa immaginare.
Sai, stiamo lavorando con un cliente che sta mettendo tutti i tipi di sensori nell'abbigliamento sportivo. Quindi, i dati provengono da ogni direzione. E in un modo o nell'altro, è un riflesso o una rappresentazione dell'entità principale. E sempre di più, sono le persone e la capacità di identificare le relazioni tra tutte queste fonti di dati e il modo in cui si collegano a quell'entità centrale, e quindi essere in grado di tracciare quell'entità centrale nel tempo in modo da poter analizzare e comprendere i cambiamenti tra quell'entità e tutti quegli altri elementi che si trovano in quelle rappresentazioni di quell'entità, per esempio un'analisi davvero critica a lungo termine e longitudinale delle persone. E questo è davvero uno dei vantaggi davvero importanti che, penso, i big data possono portarci è una comprensione molto migliore delle persone, e nel lungo termine, e capire come e le persone si comportano quando si comportano attraverso quali dispositivi, ecc. .
Quindi, lasciami passare qui velocemente. Eric ha menzionato YARN. Sai, lo lancio solo per un po 'di secondo, perché mentre FILO - la gente parla di FILATO. C'è ancora molta ignoranza, penso, su YARN. E non molte persone davvero - c'è ancora un sacco di incomprensioni su YARN. E il fatto è che se l'applicazione è stata progettata nel modo giusto e si dispone del livello o della parallelizzazione adeguati nell'architettura dell'applicazione, è possibile sfruttare YARN per utilizzare Hadoop come piattaforma di ridimensionamento. Ed è esattamente quello che abbiamo fatto.
Sai, ancora una volta, solo per sottolineare alcune delle definizioni attorno a YARN. Per noi, ciò che realmente YARN è ha permesso a noi stessi e ad altre organizzazioni di diventare colleghi di MapReduce e Spark e di tutti gli altri strumenti disponibili. Ma il fatto è che le nostre applicazioni guidano il codice ottimizzato direttamente in YARN in Hadoop. E c'è un commento davvero interessante che Mike ha menzionato, perché, sai, la domanda sull'analitica e la nostra analisi, solo perché sono nel cluster, funzionano davvero in parallelo? Puoi fare la stessa domanda su molti strumenti di qualità dei dati disponibili.
La maggior parte della giornata, gli strumenti di qualità che sono là fuori devono o estrarre i dati o inserire codice. E in molti casi, è un singolo flusso di dati che viene elaborato a causa del modo in cui devi confrontare i record, a volte nel tipo di attività di qualità dei dati. E il fatto è che, poiché stiamo utilizzando YARN, siamo stati in grado di sfruttare davvero la parallelizzazione.
E solo per darvi una rapida panoramica, poiché viene fatto un altro commento sull'importanza di poter espandere database tradizionali, nuovi database, ecc., Implementiamo o installiamo al di fuori del cluster. E spingiamo i nostri binari direttamente nel gestore risorse, YARN. E quello, e quindi YARN lo distribuisce attraverso i nodi del cluster. Ciò che fa è che YARN - permettiamo a YARN di gestire e fare il suo lavoro, che è capire dove si trovano i dati e portare il lavoro ai dati, il codice ai dati e non spostare i dati. Quando senti gli strumenti di qualità dei dati e ti dicono che la migliore pratica è quella di spostare i dati fuori da Hadoop, correre per la tua vita, perché non è così. Vuoi portare il lavoro ai dati. Ed è quello che fa YARN per primo. Porta i nostri file binari ai nodi in cui risiedono i dati.
E anche perché siamo al di fuori del cluster, possiamo anche accedere a tutti i database tradizionali e relazionali in modo da poter avere lavori che sono server client al 100% su un database tradizionale, lavori Hadoop al 100% o ibridi che attraversano il server client Hadoop , Oracle, Teradata - qualunque cosa tu voglia e tutti nello stesso lavoro, perché quella implementazione può accedere ad entrambe le parti del mondo.
E poi, tornando all'intera idea della nascita degli strumenti, vedi qui, questa è solo una semplice rappresentazione. E quello che stiamo cercando di fare è semplificare il mondo. E il modo in cui lo facciamo è portando un set molto ampio di funzionalità attorno a HDFS per renderlo ... E non è perché stiamo cercando di eliminare tutte le tecnologie innovative là fuori. Solo le aziende hanno bisogno di stabilità e non amano le soluzioni basate su codice. Pertanto, ciò che stiamo cercando di fare è offrire alle aziende un ambiente applicativo familiare, ripetibile e coerente che dia loro la possibilità di creare ed elaborare i dati in modo molto prevedibile.
Rapidamente, questo è il tipo di impatto che otteniamo con la nostra applicazione. Visualizzi MapReduce vs. Pig vs. RedPoint: nessuna riga di codice in RedPoint. Sei ore di sviluppo presso MapReduce, tre ore di sviluppo in Pig e 15 minuti di sviluppo in RedPoint. Ed è qui che abbiamo davvero un impatto enorme. Anche il tempo di elaborazione è più veloce, ma il tempo delle persone, il tempo di produttività delle persone, è notevolmente aumentato.
E la mia diapositiva finale qui, voglio tornare a questa idea, perché questa è la nostra opinione sull'utilizzo di un data lake o di un hub dati o di una raffineria di dati come punto centrale di ingestione. Non potrei essere più d'accordo con quell'idea. E attualmente stiamo discutendo con molti dei Chief Data Officer delle principali banche globali, e questa è l'architettura scelta.L'ingestione di dati da tutte le fonti esegue l'elaborazione della qualità dei dati e la gestione dei dati principali all'interno del lago dei dati, quindi spinge i dati dove devono andare per supportare le applicazioni, supportare la BI, qualunque essa sia. Quindi, se si dispone di analisi in BI, possono essere eseguite direttamente all'interno del data lake, dove tutto il meglio, che può iniziare immediatamente. Ma sono molto d'accordo con questa idea. Questa topologia qui è quella che stiamo scoprendo sta guadagnando molta trazione dal mercato. E questo è tutto.
Eric: Okay, bene. Muoviamoci qui. Vado avanti e lo consegno a Keith. E, Keith, hai circa 10, 12 minuti per scuotere la casa qui. Ci siamo presi un po 'di tempo in questi spettacoli. E abbiamo pubblicizzato 70 minuti per questo. Quindi, basta andare avanti e fare clic in un punto qualsiasi di quella diapositiva e utilizzare la freccia giù e portarla via.
Keith: Sicuro. Nessun problema, Eric. Lo apprezzo. Ho intenzione di andare avanti e colpire solo un paio di pezzi su SAS, poi mi sposterò, proprio nelle architetture tecnologiche di dove SAS si interseca con il mondo dei big data. C'è molto da spiegare in tutte queste cose. Potremmo passare ore a esaminarlo in modo molto dettagliato, ma dieci minuti: dovresti essere in grado di andare via con una breve comprensione di dove SAS ha portato le tecnologie di analisi, gestione dei dati e business intelligence in questo mondo dei big data.
Innanzitutto, solo un po 'di SAS. Se non hai familiarità con questa organizzazione, negli ultimi 38 anni abbiamo fatto analisi avanzate, business intelligence e gestione dei dati con non solo big data, ma piccoli dati e ricchezza di dati negli ultimi 38 anni. Abbiamo un enorme piede di clienti esistenti, circa 75.000 siti in tutto il mondo, che lavorano con alcune delle migliori organizzazioni là fuori. Siamo un'organizzazione privata con circa 13.000 dipendenti e 3 miliardi di dollari di entrate. E davvero, immagino, la parte importante è che abbiamo tradizionalmente una lunga storia di reinvestire quantità significative delle nostre entrate nella nostra organizzazione di ricerca e sviluppo, che ha davvero portato a sostenere molte di queste fantastiche tecnologie e piattaforme che " stai andando a vedere oggi.
Quindi, salterò direttamente in questi diagrammi di architettura davvero spaventosi. Lavoreremo da sinistra a destra nelle mie diapositive. Quindi, ci sono cose familiari che vedrai all'interno di questa piattaforma. Sul lato sinistro, tutte quelle fonti di dati di cui stiamo parlando per importare in queste piattaforme di big data. E poi, hai questa piattaforma per big data.
Non ho semplicemente messo la parola Hadoop lì in cima, perché alla fine, gli esempi che darò oggi sono specificamente attorno a tutte le tecnologie in cui ci interseciamo con queste piattaforme di big data. Hadoop sembra essere uno di quelli in cui abbiamo alcune delle opzioni di implementazione più robuste, ma ci interseciamo anche un po 'e abbiamo sviluppato molte di queste tecnologie per qualche tempo con alcuni dei nostri altri partner di data warehouse aziendali come Teradata, Oracle, Pivotal e simili. Quindi, non posso entrare in grandi dettagli su tutte le diverse tecnologie supportate su quale piattaforma, ma sono certo che tutte quelle che descrivo oggi sono per lo più tutto ciò che Hadoop e una grande quantità di esse si interseca con altri partner tecnologici che noi abbiamo. Quindi, abbiamo una piattaforma così grande seduta lì.
Il prossimo a destra, abbiamo il nostro SAS LASR Analytic Server. Ora, quello essenzialmente, è un parallelo enormemente nel server di applicazioni analitiche di memoria. Saremmo chiari che non si tratta di un database in memoria. È davvero progettato da zero. Non è il motore di query, ma progettato per soddisfare le richieste analitiche su vasta scala in modo enormemente parallelo. Quindi, queste sono le applicazioni chiave del servizio che vedete lì sul lato destro.
Ci occuperemo un po 'di più di come, sai, come le persone distribuiscono queste cose. Ma essenzialmente, l'applicazione - vedi qui - la prima è la nostra analisi SAS ad alte prestazioni. Sarà: sto usando molte delle nostre tecnologie e piattaforme esistenti come Enterprise Miner o solo un SAS, e non sto solo facendo il multithreading con alcuni di quegli algoritmi che abbiamo integrato in quegli strumenti per cui abbiamo lavorato anni, ma anche per parallelamente massicciamente quelli. Quindi, per spostare i dati da quella piattaforma di big data nello spazio di memoria a quel LASR Analytic Server, in modo da poter eseguire algoritmi analitici - sai, molti dei nuovi machine learning, reti neurali, regressioni casuali di foreste, questo tipo di cose - di nuovo, i dati che si trovano nella memoria. Quindi, liberandoci di quel certo collo di bottiglia del paradigma di MapReduce in cui siamo archiviati su quelle piattaforme, non è il modo in cui vuoi fare un lavoro analitico. Quindi, vogliamo essere in grado di sollevare i dati una volta nello spazio di memoria e iterarli attraverso, sai, a volte migliaia di volte. Quindi, questo è il concetto di utilizzare quel server analitico LASR ad alte prestazioni.
Abbiamo anche - le altre applicazioni sottostanti, l'analitica visiva, che ci consente di conservare quei dati in memoria e servire una popolazione più ampia sugli stessi dati. Quindi, consentendo alle persone di fare l'esplorazione dei big data. Quindi, prima di eseguire i nostri lavori di sviluppo del modello, stiamo esplorando i dati, arrivando a capirli, eseguendo correlazioni, facendo previsioni o trend di alberi decisionali - quel genere di cose - ma in modo molto visivo e interattivo sui dati che sono nella memoria piattaforma. Ciò è utile anche per la nostra comunità BI per quanto riguarda la presenza di una vastissima base di utenti in grado di colpire quella piattaforma per fare tipi standard di registrazione che vedresti, praticamente qualsiasi fornitore di BI là fuori.
Il prossimo passo, passiamo quindi al servizio. E per aiutare i nostri statistici e i nostri analisti a essere in grado di fare quel tipo di modellazione ad-hoc con i dati archiviati in memoria, rimossi dall'analisi visiva e dall'esplorazione nella nostra applicazione di statistiche visive. Questa è un'opportunità per le persone di cogliere, di non eseguire statistiche in lotti che erano soliti iterare, eseguire i modelli, vedere i risultati. Quindi, che può eseguire il modello, vedere i risultati. Questo per trascinare visivamente la modellazione statistica interattiva. Quindi, questo aiuta i nostri statistici e i nostri data scientist a fare molto di quel lavoro di statistica visiva esplorativa iniziale.
E poi, non abbiamo dimenticato i nostri programmatori: le persone che vogliono davvero avere, essere in grado di sbucciare i livelli dell'interfaccia opposta, sono scrivere applicazioni e scrivere la propria base di codice in SAS. E queste sono le nostre statistiche in memoria per Hadoop. E questo è essenzialmente il livello di codice che ci ha permesso di interagire con quel server analitico LASR per emettere comandi direttamente e personalizzare quelle applicazioni in base alla nostra richiesta. Questo è il pezzo analitico.
Come si organizzano queste cose ... Oops, mi dispiace ragazzi. Eccoci.
Quindi, ci sono davvero un paio di modi in cui lo facciamo. Uno è farlo con i big data - in questo caso, con Hadoop. Ed è qui che abbiamo quel SAS LASR Analytic Server in esecuzione in un cluster separato di macchine ottimizzate per l'analitica hardcore. Questo è perfetto e vicino alla piattaforma di big data, permettendoci di ridimensionarlo separatamente dalla piattaforma di big data. Quindi, vediamo persone che lo fanno quando non vogliono avere una sorta di ciò che caratterizzo come un software per vampiri che mangia via in ciascuno dei nodi del loro cluster Hadoop. E non necessariamente ridimensionano la piattaforma di big data appropriata per eseguire analisi di memoria pesante. Quindi, potresti avere 120 nodi del loro cluster Hadoop, ma potrebbero avere 16 nodi di server analitici progettati per fare quel tipo di lavoro.
Siamo ancora autorizzati a mantenere quel parallelismo dalla piattaforma dei big data per estrarre i dati in memoria. Quindi, è davvero un utilizzo di SAS con la piattaforma Hadoop. Un modello di appuntamento diverso quindi è quello di dire che possiamo usare anche quella piattaforma di merce e spingerla - essenzialmente eseguiamo il server analitico LASR sulle piattaforme Hadoop. Quindi, ecco dove siamo ... stai operando all'interno della piattaforma dei big data. Questo è anche alcuni dei nostri altri fornitori di elettrodomestici. Quindi, ciò ci ha permesso di utilizzare essenzialmente quella piattaforma di prodotti per fare quel lavoro.
Lo vediamo più spesso con cose come l'analitica ad alte prestazioni in cui si tratta di un tipo di analisi analitica monouso o monouso, più tipo di batch orientato dove sei - non vuoi necessariamente consumare lo spazio di memoria in Hadoop piattaforma. Siamo molto flessibili con questo tipo di modello di distribuzione, sicuramente stiamo lavorando con YARN in molti di questi casi per assicurarci di giocare a cluster di qualità.
Va bene, quindi questo è il mondo analitico, tanto per essere chiari lì con l'applicazione analitica. Ma ho detto che SAS all'inizio è anche una piattaforma di gestione dei dati. E ci sono cose che sono appropriate per spingere la logica in quella piattaforma dove appropriato. Quindi, ci sono un paio di modi in cui lo facciamo. Uno è nel mondo dell'integrazione dei dati, fare un lavoro di trasformazione dei dati sui dati potrebbe non avere senso ritirarlo come abbiamo sentito prima, eseguendo routine di qualità dei dati che sono grandi. Vogliamo spingere definitivamente cose come routine di qualità dei dati in quella piattaforma. E poi, cose come il punteggio del modello. Quindi, ho sviluppato il mio modello. Non voglio riscrivere quella cosa in MapReduce e rendere difficile e dispendioso il tempo per me ripetere quel lavoro nella piattaforma di database nativa.
Quindi, se guardiamo, ad esempio, il nostro acceleratore di punteggio per Hadoop, che ci consente essenzialmente di prendere un modello e spingere la logica matematica SAS verso quella piattaforma Hadoop ed eseguirla lì, usando il parallelismo all'interno di quella piattaforma di big data. Abbiamo quindi il nostro acceleratore di codice per varie piattaforme tra cui Hadoop, e ciò ci consente essenzialmente di eseguire il codice di passo dei dati SAS all'interno della piattaforma in modo enormemente parallelo, quindi, facendo un lavoro di trasformazione dei dati nella piattaforma. E poi il nostro acceleratore di qualità dei dati SAS che ci consente di avere una base di conoscenza di qualità seduta lì che può fare cose come la corrispondenza di genere, il codice di corrispondenza della standardizzazione - tutte le diverse cose sulla qualità dei dati che hai già sentito oggi.
E poi, ultimo pezzo, c'è Data Loader. Sappiamo che i nostri utenti aziendali dovranno essere in grado di non dover scrivere codice, far funzionare la trasformazione dei dati su queste piattaforme di big data. Data Loader è una bella GUI WYSIWYG che ci consente di mettere insieme quelle altre tecnologie. È come una procedura guidata dettagliata, ad esempio, eseguire una query Hive o eseguire una routine di qualità dei dati e non dover scrivere codice in quel caso.
L'ultima cosa che menzionerò è questo frontespizio. Come abbiamo già detto, abbiamo un enorme piede SAS nel mondo. E questo, non possiamo semplicemente fare tutte quelle piattaforme che sono là fuori per essere immediatamente in questo spazio. Quindi, abbiamo sicuramente un piede esistente di utenti che devono disporre di un dato contenuto in queste piattaforme di big data come estrarre i dati da Teradata e rimetterli in Hadoop, e viceversa. Eseguendo i modelli so già come eseguire sui miei server SAS, ma ho bisogno di ottenere un dato che ora viene inserito nella piattaforma Hadoop. Quindi, c'è un'altra piccola icona lì chiamata "da" e che ci consente di connetterci utilizzando i nostri motori di accesso SAS: accedere ai motori di Hadoop a Cloudera a Pola, a Teradata, a Greenplum a ... E l'elenco continua. Questo ci consente di utilizzare le nostre piattaforme SAS mature esistenti che sono già in atto per ottenere dati da queste piattaforme, fare il lavoro che dobbiamo fare, riportare i risultati in queste aree.
L'ultima cosa che menzionerò è che tutte queste tecnologie che vedi sono tutte governate dagli stessi metadati comuni standard. Quindi, parliamo di far funzionare il processo di trasformazione, di far funzionare la regola della qualità dei dati, di spostarla in memoria per poter fare analisi, sviluppare modelli nel punteggio. Abbiamo raggiunto l'intero stile di vita analitico, il ciclo di vita è governato da metadati comuni, dalla governance, dalla sicurezza, da tutte le cose di cui abbiamo parlato prima.
Quindi, solo un riassunto, ci sono davvero quelle tre grandi cose da portare lì. Uno è, possiamo trattare la piattaforma di dati come qualsiasi altra fonte di dati, attingendo da loro, spingendoli verso di loro quando è appropriato e conveniente. Possiamo lavorare con quelle piattaforme di big data, elencando i dati in un'analitica avanzata appositamente costruita nella piattaforma di memoria. Quindi, quello è il server LASR.
E infine, possiamo lavorare direttamente su quelle piattaforme di big data, sfruttando le loro capacità di elaborazione distributiva senza spostare i dati.
Eric: Beh, è roba fantastica, gente. Sì, è fantastico! Quindi, approfondiamo alcune domande. In genere passiamo circa 70 minuti o un po 'più a lungo su questi eventi. Quindi, vedo che abbiamo ancora un grande pubblico seduto lì fuori. George, immagino che ti porterò la nostra prima domanda. Se parli di inserire il tuo suono binario in Hadoop, penso che mi sembri come se avessi davvero ottimizzato il flusso di lavoro computazionale. E questa è l'intera chiave per essere in grado di fare questo tipo di governance dei dati in tempo reale, risultati dello stile di qualità dei dati, perché questo è il valore che vuoi ottenere, giusto? Se non vuoi tornare nel vecchio mondo di MDM, dove è molto ingombrante ed è molto dispendioso in termini di tempo, e devi davvero costringere le persone ad agire in determinati modi, che quasi mai funziona. E così, quello che hai fatto è, hai condensato il ciclo di ciò che era. Chiamiamolo giorni, settimane, a volte anche mesi o secondi, giusto? È quello che sta succedendo?
George: Esatto, perché la scala che otteniamo e le prestazioni che otteniamo da un cluster sono davvero sconcertanti in termini, solo, sai, sono sempre un po 'titubante riguardo ai benchmark. Ma solo per l'ordine di grandezza, quando eseguiremmo un miliardo, 1,2 miliardi di record e faremmo una standardizzazione completa dell'indirizzo - sto dicendo macchina HP di fascia media - ci vorrebbero, come, sai, otto macchine con processore, sai , 2 concerti di RAM per core, ci vorranno 20 ore per l'esecuzione. Possiamo farlo tra circa otto minuti su un cluster a 12 nodi. E così, la scala del trattamento che possiamo fare ora è così drammaticamente diversa che - e si adatta molto bene all'idea che tu abbia tutti questi dati a tua disposizione. Quindi, non è così rischioso fare l'elaborazione. Se hai sbagliato, puoi rifarlo. Hai tempo, lo sai. Ha davvero cambiato la portata di questo dove, sai, quei tipi di rischi sono diventati davvero problemi di business reali per le persone quando cercavano di operare soluzioni MDM. Devi avere 30 persone in mare aperto che gestiscono i dati e tutto il resto. E così, devi ancora avere un po 'di quello, ma la velocità e la scala con cui puoi elaborarlo ora, ti danno davvero molto più spazio per respirare.
Eric: Sì, questo è davvero un ottimo punto. Adoro quel commento. Quindi, hai il tempo di rifarlo di nuovo. È fantastico.
George: Sì.
Eric: Beh, cambia la dinamica, giusto? Cambia il modo in cui pensi a cosa proverai. Voglio dire, me lo ricordo 18 anni fa nel settore degli effetti speciali, perché avevo un cliente che si trovava in quello spazio. E spingeresti i pulsanti per renderlo e torneresti a casa. E saresti tornato, forse sabato pomeriggio, per vedere come stava andando. Ma se hai sbagliato, è stato molto, molto, molto doloroso. E ora, non è quasi - non è nemmeno vicino a essere così doloroso, quindi hai l'opportunità di provare più cose. Devo dire che penso sia davvero un ottimo punto.
George: Esatto. Sì, e ti fai saltare la gamba in più. Sai, a metà lavoro un tempo ai vecchi tempi e fallisce, hai spazzato via il tuo SOS. Questo è tutto.
Eric: Giusto. E sei in grossi guai, sì. Giusto.
George: Esatto. Giusto.
Eric: Keith, lascia che te ne dia uno. Ricordo di aver fatto un'intervista con il tuo CIL, Keith Collins, credo, forse nel 2011. E ha parlato molto della direzione che SAS stava prendendo in particolare riguardo alla collaborazione con i clienti per integrare l'analisi derivata da SAS nei sistemi operativi. E, naturalmente, abbiamo sentito Mike Ferguson parlare dell'importanza di ricordare. L'idea qui è che vuoi essere in grado di legare questa roba alle tue operazioni. Non vuoi analisi nel vuoto, disconnesso dall'azienda. Non ha alcun valore.
Se si desidera un'analisi che può influire direttamente e ottimizzare le operazioni. E se guardo indietro - e devo dire, ho pensato che fosse una buona idea allora - sembra un'idea davvero molto intelligente in retrospettiva. E immagino, questo è un vero vantaggio che voi ragazzi avete. E, naturalmente, questa grande eredità, questa enorme base di installazione e il fatto che tu sia stato concentrato sull'incorporazione di queste analisi nei sistemi operativi, il che significa che ora - e garantito, ci vorrà un po 'di lavoro - Sono sicuro che " ci ho lavorato abbastanza duramente. Ma ora, puoi sfruttare tutte queste nuove innovazioni e sei davvero in grado di rendere operativa tutta quella roba con i tuoi clienti. È una valutazione corretta?
Keith: Sì, assolutamente. Il concetto è che hai questa idea di design delle decisioni o di scienze delle decisioni che è, in una certa misura, esplorativa, di tipo scientifico. A meno che tu non possa fare ingegneria sul processo per davvero ... Se pensi allo sviluppo di un'auto, hai designer che realizzano questa bellissima auto, ma non è fino a quando gli ingegneri non mettono in atto quel piano e realizzano un vero prodotto fattibile prima di te può effettivamente mettere le cose a posto, ed è essenzialmente ciò che SAS ha fatto. Ha unito le decisioni: il processo decisionale con il processo decisionale, in modo che quando si parla di acceleratori, in particolare degli acceleratori di punteggio, si sa se si prende un modello sviluppato e si è in grado di spingerlo fuori su Teradata o inviarlo a Oracle o Hadoop, senza tempi di inattività per lo sviluppo del modello, per modellare la distribuzione. Questa è la chiave, perché i modelli si degradano nel tempo, la precisione di quei modelli. Quindi, più tempo impieghi a prenderlo e metterlo in produzione, questa è la perdita di precisione del modello.
E poi, l'altro pezzo è, vuoi essere in grado di monitorare e gestire quel processo nel tempo. Vuoi deprecare i modelli quando diventano vecchi e imprecisi. Vuoi guardarlo, verificarne l'accuratezza nel tempo e ricostruirli. E così, abbiamo anche strumenti di gestione dei modelli che si collocano in cima a questo, che tracciano davvero i metadati attorno al processo modellato. E la gente ha detto che modellare, sai, quel tipo di concetto è come una fabbrica di modelli, o come la vuoi chiamare. Il fatto è che sta mettendo in atto metadati e gestione ed è qui che le tre grandi cose che colpiamo: aiutiamo le persone a fare soldi, risparmiare denaro e tenerli fuori dalla prigione.
Eric: Anche quest'ultimo è piuttosto grande. Sto cercando di evitare tutto ciò. Quindi, parliamo di ...Sto ponendo un'ultima domanda, forse ognuno di voi può entrambi saltare su questo. L'eterogeneità del nostro mondo non farà che aumentare, mi sembra. Penso che vedremo sicuramente un po 'di cristallizzazione negli ambienti cloud ibridi. Tuttavia, vedrai un sacco di giocatori importanti che restano in giro. IBM non sta andando da nessuna parte. Oracle non sta andando da nessuna parte. SAP non sta andando da nessuna parte. E ci sono così tanti altri venditori coinvolti in questo gioco.
Inoltre, sul lato operativo, dove hai letteralmente migliaia e migliaia di diversi tipi di applicazioni. E ho sentito - molti di voi ne parlano, ma penso che entrambi concorderebbero con quello che ho detto. Abbiamo visto questa tendenza ora in termini di potenza computazionale nei motori analitici, architettura. Le aziende parlano da anni della possibilità di attingere agli altri motori e fornire una sorta di punto di orchestrazione. E immagino, George, te lo lancio prima io. Mi sembra che sia qualcosa che non cambierà. Avremo questo ambiente eterogeneo, il che significa che ci sono cose come CRM in tempo reale, qualità dei dati e governance dei dati. Avrai bisogno, come venditore, di interfacciarsi con tutti quei diversi strumenti. Ed è quello che i clienti vorranno. Non vorranno qualcosa che lo faccia bene con questi strumenti e non così bene con quegli strumenti. Vorranno la Svizzera di MDM e CRM, giusto?
George: Esatto. Ed è interessante, perché l'abbiamo abbracciato moltissimo. Parte di essa è la storia che abbiamo avuto nello spazio. E ovviamente stavamo già lavorando su tutti gli altri database, i Teradata e i pezzi del mondo. E poi, fatto nel processo di implementazione, in particolare nel modo in cui lo abbiamo fatto, solo per farlo, hai quell'intervallo su tutti questi vari database. Una delle cose che trovo interessanti è che abbiamo alcuni client che sono semplicemente intenzionati a eliminare tutti i database relazionali. E questo è interessante. Sai, voglio dire, va bene. È interessante. Ma non vedo che stia realmente accadendo su vasta scala aziendale. Non lo vedo succedere per molto tempo. Quindi, penso che l'ibrido sia qui da molto tempo e dall'altra parte della nostra applicazione in cui abbiamo la nostra piattaforma di messaggistica nella nostra piattaforma di gestione delle campagne. In realtà l'abbiamo progettato appositamente. Ora, abbiamo rilasciato una versione che lo fa e che può connettersi ora all'ambiente di dati ibridi e interrogare Hadoop, oppure interrogare qualsiasi database, qualsiasi database analitico. Quindi, penso che sia solo l'onda del futuro. E sono d'accordo sul fatto che la virtualizzazione avrà sicuramente un ruolo importante in questo, ma stiamo solo andando ai dati su tutte le nostre applicazioni.
Eric: Ok, fantastico. E, Keith, te lo lancio. Cosa ne pensi del mondo eterogeneo che stiamo affrontando nell'agire come una specie di piede?
Keith: Sì, è davvero affascinante. Penso che ciò che troviamo di più - non solo dal punto di vista della gestione dei dati - ma ciò che è davvero affascinante in questo momento è la natura open source della base di analisi. Quindi, vediamo organizzazioni come, o tecnologie come Spark, e persone che usano Python e R e tutte queste altre tecnologie open source. Penso che potrebbe essere interpretato come una sorta di conflitto o una minaccia in una certa misura. Ma la realtà è che abbiamo alcuni complimenti davvero meravigliosi con tutte quelle tecnologie open-source. Voglio dire, per esempio, stiamo operando su piattaforme open source, per l'amor di Dio.
Ma anche come poter integrare, ad esempio, un modello R in un paradigma SAS ti consente di utilizzare il meglio dei due mondi, giusto? Ad esempio, sappiamo che alcune delle cose sperimentali nel mondo accademico e alcune delle attività di sviluppo del modello sono straordinarie e super utili nel processo di sviluppo del modello. Inoltre, se potessi accoppiarlo a un tipo di strumento di classe di produzione, esegue molte operazioni di pulizia, qualità e controllo e verifica che i dati forniti al modello lo siano, è stato preparato correttamente in modo da non fallire in esecuzione. E poi, essere in grado di fare cose come campioni di modelli sfidanti con modelli open source. Queste sono le cose che stiamo cercando di abilitare e come parte di questo ecosistema davvero eterogeneo di tutte queste tecnologie. Sì, quindi è di più - per noi, si tratta più di abbracciare quelle tecnologie e cercare i complimenti.
Eric: Beh, questa è stata roba fantastica, gente. Siamo andati un po 'a lungo qui, ma ci piacerebbe arrivare a quante più domande possibili. Inoltreremo il file di domande e risposte ai nostri presentatori oggi. Pertanto, se qualsiasi domanda che hai posto non ha ricevuto risposta, ci assicureremo che riceva risposta. E gente, questo si conclude per il 2014. Cordiali saluti alla radio DM domani e la prossima settimana, e poi è tutto fatto ed è una vacanza.
Mille grazie a tutti voi per il vostro tempo e la vostra attenzione, per aver seguito tutti questi meravigliosi webcast. Abbiamo in programma un grande anno per il 2015. E ci sentiamo presto, gente. Grazie ancora. Ci pensiamo noi. Ciao ciao.