AWS accelera Spark con Iceberg e spinge CloudSearch verso OpenSearch Serverless

☁️ Punti chiave

• AWS usa viste materializzate Apache Iceberg e query rewrite automatico per accelerare workload Spark analitici senza modificare le query SQL esistenti.
• I risultati precomputati restano tabelle Iceberg leggibili da Athena, EMR, Glue, Redshift e motori compatibili, con refresh pianificabile.
• Per CloudSearch AWS indica OpenSearch Serverless come destinazione moderna, ma la migrazione richiede conversione di schema, documenti, query e policy di sicurezza.

Amazon Web Services interviene su due colli di bottiglia differenti dello stack dati enterprise: il costo delle interrogazioni analitiche sui data lake e la modernizzazione delle applicazioni di ricerca ancora basate su Amazon CloudSearch. Nel primo caso AWS mostra come utilizzare viste materializzate Apache Iceberg insieme al query rewrite automatico di Apache Spark per evitare di rieseguire continuamente join e aggregazioni costose. Nel secondo definisce un percorso operativo verso Amazon OpenSearch Serverless, che sostituisce il modello più rigido di CloudSearch con ricerca semantica e ibrida, capacità vector e scalabilità serverless. I due interventi seguono la stessa logica: spostare maggiore complessità dall’applicazione verso servizi dati gestiti.

Le viste materializzate Iceberg riducono il lavoro ripetitivo di Spark

Il primo intervento riguarda workload nei quali Apache Spark esegue ripetutamente query analitiche complesse su grandi quantità di dati: join tra più tabelle, aggregazioni, filtri e window function possono richiedere scansioni e calcoli significativi anche quando una parte rilevante del risultato è sostanzialmente già nota. Nella guida tecnica pubblicata da AWS sulle viste materializzate Iceberg, il risultato della vista viene precomputato e conservato attraverso AWS Glue Data Catalog come una normale tabella Apache Iceberg all’interno di Amazon S3 o S3 Tables. Il passaggio più interessante è il query rewrite automatico: quando l’ottimizzatore riconosce che una query può essere soddisfatta utilizzando una vista materializzata già disponibile, sostituisce automaticamente parte del piano originale senza obbligare a modificare il codice SQL dell’applicazione. La caratteristica è particolarmente utile per dashboard BI, applicazioni ISV e report legacy nei quali riscrivere centinaia di query comporterebbe rischi e costi superiori al vantaggio prestazionale.

Il modello approfondisce la direzione già seguita con AWS Glue 6.0, Spark 4.1 e il supporto completo ad Apache Iceberg v3, dove il formato aperto è diventato progressivamente il punto di incontro tra storage, catalogo e motori analitici differenti. La vista materializzata non produce infatti un artefatto proprietario utilizzabile soltanto dal runtime che l’ha generata: i dati precomputati restano una tabella Iceberg interrogabile da motori compatibili come Amazon Athena, Amazon EMR, AWS Glue e Amazon Redshift, oltre alle piattaforme esterne capaci di leggere il formato. L’automazione completa del rewrite resta invece legata al runtime Spark ottimizzato da AWS disponibile nei servizi che la supportano.

Il query rewrite evita di cambiare SQL ma introduce un costo di ottimizzazione

Il vantaggio principale consiste nella possibilità di accelerare applicazioni esistenti senza modificare le query originali. L’amministratore definisce una vista a partire da una query che può comprendere join, filtri o aggregazioni; il risultato viene materializzato e può essere aggiornato attraverso una pianificazione configurabile. Quando successivamente arriva una query compatibile, l’optimizer verifica se il risultato precomputato può sostituire una parte del piano originale. In pratica, invece di rileggere una grande tabella e ricostruire ogni volta la stessa aggregazione, Spark può partire da un dataset molto più piccolo già elaborato.

AWS segnala però che il meccanismo non costituisce un’accelerazione gratuita per qualunque workload: abilitare il rewrite aggiunge overhead durante la fase di ottimizzazione, perché il sistema deve valutare le viste candidate anche quando nessuna può essere utilizzata. Una vista più compatta può inoltre produrre meno task e quindi ridurre il parallelismo disponibile, oppure introdurre data skew. La scelta delle viste deve quindi partire dalle query realmente più costose e ripetitive, non dalla materializzazione indiscriminata di ogni risultato intermedio.

Leggi anche: AWS porta Spark sulle GPU e permette a BigQuery di interrogare direttamente i dati Iceberg su S3

CloudSearch entra nella fase della migrazione verso OpenSearch Serverless

Sul fronte della ricerca AWS affronta invece un problema di modernizzazione. Amazon CloudSearch nasce da una generazione nella quale il requisito principale era costruire rapidamente un motore full-text gestito senza amministrare direttamente cluster e nodi. Le applicazioni moderne chiedono però funzionalità differenti: semantic search, ricerca ibrida, vector search, RAG e sistemi agentici richiedono un motore capace di combinare retrieval lessicale e vettoriale e di adattare le risorse a pattern di traffico molto meno prevedibili. Nella procedura ufficiale per migrare da CloudSearch ad Amazon OpenSearch Serverless, AWS indica quindi la piattaforma serverless come destinazione naturale per la maggior parte dei workload CloudSearch, mantenendo un modello operativo gestito ma introducendo capacità di ricerca molto più ampie.

