Novità di Snowflake: estate 2025

Nuova sidebar (Preview, in fase di rilascio)

Snowflake sta rilasciando una nuova barra di navigazione laterale sinistra completamente riorganizzata. Alcuni account ce l'hanno già, altri verranno aggiornati a fasi. Da quel che vedo, ormai la maggior parte degli account è stata migrata. I gruppi di menu sono più ordinati e rispecchiano meglio il modo in cui lavorano i team. Personalmente ci ho messo un po' ad abituarmi: per qualche secondo non trovavo "databases" e "query history", ma nel complesso il nuovo layout mi piace molto!

Layout:

• Shortcuts: permette di fissare fino a tre pagine per un accesso rapido. Si possono trascinare per riordinarle.
• Work with data: Projects, Ingestion, Transformation (dbt, Task History, Dynamic Tables), AI & ML, Monitoring (qui trova la query history e anche la vista GUI della event table), Marketplace.
• Horizon Catalog: Catalog (qui ci sono i database!), Data sharing, Governance & security.
• Manage: Compute e Admin.

Ecco come fissare e rimuovere gli shortcut:

Questo screenshot, tratto dalla documentazione Snowflake, mostra a confronto la nuova e la vecchia sidebar.

A proposito, se non ha ancora provato la nuova ricerca globale, le consigliamo di farlo: cerca tra database, marketplace, documentazione e praticamente qualsiasi cosa in Snowflake per individuare le parole chiave. L'ho trovata utilissima per individuare velocemente ciò che mi serve.

Creare una Semantic View con Snowsight (Public Preview)

È possibile creare e gestire le Semantic View direttamente da Snowsight, tramite l'object explorer del database o dalla pagina Cortex Analyst. Si può usare la procedura guidata oppure caricare un file YAML.

• Punti di partenza:
  • Sidebar vecchia: Data → Databases → seleziona uno schema → Create → Semantic View, oppure AI & ML → Cortex Analyst → Create / Upload YAML.
  • Sidebar nuova: Horizon Catalog → Catalog → Database → seleziona uno schema → create, Semantic View
  • Oppure da AI & ML → Cortex Analyst

Creare una nuova Semantic View è risultato davvero semplice. Gli screenshot qui sotto illustrano la procedura.

Passaggio 1: si porti su uno schema e clicchi su "Create". L'immagine qui sotto mostra la nuova sidebar: database e schema si trovano ora in "Horizon Catalog".

Passaggio 2: compili le pagine del modulo

Ecco come ottenere lo stesso risultato dal menu Cortex Analyst:

Nota: anche l'interrogazione delle semantic view tramite SQL è in Preview. Per approfondire, consulti la documentazione.

Dynamic Tables: lettura da Iceberg gestite esternamente (GA)

Le dynamic table possono ora leggere direttamente da tabelle Iceberg gestite da un catalogo esterno. È un miglioramento importante per le funzionalità di data pipeline di Snowflake, soprattutto per chi utilizza Iceberg. Tutti i dettagli sono nella documentazione.

Tipi strutturati per le tabelle standard (GA)

Altre piattaforme dati come BigQuery e Databricks offrono da tempo tipi di dati strutturati (struct, array, record), mentre Snowflake metteva a disposizione solo il tipo variant per coprire questi casi d'uso.

Ora è possibile definire ARRAY, OBJECT e MAP come colonne strutturate nelle normali tabelle Snowflake, con un massimo di 1.000 sotto-colonne per colonna. Al momento i tipi strutturati non sono supportati su dynamic table, hybrid table o tabelle esterne. Per i dettagli, consulti la documentazione.

Pre-clustering per Snowpipe Streaming (Preview)

Snowpipe Streaming può effettuare il pre-clustering delle righe già in fase di ingest, in modo che i dati arrivino ordinati secondo le chiavi di clustering. Questo migliora le prestazioni delle query sulle tabelle più sollecitate e riduce il carico sull'automatic clustering. Non l'abbiamo ancora testato, ma sarà con ogni probabilità una leva di risparmio per i clienti con costi elevati di automatic clustering.

Per abilitare il pre-clustering, aggiunga CLUSTER_AT_INGEST_TIME=TRUE alla definizione di COPY; la tabella di destinazione deve già avere chiavi di cluster.

