Dal 5 ottobre 2026, Amazon Redshift permette di creare viste materializzate basate su Apache Iceberg, rendendo i risultati di join e aggregazioni pesanti accessibili a qualsiasi motore compatibile con Iceberg via AWS Glue.
Annunciata il 5 ottobre 2026, l'integrazione di Apache Iceberg nelle viste materializzate di Amazon Redshift segna un passaggio fondamentale verso l'architettura open lakehouse. Tradizionalmente, le viste materializzate di Redshift memorizzavano i dati internamente nel Redshift Managed Storage (RMS), limitandone l'accesso esclusivamente al cluster che le aveva create. Con l'introduzione della clausola USING ICEBERG, i risultati di query complesse, come join costosi e aggregazioni, vengono ora scritti come tabelle Iceberg standard in Amazon S3 o in Amazon S3 Table Buckets e registrati nell'AWS Glue Data Catalog. [1][2][4]
Questa novità risolve un problema critico per i team di dati che operano in ambienti multi-motore. In precedenza, per condividere un set di dati pre-aggregato tra Redshift, Apache Spark e Amazon Athena, era necessario orchestrare pipeline di ETL complesse per esportare i dati, introducendo latenze e potenziali discrepanze semantiche tra i diversi motori di calcolo. Ora, Redshift funge da motore di ottimizzazione che materializza il dato una sola volta in un formato aperto, permettendo a tutti i consumatori a valle di leggere lo stesso risultato senza necessità di copie o conversioni manuali. [1][4]
Il funzionamento tecnico si basa sulla combinazione delle capacità di ottimizzazione di Redshift e della flessibilità di Iceberg. Quando viene creata una vista materializzata Iceberg, Redshift esegue la query definita e scrive i risultati come file Parquet su S3, registrando contemporaneamente i metadati in AWS Glue. Questo rende la vista immediatamente scopribile e interrogabile da qualsiasi motore compatibile con Iceberg, tra cui Amazon Athena, Apache Spark su Amazon EMR, AWS Glue e motori terzi come Trino o Snowflake, che possono trattarla come una normale tabella Iceberg senza configurazioni aggiuntive. [1][2]
Un aspetto cruciale è la gestione della concorrenza e della manutenzione. Redshift utilizza il controllo della concorrenza ottimistica (OCC) tramite il meccanismo di aggiornamento condizionale di AWS Glue per gestire i tentativi di refresh simultanei da parte di più cluster o workgroup, assicurando che solo un'operazione abbia successo. Per quanto riguarda l'ottimizzazione dei file, se i dati sono archiviati in Amazon S3 Table Buckets, la compattazione e l'ottimizzazione dei file avvengono automaticamente; se invece si utilizzano bucket S3 generici, l'utente deve gestire manualmente la compattazione tramite strumenti esterni come Apache Spark per evitare il degrado delle prestazioni dovuto alla proliferazione di piccoli file. [2]
Processo di materializzazione e interoperabilità tra motori
Il sistema supporta il refresh incrementale, un'operazione che identifica solo i cambiamenti avvenuti nelle tabelle sorgente dall'ultimo aggiornamento, applicando esclusivamente tali modifiche alla vista. Questo processo è supportato per query che utilizzano clausole SELECT con WHERE, GROUP BY con funzioni aggregate COUNT e SUM, e join interni tra tabelle Iceberg. Se queste condizioni non sono soddisfatte, o se gli snapshot della sorgente sono scaduti o i dati sono stati modificati esternamente a Redshift, il sistema esegue automaticamente un full refresh, ricalcolando l'intero set di dati. [2]
È importante notare che, a differenza delle viste materializzate standard, quelle Iceberg non supportano l'aggiornamento automatico (AUTO REFRESH); l'operazione deve essere attivata manualmente. Inoltre, mentre Redshift può creare e aggiornare queste viste, l'interoperabilità è a senso unico per quanto riguarda la gestione: se una vista Iceberg è stata creata da un altro motore (come Spark), Redshift può interrogarla in modalità sola lettura, ma non può eseguire il refresh o l'eliminazione della stessa, operazioni riservate esclusivamente al motore che ha creato la vista. [2][3]
L'implementazione di viste materializzate Iceberg richiede il rispetto di vincoli rigorosi. Le tabelle sorgente devono essere obbligatoriamente in formato Apache Iceberg (versione 2 o inferiore) e trovarsi nella stessa regione AWS e nello stesso account della vista. Non sono supportate tabelle native di Redshift, tabelle Hive o Parquet esterne come sorgenti. Inoltre, tutti gli identificativi (nomi di tabelle e colonne) devono essere scritti in minuscolo, poiché l'AWS Glue Data Catalog non supporta identificatori case-sensitive; se il parametro enable_case_sensitive_identifier è attivo, deve essere disabilitato per la sessione. [2][3]
Esistono diverse restrizioni SQL e di configurazione: non sono ammesse funzioni definite dall'utente (UDF), funzioni mutabili, né l'uso di clausole come DISTSTYLE, DISTKEY o SORTKEY. Le tabelle filtrate tramite AWS Lake Formation (FGAC) non possono essere utilizzate come sorgenti. Per quanto riguarda la sicurezza, l'accesso può essere gestito tramite ruoli IAM o AWS Lake Formation, sebbene quest'ultimo supporti solo controlli a livello di database e tabella, senza possibilità di applicare filtri a righe o colonne sulle viste materializzate Iceberg. [3][4]
Immaginiamo un'azienda che analizza i dati di vendita globali. Attualmente, ogni team (Marketing, Finance, Operations) esegue quotidianamente una query di aggregazione simile su una tabella Iceberg di 10 TB per ottenere le vendite per regione. Questo comporta costi di scansione elevati in Athena e Spark e tempi di attesa ridondanti. La scelta strategica sarebbe creare una vista materializzata Iceberg in Redshift utilizzando un comando come: CREATE MATERIALIZED VIEW bucket@s3tablescatalog.analytics.sales_by_region USING ICEBERG PARTITIONED BY (region) AS SELECT region, count(*) as order_count FROM source_table. Questo sposta il carico computazionale su un unico refresh gestito da Redshift. [3]
Per valutare se questa soluzione è preferibile a una tabella nativa RMS, l'utente deve considerare chi consumerà i dati. Se l'accesso è limitato a dashboard ad alte prestazioni all'interno di Redshift, le viste RMS rimangono la scelta migliore per latenza. Tuttavia, se l'obiettivo è permettere a un data scientist di usare PyIceberg o a un analista di usare Athena senza duplicare i dati, la vista Iceberg è l'unica opzione percorribile. La verifica del successo dell'implementazione consiste nel monitorare la riduzione dei costi di scansione in Athena e nel confermare che i risultati siano identici tra i diversi motori, eliminando le discrepanze semantiche precedentemente riscontrate. [1][2][4]
La funzionalità è disponibile per Redshift Serverless e per i cluster provisionati con istanze Graviton in tutte le regioni supportate. La decisione di adottare le viste Iceberg rispetto a quelle standard dovrebbe basarsi sulla necessità di interoperabilità: se il dato pre-computato deve essere letto da motori esterni senza l'overhead di un processo di esportazione, Iceberg è la scelta corretta. Al contrario, per dashboard estremamente sensibili alle prestazioni che girano esclusivamente su Redshift, è possibile caricare queste tabelle in Redshift Managed Storage (RMS) per massimizzare la velocità di risposta. [1][2]
In termini di costi, l'adozione di questo modello può ridurre significativamente le spese operative. In uno scenario esemplificativo con aggregazioni medie, il passaggio da calcoli silos in più motori a un unico refresh in Redshift potrebbe abbattere i costi mensili da circa 7.500 USD a 1.500 USD, grazie all'eliminazione delle scansioni ridondanti su Athena e Spark. Tuttavia, l'utente deve considerare che l'eliminazione della vista tramite comando DROP rimuove solo l'entry nel catalogo Glue, mentre i dati fisici su S3 devono essere cancellati manualmente per evitare costi di storage residui. [4]
Apple introduce nuovi asset visivi per header di pagina e risultati di ricerca, insieme all'Asset Library e a un tool di anteprima in App Store Connect per migliorare la visibilità di app e giochi.
Dal 5 ottobre 2026, Amazon EC2 permette ai proprietari di AMI di condividere tag specifici con altri account AWS tramite il prefisso ec2:SharedTag/, eliminando la necessità di workflow di replica manuale.
Analisi dell'aggiornamento SmartThings del 6 ottobre 2026: l'introduzione di SmartThings Now per l'interfaccia, l'evoluzione del controllo locale per ridurre la latenza e l'estensione del supporto Matter 1.6.
Parliamone
Hai un’esperienza da condividere o una domanda? Scrivi un commento pertinente, senza pubblicità o link.