La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

* 16/07/96 Data Warehouse La maggior parte delle aziende dispone di enormi basi di dati contenenti dati di tipo OPERATIVO. Queste basi di dati costituiscono.

Presentazioni simili


Presentazione sul tema: "* 16/07/96 Data Warehouse La maggior parte delle aziende dispone di enormi basi di dati contenenti dati di tipo OPERATIVO. Queste basi di dati costituiscono."— Transcript della presentazione:

1 * 16/07/96 Data Warehouse La maggior parte delle aziende dispone di enormi basi di dati contenenti dati di tipo OPERATIVO. Queste basi di dati costituiscono una potenziale miniera di informazioni utili. Francesco Pasturenzi *

2 * 16/07/96 Introduzione La Data Warehouse (DW) è un sistema per il supporto alle decisioni (NON E’ SEMPLICEMENETE UNA GROSSA BASE DI DATI), permettono di: Analizzare lo stato dell’azienda (operazioni di Data Mining) Prendere decisioni rapide e migliori (analizzando dati freschi) Migliorare la qualità del servizio Prevedere l’evoluzione della domanda (si pensi alla finanza) Individuare aree critiche Realizzare strategie vincenti (es: contenimento dei costi, aumento dei profitti) Definire (es: nel campo finanziario) pratiche antifrode e antiriciclaggio Francesco Pasturenzi *

3 Business Intelligence
* 16/07/96 Business Intelligence E’ genericamente il processo di trasformazione di dati e informazioni in conoscenza. Nello specifico, le tecnologie BI hanno lo scopo di supportare un’organizzazione nello sfruttare al meglio il suo patrimonio informativo (interno ed esterno) nei processi decisionali (decision making). Le tecnologie BI forniscono delle viste storiche, correnti e predittive sui processi di business. La BI permette di customizzare le informazioni velocemente in base all’attore coinvolto e profilato. Es: nell’università gli attori coinvolti sono docente, preside, segreteria, studente. Se è stata adottata una BI per la DW dell’università, esisteranno 4 profili, ognuno dei quali potrà accedere ad una serie di informazioni. Francesco Pasturenzi *

4 Business Intelligence
* 16/07/96 Business Intelligence Lo studente visualizzerà informazioni relative ai corsi che ha inserito nel suo carico didattico e potrà ottenere percentuali del superamento dei relativi esami. Il docente vorrà avere informazioni relative a quanti studenti seguono il suo corso quest’anno e quanti l’hanno seguito negli anni passati, conoscere la città di provenienza degli studenti nei diversi anni, percentuale di studenti che preferiscono e seguono in videolezione, se il corso avrà successo l’hanno seguente ecc Alla segreteria interesseranno informazioni relative alla didattica, tasse, percentuale di nuovi iscritti, numero di corsi attivi e non nell’anno corrente rispetto agli anni precedenti, ecc. Francesco Pasturenzi *

5 Business Intelligence
* 16/07/96 Business Intelligence Il preside vorrà avere informazioni sull’andamento dell’università e magari anche di alcuni dati interessanti per lo più per le segreterie, es: percentuale di ritardi nei pagamenti, debito, ecc La BI serve per fare interrogazioni specifiche e non su DW e sugli specifici Data Mart (eventualmente su DB). La presentazione, i risultati più o meno approfonditi e i filtri dipenderanno poi dell’attore in gioco. Attenzione: In teoria si può fare BI senza un DW ma direttamente su un DB. Ovviamente bisogna avere dello storico all’interno del DB. Si andrà a lavorare su dati le cui stime e analisi non saranno mai paragonabili a quelle calcolate su una DW. Si pensi alle stock option, un investitore sarebbe più propenso ad investire se l’analisi fosse stata fatta in un range di 1-2 anni anzichè di mesi. Francesco Pasturenzi *

