Big data : entrepôt de données de santé

Ce que c’est

Un entrepôt de données pour un groupement hospitalier, alimenté par des flux d’intégration depuis une base relationnelle et des fichiers ouverts.

Ce qui était dur

Les sources n’ont ni le même format, ni la même granularité, ni les mêmes identifiants. Tout le travail est de les faire converger vers un modèle unique.

Ce que ça prouve

Chaque besoin utilisateur reste traçable jusqu’au flux qui l’alimente, et le partitionnement est choisi pour servir un besoin nommé.

Projet de groupe, dans le cadre du bloc big data du cycle ingénieur. Cas d’étude académique : un groupement hospitalier qui veut piloter son activité de soins.

Des données de soins éparpillées

Les données de soins existent, mais pas au même endroit. L’activité de consultation vit dans une base relationnelle. Le référentiel des établissements et des professionnels de santé, les données de mortalité et les enquêtes de satisfaction des patients vivent dans des fichiers ouverts publiés séparément, avec leurs propres formats et leurs propres identifiants.

Aucune question de pilotage ne se répond sans les croiser, et le volume interdit de le faire à la main : 28,4 MlignesproductionVingt-huit millions de lignes éparpillées sur des dizaines de fichiers, à faire converger vers une seule base interrogeable. réparties sur des dizaines de fichiers, dont un seul, le répertoire national des décès, en porte 25,1 MactesproductionUn fichier si lourd qu’aucun tableur ne peut l’ouvrir : c’est là que les outils big data deviennent obligatoires..

C’est ce qui fait basculer l’exercice : à cette taille, on n’ouvre pas un fichier, on le traverse.

Des identifiants qui ne se répondent pas

Les besoins sont définis avant le modèle. 8besoinsjeu de testBesoins utilisateurs tracés jusqu’aux flux : 8 besoins (jeu de test). ont été posés en amont, et chacun devait rester traçable jusqu’aux flux : à la fin, chaque flux d’intégration déclare quels besoins il alimente. C’est ce qui évite de construire un entrepôt que personne n’interroge.

Des identifiants qui ne se correspondent pas. Les identifiants d’établissement d’une source ne sont pas ceux d’une autre, et les découpages géographiques diffèrent d’un fichier à l’autre.

Un environnement de travail unique, la distribution Hadoop installée pour le cours. Sa configuration n’est pas documentée dans le livrable, et les mesures qui suivent en héritent.

De la modélisation à l’entrepôt

Chaîne d’intégration et entrepôt

Des sources hétérogènes à des requêtes qui tiennent

1. Base relationnelle

   soins, consultations, diagnostics

   Fichiers ouverts

   établissements, professionnels, satisfaction

2. Flux d’intégration

   extraction, sélection et mise en correspondance des attributs

3. Système de fichiers distribué

4. Entrepôt en étoile

   une table de faits, entourée de ses dimensions

   Partitionnement et bucketing

   choisis pour servir un besoin utilisateur nommé

Modélisation en deux temps. Un modèle conceptuel d’abord, pour comprendre le domaine, puis un modèle en étoile pour l’interrogation : chaque consultation au centre, et autour d’elle 9tables de contextejeu de testChaque consultation est rangée avec tout son contexte, prêt à être croisé : qui a consulté, qui a soigné, où, quand, pour quel diagnostic. qui disent qui a consulté, qui a soigné, où, quand, pour quel diagnostic, avec quelle satisfaction. Croiser devient une simple jointure.

Des flux d’intégration graphiques. Chaque flux lit une source, sélectionne et met en correspondance les attributs utiles, et écrit dans le système de fichiers distribué.

Une table de faits partitionnée et bucketée. La table de consultation est recréée avec un partitionnement par diagnostic et une répartition des patients en compartiments. Le livrable indique comment généraliser ce schéma aux autres tables ; il ne le fait pas.

arbitrage documenté

Entrepôt retenu contre un lac de données, parce que les sources sont déjà structurées ; modèle en étoile retenu contre un flocon, au prix d’une redondance de stockage comparée qualitativement dans le livrable.

Dessiner le stockage sur les questions

Le partitionnement sert un besoin nommé, pas un principe. La table de faits est partitionnée par diagnostic et ses patients répartis en compartiments, et le livrable dit pourquoi : c’est ce qui doit permettre de répondre au besoin qui demande un taux de consultation par diagnostic sur une période. Le stockage est dessiné à partir des questions posées, ce qui est la seule façon de le dimensionner sans deviner.

