Cours chapitre7 2012

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


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


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


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


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


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


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


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


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


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


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


Deuxième partieDeuxième partie

Introduction et Formalisation Synchronisation et ResynchronisationPilotage des processus


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


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


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


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


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


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


Troisième PartieTroisième Partie

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


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


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


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


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


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


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


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


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

Cours chapitre7 2012

Education

Transcript of Cours chapitre7 2012