CREATE OR REPLACE PIPE TEST_PRECLUSTERED_PIPE
AS
    COPY INTO TEST_PRECLUSTERED_TABLE (num) FROM (
            SELECT $1:num::number as num FROM TABLE(
                DATA_SOURCE(
                    TYPE => 'STREAMING')
        ))
        CLUSTER_AT_INGEST_TIME=TRUE;

Comando COPY FILES (GA)

COPY FILES sposta gli oggetti da uno stage all'altro. Un caso d'uso concreto è spostare i file da una cartella "unprocessed" a una "processed".

In questo scenario può impostare delle bucket policy (al di fuori di Snowflake) per assicurarsi che la cartella unprocessed venga ripulita dopo un certo periodo, senza dover scrivere codice aggiuntivo per gestire il ciclo di vita dei dati.

Ad esempio, potrebbe definire una policy che elimini i dati da unprocessed dopo 30 giorni, mentre quella sui dati processed potrebbe archiviarli su Glacier dopo 60 giorni. Una strategia di questo tipo riduce la duplicazione dei dati e i costi di storage al di fuori di Snowflake.

Eseguire i task come un altro utente: EXECUTE AS USER + IMPERSONATE (GA)

I task possono essere eseguiti con i privilegi di un utente specifico tramite EXECUTE AS USER, a condizione che il ruolo proprietario del task abbia il privilegio IMPERSONATE su quell'utente. È utile quando le policy o i sistemi a valle dipendono dall'identità dell'utente per aspetti come row access o masking, e rende molto più facile capire per conto di chi un task abbia effettivamente agito quando si rivedono i log.

Di seguito un esempio semplificato per illustrare la nuova funzionalità. L'esempio presuppone che utenti e ruoli esistano già. Per un esempio completo, comprensivo di creazione di utenti, ruoli, warehouse, grant sui task ecc., consulti la documentazione Snowflake.

-- grant impersonate.  Nuova funzionalità!
GRANT IMPERSONATE ON USER task_user TO ROLE task_role;

USE ROLE task_owner;

-- esegui il task come un altro utente
CREATE TASK team_task
  SCHEDULE='12 HOURS'
  EXECUTE AS USER task_user
  AS SELECT 1;

Il nuovo pricing di Snowpipe annunciato al Summit: ora GA per Business Critical e VPS

Nel nostro Summit Recap avevamo già anticipato che il nuovo modello di pricing di Snowpipe sarebbe stato un vantaggio per i clienti. Il vecchio modello aveva due componenti: per secondo per core e per ogni 1000 file. Il nuovo è semplificato: un importo fisso di credit per GB ingerito.

Si è passati dal concept alla GA per i clienti Business Critical e VPS, e a breve sarà disponibile anche per i clienti Standard ed Enterprise.

Per capire tutti i dettagli, le consigliamo di consultare la credit consumption table e la documentazione sui costi di Snowpipe.

Snowpark Connect for Spark e Snowpark Submit (Preview)

In poche parole, è ora possibile eseguire job Apache Spark direttamente in Snowflake senza riscrivere una riga di codice. Sono inclusi Spark DataFrame, SQL e UDF. Si possono inoltre inviare job non interattivi in modo asincrono tramite Snowpark Submit.

Queste funzionalità rappresentano un ponte pragmatico per le organizzazioni che usano Spark e stanno migrando verso Snowflake senza voler riscrivere il codice Spark nelle API Snowpark.

Lo sviluppo può avvenire con strumenti familiari come Jupyter Notebook o Snowflake Notebook. Per saperne di più, consulti la documentazione.

UDF Snowflake Scripting (GA)

È ora possibile usare la logica di Snowflake Scripting nelle UDF SQL e richiamarle inline dalle query, e non solo tramite CALL come per le stored procedure. È un'ottima soluzione per piccoli helper procedurali o funzioni SQL personalizzate da riutilizzare nelle istruzioni SELECT/INSERT.

Snowflake Scripting è un linguaggio di scripting SQL molto potente. Tutti i dettagli sulla nuova funzionalità UDF si trovano qui.

Vale la pena segnalare che la funzionalità non supporta i cursori (declare … c1 cursor for select foo from bar). Questa limitazione è probabilmente un bene per gli utenti, perché una logica riga per riga come quella dei cursori è una pessima idea all'interno di funzioni SQL.

