Una empresa de juegos recopila eventos de clickstream con Amazon Kinesis Data Streams y utiliza Kinesis Data Firehose para entregar archivos JSON a Amazon S3. Los científicos de datos consultan los datos más recientes en Amazon Athena. La empresa quiere reducir los costos de las consultas de Athena sin reconstruir el pipeline de datos existente. ¿Qué opción minimiza el esfuerzo de gestión al tiempo que cumple con el requisito?

La opción correcta minimiza los costos de consulta de Athena al convertir los datos a Apache Parquet, un formato columnar optimizado para consultas analíticas que reduce la cantidad de datos escaneados. Configurar Firehose para generar Parquet directamente y usar un prefijo de objeto YYYYMMDD permite el particionamiento, lo que reduce aún más los datos escaneados. El uso de un tamaño de búfer grande en Firehose genera archivos Parquet más grandes, lo que es eficiente para Athena. Para datos históricos, un trabajo ETL de AWS Glue consolida archivos JSON pequeños en Parquet más grandes, abordando el problema de los archivos pequeños y el rendimiento de Athena. ALTER TABLE ADD PARTITION actualiza el catálogo de Athena para reconocer los nuevos datos particionados. Las opciones incorrectas tienen desventajas: Crear un trabajo de Spark en EMR introduce complejidad operativa y costos adicionales al requerir la gestión de clústeres efímeros y la reescritura de la ubicación de la tabla de Athena. Enviar datos a otro Kinesis Data Stream y usar Amazon Managed Service para Apache Flink agrega complejidad y latencia al pipeline, además de un costo de servicio adicional. Adjuntar una función Lambda a Firehose para la conversión puede ser costoso y propenso a errores para grandes volúmenes de datos, y añade una capa de procesamiento que Firehose puede manejar de forma nativa para Parquet.