Snowflake : les Dynamic Tables peuvent-elles remplacer les ETL/ELT ?

Après toutes les annonces de Snowflake lors du Summit et Snow Day de l’année dernière, les nouvelles fonctionnalités arrivent progressivement en General Availibility. C’est désormais au tour des Dynamic Tables, et nous allons donc nous y attarder pour comprendre ce qu’elles peuvent apporter comme cas d’usage et surtout comment les mettre en place. C’est parti !

J-14

Matinale Data & IA

05 Déc 2024 |08h30 – 14h00 Paris

S'inscrire

Les Dynamic Tables : de quoi s’agit-il et à quoi servent-elles ?

Les Dynamic Tables sont un type de table spécifique dans Snowflake, au même titre que les tables permanentes ou temporaires. Elles permettent de matérialiser les données d’une requête dans une table. Les informations étant stockées physiquement, les temps de réponses y seront plus performants que sur une vue classique.

Cela ressemble beaucoup à une vue matérialisée me direz-vous ! Eh bien oui, mais sans leurs limitations (bien qu’elles en aient quelques-unes qu’il faut prendre en compte) ! En effet, les vues matérialisées ne peuvent se baser que sur une seule table source, sans faire d’opérations complexes (pas de jointures…) ce qui bloque bon nombre de scénarios.

L’autre différence fondamentale est la notion de fraîcheur de données. Une vue matérialisée se met à jour automatiquement, dès que les données de la table source changent. Ce mécanisme, bien que pratique, peut en revanche vite s’avérer coûteux.

Les Dynamic Tables sont un type de table spécifique dans Snowflake. Elles permettent de matérialiser les données d’une requête dans une table. Les informations étant stockées physiquement, les temps de réponses y seront plus performants que sur une vue classique.

Le rafraîchissement d’une table dynamique se base sur un « lag », un délai de mise à jour. Vous pouvez donc l’ajuster en fonction du besoin métier pour que la fraîcheur de données soit de 5 minutes, ou de 4 heures. Vous avez ainsi la maîtrise du coût qu’elles vont générer. En contrepartie, il est néanmoins important d’avoir une vision claire de la chaîne pour définir ces délais de manière cohérente pour le métier.

Résumons tout cela avec le schéma ci-dessous.

Pour quels cas d’usages miser sur les Dynamic Tables ?

Les points forts des Dynamic Tables en font de très bonnes candidates pour les pipelines de données en temps réel directement dans Snowflake, sans autre outil type ETL/ELT.

En effet, en plus de pouvoir se sourcer sur plusieurs tables, les Dynamic tables peuvent également se baser sur d’autres Dynamic Tables ! A partir de ce principe, on peut très bien imaginer un flux de bout en bout de transformation des données.

Dans le schéma ci-dessus, les tables sources sont les données brutes issues des bases opérationnelles. La première table dynamique est la dimension clients, et la deuxième une table de fait récupérant les commandes et les informations de la dimension clients. Les utilisateurs Dataviz utiliseront ces tables pour visualiser les données en quasi-temps réel, à partir du moment où les tables sources sont mise à jour.

Reste-il une place pour les ETL/ELT dans Snowflake ?

Pour répondre à cette question, il faut préciser qu’il en existe deux types :

• Les « low code », orientés graphique et ergonomique, comme Informatica, Talend, Semarchy xDI, Matillion…
• Les « code », DBT (Data Built Tool) par exemple, où les flux se font exclusivement à base de code SQL, Python…

Pour les « low code », la différence d’approche avec les Dynamic Tables est importante. Il est donc compliqué d’imaginer de les remplacer, car cela implique un changement d’usage fort pour les utilisateurs.

Pour les « code », la question se pose ! En effet, on retrouve le même principe de transformation, avec des tables construites à partir de requêtes, elles-mêmes utilisées pour en alimenter d’autres.

Cependant, les Dynamic Tables n’offrent pas tous les avantages que propose DBT et on perd certains éléments essentiels :

• L’intégration avec des systèmes de versionning comme Git.
• La possibilité de définir et d’automatiser des tests
• La génération de la documentation automatisée

Les tables dynamiques se positionnent donc plus en complément des ETL/ELT pour certains cas d’usage spécifiques, en quasi-temps réel, sans orchestrateur.

Comment mettre en place des Dynamic Tables et les monitorer ?

Fidèle à son paradigme, Snowflake fait dans la simplicité. La création d’une table dynamique se réalise à l’aide d’une opération DDL (Data Description Language) des plus classiques :

Une nouvelle catégorie Dynamic Tables est présente dans le menu Monitoring de Snowsight qui stocke toutes les informations nécessaires pour en avoir la supervision globale :

Pour vous entraîner, je ne peux que vous recommander les quickstarts Snowflake qui permettent d’avancer pas à pas sur la découverte de fonctionnalités.

Au niveau des coûts, deux aspects sont à prendre en compte :

• Le stockage.Comme précisé, les données de ces tables sont matérialisées et entrent en compte dans la volumétrie globale de votre account Snowflake.
• Le process. On reste sur l’usage d’un virtual warehouse classique, qui consommera des crédits en fonction de sa taille et du temps d’exécution.

Même si cela semble évident, il est bon de rappeler que pour optimiser les coûts dans Snowflake, il est essentiel de s’assurer que les bonnes pratiques en matière de requêtes SQL soient bien appliquées !

J’espère que cet article vous aura éclairé sur les Dynamic Tables, et que vous saurez maintenant qu’elles n’ont pas la vocation à remplacer les ETL/ELT. Elles leur sont complémentaires, notamment dans la mise en place de pipelines quasi-temps réel.

Chez Business & Decision (Orange Business), nous accordons beaucoup d’importance aux roadmaps de nos partenaires comme Snowflake pour se tenir informé des dernières fonctionnalités mises à disposition. Cela nous permet de pouvoir conseiller au mieux nos clients en fonction de leurs cas d’usage.

Si vous souhaitez en savoir plus, contactez-nous 😉

👉 Retrouvez toute notre actu en temps réel en nous suivant sur LinkedIn 👈