6 Business Intelligence
* 16/07/96 Business Intelligence Le funzioni principali di un sistema DW/BI sono estrarre i dati dai sistemi sorgenti, pulirli, allinearli, conformarli e trasportali verso il data warehouse rendere questi dati disponibili agli utenti di business finali, in modo efficace Francesco Pasturenzi *

7 ( Praticamente TUTTI gli AMBITI in cui trattiamo DATI ELETTRONICI )
* 16/07/96 Ambiti applicativi Industrie manifatturiere: gestione ordini, spedizioni e supporto clienti Servizi finanziari: analisi acquisti (carta di credito, azioni) Assicurazioni (es: riconoscimento frodi) Tramite il DM si possono classificare cattivi clienti e buoni clienti in base ai suoi precedenti e da li aumentare o diminuire per esempio la polizza sulla vita Telecomunicazioni: analisi delle chiamate, riconoscimento frodi Servizi pubblici: analisi di utilizzo (prevedere il collassameto delle linee in certi periodi) Sanità: analisi dei risultati negli anni ( Praticamente TUTTI gli AMBITI in cui trattiamo DATI ELETTRONICI ) Francesco Pasturenzi *

8 * 16/07/96 Data Warehouse E’ una base di dati per il SUPPORTO ALLE DECISIONI che è mantenuta separatamente dalle basi di dati operative dell’azienda. Dati: Orientati a oggetti di interesse (tabelle dei fatti) Integrati e consistenti (no attributi vuoti... in teoria) Dipendenti dal tempo, NON VOLATILI Utilizzati per il supporto alle decisioni aziendali. NON VOLATILI: i dati non vengono sovrascritti, vengono aggiornati aggiungendone di nuovi nel tempo. Francesco Pasturenzi *

9 Data Warehouse I dati vengono separati dai DB ER alle DW perché:
* 16/07/96 Data Warehouse I dati vengono separati dai DB ER alle DW perché: Ricerche complesse riducono le prestazioni delle transazioni operative (INSERT, UPDATE, SELECT di tutti i giorni) Analisi + Uso non è fattibile le prestazioni crollerebbero da entrambe le parti. Metodi di accesso diversi a livello fisico (es: uso di viste materializzate [per velocizzare join e group by], procedure ad hoc, comandi ottimizzati all’analisi) Il DW contiene tutto lo storico o buona parte di esso dei DB ER, questo permette di fare analisi a lunga gittata indietro nel tempo. Es: ogni volta che si fanno una serie di UPDATE su un DB viene fatta un operazione di ETL su una DW (INSERT di nuove tuple, con timestamp diverso). Francesco Pasturenzi *

10 * 16/07/96 Data Warehouse Quindi l’ analisi su DB è possibile farla solo al tempo corrente. Es: operazioni al bancomat, dopo un prelievo viene visualizzato il credito corrente più le utlime operazioni fatte nell’ultimo mese. Durante la fase di ETL, per avere poi le proprietà di qualità dei dati analizzati, si fanno partire dei programmi per la correttezza dei valori provenienti dalla base di dati sorgente. Es: la carriera di uno studente, in un DB, quello della didattica è studente, mentre in quello della segreteria è professore  INCONSISTENZA tra i DB operazionali, in uno dei due non è stato fatto un UPDATE. la DW deve prevedere problemi di questo genere e trattare l’inconsistenza guardando il timestamp. Francesco Pasturenzi *

11 * 16/07/96 Struttura dei dati I dati vengo rappresentati come un (iper)cubo con tre o più dimensioni. Es: DW per l’analisi delle vendite di una catena di supermercati Assi dimensionali: prodotto, negozio e tempo (DIMENSIONI) Misure: quantità venduta, importo vendita (ELEMENTI QUANTITATIVI) Francesco Pasturenzi *

