Théorie et Pratique du Système d’Information
Septième Chapitre: Distribution de l’information
Janvier-Mars 2012
Ecole Poly...
Plan du Cours – Distribution de l’Information

Première partie:
Distribution et Qualité des Données
 Deuxième partie:
Syn...
Première Partie: Distribution et Qualité des données

Distribution des données
Données
locales

composant
A

composant
B

...
Première Partie: Distribution et Qualité des données

Contraintes dans la gestion des données


Contraintes de performanc...
Première Partie: Distribution et Qualité des données

Concept de transaction


Double complexité à gérer (accès aux objet...
Première Partie: Distribution et Qualité des données

Propriétés ACID
Atomicité : une transaction doit s'effectuer en tout...
Première Partie: Distribution et Qualité des données

Le protocole 2PC (Two Phase Commit)


Sur un DBMS, la gestion des t...
Première Partie: Distribution et Qualité des données

Problématique de la distribution de données
Gestion des interactions...
Première Partie: Distribution et Qualité des données

Bases de données relationnelles
Proposées par E. Codd en 1970
 Tabl...
Première Partie: Distribution et Qualité des données

Annuaires Distribués


Annuaire: cas particulier de base de données...
Première Partie: Distribution et Qualité des données

Approches alternatives


XML Store







Stockage natif de XM...
Deuxième partie
Introduction et Formalisation
 Synchronisation et Resynchronisation
 Pilotage des processus


Copyright...
Deuxième Partie: (re) Synchronisation

Distribution et Stockage d’Information


La distribution fait déjà partie des arch...
Deuxième Partie: (re) Synchronisation

DCC (Distributed Concurrency Control)


Mécanisme central de la gestion des transa...
Deuxième Partie: (re) Synchronisation

Synchronisation et Processus
(1) Changement sur OM1
Données
locales

composant
A

(...
Deuxième Partie: (re) Synchronisation

The Snapshot Problem


« Distributed Snapshots : Determining Global States of Dist...
Deuxième Partie: (re) Synchronisation

Processus et Transactions Longues

Les processus servent à implémenter les transact...
Deuxième Partie: (re) Synchronisation

Re-synchronisation


Désynchronisation:







Erreurs durant le processus
Cr...
Troisième Partie




Introduction et Formalisation
Synchronisation et Re-synchronisation
Architecture de Données

Copyr...
Troisième Partie: Architecture de données

Design Patterns: Pas de solution unique
Sur un domaine de données, avec des con...
Troisième Partie: Architecture de données

Une « bonne » architecture de données (résumé)


Un modèle




Un cycle de v...
Troisième Partie: Architecture de données

MDM (Master Data Management)


Solution informatique en cours d’émergence pour...
Troisième Partie: Architecture de données

Modélisation de données - Principes






« Penser objet » : encapsulation e...
Troisième Partie: Architecture de données

Modélisation de données - Conseils








Réification des liens. La réific...
Troisième Partie: Architecture de données

Exigence sur les données


Gouvernance






CNIL






Ex: COBIT
 DS11...
Troisième Partie: Architecture de données

Cycle de vie
Lecture
Destruction

Création

Purge

Ecriture

Naissance
 Un seu...
Troisième Partie: Architecture de données

Processus de Gestion de Données
Bon
usage

1.

2.

3.

4.

5.

6.

Filtrage
Vér...
Prochain SlideShare
Chargement dans…5
×

Cours chapitre7 2012

2 036 vues

Publié le

Cours sur le système d'information en 9 chapitres

Publié dans : Formation
  • Soyez le premier à commenter

Cours chapitre7 2012

  1. 1. Théorie et Pratique du Système d’Information Septième Chapitre: Distribution de l’information Janvier-Mars 2012 Ecole Polytechnique Yves Caseau Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 1/28
  2. 2. Plan du Cours – Distribution de l’Information Première partie: Distribution et Qualité des Données  Deuxième partie: Synchronisation et Re-synchronisation  Troisième partie: Architecture de données  Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 2/28
  3. 3. Première Partie: Distribution et Qualité des données Distribution des données Données locales composant A composant B même client composant C Données partagées  Objets métiers    Eléments d’informations    Implicite (un seul client), explicite (« référenciel ») ou explicité (un seul stockage) Seul le cas de l’entreprise étendu nécéssite une approche implicite (avec formats import/exports) Hétérogènes (XML, BD relationnelle, propriétaires, …) Répliqués et répartis SPT (Single Point/Source of Truth)   Le plus important : qui est la « référence » Outil: cycle de vie Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 3/28
  4. 4. Première Partie: Distribution et Qualité des données Contraintes dans la gestion des données  Contraintes de performance     Contraintes logicielles    Temps de réponse transactionnel (latence)  En mémoire < disque local < disque en réseau  exemple: fournir une description (partielle) d’un objet dans un message/appel de service au lieu de fournir un pointeur/identité Volume de réponse (débit transactionnel)  Raison # 1 pour répliquer des bases de données Temps de transfert (débit) Les progiciels ont leur propre stockage de données C’est une des raisons qui en fait un choix stratégique  Ex: ERP – SAP, CRM – Siebel, etc. Contraintes de disponibilité  Aller chercher des objets métiers à l’extérieur crée une dépendance de plus Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 4/28
  5. 5. Première Partie: Distribution et Qualité des données Concept de transaction  Double complexité à gérer (accès aux objets métiers)    La notion de transaction répond à cette problématique    Accès concurrents (plusieurs requêtes en même temps) Logique métier d’un ensemble de requêtes (ex: processus) Regroupe un ensemble d’actions en garantissant une cohérence unitaire (tout ou rien) Garantit l’exécution concurrente sans perte de cohérence  Sériabilité  Exemple type: virement bancaire  Typologie    Transactions locales (DBMS) ou distribuées Transactions courtes (DBMS) ou longues (services/processus) Standard de transaction sur Web Services: WS-T  WS-T Atomic-transaction  WS-T Business Activity (LRA) Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 5/28
  6. 6. Première Partie: Distribution et Qualité des données Propriétés ACID Atomicité : une transaction doit s'effectuer en tout ou rien ;  Cohérence : la cohérence des données doit être assurée dans tous les cas, même dans les cas d'erreur où le système doit revenir au précédent état cohérent ;  Isolation : la transaction va travailler dans un mode isolé où elle seule peut voir les données qu'elle est en train de modifier, cela en attente d'un nouveau point de synchronisation ; le système garantit aux autres transactions, exécutées en parallèle sur le même système, une visibilité sur les données antérieures ;  Durabilité : lorsque la transaction est achevée, le système est dans un état stable durable, soit à l'issu d'une modification transactionnelle réussie, soit à l'issue d'un échec qui se solde par le retour à l'état stable antérieur.  Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 6/28
  7. 7. Première Partie: Distribution et Qualité des données Le protocole 2PC (Two Phase Commit)  Sur un DBMS, la gestion des transactions relève de   l’ordonnancement des lectures/écritures La pose des points de reprises pour exécuter le retour arrière En environnement distribué, il faut ajouter une coordination (gestion des echecs)  Ex: Protocole classique de transactions courtes      Distribué (ressources) Centralisé (coordinateur) Court et Transaction longue: => « compensation »   Optimiste (évite le locking) Robuste Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 7/28
  8. 8. Première Partie: Distribution et Qualité des données Problématique de la distribution de données Gestion des interactions (contrôle de la concurrence)  Gestion de la synchronisation  Approches par les outils:      Bases de données relationnelles Annuaires distribués EII  Cf. chapitre 3  Solution lourde (performance)  Probablement la solution du futur (« synchronisation as a service ») Bases de données hétérogènes massivement distribuées Directory Management Query Processing Distributed DB Design Reliability Concurrency Control Deadlock Management Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 8/28
  9. 9. Première Partie: Distribution et Qualité des données Bases de données relationnelles Proposées par E. Codd en 1970  Tables + normalisation  Algèbre relationnelle (8 opérateurs)  Sélection, jointure, projection, …  Optimisation des requêtes  SQL (Structured Query Language)  OS UI Apps.. Client Client DBMS communication SQL queries results Communication Semantic Controller Server Query Optimizer  DBMS (Database Management System)  Gestion des requêtes  I/O, recovery, … Parallélisme: (Oracle RAC)  Mécanismes de réplication  Synchrone/ asynchrones  Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) Transaction Manager Recovery Manager Runtime Support OS database 9/28
  10. 10. Première Partie: Distribution et Qualité des données Annuaires Distribués  Annuaire: cas particulier de base de données (directory)    Il existe des implémentations spécialisées      Entrée (distinguished name), description (un ou plusieurs attributs) Structure hiérarchique (modèle X500 – arbres … plats) Pour des raisons historiques (systèmes hiérarchiques) Besoins différents (read vs. peu de write) Exemple connu: DNS (Domain Name System) Inclus dans Windows: Active Directory Il existe des protocoles de distribution plus efficaces (cas particulier): LDAP – Lightweight Directory Access Protocol    Synchronisation (LDAP Content Synchronization Protocol) Replication (via slurpd ) Version 3 - IETF Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 10/28
  11. 11. Première Partie: Distribution et Qualité des données Approches alternatives  XML Store      Stockage natif de XML Très gros volumes, hétérogènes Requêtes: Xpath, Xquery, … Une solution qui va s’imposer progressivement Bases de données massivement parallèles   Une solution d’avenir:  Scalabilité, redondance (fiabilité), coût des opérations (serveurs banalisés) Ex: Google database  Google File System – Replication redondante (au moins 3) sous formes de chunks – Gestion des updates avec un mécanisme de transaction – Optimisé pour le débit (vs. latence) Google BigTable Aussi: Oracle sur un GRID   Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 11/28
  12. 12. Deuxième partie Introduction et Formalisation  Synchronisation et Resynchronisation  Pilotage des processus  Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 12/28
  13. 13. Deuxième Partie: (re) Synchronisation Distribution et Stockage d’Information  La distribution fait déjà partie des architecture modernes Serveurs applicatifs Serveurs données Cluster HP  SAN SAN   Architecture permettant d’utiliser des disques distants Souvent construit sur un réseau « fibre channel » Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 13/28
  14. 14. Deuxième Partie: (re) Synchronisation DCC (Distributed Concurrency Control)  Mécanisme central de la gestion des transactions   Aussi appelé « Concurrency Control Services » (Cummins)   Acteurs = processus/services qui partagent des objets métiers Deux familles:    Acteurs = transactions qui se partagent des ressources (données) Pessimistes la synchronisation a lieu avant l’exécution (Validate > Read > Compute > Write) Optimistes le test de validité est fait avant l’écriture – si il y a conflit, la transaction est « abortée » Deux mécanismes:   Locks (compteurs) des verrous assignés aux acteurs qui possèdent le droit d’écrire, et qui limitent l’accès (lecture/écriture) Timestamps ordonnancement des accès en fonction d’une sérialisation possible Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 14/28
  15. 15. Deuxième Partie: (re) Synchronisation Synchronisation et Processus (1) Changement sur OM1 Données locales composant A (?) Mise à jour replicat OM1 composant B Données partagées (2) Fin d’activité (3) Nouvelle activité Référence OM (?) Mise à jour référence OM1 Moteur de Processus  Deux flux d’informations circulent:    Séquencement des processus Mise à jour des objets métiers Il est important qu’ils soient synchronisés (pour la bonne exécution du processus)   Exemple Pernod (« propagation trop rapide des processus ») Exemple Bouygues Telecom: messages « contextuels » qui combinent les deux flux  Plus gros  Plus complexe Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 15/28
  16. 16. Deuxième Partie: (re) Synchronisation The Snapshot Problem  « Distributed Snapshots : Determining Global States of Distributed Systems » K. Chandy & L. Lamport  Comment capturer une image de l’état global du système au travers de processus distribués ?  Modèle de système distribué = ancêtre du pi-calcul - systèmes non synchronisés avec des mémoires distinctes qui communiquent par envoi de message  « An introduction to snapshot algorithms in distributed computing »  A. Kshemkalyani & al.    Lien avec le problème précédent: garantir que le « snapshot » n’est pas faussé par la propagation des « updates »    Le problème est difficile  Pas de solution générale (any snapshot) efficace (overhead prohibitif – cf. expérience Peter Tabeling) Avoir résolu le problème signifie qu’on peut garantir la consistance des objets métiers sans assurer une synchronisation permanente Pas de solution générale =>  « Plus petits snapshots » - limiter la concurrence  Ne pas chercher à séparer les deux flux process/syncho Résultat connu dans le monde du « cloud » sous le nom de Théorème de Brewer (CAP : Coherence – Availability – Partition Tolerance) Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 16/28
  17. 17. Deuxième Partie: (re) Synchronisation Processus et Transactions Longues Les processus servent à implémenter les transactions longues  L’implémentation s’appuie sur la (re)synchronisation  Début du processus Etat S1 initial cohérent : Une référence unique + Toutes les copies sont synchronisées Participants : l’état des objets est contenu dans les messages qui circulent Non-participants : l’état des objets est défini par la référence avec un « lock » sur l’écriture Fin du processus succès échec Etat final cohérent (modification de la référence) Retour à S1 par re-synchronisation des systèmes impliqués dans la Transaction depuis la référence Etat temporaire : deux parties= les systèmes qui participent à la transactions et les autres Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 17/28
  18. 18. Deuxième Partie: (re) Synchronisation Re-synchronisation  Désynchronisation:      Erreurs durant le processus Crash/ incidents /reprises / retard de planification Erreurs de saisie La désynchronisation est une condition récurrente  Besoins: 1. 1. Outils de re-synchronisation  Utilisation régulière  Reprise sur incident Processus permanent de nettoyage des données  Administration de données  Implication MOA (propriétaire) (rappel : les mauvaises données coûtent cher aux entreprises) Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 18/28
  19. 19. Troisième Partie    Introduction et Formalisation Synchronisation et Re-synchronisation Architecture de Données Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 19/28
  20. 20. Troisième Partie: Architecture de données Design Patterns: Pas de solution unique Sur un domaine de données, avec des contraintes fortes de  performance: Tuxedo – composants:  Moniteur transactionnel •System/T: serveur de noms et gestionnaire de transactions (gestion de la concurrence) •System/WS: partie client  OLTP (On Line Transaction Processing) (Windows/Unix) •System/Q: gestion de la queue des  Ex: Tuxedo message + gestion des ressources  Multi-domaine, multi-processus,  •System/Tdomain: gestion transactionnelle multi-domaine contraintes performances modérées  SOA + annuaire (ex: MDM)  Ou (ponctuellement) replicat LDAP  Multi-domaine, multi-processus,  contraintes performances modérées  Contrôle de concurrence sur processus  Point clé: tout appel de service d’écriture passe par la gestion des demandes.   Gros volumes, pas de contrainte de latence: EII Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 20/28
  21. 21. Troisième Partie: Architecture de données Une « bonne » architecture de données (résumé)  Un modèle   Un cycle de vie et des propriétaires    Où sont les copies et pourquoi ? Qui est la référence (SPT) Des mécanismes (audit / synchro / etc.)    Qui crée, qui lit, qui modifie, qui supprime ? Un plan de distribution   Global, partagé, compris, entretenu Si il y a distribution (copies), il y aura des problèmes  purge Des outils   La gestion des données distribuées est difficile (surtout du point de vue des performances) – éviter de réinventer la roue ! Il vaut mieux simplifier l’architecture de données (diviser pour régner) et utiliser des solutions « du commerce » Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 21/28
  22. 22. Troisième Partie: Architecture de données MDM (Master Data Management)  Solution informatique en cours d’émergence pour la gestion des « données de références »    Une méthode (MDM Alliance Group = MAG)      Référentiel = Modèle + Annuaires + processus/services  Ambigüité (collection de BD vs. Service)  Première brique = modèle commun Master Data = objets métiers transverses (partagés) 1er temps : modéliser le métier / les cycles de vie 2ème temps: créer un modèle logique de donnée urbanisation des donnée (ex: repérer les couplages) 3ème temps: implémentation Cf. Pierre Bonnet: le promoteur de MDM  Exemple: EXB.platform (Orchestra Networks)   Plateforme logicielle pour manipuler des modèles de données et interagir avec des services SOA Vidéo: http://www.orchestranetworks.com/product/index.cfm Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 22/28
  23. 23. Troisième Partie: Architecture de données Modélisation de données - Principes    « Penser objet » : encapsulation et hiérarchisation de classes. Il s’agit de se concentrer sur le « quoi avant le comment » et de décrire l’ontologie des objets avant de penser à leur description. L’encapsulation propre à l’approche objet signifie qu’un objet n’est pas défini à partir de ses données internes mais par sa position ontologique et par ses interfaces (les services qu’il peut rendre). « Penser méta » signifie qu’il faut construire et formaliser le méta-modèle de données pour:  mieux communiquer (on peut échanger des diagrammes en sachant de quoi on parle),  pouvoir échanger des données entre modèles, ou faire émerger des modèles communs plus facilement,  obtenir une modélisation plus précise en se forçant à se poser des bonnes questions. « Penser générique » consiste à faire abstraction du positionnement de l’entreprise au sein de son industrie et s’imaginer que le modèle de données peut être partagé par d’autres membres de cette même industrie. Il s’agit de se demander en quoi le modèle serait différent si :  nous étions une autre entreprise (choisir un concurrent),  nous décidions d’opérer nos services pour le compte d’autres entreprises,  nous décidions d’acheter une partie des services à l’extérieur (outsourcing). Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 23/28
  24. 24. Troisième Partie: Architecture de données Modélisation de données - Conseils     Réification des liens. La réification du lien consiste à introduire un objet qui représente ce lien, ce qui va permettre d’attribuer des propriétés modales à ce lien (degré de fiabilité, durée de validité, éléments constitutifs de preuve, etc.). En utilisant une hiérarchie de classe pour représenter ce lien réifié, nous allons pouvoir faire évoluer la sémantique du lien au cours des évolutions du modèle. Produits de hiérarchies. Il faut utiliser des décompositions en éléments typés, ce qui signifie mettre à profit la notion de « sous-objets » pour décrire un objet complexe. La hiérarchie induite par ces sous-objets s’appelle une hiérarchie « produit » et elle remplace avantageusement la notion d’héritage multiple qui n’est pas supportée par de nombreux outils de modélisation ou de développement. Réification des rôles. C’est l’application du principe de réification des liens au cas particulier des rôles. Représenter les rôles par un ensemble d’objets qui peut évoluer, par ajout ou par enrichissement, conduit à un modèle très extensible. Substitution groupe/individu. Une des limites les plus courantes d’évolutivité des modèles est liée précisément à l’évolution des rôles, en particulier à leur cardinalité. Par exemple, on peut découvrir qu’un rôle que l’on croyait individuel peut être partagé par un groupe. Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 24/28
  25. 25. Troisième Partie: Architecture de données Exigence sur les données  Gouvernance    CNIL    Ex: COBIT  DS11 : gérer les données  PO2 : définir l’architecture de l’information Impact des crises (ex: Sarbanes- Oxley) Déclarer tout ce qui touche à « la personne » Contraintes max sur la durée de vie Exigences légales   Ex: données financières Contraintes min sur la durée de vie  Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 25/28
  26. 26. Troisième Partie: Architecture de données Cycle de vie Lecture Destruction Création Purge Ecriture Naissance  Un seul système est responsable de la création (cohérence)  Le système référent n’est pas forcément le lieu de la création  Lecture  Il faut maintenir la liste des lecteurs d’une donnée métier  Ecriture  Une seule référence   Qui dit écriture dit transaction (retour arrière ? Log ? Backup …)  Mort  La destruction relève de la responsabilité du propriétaire de la donnée  Purge  Une donnée qui ne sert plus n’est pas automatiquement purgée !  La gestion des purges fait partie des responsabilités du propriétaire  Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 26/28
  27. 27. Troisième Partie: Architecture de données Processus de Gestion de Données Bon usage 1. 2. 3. 4. 5. 6. Filtrage Vérification Cohérence Echanges Synchronisation Le bon usage des applications.: très souvent, les données incorrectes sont introduites par un usage inapproprié d’une application. La validation des entrées, qui doit être effectuée par chaque application. Il est beaucoup plus coûteux d’extraire des données fausses que d’éviter de les faire rentrée. La conception des échanges doit garantir la cohérence à tous les niveaux (format et sémantique). Le protocole de synchronisation (et de resynchronisation continue) doit être cohérent avec le bon déroulement des processus de l’entreprise. Des audits de qualité et de synchronisation doivent être menés de façon continue Les purges (données inutiles) et la resynchronisation exceptionnelle (réparation) Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) Audit Nettoyage Réparation 1.Architecture de données 2.Bonne utilisation des outils (responsabilité conjointe MOA) 3.Filtrage des entrées (implémenter les contrôles de cohérence) 4.Cohérence des échanges et distribution correcte du MIM (conception) 5.Fonctionnement synchronisation (responsabilité conception système) 6.Fonctionnement re-synchro 7.Supervision de la QoS fonctionnelle et des rejets 8.Nettoyage et purge des systèmes 9.Qualité des données : on n’améliore que ce que l’on mesure 27/28

×