Des tâches et des ruisseaux à la tranquillité: mon premier vrai projet avec des tables dynamiques de flocon de neige

Permettez-moi de vous parler du moment où j’ai réalisé que j’avais compliqué des choses depuis des années.

Je travaillais sur un pipeline dans Snowflake. Vous connaissez le type – un processus de transformation en plusieurs étapes où quelques tables de base alimentent les tables intermédiaires, une certaine réconciliation se produit, et finalement tout atterrit dans une couche de rapport final. J’avais configuré cela de la manière traditionnelle: Streams + Tâches + un tas de scripts SQL + logique d’orchestration pour s’assurer que tout a tiré dans l’ordre.

Cela a fonctionné. Mais c’était… cassant. Et lourd.

Donc, quand j’ai entendu parler de tables dynamiques de flocon de neige – je l’admets – je n’ai pas sauté avec les deux pieds. J’ai été brûlé par des approches «plus simples» qui se sont transformées en dette technologique sur la route. Mais j’étais curieux.

Et finalement, j’ai été impressionné.

Que sont les tables dynamiques (dans la vraie vie)?

Selon les mots de Snowflake, les tables dynamiques sont des tables matérialisées définies par SQL, rafraîchissantes. Ils se trouvent quelque part entre une vue et un pipeline de données complet.

Dans mes mots? Ils sont comme dire:

«Hey Snowflake, voici le SQL qui définit le résultat que je veux. Gardez-le frais pour moi.»

Et il écoute. De manière fiable.

Vous n’écrivez pas de logique pour les rafraîchissements. Vous ne planifiez pas les tâches. Vous déclarez simplement le résultat souhaité en utilisant SQL, et Snowflake s’occupe de l’orchestration.

Le cas d’utilisation qui m’a converti

J’avais un pipeline de réconciliation qui a rejoint les ordonnances transactionnelles avec des événements d’expédition d’entrepôt. L’idée était d’identifier les décalages – par exemple, les ordres marqués «livrés» qui n’avaient pas de scans d’expédition correspondants.

• Mon ancienne approche impliquait:
• Une requête complète à la casse dans une tâche SQL
• Un flux de suivi des inserts de commande
• Logique manuelle pour éviter de retraiter les vieilles rangées
• Réessayer les scripts lorsque les tâches ont échoué
• Enregistrement en qui je n’ai jamais tout à fait confiance
  C’était bien. Mais quand j’ai revisité la logique avec des tables dynamiques, j’ai réalisé que je pouvais tout couper à ceci:

Créer ou remplacer les Orders de table dynamique
Target_lag = ’15 minutes ‘
Warehouse = ‘analytics_wh’
COMME
SÉLECTIONNER
O.Order_id,
O.status as Order_Status,
S.Status as expédition_status,
CAS
Lorsque S.Status est nul, alors «expédition manquante»
Quand O.Status <> S.Status alors «décalage»
Sinon ‘ok’
Se terminer comme réconciliation_result,
Current_timestamp () en tant que processEd_at
De Raw.orders o
À gauche rejoindre Raw.shipments s
Sur o.order_id = s.order_id;

C’est ça.

• Pas de flux.
• Pas de tables de mise en scène intermédiaires.
• Pas de Dag à entretenir.
• Juste SQL + Snowflake = Magic.

Qu’est-ce qui m’a époustouflé

• Il est incrémentiel par défaut: Snowflake suit change dans les coulisses et les applique intelligemment – pas besoin de code CDC ou de filigranes.
• Vous pouvez enchaîner les tables dynamiques: une table dynamique en nourrit une autre, formant une structure en forme de Dag que les flocons de neige gère automatiquement.
• Observabilité intégrée: vous pouvez voir le décalage, l’historique de rafraîchissement, et plus encore – en neige.
• Sans couture entre lot et streaming: Besoin de mises à jour plus rapides? Il suffit de modifier le Target_lag.

Gotchas que je frappe (donc tu n’as pas à le faire)

Ce n’était pas tout le soleil. Quelques choses m’ont déclenché:

• Tout SQL n’est pas pris en charge – j’ai essayé d’utiliser une fonction non déterministe (rand () pour l’échantillonnage) et j’ai été rejeté. S’en tenir à la logique déterministe.
• Aucune logique procédurale – vous ne pouvez pas utiliser des procédures stockées ou une logique de ramification complexe. Mais c’est en quelque sorte le point – c’est déclaratif par conception.
• Le rafraîchissement n’est pas instantané – c’est automatique, pas immédiat. Si vous vous attendez à une fraîcheur inférieure à une seconde, ce n’est pas encore en streaming en temps réel.
• Pourtant, pour 99% de mes cas d’utilisation – en particulier les rapports, les pipelines par lots et les transformations en couches – les tables dynamiques l’ont écrasé.

Le résultat
Après le changement:

• Mon code de pipeline a diminué de ~ 60%.
• Les frais généraux opérationnels sont tombés à zéro (ne l’ont pas littéralement touché depuis des semaines).
• Les parties prenantes ont reçu des données plus fréquentes et précises.

Leçons apprises

• Si vous jonglez toujours avec des flux + tâches + DML, pensez à donner un coup de chance aux tables dynamiques.
• Ils ne sont pas pour tout, mais pour les pipelines de transformation des données, ils changent la donne.
• C’est SQL-premier, l’automatisation et le silence sur le plan opérationnel. Et c’est un beau combo.

Pensée finale

Les tables dynamiques ne simplifient pas seulement les pipelines de flocon de neige. Ils vous invitent à repenser ce qu’est un pipeline.

Donc, si vous êtes fatigué d’écrire du code de colle et de chasser les Dags cassés, il est peut-être temps de laisser Snowflake gérer l’orchestration pour vous – et de vous concentrer sur ce qui vous intéresse réellement: des données propres, précises et dignes de confiance.

Vous avez trouvé cela utile? PARTAGEZ-LE