Ludovico Ferrara Partner Technology Reply s.r.l.

Presentazione sul tema: "Ludovico Ferrara Partner Technology Reply s.r.l."— Transcript della presentazione:

1 Ludovico Ferrara Partner Technology Reply s.r.l.
Progetto CARE Ludovico Ferrara Partner Technology Reply s.r.l. Club TI Triveneto – Evento Grandi Moli di Dati Esempio di Apertura

2 Reply REPLY è stata fondata nel 1996, sulla base dell’idea che l’avvento della rete e delle nuove e sempre maggiori possibilità di comunicazione, avrebbero radicalmente trasformato la società, i comportamenti e le aziende. Globalizzazione e Delocalizzazione sono rese possibili da reti sempre più veloci e complesse che consentono di creare, collezionare, validare e distribuire informazioni indipendentemente dallo spazio e dal tempo. Questa rivoluzione richiede una nuova generazione di professionisti altmamente specializzati capaci di integrare tecnologia, comunicazione e processi. REPLY ( e’un azienda di servizi informatici che) integra cultura, competenza e proattività, applicando i nuovi paradigmi e le nuove tecnologie, dell’informatica e della comunicazione, per eccellere nella software integration e nello sviluppo di soluzioni di e-business ed internet , flessibili, efficienti ed efficaci

3 Revenue & People 277.2 230.2 144.7 112 86 77.1 60.3 33.3 18.6 People
Millions of EURO 230.2 144.7 112 86 77.1 60.3 33.3 18.6 1999 2000 2001 2002 2003 2004 2005 2006 2007 244 396 647 750 875 1011 1277 1925 2272 People Headcount as at Dec. 31

4 EBITDA & EBIT 31.5 EBITDA CAGR (99-06): 33.7% EBIT CAGR (99-06): 36.1%
Millions of EURO EBIT EBITDA EBITDA CAGR (99-06): 33.7% EBIT CAGR (99-06): 36.1% 21.0 14.2 12.3 11.0 10.3 6.7 4.1 3.2 4.7 8.4 9.1 6.5 12.0 18.8 27.8 1999 2000 2001 2002 2003 2004 2005 2006

5 Reply Characteristics
Autonomous and specialized Enterprises Reply Companies share management philosophy, Goals and management functional standards, to guarantee quality, proficiency and effectiveness. Focalization Methodology Culture Flexibility A strong team culture Reply companies work together and join their expertise aiming to optimize efficiency and reach An increased market strenght. Ethics Reliability Honesty Transparency

6 Reply Companies Reply Germany Esempio Grafico colonne

7 Reply: 2 companies focused on Oracle’s proposition
> Focused on design and development of Architetture Service Oriented projects using Oracle Fusion Architecture. > Location in Milan, Turin, Rome, Treviso > “Tuned” with Oracle Technology using the certification program (OCA, OCP, OCM) and joining to Beta Site Program (Database, Oracle Fusion Middleware). > Focus on Design and Build up solution for the extended enterprise using Oracle eBusiness Suite > Location in Milan, Rome, Treviso > Functional skills on eBS modules. > Technological skills in order to implement vertical solution. Processes Technology Applications

8 Some Milestones Customer Satisfation Awards for eBusiness Suite Largest Competence Center on Oracle Application in Italy Certified Advantage Partner for eBS OFM11g Beta Site 1996 1998 2000 2002 2004 2006 2008 Customer Excellence Partnering OPN Innovation Award Certified Advantage Partner (Technology) Oracle Certified Partner (Technology) First Beta Site (Oracle8) then 8i, 9, 10g and OAS Beta Server (Bpel, Esb) Startup

9 Our Offer Customers Methodologies, Processes Technologies
SOA Methodology (SOA Maturity Model) Process Design (BPA Suite) Technological Stack Technologies Application Solutions Enterprise Web2.0 (RIA) BI & CPM SOA Identity & Access Management Core Technologies Customers Application Integration Architecture (AIA) eBusiness Suite OTM, Demantra, Agile PLM

10 Progetto CARE Esempio di Apertura 10

11 Customer Analysis, Relation & Experience
Analytic CRM Operational CRM CARE Platform

12 CARE come supporto al Relation Management

13 Customer Analysis, Relation & Experience
Relativamente ai consumatori vengono collezionate: le informazioni utilizzate dalle applicazioni di CRM applicativo le informazioni utilizzate dalle applicazioni analitiche (es.: score di Data Mining) le informazioni sui prodotti e i servizi e sulle relazioni di proprietà/uso da parte del consumatore le informazioni relative alle iniziative di marketing, di promozione prodotti e servizi le informazioni sui ritorni da parte dei consumatori alle iniziative le informazioni sulle richieste e/o i contatti sui canali di relazione le informazioni circa le risposte/azioni intraprese nei loro riguardi

