Una empresa carga archivos CSV en un bucket de Amazon S3. Un crawler de AWS Glue construye tablas y esquemas para los datos, y un trabajo de AWS Glue procesa las tablas y escribe los resultados en una base de datos de Amazon Redshift. El trabajo de Glue maneja el mapeo de columnas y crea las tablas de Redshift según sea necesario. Volver a ejecutar el trabajo de Glue provoca que aparezcan filas duplicadas en las tablas de Redshift. La empresa necesita una forma de actualizar las tablas de Redshift sin introducir duplicados. ¿Qué enfoque satisface este requisito?

La opción correcta utiliza una tabla de staging en Redshift para realizar un "upsert" (actualizar si existe, insertar si no). Este es un patrón común y eficiente para evitar duplicados y mantener los datos actualizados en Redshift. Al cargar primero en una tabla temporal, se pueden ejecutar comandos SQL como UPDATE y INSERT (o MERGE en versiones más recientes) para gestionar los cambios. Las otras opciones son incorrectas porque: Cargar en MySQL introduce complejidad y latencia innecesaria, y Redshift está diseñado para manejar grandes volúmenes de datos directamente. dropDuplicates() de Spark solo elimina duplicados dentro del conjunto de datos actual, no resuelve el problema de duplicados con datos ya existentes en Redshift. ResolveChoice de AWS Glue se usa para resolver esquemas dinámicos o tipos de datos mixtos, no para la deduplicación basada en el contenido de filas existentes en una base de datos de destino.