Je suis un programmeur paresseux ! C’est un détail important que j’ai appris de Roelant Vos lors de sa formation la semaine dernière. Mais il y avait beaucoup d’autres sujets intéressants. Un résumé personnel d’un cours de 3 jours sur les modèles de conception d’entrepôts de données.
La semaine dernière, j’ai eu l’occasion de participer au cours sur les modèles de conception d’entrepôts de données de Roelant Vos. J’ai vu Roelant dans des présentations sur des conférences de modélisation de données, et j’apprécie son blog avec beaucoup d’informations utiles sur l’architecture de Data Warehouse et la mise en œuvre de Data Vault. Ainsi, lorsque j’ai reçu l’information de mes collègues de Trivadis qu’il donnerait une formation à Zurich, j’ai saisi l’opportunité de rejoindre ce cours de 3 jours.
Je ne vais pas écrire une revue détaillée de l’ensemble du cours dans ce billet de blog. Mais dans les lignes suivantes, vous trouverez quelques notes sur trois sujets qui étaient – de mon point de vue – importants dans cette formation : Pattern Based Design, Persistent Staging Area et Virtual Data Warehouse.
Une architecture typique d’entrepôt de données se compose de plusieurs couches pour le chargement, l’intégration et la présentation des informations métier provenant de différents systèmes sources. Le nombre et les noms des couches peuvent varier dans chaque système, mais dans la plupart des environnements, les données sont copiées d’une couche à l’autre avec des outils ETL ou des instructions SQL pures. Avec une bonne architecture, les modèles pour transformer et charger les données dans une couche particulière sont toujours similaires. Cela facilite (et accélère) le développement des processus ETL, car les modèles reproductibles peuvent être générés avec un outil d’automatisation des entrepôts de données (DWA). Sur le blog de Roelant, vous trouverez un aperçu de son cadre d’intégration des données. Des exemples de code sont disponibles sur GitHub.
Pourquoi suis-je un programmeur paresseux ? Comme beaucoup d’autres développeurs, je n’aime pas écrire du code répétitif. Roelant est un programmeur paresseux, lui aussi. C’est pourquoi il a passé beaucoup de temps à développer des outils et des méthodes pour accélérer les tâches de développement en générant le code SQL pour construire et charger les entrepôts de données. Pendant le cours, il a expliqué de nombreux modèles de conception avec le générateur SQL VDW (Virtual Data Warehouse). Il peut être téléchargé gratuitement sur son site web et est utile pour les prototypes rapides et les tests de régression des changements de patrons.
Persistent Staging Area
Une couche importante de l’architecture proposée est le PSA (Persistant Staging Area). Bien que cette zone de la couche de staging soit facultative, elle est très pratique et fortement recommandée, notamment lorsque les exigences métier ne sont pas encore claires au début du projet. Le PSA est une archive historique des données des systèmes sources et remplace la zone de transit volatile classique. Le PSA est chargé soit avec des mécanismes CDC (Change Data Capture) soit avec une détection delta entre le système source et la version actuelle du PSA. La Persistent Staging Area est la source unique pour charger les tables de Data Vault (Hubs, Links et Satellites) dans la couche d’intégration.
L’avantage d’une Persistent Staging Area est que seules les parties actuellement requises de l’information doivent être chargées dans les tables de Data Vault. Nous n’avons pas à nous soucier des exigences futures, car les données originales sont toujours disponibles dans le PSA et peuvent être rechargées lorsqu’elles sont nécessaires. J’ai vu et utilisé cette approche dans plusieurs projets clients, et c’est une bonne assurance contre les exigences métier inconnues.
Entrepôt de données virtuel
Lorsque j’ai vu Roelant Vos pour la première fois sur la conférence Data Modeling Zone 2017 à Düsseldorf, j’ai été très impressionné par une approche d’architecture intéressante qu’il a expliquée : La seule couche persistante d’un entrepôt de données est le PSA, et tout le reste est mis en œuvre au-dessus des tables du PSA avec des vues. Il s’agit de l’implémentation cohérente d’un entrepôt de données virtuel supporté par le logiciel VDW de Roelant. J’ai vu cela en théorie et dans certaines présentations, mais jamais dans sa forme complète dans un projet réel.
Cette approche « NoETL » présente plusieurs avantages : 1. Il est très facile de changer la logique de transformation sans recharger toutes les couches de votre entrepôt de données. 2. Dès que de nouvelles données sont chargées dans la couche PSA, elles sont immédiatement visibles dans toutes les couches suivantes. 3. Il s’agit d’une sorte d’entrepôt de données à schéma de lecture où vous pouvez décider au moment de la requête comment les données sources doivent être interprétées. Tout cela semble très bien, mais je vois toujours le défi d’une bonne performance d’interrogation. Je pense que, dans la plupart des situations, il faut persister au moins les données couramment utilisées. Mais avec l’approche des vues, cela peut être fait sans beaucoup d’efforts, par exemple avec les vues matérialisées.
Le cours de 3 jours a plus que répondu à mes attentes. Bien que j’ai déjà utilisé certains des concepts moi-même (pour être honnête, la plupart de ce que Roelant a expliqué m’était déjà familier), j’ai vraiment apprécié la construction étape par étape d’une architecture d’entrepôt de données à l’aide de nombreux exemples de code et de démos en direct. Ou comme je l’ai dit comme retour spontané à la fin du cours : « C’était amusant ».