12 * 16/07/96 Struttura dei dati Le misure numeriche sono memorizzate nella tabella dei fatti. (+ avanti) Le dimensioni descrivono il contesto di ogni misura nella tabella dei fatti. Le dimensioni contengono molti attributi descrittivi. Esempio: DW per l’analisi delle vendite di una catena di supermercati. Tabella dei fatti: Vendita (Sale) Dimensioni: Negozio, Prodotto, Data Negozio: 300 righe = 300 negozi Prodotto: prodotti di cui 3000 venduti ogni giorno in ogni negozio (1/10) Francesco Pasturenzi *

13 * 16/07/96 Struttura dei dati Tempo: si tengono solo gli ultimi 2 anni = 2 x 365 giorni Numero di righe della tabella dei fatti: 730 x 300 x 3000 = 657 millioni Se ogni chiave di ogni prodotto venduto è di 4Kbyte vengono occupati circa 21 Gbyte. (dovuto al tempo principalmente). Da qui si capisce che la memoria HDD è molto importante nelle DW e non tutte le aziende si possono permette di fare analisi a lunga gittata tenendo comunque lo storico senza eliminarlo. Strumenti di analisi: Analisi OLAP: calcolo tramite funzioni aggregate complesse (es: media mobile, top ten) Usano una pesante componente algoritmica (molta CPU, RAM, CACHE, swapping eventualmente) Francesco Pasturenzi *

14 * 16/07/96 Struttura dei dati Una volta trovati i dati bisogna presentarli all’utenza eterogenea. Qui entrano in gioco linguaggi di compilazione e non. Si può rimanere sull’azienda che fa il DBMS es: BI di Oracle, oppure creare una piattaforma in Java, creare le procedure e package in Oracle PL/SQL e usare CSS3, HTML 5 e JS per presentarli in modo completamente custom, è ovvio che costa molto ma molto di più in termini di ore uomo per l’azienda cliente anche se le licenze Oracle sono molto costose. Allora perché? Si vuole evitare di legare mani e piedi ad un unico partner. Resta il fatto che la BI usa un tool e interfaccia tutta sua con vari vincoli e blocchi, ma il risultato per quanto riguarda l’analisi sarà sempre migliore perché è UNO STRUMENTO AD HOC per il Data Mining con Oracle come DW. Personalizzabile in parte. Francesco Pasturenzi *

15 * 16/07/96 Architetture per DW Esistono diverse architetture per le DW, si preferiscono quelle a due o più livelli e si evitano fortemente quelle ad un solo livello. Nella DW bisogna separare l’elaborazione transazionale dall’analisi dei dati. Le architetture a due o più livelli separano in misura diversa i dati in ingresso nella DW dai dati oggetto di analisi. Francesco Pasturenzi *

16 * 16/07/96 Architetture per DW Warehouse aziendale: contiene informazioni sul funzionamento di «tutta» l’azienda, la progettazione e realizzazione richiedono molto tempo. Sorgenti di dati: possono trovarsi su file di tipo diverso, dove per file, intendo veri e propri file strutturati come db (es: db di default in Python) Oppure veri e propri db (Oracle, MySQl, SQLite, MongoDb, DB2,…) Data Marts: sottoinsiemi della DW, un data mart è una parte specifica della DW. Es: i dipartimenti di un università oppure le sottosezioni in una grossa azienda. Francesco Pasturenzi *

17 * 16/07/96 Architetture per DW Quindi un Data Mart è un sottoinsieme dipartimentale focalizzato su un settore prefissato. Due possibilità: Alimentato dalla DW primaria Alimentato direttamente dalle sorgenti Il vantaggio di partire dai Data Mart per creare la DW è che la realizzazione è molto più rapida e si possono da subito effettuare analisi sui dati. Di solito l’approccio usato è: 1)Creo i diversi Data Mart (es: DM1: Innovazione, a cui sono collegate le sorgenti di Telemedicina(oracle), Eco Move(mysql), Cubovision(mongoDb))  + veloce 2)Una volta che ho DM1, DM2,…..,DMn integro il tutto è ottengo la DW. 3) Posso effettuare analisi sui singoli DM oppure sull’intera DW facendo un intersezione tra DM. Francesco Pasturenzi *

