CloudFlow Datastore ora parla SQL

Interrogare, rimodellare e gestire le tabelle Datastore con PostgreSQL, direttamente all'interno di un flow.

Le tabelle Datastore sono ottime per conservare informazioni tra un'esecuzione di un flow e l'altra: quali risorse sono già state elaborate, le soglie per ciascun account, quando è stato eseguito un job l'ultima volta. Ma nel momento in cui si voleva calcolare qualcosa a partire da quei dati, ci si scontrava con un muro. Get, Insert, Upsert e Delete possono recuperare e salvare righe, ma non sanno calcolare la media di una colonna, unire due tabelle o rispondere alla domanda "il valore di oggi è anomalo rispetto agli ultimi 30 giorni?". Quella logica finiva nei nodi Code o, più spesso, da nessuna parte.

Quella lacuna è ora colmata. Il nodo Datastore dispone di una nuova azione: Run SQL.

Cosa ottiene

Run SQL esegue un'istruzione con sintassi PostgreSQL completa sulle tabelle Datastore in CloudFlow. Le tabelle si referenziano per nome e i valori provenienti da step precedenti o da variabili del flow si collegano con parametri :name: una data calcolata da una trasformazione Date/time finisce così direttamente nella clausola WHERE. L'editor valida l'istruzione durante la digitazione e, nel caso di una SELECT, ricava lo schema di output all'istante, così i nodi a valle possono referenziare ogni colonna prima ancora che il flow venga eseguito.

E non si tratta solo di SELECT. L'azione copre INSERT, UPDATE e DELETE, oltre al DDL necessario per una tabella che si mantiene da sola: CREATE TABLE, aggiunta ed eliminazione di colonne e vincoli di unicità. Un flow ora può creare la propria tabella di storico, aggregarne i dati ed eliminare le righe più vecchie della finestra di retention, il tutto con tre brevi istruzioni. Le istruzioni vengono eseguite con un ruolo di database ristretto, limitato alle tabelle della Sua organizzazione, e quando si testa un'istruzione che modifica i dati, l'editor chiede conferma prima di toccare i dati reali.

Inizi dal tutorial

Abbiamo creato un esempio funzionante che sfrutta gran parte di queste funzionalità in un unico flow: il Cost spike sentinel. Ogni mattina registra in una tabella Datastore la spesa AWS del giorno precedente per servizio, poi una singola SELECT con una CTE confronta ogni servizio con la propria media mobile a 30 giorni e restituisce solo i servizi che superano la baseline di oltre il 50%. Un filtro e una notifica Slack lo trasformano in un avviso, e una DELETE mantiene la tabella a 90 giorni di storico. Nessun database esterno, nessun job di warehouse.

Il tutorial del Cost spike sentinel mostra passo dopo passo come costruirlo da zero, incluso l'SQL esatto.

Run SQL è disponibile da subito per tutti gli utenti con accesso a Datastore in CloudFlow. Se costruisce qualcosa con questa funzionalità, in particolare quel tipo di analisi tra esecuzioni diverse che prima richiedeva un database esterno, ce lo racconti. Il feedback migliore arriva da tabelle e query reali.