La scelta si inserisce nella nuova architettura di OpenSearch Serverless, che AWS ha progressivamente riprogettato separando maggiormente compute e storage e rendendo indipendente la scalabilità delle attività di indicizzazione e ricerca. La piattaforma può ridurre il compute fino a zero durante i periodi di inattività, lasciando il costo dello storage, ma il serverless non è necessariamente la soluzione corretta in qualunque situazione. AWS stessa indica i normali domini gestiti di Amazon OpenSearch Service quando il workload richiede latenza read-after-write particolarmente bassa, tempi di risposta estremamente prevedibili oppure un controllo diretto della configurazione delle istanze. È quindi una migrazione architetturale, non una semplice sostituzione del nome del servizio.

Migrare significa ricostruire schema, dati e query

Il passaggio da CloudSearch a OpenSearch Serverless richiede innanzitutto di inventariare l’ambiente esistente: numero dei documenti, dimensione complessiva, campi, tipi, configurazioni di ricerca e ordinamento, synonym, stopword e funzioni personalizzate di ranking. CloudSearch non offre un meccanismo integrato di export o snapshot dei dati, quindi AWS richiede che la sorgente originale sia ancora disponibile in un archivio durevole come Amazon S3 o DynamoDB. I documenti devono essere trasformati dal formato utilizzato da CloudSearch in JSON compatibile con OpenSearch e successivamente reindicizzati, preferibilmente attraverso Amazon OpenSearch Ingestion quando il volume e i requisiti operativi rendono necessario un caricamento ripetibile e riavviabile. Anche il modello dei dati cambia. I campi text diventano normalmente campi text, i literal corrispondono ai keyword, coordinate geografiche possono diventare geo_point e i campi numerici devono essere dimensionati in funzione dei valori realmente contenuti. AWS consiglia inoltre mapping espliciti con modalità dynamic: strict, così da respingere all’ingestion documenti contenenti campi imprevisti anziché creare automaticamente strutture che potrebbero introdurre schema drift. Per campi testuali utilizzati anche per ordinamento o aggregazione è possibile aggiungere un sotto-campo keyword, separando il testo analizzato dal valore esatto. È un livello di controllo maggiore rispetto al modello CloudSearch, ma richiede che la migrazione venga progettata e validata prima del cutover.

Da URL query a OpenSearch DSL cambia anche l’applicazione

Il secondo cambiamento sostanziale riguarda il linguaggio delle interrogazioni. CloudSearch espone una sintassi prevalentemente URL-based, mentre OpenSearch utilizza API REST con una Query DSL strutturata nel body della richiesta. Ricerca, filtri, ordinamento, boosting, query booleane e range devono quindi essere tradotti. Non basta trasferire l’indice e modificare l’endpoint: il software che interroga CloudSearch deve essere adattato ai client e alla semantica di OpenSearch. AWS raccomanda di verificare separatamente document count, risultati delle query, ranking e latenza prima del passaggio del traffico produttivo, arrivando a suggerire la replica del traffico reale o almeno volumi significativi di query sintetiche per individuare divergenze che un semplice test funzionale potrebbe non mostrare. Cambiano anche le policy. CloudSearch utilizza principalmente IAM per autorizzare le API, mentre OpenSearch Serverless separa encryption policy, network policy e data access policy. La distinzione rende più granulare il controllo tra cifratura, raggiungibilità della collection e autorizzazione sugli indici, ma obbliga a tradurre consapevolmente il modello di sicurezza esistente. Il lavoro recente su OpenSearch Serverless e AWS PrivateLink mostra la stessa direzione: AWS sta cercando di diminuire la complessità operativa della piattaforma senza eliminare le decisioni che riguardano isolamento di rete, identità e accesso ai dati.

Continua con:

• AWS sposta oltre mille modelli SQL verso un lakehouse aperto basato su S3, Iceberg e Spark
• AWS collega Kinesis, Glue 6.0 e Apache Iceberg nelle pipeline dati per analytics e agenti AI

AWS sposta l’ottimizzazione dal codice verso l’infrastruttura dati

I due interventi agiscono su livelli differenti ma seguono un principio comune. Con le viste materializzate Iceberg, AWS cerca di accelerare Spark senza obbligare l’organizzazione a riscrivere il patrimonio SQL accumulato negli anni; con la migrazione verso OpenSearch Serverless, sposta verso il servizio gestito una parte sempre maggiore dei problemi di capacità, scalabilità e funzionamento del motore di ricerca. Non significa eliminare il lavoro architetturale: progettare una vista sbagliata può aggiungere overhead senza migliorare le query, esattamente come trasferire CloudSearch senza ripensare mapping, ranking e sicurezza può produrre un sistema formalmente migrato ma funzionalmente differente. La tendenza è piuttosto quella di separare sempre più dato, compute e applicazione, facendo di Iceberg, Glue, S3 e OpenSearch componenti intercambiabili di un livello dati nel quale l’ottimizzazione viene progressivamente incorporata nella piattaforma invece di essere risolta query per query o server per server.