14 CARE: schema funzionale
Data Browsing And Searching Customer Identity Infos Campaign Mgr Contact Mgr [TBV] Data Mining Tool Customer Intelligence Reporting And Analysis CARE Portal Report & analysis engine Data mining Data mart access Data Mining and Analysis Runtime Services/Components Data Acquisition Subsystem and Services: Normalization, Validation, Matching Quality P,S&C data access C&P Data browsing and searching services Data edit services Data Browsing Admin services Campaign mgmt Target extraction schedule Campaign definition Target defin. Dealer authorization management Appointment Agenda Contact mgmt [TBV] Data Quality Management GUI Admin GUI and Web Services Interface Schemas / Meta Schemas Schema funzionale Campaign Definition, Redemption Measures Customer And Consumer SocioDemo characteristics Products, Services, Contacts Tracking History Contact Management [TBV] Data Acquisition Territory, Dictionary Normalization, Validation, Matching Rules Mapping, Transformation, Loading

15 CARE: Architettura logica acquisizione dati
Care repository Preprocessing (es.: split dei files, padding) DWI EDM: mapping per formati interni standard CARE (es.: MOVAN, MURF) DWI PARTY: doblonatore e caricatore dati anagrafico nella basedati DWI DNA: normalizzatore (1), generatore di hash code Liste di alimentazione Files di alimentazione Caricatore dati di prodotto, servizio e contatto Formato standard interno Formato MURF Architettura logica (1) per alcuni mercati si usano algoritmi di normalizzazione di terze parti (es.: ASSESSO Datacare per il brasile)

16 CARE: software di base e prodotti
Oracle Database Enteprise Edition Data Mining Option Partitioning Option Oracle Workflow Oracle Application Server Enterprise Edition; relativamente alle sue componenti viene utilizzato il conteiner java OC4J e le componenti runtime di Oracle Discoverer Oracle Discoverer (in piano il passaggio ad Oracle BI EE) Oracle Warehouse Builder SPSS Clementine Server 10.1 Microfocus Cobol Server Express 4.0 Piattaforma di normalizzazione DWI costituita da: Mappatura e configurazione flussi dati (modulo EDM) Normalizzatore e codificatore hash (moduli specifici per mercato es.: DNA 5.0 per l’Italia oppure DNA 5.0 con integrazione engine di normalizzazione ASSESSO di Datacare per il brasile) Deduplica e caricamento dati DB (modulo PARTY) User Interfaces per configurazione prodotti DWI (design time), per ricerca, navigazione e aggionarmento delle tabelle del sottosistema di acquisizione anagrafica (run time) Software di base e prodotti specifici

17 Care: architettura fisica

18 Le dimensioni della base dati
Allocazione RDBMS produzione: Gb Allocazione RDBMS certificazione: Gb Consumatori (IT): 51,5 M Aziende: 4,5 M Privati M Veicoli (IT): ,5 M Gruppo FIAT 22,5 M Concorrenza 30M Ordini (IT): M (800 K/anno) Finanziamenti (IT): 3 M (77 K/anno) Estensioni di garanzia(IT): 1,6 M (77 K/anno) Interventi (garanzie, soccorsi, etc.): 17,5 M (1,5 M/anno) Contatti(IT): M Per il mercato Italia: ca. 20 flussi dati e aggiornamenti di codifiche al giorno; ca. 25 flussi acquisiti su base settimanale Dimensionamento Ti allego l’analisi dell’allocazione dello storage fatta a settembre 2007, circa l’allocazione dello spazio. Dati significativi: 1817 GB allocati sul DB di Produzione 1109 GB allocati sul DB di Certificazione Non è suddiviso per mercato, ma se ti interessa posso ricavarlo. Compression E’ interessante anche la differenza di occupazione tra prod/cert dove in cert usiamo i tablespace compressi. Inoltre i tablespace compressi si sono rivelati a volte vincolanti perché non permettono di fare tutte le operazioni che si fanno sui tablespace non compressi. In generale con tbs compressi non si verificano perdite di performance.

19 Grandi moli di dati: il punto di vista applicativo
Esempio di Apertura 19

