Administrer Snowflake avec une approche Data Mesh en garantissant une consistance de la gouvernance au sein des divers comptes repose sur un principe clé : la gouvernance fédérée.
Prenons un exemple : Vous venez de prendre vos fonctions de DSI au sein d’un groupe international. Parmi vos premiers chantiers figure l’harmonisation de l’écosystème data, sans brider la capacité d’initiative des équipes locales. Vous savez que l’approche Data Mesh (architecture de données décentralisée) repose sur une forte autonomie des domaines, mais qu’elle n’a de valeur à l’échelle que si elle s’appuie sur une data gouvernance fédérée solide, capable d’aligner règles, standards et responsabilités.
Dans cet article, nous verrons comment mettre en place une gouvernance fédérée au-dessus de Snowflake.
Dans Snowflake, vous avez à votre disposition plusieurs conteneurs pour “ranger” vos données.
Voici leur hiérarchie :
Pour garantir le bon usage des données et de l’outil Snowflake, vous pouvez vouloir surveiller les éléments suivants :
Tous les éléments de gouvernance sont réunis sous une nouvelle bannière qui s’appelle Snowflake Horizon et qui ne cesse de s’enrichir.
1️⃣ Utiliser un seul compte et séparer les départements dans des bases de données.
2️⃣ Utiliser plusieurs comptes et déployer votre gouvernance depuis votre CI/CD.
3️⃣ Utiliser plusieurs comptes dont un Zero Data Account qui porte la gouvernance.
On peut, et d’ailleurs on a fait comme cela pendant des années, utiliser un compte Snowflake unique et isoler les départements dans des bases de données.
Voici un exemple dans un schéma :
Avantages :
Inconvénients :
On peut utiliser un compte DSI et un compte par département qui a la capacité d’opérer son propre Snowflake. En effet, si ce n’est pas le cas, il est peut être préférable de garder les objets au niveau du compte DSI et de fournir un service complet aux filiales.
Pour déployer les éléments de gouvernance (tags, masking policies, etc.) on va utiliser une CI/CD (par exemple le couple Github Actions + schemachange) pour exécuter automatiquement les scripts sur les différents comptes Snowflake.
On peut utiliser aussi l’intégration de Git directement dans Snowflake et coder une procédure qui gère les déploiements.
Attention : on ne pourra pas faire de jointures d’un compte à l’autre directement dans nos requêtes.
On va publier l’objet partagé (table, vue, etc) sur un Private Listing qui sera accessible à un ou plusieurs comptes.
Cette contrainte peut être vue comme une opportunité de gérer ses publications de data products de manière mieux maîtrisée. Car quand on sait que l’on est producteur de données, on se doit de fournir à ses consommateurs une expérience de qualité (une documentation, des données de qualité, pas de modification du contrat d’interface, etc).
Avantages :
Inconvénients :
L’approche de Zero Data Account est possible chez Snowflake depuis l’arrivée des Replication Groups. Mais le principe est simple et répandu dans les approches DevOps (par ex. avec AWS Control Tower).
Au lieu d’utiliser une CI/CD, on va déployer les éléments de gouvernance directement depuis Snowflake à travers les groupes de réplication qui seront déployés sur les autres comptes de la même organisation.
On va pouvoir centraliser toutes les informations de gouvernance citées précédemment au niveau de ce Zero Data Account qui, comme son nom l’indique, n’a pas vocation à héberger des données.
Le Zero Data Account doit être au niveau de souscription Business Critical pour pouvoir utiliser la réplication des objets de gouvernance.
Je n’ai pas trouvé dans la doc si les comptes cibles devaient être aussi en Business Critical mais il me semble que non.
Pour savoir si les comptes ont bien utilisé les éléments de gouvernance, on pourra leur demander de nous partager les tables de medata comme par exemple SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCE.
Mais on peut aussi se parler entre humains lors des points de gouvernance fédérée.
Avantages :
Inconvénients :
Masterclass: Deliver a Domain-Driven Data Mesh Architecture Successfully