Dynamic table: UNION nei refresh incrementali (GA)

Man mano che i clienti continuano ad adottare le funzionalità native di data pipeline di Snowflake, Snowflake colma una lacuna evidente e fastidiosa: le dynamic table incrementali supportano ora UNION (distinct) nelle query di refresh, ampliando le tipologie di merge multi-sorgente eseguibili senza dover ripiegare sul full refresh. Gli altri operatori insiemistici (ad esempio minus, except, intersect) restano non supportati in modalità incrementale.

CREATE DYNAMIC TABLE my_dynamic_table
 TARGET_LAG = DOWNSTREAM
 AS
 SELECT * from foo
 -- non serve più union all
 union
 select * from bar;

Un consiglio per chi è alle prime armi con SQL: è considerata best practice preferire union all a union, perché union impone un distinct, rallentando l'esecuzione della query. Quindi utilizzi questa nuova funzionalità solo se ha realmente bisogno di un risultato distinct.

Ad oggi la documentazione Snowflake non è ancora stata aggiornata per includere il supporto dell'operatore union, ma di fatto la funzionalità è stata rilasciata. 🧐

Eventi di monitoring per Snowpipe ed eventi di auto-refresh Iceberg (GA)

Snowpipe pubblica ora eventi di ingestion dettagliati nella Event Table attiva. Può vedere quando una pipe cambia stato, tracciare l'avanzamento per ciascun file e consultare riepiloghi periodici dell'attività di ingestion. Inoltre, Snowflake emette eventi anche ogni volta che una tabella Iceberg gestita esternamente viene aggiornata automaticamente.

Il risultato è la possibilità di osservare l'intero ciclo di vita dell'ingestion, dai file in stage che arrivano in Snowpipe fino alle tabelle Iceberg a valle mantenute aggiornate, tutto in un unico posto. Si colma così una lacuna di visibilità che si trascinava da tempo. In pratica, diventa molto più semplice diagnosticare file bloccati o refresh in ritardo, e si apre la strada a un alerting più puntuale sugli SLA delle data pipeline. La considero una di quelle funzionalità di "quality of life" che a prima vista non sembrano sensazionali, ma che i team con pipeline di ingestion in produzione apprezzeranno fin da subito.

Qui trova altre informazioni sulla funzionalità.

Impostare una dimensione target dei file per le tabelle Iceberg (Preview)

È ora possibile definire una dimensione target per i file Parquet quando si crea o si modifica una tabella Iceberg. Questo offre un controllo maggiore sulla scrittura dei dati e può migliorare le prestazioni quando i file vengono letti da motori come Spark o Trino.

È particolarmente utile in configurazioni multi-engine, dove la dimensione dei file può fare la differenza sull'efficienza delle query. File più piccoli sono adatti a query rapide e granulari, mentre file più grandi riducono l'overhead nelle scansioni estese. Lo vedo come un passo concreto che rende Snowflake più flessibile in scenari ibridi di tipo lakehouse.

Ecco un esempio di come creare o modificare una tabella Iceberg sfruttando questa nuova funzionalità:

CREATE ICEBERG TABLE my_iceberg_table (
  amount INT,
  name STRING
)
  CATALOG = 'SNOWFLAKE'
  EXTERNAL_VOLUME = 'my_external_volume'
  BASE_LOCATION = 'my_iceberg_table'
  TARGET_FILE_SIZE = '64MB'; -- NUOVO!

ALTER ICEBERG TABLE my_iceberg_table
SET TARGET_FILE_SIZE = '128MB';

ALTER LISTING: aggiunta e rimozione dei target semplificate (GA)

I provider del Marketplace possono ora aggiungere o rimuovere i target di un listing tramite un manifest parziale, senza dover reinviare l'intero set di target. Si riduce così la complessità dell'automazione quando si gestiscono molti account, ruoli o organizzazioni.

Fact e metriche private nelle semantic view (General Availability)