20 Design: capacity planning
Spazio disco: definizione delle principali entità e calcolo delle loro occupazioni Risorse elaborative DB server: definizione della numerosità degli accessi ai dati secondo una classificazione (complessi, medi e semplici); interpolazione con i risultati dei test TPC Risorse elaborative Application Server: definizione della numerosità dell’utenza e del tipo e della frequenza di accesso al sistema; interpolazione con i risultati dei test SPECjAppServer2002 Spazio disco: particolare attenzione alla codifica UTF-8 (multibyte) Per risorse elaborative si intende CPU e RAM

21 Design: modelli dati dedicati
Customer Intelligence Data Mining Operational DB Customer Intelligence Data Mart Data Mart Analysis Repository DB L’operazionale porta solo le informazioni nell’ultima versione (senza tutta la storia legata agli arricchimenti dovuta ai caricamenti successivi); inoltre viene parzialmente denormalizzato per agevolare l’accesso ai dati Esempi: ETL per caricare la fact dell’immatricolato ci mette 1,5 h Il fatto di usare un modello dati dedicato mi permette anche di ricalcolare le tabelle di dominio sulla base delle quali popolare le combo di paramentrizzazione delle query in modo strattamente correlato ai dati da utilizzare (NO dati storici vecchi) Data acquisition engine Data Information flows

22 DB application: set based vs row based
Set Based: il set di dati viene elaborato con un unica chiamata SQL. Vantaggi prestazioni molto elevati Codifica software molto strutturata Svantaggi L’anomalia su un singolo record invalida tutta l’operazione Tracking delle operazioni più complesso Codifica software più complessa Per un utilizzo efficace, tale approccio richiede l’implementazione di uno step propedeutico di trattamento dati per prevenire tutte le possibili cause di anomalia. Row Based: il set di dati viene elaborato con una chiamata SQL per ogni record. Consolidamento dell’operazione sul singolo record (commit) Semplicità di Tracking delle operazioni Codifica software più semplice Prestazioni scarse nel caso di manipolazioni a blocco di grosse moli di dati E’ un approccio indispensabile nelle situazioni dove a seconda dell’esito della singola operazione si condiziona il passo successivo. Set based Row based: si ha un maggior controllo dell’operazione di manipolazione della singola riga senza la necessità di pretrattare i dati per annullare le cause di malfunzionamento

23 DB application: opzione Oracle Partitioning
Tabella partizionata: tabella nella quale i dati sono fisicamente segmentati a seconda del valore della/e chiave/i di partizionamento. Es.: Nelle operazioni di accesso ai dati, specificando la chiave di partizionamento, si utilizzerà soltanto il relativo segmento e non tutta la tabella. Vantaggi Ricerche più rapide, soprattutto nelle situazioni in cui sia necessario un table scan. Svecchiamento della base dati più efficace (drop di singole partizioni) Ogni partizione può avere caratteristiche di storage diverse Distribuzione della tabella segmentata su Tablespaces diversi Svantaggi Ricerche penalizzate nelle situazioni in cui non venga specificata la chiave di partizionamento Necessità di intervenire sulla struttura nelle situazioni in cui la chiave di partizionamento assuma nuovi valori per i quali non era stata definita una partizione Il valore della chiave di partizionamento non è aggiornabile Tipicamente le chiavi di partizionamento sono il tempo, ma può essere utile farlo per organizzazioni o altro Non è aggiornabile vuol dire cancellare il record ed effettuare un altro inserimento con il valore corretto Nella Customer Intelligence ho una partizione per mercato; solo la qualità dei dati su DB è partizionata per settimana Il fatto di poter andare su Tablespace diverse mi permette anche di andare su file system diversi

24 DB configuration: l’uso del parallelismo
Real Application Cluster: utilizzo del parallelismo a livello di nodo server di elaborazione Parallelizzazione applicativa: con il disegno di una strategia opportuna per evitare i conflitti e la contesa delle strutture dati è possibile lanciare elaborazioni parallele che vengono risolte dal server RDBMS Parallelizzazione del motore SQL: specie nel caso di approcci Set Based il motore può sfruttare l’architettura multiprocessore dei server per parallelizzare l’accesso e la monipolazione dei dati L’ottimizzatore Oracle permette di scomporre automaticamente una singola operazione in tante operazioni parallele, in modo tale da utilizzare tutte le risorse parallelizzabile dell’hardware a disposizione, come ad esempio le CPU oppure lo Storage. In linea di massima, i tempi di accesso in lettura si riducono di un fattore proporzionale al numero di CPU (es. per leggere 100M con le feature di parallel impiega ¼ del tempo rispetto alla stessa operazione senza parallelismo). Solamente le operazioni “set based” sono processabili con le feature di parallel dal motore Oracle. Quando si utilizzano operazioni “row based” (che tipicamente fanno uso di cursori) l’alternativa è eseguire operazioni parallele che non possano andare in conflitto. In CARE il caricamento del Repository è suddiviso tra i vari mercati. Le operazioni di caricamento del repository avvengono in parallelo sui diversi mercati. Svantaggi Real Application Cluster: In applicazioni di datawarehousing il RAC tipicamente non ha nessun beneficio, anzi se non opportunamente configurato può portare a gravi problemi di performance e sicuramente porta ad un aumento dei costi. RAC porta vantaggi tipicamente in caso di applicazioni transazionali con molti utenti che fanno tante query semplici. RAC non porta vantaggi in ambienti di DWH perché tipicamente vengono fatte poche query estremamente complesse: la risoluzione di una query avviene sempre solamente a livello di un singolo nodo. Con RAC si avrebbe un overhead dovuto alla sincronizzazione con gli altri nodi dei cluster.