18 Architetture per DW Processo ETL:
* 16/07/96 Architetture per DW Processo ETL: Estrazione: acquisizione dei dati dalle sorgenti Pulitura: operazioni volte al miglioramento della qualità dei dati (correttezza e consistenza) Trasformazione: conversione dei dati dal formato operazionale a quello di data warehouse (integrazione) Caricamento: propagazione degli aggiornamenti al data warehouse Metadati: = dati sui dati Per ETL, descrivono i dati sorgenti e le trasformazioni necessarie per l’integrazione. Per la gestione dei dati: descrivono la struttura dei dati presente nel data warehouse Francesco Pasturenzi *

19 * 16/07/96 Architetture per DW Query con molti JOIN e GROUP BY su tabelle con centinaia di milioni di records richiederanno molta più CPU e MEMORIA. Per ottimizzare le performance di una query bisogna andare ad utilizzare indici BitMap, B+Tree, uso di viste classiche e materializzate altrimenti aumentano i MISS delle cache e la cpu schizza al 99% per job e si ha un aumento dello swapping tra HDD e RAM. Quindi i server OLAP devono essere ben carrozzati. Es: Se si esegue una query con attributi della vista in una group by automaticamente vengono presi i dati della vista che sono già pronti e magari già in memoria evitando di rifare join e group by ma si eseguono solo i predicati della clausola where non indicizzati. Francesco Pasturenzi *

20 * 16/07/96 Architetture per DW Analisi sui dati: = DATA MINING = PL/SQL+SQL99 interfacciato con BI. Una accenno al Data Mining: Le principali tecniche sono: Classificazione: modello predittivo, richiede dati già classificati, in questa tecnica si divide il Data Set in due parti Training e Test Set. Il Training serve per creare il classificatore il Test set per validarlo. Regole di associazione: ricerca di correlazioni (es: market basket) Clustering: suddivisione dei dati in gruppi omogenei, la tecnica di clustering è una delle più difficili perché bisogna misurare la distanza tra gli oggetti. L’algoritmo più utilizzato è il DBScan basato sulla densità dei dati. Francesco Pasturenzi *

21 Architetture per DW Architettura a due livelli
* 16/07/96 Architetture per DW Architettura a due livelli Francesco Pasturenzi *

22 Architetture per DW Disaccoppiamento dalle sorgenti
* 16/07/96 Architetture per DW Disaccoppiamento dalle sorgenti Possibilità di gestire dati esterni al sistema OLTP (file di teso: db di Python) Modellazione dei dati adatta all’analisi OLAP Progettazione fisica del DW mirata al carico analitico Separazione del carico transazionale da quello analitico. Le performance non collassano. Uso e analisi separato. Necessità di svolgere «al volo» la preparazione dei dati ETL (UNICO SVANTAGGIO) Francesco Pasturenzi *

23 Architetture per DW Architettura a tre livelli
* 16/07/96 Architetture per DW Architettura a tre livelli Francesco Pasturenzi *

24 * 16/07/96 Architetture per DW Staging Area: area di transito che permette di separare l’elaborazione ET dal caricamento nel data warehouse Permette operazioni complesse di trasformazione e pulizia dei dati Controlli sui singoli attributi correlati ad altri attributi. (es:sesso-nome) Esecuzione di pre-conteggi e creazioni di nuovi attributi utili per l’analisi. Introduce ulteriore ridondanza Aumenta lo spazio necessario per i dati.(aumenta i costi) Può essere vista come una piccola area di backup delle sorgenti. Francesco Pasturenzi *

