Un'azienda carica file CSV in un bucket Amazon S3. Un crawler AWS Glue crea tabelle e schemi per i dati, e un job AWS Glue elabora le tabelle e scrive i risultati in un database Amazon Redshift. Il job Glue gestisce la mappatura delle colonne e crea le tabelle Redshift secondo necessità. Rieseguire il job Glue causa la comparsa di righe duplicate nelle tabelle Redshift. L'azienda ha bisogno di un modo per aggiornare le tabelle Redshift senza introdurre duplicati. Quale approccio soddisfa questo requisito?

L'approccio corretto prevede l'uso di una tabella di staging in Amazon Redshift per gestire gli aggiornamenti e prevenire i duplicati. Caricando i nuovi dati in una tabella temporanea (staging), è possibile eseguire operazioni SQL come MERGE (o una combinazione di DELETE e INSERT) per aggiornare le righe esistenti e inserire quelle nuove nella tabella finale di Redshift. Questo garantisce che ogni record sia presente una sola volta e che i dati siano sempre aggiornati. Le altre opzioni sono meno efficaci o inappropriate: Caricare i dati in un database MySQL e poi copiarli in Redshift introduce complessità e latenza inutili, oltre a non essere la soluzione idiomatica per Redshift. dropDuplicates() di Apache Spark rimuove i duplicati all'interno di un singolo batch di dati, ma non risolve il problema dei duplicati tra esecuzioni diverse del job, che è il problema principale qui. ResolveChoice di AWS Glue è una trasformazione per risolvere problemi di tipi di dati o schemi divergenti, non per gestire i duplicati logici basati su chiavi primarie o logica di business in un database.