25 DB configuration: utilizzo di Hints
Il motore del database normalmente determina autonomamente il miglior piano di esecuzione per la risoluzione di una query. Il piano di esecuzione viene definito sulla base delle statistiche calcolate periodicamente sui dati presenti nelle diverse tabelle. Qualora si verifichino dei grossi cambiamenti nelle tabelle rispetto alle statistiche il piano potrebbe non essere più ottimale In alcuni casi è comunque necessario intervenire manualmente definendo un piano alternativo condizionando il comportamento del motore con direttive che si chiamano hint. Questa attività è molto delicata e complessa, per cui deve essere effettuata soltanto quando indispensabile. In alternativa agli hint si possono usare le funzionalità di “Plan Stability” di Oracle. Utilizzare gli hint è tipicamente più semplice.

26 DB configuration: utilizzo di Hints (esempio)
Una tabella di staging, sulla quale è presente una PK, è normalmente vuota. La statistica dice che non ci sono record e quindi l’ottimizzatore non può sfruttare l’indicizzazione della PK, in quanto non ha informazioni per orientarsi. Una procedura carica massivamente dati sulla tabella. Poichè l’indice sulla PK non viene usato per la verifica di univocità, le prestazioni degradano; all’aumentare dei record aumenta anche il costo della ricerca sequenziale Impostando un hint che forzi sempre l’utilizzo dell’indice sulla PK, si migliorano le prestazioni sull’inserimento massimo dei record Utile anche quando ho PL/SQL dinamico e l’ottimizzatore non sceglie il piano di esecuzione ottimale; quindi con la conoscenza a priori che abbiamo lo condizioniamo con hint opportuni

27 DB configuration: data compression
E’ possibile configurare la compressione delle aree di memorizzazione fisica dei dati su disco (Tablespace) Questo meccanismo è stato utilizzato per l’ambiente di certificazione, consentendo di poter replicare tutti i dati in produzione con un costo di spazio disco ridotto Vantaggi: Riduzione dei costi: occupazione dello storage ridotta del 40% (da 1.8TB a 1.1TB) In determinati casi (operazioni di lettura, e di insert) aumento delle performance Svantaggi: Nelle operazioni di aggiornamento degrado delle performance Maggiore complessità nelle operazioni di allineamento tra ambiente di produzione e certificazione Per ridurre i costi si è scelto di mantenere i database di certificazione in modalità compressa (TABLESPACE COMPRESSION di Oracle). La riduzione delle allocazioni è notevole. Per determinate operazioni non si registrano perdite di performance, anzi in determinati casi la diminuzione degli accessi allo storage aumenta le performance. Le operazioni di aggiornamento (UPDATE) non permettono la compressione, per cui comportano perdita di performance e nessun vantaggio nella riduzione delle allocazioni. Su tabelle/tablespace compressi esistono delle limitazioni. Ad esempio, le operazioni di export/import per l’allineamento dei dati non effettuano automaticamente la compressione. Come conseguenza l’allineamento di produzione con certificazione impiega circa una settimana, in cui vengono svolti diversi passi manuali. Molto utile negli accessi pesanti in Read Only esempio Customer Intelligence è conveniente comprimere; caricamento del data mart è in full refresh ovvero solo insert non update