È possibile contrassegnare fact e metriche come PRIVATE in fase di definizione di una semantic view. Gli elementi privati sono utilizzabili nei calcoli interni alla vista, ma non possono essere interrogati direttamente né usati nei filtri. Continuano comunque a comparire in DESCRIBE SEMANTIC VIEW e GET_DDL, il che è utile per la discoverability e per gli audit. Torna comodo quando si vogliono esporre metriche pulite e pronte per il business mantenendo nascosti fact ausiliari e metriche intermedie. La mia opinione: è una mancanza di cui non mi ero mai accorto, ma rende le semantic view molto più adatte all'uso in produzione per analytics governate.

CREATE SEMANTIC VIEW my_sales_view
  TABLES (
    orders AS my_db.my_schema.orders PRIMARY KEY (order_id)
  )
  FACTS (
	  -- Nuova funzionalità
    PRIVATE adjustment_factor AS AVG(orders.adjustment)
  )
  METRICS (
    total_revenue AS SUM(orders.revenue),
    -- Nuova funzionalità
    PRIVATE adjusted_revenue AS SUM(orders.revenue + adjustment_factor)
  );

Funzione AI_EXTRACT (Preview)

AI_EXTRACT estrae campi strutturati da input non strutturati. Funziona su stringhe o input di tipo FILE, e il formato della risposta si definisce con semplici prompt o coppie nome-prompt. Pensi a fatture, contratti, note cliniche o PDF di marketing: tutto estratto direttamente all'interno di Snowflake. Il risultato è un numero ridotto di round trip verso servizi esterni e un percorso più semplice per arrivare a dati strutturati e già pronti. È una funzionalità promettente per i team che hanno già centralizzato i dati in Snowflake, ma la tratti come qualsiasi funzionalità AI in preview. Il mio approccio è quello di partire da un set di test etichettato per valutarne le prestazioni. E pensi bene ai guardrail da aggiungere prima di integrarla in pipeline critiche!

Esempi:

-- Sintassi:
AI_EXTRACT( <text>, <responseFormat> )

-- esempio che specifica un output strutturato
AI_EXTRACT( <'sql column containing unstructured text'>,
['address': 'City, street, ZIP', 'name': 'First and last name'] )

