CloudFlow Datastore parle désormais SQL

Interrogez, transformez et maintenez vos tables Datastore en PostgreSQL, directement au sein d'un flow.

Les tables Datastore excellent à mémoriser des informations entre deux exécutions d'un flow : les ressources déjà traitées, les seuils par compte, la date de dernière exécution d'un job. Mais dès qu'il s'agissait d'effectuer un calcul sur ces données, on se heurtait à un mur. Get, Insert, Upsert et Delete permettent de lire et d'écrire des lignes, mais pas de calculer la moyenne d'une colonne, de joindre deux tables ou de répondre à la question le chiffre du jour est-il inhabituel par rapport aux 30 derniers jours ? Cette logique finissait dans des nodes Code ou, le plus souvent, nulle part.

Cette lacune est désormais comblée. Le node Datastore dispose d'une nouvelle action Run SQL.

Ce que vous y gagnez

Run SQL exécute une instruction PostgreSQL complète sur vos tables Datastore dans CloudFlow. Vous référencez les tables par leur nom et vous liez des valeurs issues d'étapes précédentes ou de variables de flow avec des paramètres :name : une date calculée par une transformation Date/time s'insère directement dans votre clause WHERE. L'éditeur valide l'instruction au fil de la saisie et, pour un SELECT, il déduit immédiatement le schéma de sortie, si bien que les nodes en aval peuvent référencer chaque colonne avant même la première exécution du flow.

Et il ne s'agit pas seulement de SELECT. L'action couvre INSERT, UPDATE et DELETE, ainsi que le DDL nécessaire à une table qui s'entretient d'elle-même : CREATE TABLE, l'ajout et la suppression de colonnes, et les contraintes d'unicité. Un flow peut désormais créer sa propre table d'historique, l'agréger et purger les lignes plus anciennes que sa fenêtre de rétention, le tout en trois petites instructions. Les instructions s'exécutent sous un rôle de base de données restreint, limité aux tables de votre organisation, et lorsque vous testez une instruction qui modifie des données, l'éditeur vous demande confirmation avant de toucher à des données réelles.

Commencez par le tutoriel

Nous avons construit un exemple concret qui exploite la plupart de ces fonctionnalités dans un seul flow : la sentinelle de pics de coûts (Cost spike sentinel). Chaque matin, elle enregistre les dépenses AWS de la veille par service dans une table Datastore, puis un seul SELECT avec une CTE compare chaque service à sa moyenne glissante sur 30 jours et ne renvoie que les services dépassant de plus de 50 % leur niveau de référence. Un filtre et une notification Slack transforment le tout en alerte, et un DELETE limite la table à 90 jours d'historique. Aucune base de données externe, aucun job de warehouse.

Le tutoriel Cost spike sentinel vous guide pas à pas dans sa construction, avec le SQL exact.

Run SQL est disponible dès maintenant pour tous les utilisateurs ayant accès à Datastore dans CloudFlow. Si vous construisez quelque chose avec, en particulier ce type d'analyse inter-exécutions qui nécessitait auparavant une base de données externe, faites-le-nous savoir. Les meilleurs retours viennent de tables et de requêtes réelles.