L’étoile, choisie parmi trois modélisations comparées. Le modèle en étoile dénormalise les dimensions, donc duplique de l’information. En échange, une requête traverse moins de jointures et le modèle se relit sans schéma sous les yeux. Le livrable porte le tableau de comparaison, redondance de stockage comprise : l’arbitrage est tranché, il n’est pas passé sous silence.

Les transformations ont changé de place en cours de projet. Le premier livrable les plaçait dans l’outil de visualisation. Le second les déplace dans les flux d’intégration, et acte le revirement sans le justifier. La raison, telle que je la reconstitue : faire les transformations en aval revient à les refaire à chaque rafraîchissement, dans un outil qui n’est pas fait pour ça, et à les rendre invisibles à quiconque n’ouvre pas le tableau de bord.

Des tables internes plutôt qu’externes, pour que la suppression d’une table emporte ses données : le cycle de vie reste maîtrisé, au prix d’une perte irréversible en cas d’erreur.

Ce que le projet a produit

Un entrepôt complet et traçable. Le modèle en étoile est livré avec ses 9tables de contextejeu de testChaque consultation est rangée avec tout son contexte, prêt à être croisé : qui a consulté, qui a soigné, où, quand, pour quel diagnostic., les flux qui l’alimentent existent, et chacun des 8besoinsjeu de testBesoins utilisateurs tracés jusqu’aux flux : 8 besoins (jeu de test). se suit du besoin exprimé jusqu’au flux qui le sert. C’est ce que le projet démontre, et c’est le travail de conception qui vaut d’être montré.

La mesure de performance, elle, ne démontre rien

Le livrable mesure deux temps de requête. Une requête filtrée sur un identifiant de patient et un identifiant de professionnel, sur la table à plat : 1,8secondesjeu de testRequête à deux prédicats, table non partitionnée : 1,8 secondes (jeu de test).. Une requête filtrée sur le seul identifiant de patient, sur la table partitionnée : 0,4secondesjeu de testRequête à un prédicat, table partitionnée et bucketée : 0,4 secondes (jeu de test)..

Ce sont deux requêtes différentes. L’une porte deux prédicats, l’autre un seul. Une requête moins sélective sur une table optimisée face à une requête plus sélective sur une table brute : la comparaison n’est pas appariée, et l’écart mélange l’effet du stockage et celui de la requête. Le livrable présente pourtant ces deux temps comme une évaluation du partitionnement.

Et le filtre ne porte pas sur la clé de partition. La table est partitionnée par diagnostic ; les deux requêtes filtrent sur le patient, qui est la colonne de répartition en compartiments. Ce n’est donc pas le partitionnement qui pourrait expliquer un gain sur ces requêtes, à supposer qu’un gain soit établi.

Je publie les deux chiffres parce qu’ils ont été mesurés, et ce constat avec eux : un protocole de comparaison qui change deux choses à la fois ne mesure ni l’une ni l’autre.

Ce que la mesure ne démontre pas

Le volume chargé n’est pas documenté. Les temps ci-dessus n’ont donc pas d’échelle : on sait qu’une requête a pris tel temps, on ne sait pas sur combien de lignes.

Le premier temps est une borne, pas une mesure exacte : le livrable écrit « plus de », suivi de la valeur. Le second est donné comme atteint. Une seule exécution par requête est rapportée, sans dispersion.

Le chiffrement, la fédération et la réplication sont décrits, pas activés. La section correspondante du livrable est documentaire : rien n’établit que ces mécanismes ont tourné.

La part individuelle n’est pas séparable. C’est un livrable collectif, et je ne revendique aucun de ces chiffres comme personnel. Le travail existe et il est décrit ici ; l’attribution ne l’est pas.

Si je recommençais

Je changerais une seule chose à la fois. C’est le défaut central du projet, et je ne l’ai vu qu’en relisant le livrable pour cette page. Comparer une table optimisée à une table brute exige d’exécuter exactement la même requête sur les deux. Deux requêtes différentes ne produisent pas une mesure, elles produisent deux nombres.

Je ferais porter le filtre sur la clé de partition. Mesurer l’effet d’un partitionnement par diagnostic demande une requête qui filtre sur le diagnostic. Le protocole ne pouvait pas répondre à la question qu’il posait.

Je consignerais le volume de données avec chaque mesure. Un temps de requête sans nombre de lignes n’est pas un résultat, c’est une anecdote. C’est le reproche que je fais ailleurs à un chiffre publié sans effectif, et il s’applique ici.