25 * 16/07/96 OLTP e OLAP OLTP (On-Line Transaction Processing) è caratterizzato da un largo numero di piccole transazioni (INSERT, UPDATE, DELETE). L’obiettivo principale dei sistemi OLTP è eseguire le query il più velocemente possibile mantenendo comunque integrità dei dati in ambienti multi-utente/muti-accesso. Integrità di solito controllata tramite funzioni di Hash (funzioni di hash su dei digest) come per la sicurezza in rete. La misura dell’efficacia è data dal numero di transazioni al secondo. Nei database OLTP sono presenti dati dettagliati e del tempo corrente. Poi si, ci possono essere più tuple che puntato ad una stessa entità con diverso timestamp ma rimangono comunque di tipo OLTP, non è visto come storico. Quindi negli OLTP interessa il valore corrente. Francesco Pasturenzi *

26 OLTP e OLAP Es: Bancomat (OLTP) 1) Prelievo di 500€
* 16/07/96 OLTP e OLAP Es: Bancomat (OLTP) 1) Prelievo di 500€ 2) Saldo corrente (non mi interessa quello di un mese fa) Steps 1) e 2) sono ripetitivi per tutti i clienti della banca, i parametri che cambiano sono: quantità prelevata, numero di conto, saldo, data prelievo, … Vengono fatti degli accessi in lettura (pochi, diretti, molto veloci) e aggiornamenti di pochi record (es: tabella saldo: una tupla per ogni cliente) Dimensioni della base di dati da 100MB a qualche Gbyte. Francesco Pasturenzi *

27 OLTP e OLAP OLAP (On-lLine Analytical Processing)
* 16/07/96 OLTP e OLAP OLAP (On-lLine Analytical Processing) È caratterizzato da un basso volume di transazioni manuali. Le query sono spesso molto complesse e contengono aggregazioni di dati. Per i sistemi OLAP, la misura dell’efficacia è data dal tempo di risposta che deve essere il più basso possibile. Il tempo dipende dagli algoritmi in gioco durante l’analisi, dal numero di dati e atributi su cui si va a lavorare, dal numero di aggregazioni, dalla memoria e cpu disponibile. Slicing: affettare Dicing: cubetti Francesco Pasturenzi *

28 OLTP e OLAP Analisi dei dati => sistemi OLAP (DW)
* 16/07/96 OLTP e OLAP Analisi dei dati => sistemi OLAP (DW) Non mi posso accontentare dei soli «valori correnti», quindi dati di tipo storico, quindi multidimensionali. Nei sistemi OLAP si fa accesso a centinaia di milioni di record in lettura, al contrario degli OLTP. Una volta dati in pasto agli appositi algoritmi ne verranno fuori un centinaio/migliaio. Nei sistemi OLAP le interrogazioni sono molto complesse, largo uso di OVER BY(), Viste Materializzate, ranking. Le dimensioni delle basi di dati sono dai 100Gb a qualche TeraByte. Francesco Pasturenzi *

29 OLTP e OLAP In sintesi: OLTP Contengono dati di tipo operazionale
* 16/07/96 OLTP e OLAP In sintesi: OLTP Contengono dati di tipo operazionale Sarebbero le basi di dati classiche, quelle che fanno da sorgenti Insert, Update, Delete molto veloci, eseguite dagli utenti finali Query semplici che ritornano pochi record (da subito) Molto veloci Spazio richiesto non eccessivo, accettabile Contengono un piccolo storico attraverso l’uso di un attributo di tipo TIMESTAMP Molte tabelle Il backup si DEVE FARE!! Francesco Pasturenzi *