-- altro esempio in cui l'output è in linguaggio naturale
-- qui estraiamo da un file invece che da una colonna
AI_EXTRACT( <'a pdf file in Snowflake Stage'>,
['give me address and first and last name' );\
```\
\
### Modalità layout di AI Parse Document (GA)\
\
La modalità layout di [`AI_PARSE_DOCUMENT`](https://docs.snowflake.com/en/user-guide/snowflake-cortex/parse-document#ai-parse-document) è una nuova funzionalità GA che sostituisce la funzione `SNOWFLAKE.CORTEX.PARSE_DOCUMENT`. Estrae il layout di un documento in Markdown preservando il flusso del testo, le tabelle e la struttura. Detto in modo semplice: da PDF (o simili) a Markdown! 🥳 Si ottiene così una forma intermedia pulita per chunking, RAG o parsing a valle. Questo parsing layout-aware sembra essere la base per una document AI davvero affidabile. Posso anche immaginare di combinarla con `AI_EXTRACT` per passare dai file grezzi a righe strutturate in pochi passaggi.\
\

\

Elaborazione distribuita in Snowflake ML: Many Model Training e Distributed Partition Function (General Availability)\

Snowflake ML supporta ora due pattern distribuiti. Many Model Training (MMT) addestra modelli separati per ogni partizione di un Snowpark DataFrame in parallelo. Distributed Partition Function (DPF) esegue la sua funzione Python su più partizioni distribuite su uno o più nodi di un compute pool, gestendo automaticamente lo storage degli artefatti e il tracciamento dell'avanzamento. Si elimina così buona parte del lavoro di orchestrazione, scalando direttamente sulla piattaforma che già utilizza.

Se vuole approfondire, Train models across data partitions e Process data with custom logic across partitions sono documentati in modo molto dettagliato.
\

\

Data Metric Function: ACCEPTED_VALUES (GA)\

ACCEPTED_VALUES è una DMF di sistema che verifica se i valori di una colonna soddisfano un'espressione booleana e restituisce il numero di righe che non la soddisfano. La può associare a una tabella o vista secondo una pianificazione, oppure eseguirla on demand con SYSTEM$DATA_METRIC_SCAN.

È un modo a basso sforzo e ad alto valore per intercettare semplici problemi di conformità, come enum e set di codici, senza dover scrivere SQL personalizzato.
\

1-- sintassi\
\
2SNOWFLAKE.CORE.ACCEPTED_VALUES ON ( <column>, <lambda-expression> )\
\
3\
\
4-- esempio\
\
5ALTER TABLE orders\
\
6  ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.ACCEPTED_VALUES\
\
7    ON (\
\
8      order_status,\
\
9      order_status -> order_status IN ('Pending', 'Shipped', 'Delivered', 'Returned')\
\
10    );\
\
11\
\
12 CALL SYSTEM$DATA_METRIC_SCAN('orders');\
\
13 -- restituisce tutte le DMF associate alla tabella orders\
```\
\
### Aggiornamenti su Snowflake Data Clean Room (GA)\
\
Una data clean room è un ambiente sicuro in cui più parti possono analizzare insieme dataset combinati senza accedere direttamente ai record grezzi degli altri partecipanti. Avviene tramite controlli rigorosi sulle query e policy che consentono solo output approvati, come aggregati o risultati anonimizzati, e mai dati a livello di riga.\
\
Il mese scorso Snowflake ha rilasciato 4 aggiornamenti per le data clean room. Sono sostanzialmente migliorie di quality of life che riducono gli attriti nell'utilizzo delle clean room.\
\
- **Flusso semplificato per la condivisione cross-region**: i provider non devono più chiamare sia `request_laf_cleanroom_requests` sia `mount_laf_cleanroom_requests_share` per accettare le richieste dei consumer di un'altra region. Ora basta usare `provider.mount_request_logs_for_all_consumers`. Lo si vede nella [developer guide](https://docs.snowflake.com/en/user-guide/cleanrooms/activation?utm_source=chatgpt.com), nella sezione "Implementing activation in your clean room".\
- **Installazione semplificata**: Snowflake crea ora automaticamente, e verifica, il service user necessario per le clean room, oppure riutilizza uno già esistente, invece di lasciarlo fare manualmente all'utente. Significa meno passaggi di setup prima di poter iniziare effettivamente a usare le clean room.\
- **Test su singolo account**: si può ora usare un singolo account Snowflake per agire sia da provider sia da consumer all'interno di una clean room di test. È un'ottima soluzione per ambienti di dev/test, perché consente di costruire e validare i template di clean room senza dover allestire account separati. La pagina tutorial & samples lo mostra in azione ("[Basic UI tutorial, single account](https://docs.snowflake.com/en/user-guide/cleanrooms/tutorials-and-samples?utm_source=chatgpt.com)"). Consulti la [documentazione](https://docs.snowflake.com/en/user-guide/cleanrooms/developer-introduction#label-dcr-self-share-for-developers) per una lettura più rapida.\
- **Frequenze di refresh configurabili per Cross-Cloud Auto-Fulfillment**: per impostazione predefinita, il refresh dei dati tra account provider e account consumer in cloud o region differenti avviene ora ogni 30 minuti (rispetto alle precedenti 24 ore). E può configurare la frequenza a piacere. [Consulti la documentazione](https://docs.snowflake.com/en/user-guide/cleanrooms/provider.html#dcr-provider-set-laf-dcr-refresh-schedule).\
\
### Snapshot Write Once, Read Many (WORM) (Preview)\
\
Gli [Snapshot](https://docs.snowflake.com/en/user-guide/snapshots) WORM sono backup **immutabili** point-in-time di tabelle, schemi o database. Si basano su snapshot set e su snapshot policy opzionali per pianificazione e scadenza. **Retention lock** e **legal hold** aggiungono protezione contro l'eliminazione, con il retention lock pensato per offrire solide garanzie di compliance. Nemmeno l'accountadmin può eliminare queste tabelle: una difesa robusta contro credenziali compromesse e ransomware. Gli Snapshot WORM sono disponibili in tutte le edizioni, mentre retention lock e legal hold sono riservati a Business Critical e superiori.\
\
È un controllo concreto per la resilienza al ransomware e per la retention regolamentare, che va oltre Time Travel. La funzionalità è promettente per l'igiene dei backup, ma è ancora in preview: quindi testi i percorsi di restore e pianifichi lo storage prima di affidarsi al retention lock.\
\

\

Org profile (General Availability)\

È ora possibile creare e gestire gli organization profile in Snowsight, assegnare quali account e ruoli possono pubblicare con un profilo e brandizzare i listing interni con un avatar e un URL di riferimento. Ciò rafforza la fiducia all'interno dell'Internal Marketplace ed elimina molto SQL una tantum per il setup. Le grandi organizzazioni risultano più ordinate e i consumer hanno una provenance più chiara dei prodotti dati interni.

\

Attivazione self-service di Tri-Secret Secure (General Availability)\

Come ripasso dalla sua formazione Snowflake, Tri-Secret Secure è l'approccio di Snowflake alla cifratura che coinvolge tre chiavi: la chiave di Snowflake, la chiave del cloud provider e una chiave gestita dal cliente. I dati possono essere decifrati solo se tutte e tre sono disponibili, dando così ai clienti il controllo diretto per sospendere l'accesso disabilitando la propria chiave. È disponibile per Business Critical e VPS.

Grazie alla nuova funzionalità di Self Service Activation, gli ACCOUNTADMIN possono attivare Tri-Secret Secure in autonomia tramite funzioni di sistema, gestire la chiave gestita dal cliente e disattivarla se necessario. Si riduce così il ricorso al supporto e controlli di cifratura robusti diventano parte dell'igiene standard di un account, anziché un progetto a sé che richiede il customer support.
\

Query Insights: prestazioni dei join e ottimizzazione (Public Preview)\

Contesto:

Query Insights è una funzionalità integrata relativamente nuova che mette in evidenza automaticamente osservazioni sulle sue query, come join inefficienti o filtri mancanti. Invece di analizzare i profili grezzi, riceve suggerimenti leggibili che indicano gli interventi utili per migliorare le prestazioni e ridurre i costi.

Gli insight si trovano in Snowsight Query History → Query Profile, oppure interrogando la vista snowflake.account_usage.query_insights. Uno strumento di terze parti come SELECT offre una observability molto più ricca sui query insight, con una UI pensata appositamente.


Nuova funzionalità:

Query Insights aggiunge nuove osservazioni su errori di join e opportunità di ottimizzazione, consultabili in Snowsight o interrogando la vista QUERY_INSIGHTS. I suggerimenti segnalano pattern come condizioni di join mancanti, exploding join, mancanza di filtri, utilizzo della search optimization e spillage, per individuare più rapidamente la causa principale. È utilissimo per il triage, anche se per le analisi più approfondite continuerà a fare affidamento su Query Profile.
\

Semantic view: elencare dimensioni e metriche a qualsiasi livello (GA)\

Può fare l'inventario del suo semantic layer con SHOW SEMANTIC DIMENSIONS e SHOW SEMANTIC METRICS a qualsiasi livello: view, schema, database o account, ed elencare anche quali dimensioni sono valide per una metrica specifica. Aiuta a fare audit dei modelli, verificare grain e relazioni e tenere i team allineati su ciò che è davvero disponibile. È una piccola funzionalità, ma davvero comoda per chi ricopre ruoli di amministrazione e si appoggia ai comandi show per ragionare sulla governance.
\

Ecco una rapida carrellata di altri aggiornamenti che vale la pena segnalare:
\

• Multi-Node ML jobs - Preview\
• Create Index supporta "Include Columns" - GA\
• Consistency Secret ora opzionale in generate_synthetic_data - GA\
• Querying Semantic Views da Preview a GA\
• La funzione SEARCH_IP supporta la ricerca di indirizzi IPv6 - GA\
• Le email del Trust Center passano da Preview a GA Nuovo Stage Volume per Snowpark Container Services - Preview\
• Connector Microsoft Power Apps - GA
  \

Wow, davvero un sacco di funzionalità in due mesi! Ci faccia sapere se ha bisogno di un confronto su una qualsiasi di queste.



Jeff è un Data and Analytics Consultant con oltre 15 anni di esperienza nell'automazione degli insight e nell'utilizzo dei dati per governare i processi di business. Sul piano tecnologico è specializzato in Snowflake + dbt + Tableau. Sul piano dei settori, ha esperienza in Public Utility, Clinical Trials, Publishing, CPG e Manufacturing. Può contattarlo in qualsiasi momento all'indirizzo [email protected].\