Upload
yves-caseau
View
391
Download
2
Embed Size (px)
DESCRIPTION
Cours sur le système d'information en 9 chapitres
Citation preview
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 1/28
Théorie et Pratique du Système Théorie et Pratique du Système d’Informationd’InformationSeptième Chapitre: Distribution de Septième Chapitre: Distribution de l’informationl’information
Janvier-Mars 2012Ecole Polytechnique
Yves Caseau
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 2/28
Plan du Cours – Distribution de l’InformationPlan 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) 3/28
Distribution des donnéesDistribution des données
Objets métiers 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) Eléments d’informations
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
Pre
miè
re P
art
ie:
Dis
trib
uti
on
et
Qu
alité
des d
on
nées
composantA
même client
Données locales
Donnéespartagées
composantB
composantC
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 4/28
Contraintes dans la gestion des donnéesContraintes dans la gestion des données
Contraintes de performance 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)
Contraintes logicielles 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
Pre
miè
re P
art
ie:
Dis
trib
uti
on
et
Qu
alité
des d
on
nées
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 5/28
Concept de transactionConcept de transaction
Double complexité à gérer (accès aux objets métiers) Accès concurrents (plusieurs requêtes en même temps) Logique métier d’un ensemble de requêtes (ex: processus)
La notion de transaction répond à cette problématique 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)
Pre
miè
re P
art
ie:
Dis
trib
uti
on
et
Qu
alité
des d
on
nées
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 6/28
Propriétés ACIDProprié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.
Pre
miè
re P
art
ie:
Dis
trib
uti
on
et
Qu
alité
des d
on
nées
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 7/28
Le protocole 2PC (Le protocole 2PC (Two Phase CommitTwo 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
Pre
miè
re P
art
ie:
Dis
trib
uti
on
et
Qu
alité
des d
on
nées
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 8/28
Problématique de la distribution de donnéesProblé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
Pre
miè
re P
art
ie:
Dis
trib
uti
on
et
Qu
alité
des d
on
nées
Distributed DB Design
Directory Management
Query Processing
Reliability
Concurrency Control
Deadlock Management
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 9/28
Bases de données relationnellesBases de données relationnellesP
rem
ière
Part
ie:
Dis
trib
uti
on
et
Qu
alité
des d
on
nées
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)
DBMS (Database Management System)
Gestion des requêtes I/O, recovery, …
Parallélisme: (Oracle RAC) Mécanismes de réplication
Synchrone/ asynchrones
OS
Communication
communication
Semantic Controller
Query Optimizer
Transaction ManagerRecovery Manager
Runtime Support
OS
database
Client DBMS
UI Apps..
SQL queries
results
Client
Server
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 10/28
Annuaires DistribuésAnnuaires Distribués
Annuaire: cas particulier de base de données (directory) Entrée (distinguished name), description (un ou plusieurs attributs) Structure hiérarchique (modèle X500 – arbres … plats)
Il existe des implémentations spécialisées 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
Pre
miè
re P
art
ie:
Dis
trib
uti
on
et
Qu
alité
des d
on
nées
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 11/28
Approches alternativesApproches 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
Pre
miè
re P
art
ie:
Dis
trib
uti
on
et
Qu
alité
des d
on
nées
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 12/28
Deuxième partieDeuxième partie
Introduction et Formalisation Synchronisation et ResynchronisationPilotage des processus
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 13/28
Distribution et Stockage d’InformationDistribution et Stockage d’Information
La distribution fait déjà partie des architecture modernes
SAN Architecture permettant d’utiliser
des disques distants Souvent construit sur un réseau
« fibre channel »
Deu
xiè
me P
art
ie:
(re)
Syn
ch
ron
isati
on
Serveurs applicatifs Serveurs données
SANCluster HP
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 14/28
DCC (DCC (Distributed Concurrency ControlDistributed Concurrency Control))
Mécanisme central de la gestion des transactions Acteurs = transactions qui se partagent des ressources (données)
Aussi appelé « Concurrency Control Services » (Cummins) Acteurs = processus/services qui partagent des objets métiers
Deux familles: 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)
Timestampsordonnancement des accès en fonction d’une sérialisation possible
Deu
xiè
me P
art
ie:
(re)
Syn
ch
ron
isati
on
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 15/28
Synchronisation et ProcessusSynchronisation et 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
Deu
xiè
me P
art
ie:
(re)
Syn
ch
ron
isati
on
composantA
Données locales
Donnéespartagées
composantB
Référence OM
(1) Changement sur OM1
Moteur de Processus
(2) Fin d’activité
(?) Mise à jour replicat OM1
(3) Nouvelle activité
(?) Mise à jour référence OM1
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 16/28
The Snapshot ProblemThe 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.
Le problème est difficile Pas de solution générale (any snapshot) efficace (overhead prohibitif – cf. expérience
Peter Tabeling) Lien avec le problème précédent: garantir que le « snapshot » n’est pas faussé
par la propagation des « updates » 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)
Deu
xiè
me P
art
ie:
(re)
Syn
ch
ron
isati
on
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 17/28
Processus et Transactions LonguesProcessus et Transactions Longues
Les processus servent à implémenter les transactions longues L’implémentation s’appuie sur la (re)synchronisation
Etat S1 initial cohérent :Une référence unique +Toutes les copies sont synchronisées
Etat final cohérent (modificationde la référence)
Retour à S1 par re-synchronisation des systèmes impliqués dans laTransaction depuis la référence
succès
échec
Début du processus Fin du processus
Etat temporaire : deux parties= les systèmes qui participent à la transactions et les autres
Participants : l’état des objets est contenu dans les messagesqui circulent
Non-participants : l’état des objets est défini par la référence avec un « lock » sur l’écriture
Deu
xiè
me P
art
ie:
(re)
Syn
ch
ron
isati
on
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 18/28
Re-synchronisationRe-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. Outils de re-synchronisation Utilisation régulière Reprise sur incident
2. 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)
Deu
xiè
me P
art
ie:
(re)
Syn
ch
ron
isati
on
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 19/28
Troisième PartieTroisième Partie
Introduction et Formalisation Synchronisation et Re-synchronisation Architecture de Données
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 20/28
Design PatternsDesign Patterns: Pas de solution unique: Pas de solution unique
Sur un domaine de données, avec des contraintes fortes de performance:
Moniteur transactionnel (gestion de la concurrence)
OLTP (On Line Transaction Processing) Ex: Tuxedo
Multi-domaine, multi-processus, 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
Tro
isiè
me P
art
ie:
Arc
hit
ectu
re d
e d
on
nées
Tuxedo – composants:•System/T: serveur de noms et gestionnaire de transactions•System/WS: partie client (Windows/Unix)•System/Q: gestion de la queue des message + gestion des ressources•System/Tdomain: gestion transactionnelle multi-domaine
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 21/28
Une « bonne » architecture de données (résumé)Une « bonne » architecture de données (résumé)
Un modèle Global, partagé, compris, entretenu
Un cycle de vie et des propriétaires Qui crée, qui lit, qui modifie, qui supprime ?
Un plan de distribution Où sont les copies et pourquoi ? Qui est la référence (SPT)
Des mécanismes (audit / synchro / etc.) 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 »
Tro
isiè
me P
art
ie:
Arc
hit
ectu
re d
e d
on
nées
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 22/28
MDM (Master Data Management)MDM (Master Data Management)
Solution informatique en cours d’émergence pour la gestion des « données de références »
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) Une méthode (MDM Alliance Group = MAG)
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
Tro
isiè
me P
art
ie:
Arc
hit
ectu
re d
e d
on
nées
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 23/28
Modélisation de données - PrincipesModé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).
Tro
isiè
me P
art
ie:
Arc
hit
ectu
re d
e d
on
nées
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 24/28
Modélisation de données - ConseilsModé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.
Tro
isiè
me P
art
ie:
Arc
hit
ectu
re d
e d
on
nées
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 25/28
Exigence sur les donnéesExigence sur les données
Gouvernance Ex: COBIT
DS11 : gérer les données PO2 : définir l’architecture
de l’information Impact des crises
(ex: Sarbanes- Oxley) CNIL
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
Tro
isiè
me P
art
ie:
Arc
hit
ectu
re d
e d
on
nées
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 26/28
Cycle de vieCycle de vie
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
Tro
isiè
me P
art
ie:
Arc
hit
ectu
re d
e d
on
nées
Création
Lecture
Purge
Destruction
Ecriture
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 27/28
Processus de Gestion de DonnéesProcessus de Gestion de Données
1. Le bon usage des applications.: très souvent, les données incorrectes sont introduites par un usage inapproprié d’une application.
2. 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.
3. La conception des échanges doit garantir la cohérence à tous les niveaux (format et sémantique).
4. Le protocole de synchronisation (et de re-synchronisation continue) doit être cohérent avec le bon déroulement des processus de l’entreprise.
5. Des audits de qualité et de synchronisation doivent être menés de façon continue
6. Les purges (données inutiles) et la re-synchronisation exceptionnelle (réparation)
Tro
isiè
me P
art
ie:
Arc
hit
ectu
re d
e d
on
nées
Bonusage
Filtrage Vérification
CohérenceEchanges
Synchronisation
Nettoyage Réparation
Audit
1.Architecture de données2.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 rejets8.Nettoyage et purge des systèmes9.Qualité des données : on n’améliore que ce que l’on mesure