Tout bon Solutions ou Data Architect a, à tout moment, divers problèmes sur son bureau. C'est normal. Ce qui est anormal, c'est que le même problème revienne sans cesse sur ce bureau. C'est le seul pattern répétitif dont vous voulez vous débarrasser. L'automatisation des données consiste d'abord à repérer ces patterns, puis à agir en conséquence.
Résoudre la solution conceptuellement au bon endroit devrait toujours être le statu quo de l'architecte. Bien que ce soit toujours souhaitable, la pression du temps nous pousse parfois à faire des bêtises. Cependant, lorsque vos solutions reposent sur des patterns répétitifs, cela vous force en quelque sorte la main.
Il est très inconfortable de corriger des solutions ponctuelles si elles ont été générées par un processus automatisé. Vous vous ferez quelques ennemis en créant ce genre de solutions en silo.
En utilisant des patterns répétitifs, vous êtes forcé de prendre du recul et de regarder le problème de bout en bout. Par exemple, vous êtes forcé d'examiner le modèle de données logique et d'identifier d'éventuelles lacunes, plutôt que de simplement ajuster un peu de code SQL qui charge les données dans votre objet cible. Cela met en évidence que votre pattern n'est pas parfait et vous force ainsi à le rendre plus robuste.
Vous pouvez toujours vous sortir d'une situation délicate en codant, mais il n'est pas durable d'avoir des patterns de code sur mesure partout dans votre écosystème.
Je ne suis pas un grand partisan des plateformes no-code. Je n'ai aucun problème avec les plateformes high-code, tant que je n'ai pas à écrire le code moi-même ou, si je le fais, une seule fois. Mais je serais sévèrement limité si je n'avais pas le droit de regarder le code et d'ajuster le pattern si nécessaire.
Au sujet de l'automatisation des données, il serait hypocrite de ma part de ne pas partager cette image chaque fois que j'en parle. Cela reste vrai et il est bon de s'en souvenir.
crédit image : xkcd.com
Ce n'est pas parce que quelque chose est pénible que ce n'est pas la bonne chose à faire. Mettre en place ces premiers templates et patterns est difficile, mais cela finira par l'emporter sur le manuel.
Voici quelques-uns de mes patterns répétitifs évidents à envisager pour l'automatisation des données.
Chargement
Quel que soit votre pattern de chargement, qu'il s'agisse de batch loads, d'une approche CDC ou de streaming piloté par messages. La façon dont vous ingérez les données sur votre plateforme ou votre stockage souhaité doit être légère en transformation et répétable. Configurer le processus de chargement ne devrait prendre que quelques clics.
Je suis partisan de l'ELT : charger vos données telles quelles et les transformer dans la cible. Cela facilite la modularisation du chargement, et la plateforme cible peut alors faire le gros du travail en optimisant les plans de requête pour les transformations sur la cible.
Transformation des données
Le T dans ETL/ELT ne doit pas être purement sur mesure.
Modulariser différentes fonctions est un bon principe dans de nombreux métiers, en particulier le développement logiciel. Modularisez les fonctions qui se répètent souvent. Quelques exemples : les patterns de data cleansing et les règles métier strictes comme le data type casting.
Conceptuellement (revoilà ce mot) faites les mêmes choses au même endroit. Ne nettoyez et ne transformez pas en 1 étape. Ainsi, vous pouvez modulariser les tâches répétitives et les séparer des non répétitives.
Le T dépend aussi du style. Un style de modélisation Data Vault, par exemple, est fortement orienté automatisation et il est donc évident d'y mettre l'accent sur les patterns répétitifs, mais même les styles 3NF et Kimball sont très répétitifs par nature.
Choisissez un style de modélisation et tenez-vous-y. Cela peut bien sûr être une combinaison de design patterns, mais décidez d'un standard et évitez les variations ponctuelles individuelles. Vous en tenir aux patterns que vous vous êtes fixés vous force aussi à faire la bonne chose au bon endroit. En ne choisissant pas de technique de modélisation spécifique, vous faites aussi un choix : vous laissez les décisions entre les mains de chaque engineer. Cela aboutit à du code spaghetti non répétable. Introduisez de nouveaux patterns si le besoin se présente, mais introduisez-les en tant que pattern plutôt que de donner libre cours aux data engineers.
Data Quality
Modularisez et répétez les contrôles de qualité dans votre processus d'acquisition de données, mais assurez-vous qu'ils atterrissent entre les bonnes mains.
Les contrôles de qualité échoués doivent revenir vers les personnes qui seront pénalisées pour de mauvaises données. Qu'il s'agisse de vos product owners ou des data stewards désignés, ils doivent être proactifs pour éliminer les problèmes de data quality.
Un flux de processus simple pourrait ressembler à ceci, où les « mauvaises données » sont masquées. Les données peuvent être masquées en taguant les jeux de données s'ils ont échoué aux contrôles de qualité. Ils peuvent ensuite être exclus des processus de chargement ou masqués via des vues ou une sécurité au niveau des lignes/colonnes.
Quelle que soit la manière dont vous décidez de taguer, masquer ou exclure les données échouées, elles peuvent être livrées sous forme d'instructions DDL intégrées à votre processus d'automatisation.
Stratégie de distribution
La distribution des données sur les plateformes MPP est un élément crucial du cycle de vie et de la durabilité de vos plateformes de données.
Selon vos patterns de modélisation, cela peut être fortement ou légèrement automatisé, mais il ne devrait pas y avoir d'absence totale d'opportunités d'automatisation.
Quelle que soit votre plateforme, la façon dont vous devriez stocker les données repose sur plusieurs facteurs, comme les query patterns, la quantité de données et le fait que les objets doivent être optimisés pour la lecture ou l'écriture. Les query patterns dépendent fortement du style de modélisation de données que vous utilisez. Beaucoup de ces facteurs sont connus au moment du design, et la distribution peut donc être allouée lors de la création initiale du DDL. Certains nécessitent un affinage au fil du temps, à mesure que la taille de vos données et vos query patterns changent. Cela peut toujours être automatisé, car des health checks sont effectués en continu sur vos données.
En raison de la nature répétitive et standardisée de Data Vault en tant que style de modélisation, il existe une bonne opportunité d'appliquer des standards de distribution appropriés sans intervention. Au moment du design, cela peut être écrasé si des modifications sont nécessaires.
En général, différentes plateformes (comme Synapse, Redshift, Snowflake et Delta Lake, pour n'en citer que quelques-unes) disposent d'une bonne documentation sur les stratégies à suivre en matière de partitioning, de distribution et de clustering. Elles ont aussi généralement une documentation qui vous indique comment effectuer des health checks pour vérifier si vos données sont devenues asymétriques. Vous pouvez alors intégrer les enseignements de cette communauté plus large dans un pattern répétable à exécuter périodiquement, permettant à vos données de « s'auto-réparer ».
Data Security
La data security occupe une place importante chaque fois que je parle avec des clients. Elle a toujours été importante, mais elle devient plus nuancée. La plupart des entreprises migrent vers le cloud et les solutions « as a service ». Cela, combiné à la complexité liée aux informations personnelles, en fait une tâche compliquée à appréhender. Non seulement chaque pays a sa propre législation, mais chaque entreprise a sa propre interprétation de cette législation.
Disclaimer : l'automatisation ne réglera pas ces nuances.
L'automatisation vous permet toutefois d'itérer et de tester vos politiques de sécurité bien plus rapidement. Donnez à l'équipe compliance de quoi travailler. Seuls les avocats peuvent travailler avec des règles sur papier, le reste d'entre nous a besoin de les voir en action.
Vous ne devriez pas avoir à appliquer manuellement des politiques de sécurité par utilisateur ou par rôle. Définissez les politiques en amont et, idéalement, vous voulez qu'elles soient déployables (et non déplorables) au moment du design.
Selon votre style de modélisation, vous pouvez facilement déployer des données sensibles vers différentes tables normalisées dans des schémas sécurisés (comme avec Data Vault), ou les garder ensemble tout en appliquant des politiques au niveau des colonnes ou des lignes sur la table via la génération de DDL. Que vous masquiez les données, les chiffriez ou les protégiez simplement de l'utilisateur, la plupart des plateformes cibles offrent certaines ou toutes ces fonctionnalités. Le design reste homogène, le déploiement s'adapte selon la plateforme cible vers laquelle vous déployez.
Tests
Beaucoup a été écrit à ce sujet, et je vous recommanderais de lire notamment sur le testing en data ops¹.
C'est un sujet vaste et je vais simplement souligner un aspect que je vois négligé : curated input, curated output. Créer des jeux de données curatés contre lesquels tester, c'est là que résident la douleur et la gloire.
Refuser les invitations à des réunions
Ok, c'est un bonus, mais les gens sont complètement « Zoomed out ». Des solutions bien architecturées vont de pair avec des plans bien exécutés. Les deux ont besoin, de temps en temps, d'un effort concentré et ininterrompu.
En résumé, en regardant l'automatisation des données de bout en bout, il y a probablement bien d'autres domaines et fonctions que l'on peut automatiser, mais je trouve que ces six jouent un rôle central dans la durabilité de votre architecture. Améliorer continuellement les patterns pour ceux-ci vous force à construire des solutions bien architecturées et à briser le cycle où il faut corriger sans cesse les mêmes problèmes.
Continuez simplement à vous demander où existent des patterns répétitifs ou où ils peuvent être améliorés · améliorez le pattern, rincez et répétez.
À PROPOS DES AUTEURS
Corné Potgieter
Data Architect
