[PASS Summit 2013] Building an effective Data Warehouse Architecture

Speaker : James Serra – BI Consultant, SolidQ

Niveau de la session : 100

1. What à DWH is not :

  • une copie de la base source avec un préfixe « DW »,
  • une copie de plusieurs tables issues de différentes sources unies dans une vue,
  • un amas de données non structurés,

2. Why DWH ?

  • diminuer la charge sur le système de production,
  • optimiser l’accès en lecture et les scans disque séquentiels,
  • intégrer plusieurs sources de données,
  • constituer un historique de données,
  • restructurer et renommer les tables et les champs,
  • assurer la qualité de données,
  • garantir l’unicité de la donnée,

 3. Fast Track Data Warehouse :

  • Configuration matérielle optimisée pour le data warehousing. Elle permet d’éviter de perdre des mois de configuration, installation, test et optimisation,
  • Plusieurs appliances sont proposées dans ce contexte chez IBM, HP, DELL,
  • Le Fast Track est actuellement en version 4.0,

4. Kimball and Inmon methodologies :

  • 2 approches pour construire un data warehouse,
  • Kimball est une approche en top down orientée métier. Elle repose sur :

– un modèle dimensionnel en 2 tiers (datamart, cube) simple pour les utilisateurs finaux mais dérangeante pour les IT habitués au modèle relationnel,
– un schéma en étoile (dimensions, faits),
– des clés métiers (surrogate key),
– l’architecture : source oltp – staging – DWH – cube – rapports,

  • Inmon est une approche dans laquelle le data warehouse est construit iterativement. Elle repose sur un modèle relationnel en 3 tiers (DWH, datamart, cube) familier aux IT et sur des clés naturelles. Les utilisateurs finaux y ont une participation passive. L’architecture est : source oltp – staging – DWH – plusieurs datamarts – plusieurs cubes – rapports,
  • la méthodologie Inmon est suivie dans 39% des entreprises alors que 26% d’entre elles optent pour Kimball,
  • aucun modèle n’est mieux qu’un autre (ils sont même complémentaires) et aucun des 2 ne doit être appliqué en totalité –> il faut adapter à son cas, ses besoins, son infrastructure,

5. Populating a data warehouse :

  • déterminer la fréquence de mise à jour (quotidien, hebdomadaire, etc.),
  • full extraction pour les dimensions,
  • incremental extraction pour les faits,
  • pour détecter les données qui ont changé dans la source : timestamp – last update, Change Data Capture, partitionnement par date, triggers sur les tables, MERGE SQL, colonne DEFAULT value populated with date,

6. ETL vs ELT :

  • ELT : à faire en cas de grosse volumétrie à condition que la source et la cible soit dans la même base. L’intégration de données se fait via la tâche SQL (et non en Data Flow Task comme en ETL),

7. Architecture DWH possible et optimisée :

Sources – staging – DQS – MDS – DWH – cube – rapports – SharePoint,

Conclusion :

Session intéressante qui permet de (re)découvrir la base de mise en place dune solution décisionnelle performante. Bon overview des modèles de Kimball et Inmon (différences, pratiques de modélisation). Session théorique menée par un speaker très pédagogue.

Ismaïl Ben Lamine

[Pass Summit 2013] Reduce Reuse Recycle – Automating your BI Framework

Speaker : Stacia Misner, Principal Consultant Data Inspirations

Niveau de la session : 300

Agenda :

  • Frameworks Options : which ways ?
  • Changing a BI solution : the long way
  • Changing a BI solution : the short way

1. The long way :

ETL design patern : lots templates réutilisables (selon staging ou dwh)

Master Extract Package (staging) et  Master Transform load Package (chargement du dwh) et entre les 2 : création d’un snaphost sur la base (retour arrière si erreur)

Extract Package = duplication du lot par copy manuel et modif des mapping (avec convention de nommage des composants par trigramme)

Load Pattern pour les faits (insert des news rows seulement) et dimension (lecture all data et update si besoin : pattern selon Type 0,1 ou 2 du SCD mais transformations qui varient selon les dimensions)

Facts Extract for Ongoing Load

2. The Short way :

Dimension loader Package Creator: utilitaire à télécharger (google) = demo de 10 minutes : ça semble pas mal (merge en t-sql pour les dimensions) mais pas certain que ce projet soit bien maintenu (lots générés en version sql 2008).

BIML : présentation du biml ratée (la présentatrice a dû passer le relais à son collègue en secours car elle n’y arrivait pas) .

Piste très intéressante d’utiliser le BIML (sert aussi pour du SSAS par exemple).

Présentation confuse (mais très prometteuse) d’un outil (payant !) de génération du biml (notamment pour SSIS) : logiciel de la société varigence.

A  noter que c’est cette société qui fournit dans le BIDS helper le générateur du code BIML (menu conceptuel générer les lots ssis et créer un fichier biml).

3. Conclusion :

Déception : options d’automatisation = copier coller de templates SSIS … et templates qui ne sont pas adaptés à la réalité (fact table = insert new row only donc par exemple pas de gestion des suppression, utilisation du scd comme composant…).

De plus la session a parlé plus de concepts généraux de conception de lots SSIS (gestion de proportion du temps de présentation des sujets est ratée) plutôt que d’industrialisation via d’autres techniques de dev hors SSIS (powershell + SSIS, .NET + SSIS, biml).

A creuser donc : biml surtout et tester (trial version) de Varigence.

En complément, sur le site http://www.varigence.com/ :

Vous pouvez regarder les vidéos de présentation de leurs outils : MIST (notamment), voir d’autres outils (VIVID?).

Bref je n’avais même pas entendu le nom de la boîte Varigence ou les outils utilisés très rapidement (MIST) : je dois être sourd et pas de chance aveugle (ça fait beaucoup pour une seule personne) également (car je n’ai vu aucun logo de MIST ou de Varigence)

Pascal Rouzé

Indexation DataWarehouse

L’indexation d’un entrepôt de données est délicate :

  • si vous avez trop peu d’indexes les temps de chargement de votre entrepôt seront optimum mais les temps de requêtage seront déplorables
  • au contraire, si vous avez trop d’indexes, les temps de chargement vont exploser mais les performances de requêtage seront excellentes.

Afin de prévoir un plan d’indexation optimum vous devez prendre en compte certains critères :

  • le type d’entrepôt (archive vs temps (quasi) réel)
  • la taille des dimensions et des tables de faits
  • le nombre d’utilisateurs ayant accès à l’entrepôt (le nombre d’accès concurrents max à gérer)
  • le type d’accès aux données (ad-hoc ou via des interfaces d’applications structurées)
  • le mode d’alimentation (upsert, annule/remplace …)
  • etc …

Voici néanmoins quelques règles basiques à respecter lors du design de votre entrepôt.

Lire la suite