28 Case Study: Data Mart Analysis
Fase Note Durata MIDA: Tecnologia SAS, basata su file System 40 ore 1 CARE: Tecnologia Oracle, hardware partizionato 30 ore 2 Tecnologia Oracle, Hardware non partizionato 20 ore 3 Hardware non partizionato, Tablespace compression 19 ore Data Mart Analysis: caricamento integrale settimanale IBM pSeries P595: può montare fino a 64 cpu e 2 TB di RAM IBM pSeries P550: può montare fino a 4 cpu e 64GB di RAM Configurazione effettiva della partizione/macchina dedicata: 4CPU, 24GB RAM Storage invariato, Connessione allo storage invariato Riduzione dei costi: il contratto tra IBM e Fiat Group prevedeva costi più alti per la partizione che per la macchina dedicata Scalabilità: il tempo di migrazione da una piattaforma hardware all’altra ha richiesto 4 ore di downtime grazie alle tecniche di mirror dei dischi e alternate disk install Aumento delle performance: vedi case study DMA, procedura di ricalcolo del DMA passa da 30 ore a 20 ore Performance costanti: sulla macchina partizionata le performance dipendevano anche dalle attività delle altre partizioni Spiegazioni: Sebbene il partizionamento del sistema operativo AIX assegni risorse dedicate alle singole partizioni (RAM, CPU, etc.) alcune risorse rimangono condivise (canali di I/O, bus, etc.)

29 Gli impatti sulla Web Application
Il modello dati è stato progettato in modo ottimale per il suo trattamento (es.: informazioni nella loro forma più aggiornata, uso della denormalizzazione, etc) Utilizzo dei meccanismi di cache delle componenti di Object Relational Mapping Per le estrazioni utenti si realizza l’accesso ai dati in background secondo i criteri di query selezionati e si effettua un pre-calcolo della lista da estrarre (in xml). In un secondo momento si trasforma (uso di xsl) la lista nel struttura e nel formato specifico dell’estrazione richiesta Utilizzo di pull parser ovvero parser che consentono le trasformazione di grandi documenti XML con un uso limitato della memoria e compressione dei files per il download

30 Q&A Contact Ludovico Ferrara Partner Technology Reply s.r.l. Esempio di Apertura 30

31 BACKUP

32 Alcuni dati di dimensionamento solo sul mercato Italia
La ns.applicazione Alcuni dati di dimensionamento solo sul mercato Italia Le tecnologie usate per la gestione di grandi moli di dati: Design: Capacity planning (L) Design: modelli dati dedicati (L) DB: operazioni set based vs row based (cursori) puntualizzare che verifiche stringenti per non avere pesanti rollback (P) DB: il partizionamento (P) DB: il parallelismo (vedi caricamento dma) (A) DB: il condizionamento del comportamento ottimizzatore con Hints (P) DB: data compression (A) Hardware dedicato preferibile ad hardware partizionato (A) Esempio del dma (A)             SAS (file system, no parallelismo) 40 ore             Oracle (su host partizionato, tecniche di parallelismo, etc.) 26 ore             Oracle (hardware non partizionato) 20 ore             Oracle (compressed, non partizionato) 18 ore Web Application: caching dei dati basato sia sulle tecnologie utilizzate (iBatis) che su soluzioni applicative (preFetch delle informazioni) (R)

33 Customer Analysis, Relation & Experience
da completare

34 CARE: architettura tecnica

35 CARE: censimento Flussi ITALIA
Esempio di censimento dei flussi esterni ed interni alla piattaforma CARE per il mercato ITALIA

36 Mida come supporto al Relation Management

37 CARE: tecnologie per l’acquisizione dati
Per la realizzazione del sistema di acquisizione dati sono state usate le seguenti tecnologie: preprocessing: shell unix di trattamento files piattaforma DWI: nelle sue componenti EDM, DNA e PARTY; comprende le logiche e gli algoritmi in linguaggio COBOL oltre al modello dati relazionale per la memorizzazione della componente anagrafica caricatore di prodotto, servizi e contatti: procedure di ETL sviluppate con Oracle Warehouse Builder ed automatizzate in catene elaborative con l’uso di Oracle Workflow Automazione acquisizione: tutto il trattamento elaborativo per l’acquisizione dati è gestito con catena di schedulazione orchestrate da Maestro (standard GV) Componenti tecnologici acquisizione dati

38 CARE: tecnologie utilizzate per il portale
Per la realizzazione del portale in java sono stati usati i seguenti framework e le seguenti tecnologie: framework Struts: implementazione del design pattern model-view-controller per la realizzazione di applicazioni web framework Spring: implementazione del design pattern DAO per la manipolazione degli oggetti in lettura/scrittura dalla basedati framework iBatis: per l’accesso fisico alla basedati, separando la manipolazione degli oggetti dai comandi SQL language di manipolazione del DB libreria AJAX: per rendere più rapido il rinfresco delle pagine e alleggerire il traffico tra il client ed il web server Componenti tecnologici del FE WEB