30 OLTP e OLAP OLAP Contengono dati provenienti dai sistemi OLTP
* 16/07/96 OLTP e OLAP OLAP Contengono dati provenienti dai sistemi OLTP Corrispondono alle Data Warehouse Sono presenti job/thread che popolano la DW e job che effettuano un refresh. Query complesse con molte aggregazioni (ritornano milioni di record che poi verranno ridotti ad una decina/centinaio Velocità di processamento: dipende dall’ammontare dei dati, i refresh dei dati e le query complesse possono richiedere molte ore. La velocità può essere migliorata creando indici e viste. Spazio richiesto dell’ordine dei TeraByte. Contengono dati di tipo storico Poche tabelle, de-normalizzate Il backup «opzionale» alcuni preferiscono un reloading dei dati dai sistemi OLTP (sorgenti) come sistema di recupero in caso di errori. Francesco Pasturenzi *

31 * 16/07/96 NAS, SAN e Data Center Data Center è un impianto utilizzato per i sistemi informatici, fornisce applicazioni e servizi ai dispositivi che le richiedono. Esempi di servizi sono quelli delle telecomunicazioni e di storage. Un Data Center quindi è una struttura fisica in cui si trovano dei computer (di solito, nelle grosse aziende) con all’interno installati dei jobs/server che rispondono alle richieste provenienti dalla stessa azienda che ospita le macchine o da clienti esterni (es:si pensi ad aziende come Google e Telecom Italia).Il problema di queste strutture è la dissipazione di calore che deve essere gestita e controllata, infatti molti dei Data Center di Google si trovano vicino a pozzi d’aqua in modo da creare dei grossi dissipatori liquidi ad alta dispersione. Quindi un Data Center può contenere più di una Data Warehouse e più altri servizi(BI) correlati con la stessa Data Warehouse o con altre applicazioni. Francesco Pasturenzi *

32 * 16/07/96 NAS, SAN e Data Center Data Warehouse quindi è un archivio di dati memorizzati elettronicamente. Le Data Warehouse sono progettate per facilitare il reporting e l'analisi. Un Data Mart è un sottoinsieme di un archivio di dati organizzativi, di solito orientato verso uno scopo specifico o principale interessato, che può essere distribuito per supportare le esigenze di business. Quindi ci possono essere uno o più Data Mart in un Data Warehouse a sua volta ospitata in un Data Center che può contenere più Data Warehouse più altri servizi correlati. Francesco Pasturenzi *

33 NAS, SAN e Data Center Differenza tra NAS e SAN
* 16/07/96 NAS, SAN e Data Center Differenza tra NAS e SAN Una Storage Area Network (SAN) è una rete o parte di una rete ad alta velocità (generalmente Gigabit/sec) costituita esclusivamente da dispositivi di memorizzazione di massa, in alcuni casi anche di tipi e tecnologie differenti. Il suo scopo è quello di rendere tali risorse di immagazzinamento (storage) disponibili per qualsiasi computer connesso ad essa. Un Network Attached Storage (NAS) è un dispositivo collegato ad una rete di computer la cui funzione è quella di condividere tra gli utenti della rete una Area di storage (o disco).Generalmente i NAS sono dei computer attrezzati con il necessario per poter comunicare via rete dati. Si tratta di dispositivi dotati solitamente di un sistema operativo basato su Linux (generalmente trasparente dall'utente) e di diversi hard disk destinati all'immagazzinamento dei dati. Francesco Pasturenzi *

34 * 16/07/96 NAS, SAN e Data Center Questi dispositivi non vanno scambiati con gli Storage Area Network (SAN); questi ultimi sono soluzioni di immagazzinamento dati (storage) differenti: tali sistemi comprendono una rete e fanno riferimento a tecnologie e protocolli spesso proprietari. Talvolta un sistema NAS può essere utilizzato come nodo di una SAN, data la scalabilità di tale architettura. I protocolli attualmente più diffusi, usati per la comunicazione all'interno di una SAN, sono FC (Fibre Channel) ed iSCSI (Internet SCSI – Ultra-640[USB 3.0 arriva a 600MB/s]). Nella NAS di solito si usa l’FTP. Francesco Pasturenzi *


Scaricare ppt "* 16/07/96 Data Warehouse La maggior parte delle aziende dispone di enormi basi di dati contenenti dati di tipo OPERATIVO. Queste basi di dati costituiscono."

Presentazioni simili


Annunci Google