Dans chaque entreprise, le Datawarehouse (DWH) est la base de données qui a pour vocation de répondre à pratiquement n\’importe quelle question métier d’une manière rapide et fiable. Cette vocation, qui donne au DWH sa position centrale depuis de nombreuses années, est aujourd’hui challengée par le Data Lake, ce qui aboutira certainement à la disparition du DWH. Cet article fait le point sur ces attaques, propose une nouvelle vision du décisionnel sans DWH et présente les premières étapes pour la mettre en place.
Pourquoi le DWH est attaqué?
Le Datawarehouse coûte cher
Alors que la plupart des coûts IT diminuent, le coût du DWH ne diminue pas. Au contraire, plus un DWH vit et grandit, plus il coûte cher, car le coût de maintenance de cette structure monolithique n\’est pas linéaire avec la quantité d’informations qui y est gérée. La modélisation évolutive (ie le Data Vault) ainsi que les techniques d’automatisation du DWH ont pour objectif de permettre une linéarité du coût, mais ces principes restent peu utilisés. Il est même possible que ces approches n\’aient pas le temps de prendre, du fait de l’apparition des approches \ »Data Lake\ » décrites ci-dessous.
Le DWH bride l’innovation Métier
Plusieurs raisons à cette incompatibilité entre DWH et innovation Métier:
- De nombreux processus sont en place pour protéger la qualité des données du DWH, en particulier du fait du nombre de rapports qui en dépendent. Ces processus rendent difficiles et lentes toutes les évolutions au contenu du DWH.
- Le DWH doit répondre à un grand nombre de questions à partir d’un unique ensemble de tables liées. Plus le temps passe, plus il est difficile d’ajouter un nouveau domaine à cet ensemble. Et plus cette difficulté nécessite de l’expertise IT, plus cela prend du temps.
- Le DWH ne gère que des informations structurées, ce qui a pour conséquence que les images, les tweets ou les emails sont agrégés en quelques statistiques dans le DWH. Sans possibilité d’exploiter les données brutes.
- Enfin lorsqu\’un cas d’usage de la donnée apparaît, il faut pouvoir en évaluer rapidement le coût et la valeur. Ce qui n\’est pas compatible avec le rythme d’évolution d’un DWH.
Comme le DWH n\’est pas compatible avec le rythme d’évolution du Métier. Les utilisateurs se sont habitués à extraire des données du DWH, à les fusionner eux-mêmes avec d’autres données dans Excel ou un outil de DataViz. Mais également de construire leurs tableaux de bord. Ce qui, en plus, empêche le partage des données et la gouvernance.
Le DWH ne gère pas le temps réel
Avec toutes les étapes d’intégration et de préparation de la donnée, les Datwarehouse sont le plus souvent alimentés une à deux fois par jour. Et même l’intégration d’une seule table de fait alimentée en temps réel est rendu complexe par le fait que toutes les tables de référence ne sont quant à elles alimentées qu’une fois par jour.
Le Datawarehouse empêche les évolutions organisationnelles
Le DWH est complètement géré par l’IT, qui en contrôle les accès autant que les évolutions. Ainsi les initiatives liées à la donnée des Directions Métiers ne peuvent s’appuyer sur le DWH sans une implication forte de la DSI. Alors même que des outils arrivent sur le marché pour permettre la transformation et la préparation de données par des utilisateurs Métiers, le DWH maintient l’IT sur le chemin critique des données. Certaines société ont tenté de créer des espaces de moindre gouvernance dans leur Datawarehouse mais cette approche est beaucoup mieux gérée dans un Data Lake.
Le Datawarehouse n\’est pas adapté aux projets agiles
Le développement de flux ETL et de tableaux de bord peut suivre une méthodologie agile comme Scrum, mais les processus de déploiement des DWH empêchent toute application de l’agilité à ces projets.
Que faut-il conserver du Datawarehouse?
Malgré les travers indiqués ci-dessus, de nombreuses caractéristiques du Datawarehouse restent importantes:
- Agréger des données en provenance de plusieurs sources, autour de dimensions communes, afin de simplifier la construction de datasets pour les utilisateurs
- Gérer la qualité des données présentées aux utilisateurs, que ce soit pour les référentiels ou les faits
- Gérer la sécurité des accès, pour ne montrer à chaque utilisateur que ses données
- Manager la performance des accès par de nombreux utilisateurs
- Permettre le drill, l’analyse depuis les données agrégées jusqu\’aux données de détail
Ensuite, il faut qu’un remplaçant du DWH ait les capacités suivantes:
- Intégrer tous les types de données de l’entreprise
- Exploiter des données en temps réel
- Enregistrer les données une seule fois pour les exploiter dans de nombreux cas d’usage, dont la Data Science
- Réaliser des petits projets qui, ensemble, forment une grande architecture Data
Quelle vision pour un décisionnel sans DWH?
Voici quelques caractéristiques d’un futur SI décisionnel sans DWH :
Limiter la duplication des données
Chaque transformation de données requiert du temps de développement, de test, de traitement et, plus tard, d’évolution. Ainsi, limiter le nombre de copies de la données augmente l’agilité de l’architecture décisionnelle. Un des objectifs du Data Lake est de minimiser le nombre de recopies des données.
Par exemple, et d’une manière très simplifiée, pour un Data Lake organisé sur un principe de fichiers, nous pourrions nous limiter à trois zones:
- Raw Zone, pour maintenir une copie brute des fichiers transmis au Data Lake
- Refined Zone, avec des datasets de qualité contrôlée, préparés dans le cadre de cas d’usage
- Distilled Zone, pour laisser une zone moins controlée par l’IT où les utilisateurs continuent à travailler les données
Dans cette approche, deux zones sont suffisantes pour enregistrer les fichiers bruts et les transformer en datasets directement exposés aux utilisateurs. L’objectif est alors de ne pas créer de copies supplémentaires des données pour les besoins des outils BI ou de Dataviz.
Les trois zones ci-dessus (Rawn Refined, Distilled) correspondent à trois niveaux de gouvernance distincts, et la zone Refined doit correspondre à la qualité du DWH actuel.
Limiter la duplication du code ETL
Pour dessiner les flux d’alimentation, certains frameworks traitent avec le même code des données en batch et des données en flux (flux = temps réel). Il y a dans ces frameworks (ex. Apache Beam) la capacité à créer des architectures qui agrègent des données de plusieurs sources en temps réel sans avoir à créer un code complexe pour la gestion batch/flux.
Amener les utilisateurs IT et métiers à cataloguer les données
Lors de la création de nouveaux datasets, par les utilisateurs IT ou bien Métiers, il est nécessaire de documenter le contenu de chaque fichier. C\’est une tâche difficile, qui ne peut se faire qu\’au moment de la publication des fichiers. Certains outils (data-catalog) scannent automatiquement les fichiers ajoutés pour proposer une documentation à l’utilisateur qui publie. Ensuite il suffit de compléter et de valider.
Ouvrir le Data Catalog et fermer les datasets
Au fur et à mesure de la création de nouveaux datasets, une autre activité primordiale est de mettre en place la sécurité. Elle est nécessaire pour contrôler la visibilité des données enregistrées dans le Data Lake. Dans la vision proposée ici, les datasets sont inaccessibles par défaut et le data-catalog est ouvert à tout le monde. L’ouverture de droits est réalisée à la demande des utilisateurs, ces demandes doivent être motivées et temporaires. Comme le data-catalog enregistre les demandes et les validations d’accès (avec la ressource, le demandeur, le validant, la durée de l’accès, etc.). il est aussi possible d’auditer les droits et aussi de savoir quels datasets sont utilisés et doivent être maintenus.
Brancher la BI et la Dataviz directement sur le Data Lake
Pour réduire la recopie des données, il faut exposer directement les datasets du Data lake aux outils BI et Dataviz. Les plateformes \ »BI-sur-Data-Lake\ » que nous intégrons proposent une couche sémantique, une couche de sécurité et une couche de performance. Ce qui permet aux utilisateurs de se connecter par Excel ou Tableau aux fichiers ou aux tables du Data Lake. Cette couche unique expose les mêmes données, les mêmes règles de gestion et les mêmes droits à toutes les interfaces BI et DataViz. Et en plus, sans copie supplémentaire des données à l’intérieur ou à l’extérieur du Data Lake. Depuis Excel, Tableau ou n\’importe quel outil DataViz, chaque utilisateur a accès à ses données, organisées en dimensions. Il peut également effectuer des drills dans ses rapports, avec une performance identique à celle des cubes.
Comment mettre en place cette vision aujourd’hui?
L’équipe Polarys Think effectue des missions de conseil en organisation et en architecture. En organisation car le premier impact de l’adoption du Data Lake est organisationnel. Accompagné d’une re-répartition des rôles autour de la donnée entre l’IT et les métiers. En architecture aussi, où nous avons sélectionné un ensemble de partenaires qui partagent cette vision du Data Lake:
- Des plates-formes de stockage de données en mode Cloud, certaines exclusivement sous forme de fichiers, certaines mixtes fichiers/tables
- Outils de Gouvernance des données
- Des outils de BI-sur-Data-Lake,
- Des outils de BI, Data Visualisation, Data Preparation et Data Science
Contactez-moi pour avoir davantage d’informations sur ces missions et ces partenariats.
Dans cette vision, le Datawarehouse disparaît-il vraiment?
Oui, le DWH disparaît complètement, avec ses coûts et aussi ses limitations. Ce qui est conservé, c’est ce que couvre le DWH. il permet un accès fiable à des données de qualité à partir de plusieurs outils.
Le DWH devient une région du Data Lake. Une région où la qualité des données et les interfaces pour les outils BI et DataViz sont contrôlées. Le Datawarehouse devient une gouvernance particulière de la donnée.
Seul Google BigQuery conserve tout son rôle dans cette vision. BigQuery est la zone de stockage de traitement et de présentation des données structurées de Google Cloud Platform. Il peut être alimenté et requêté en temps réel. Il est vu ici plutôt comme la composante \ »données structurées\ » d’un Data Lake sur Google.
Conclusion
Chez Polarys, nous pensons que la transformation d’une organisation centrée sur un DWH à une organisation centrée sur un Data Lake est un processus laborieux. Mais que le Data Lake vient simplifier l’architecture, supprimer des freins à l’innovation et ainsi permettre l’émergence de nouveaux services centrés sur la donnée.
Que pensez-vous de cette vision? Prêt à éteindre votre DWH?
Auteur : Arnaud Lievin, Directeur Data Science
Si vous souhaitez en savoir plus sur notre offre Data Science, cliquez ci-dessous :
