Una empresa registra millones de pedidos diariamente en Amazon DynamoDB. Se añaden nuevos pedidos continuamente a medida que los clientes los envían. Un científico de datos debe producir predicciones de horas pico y crear un panel de Amazon QuickSight que muestre datos de pedidos casi en tiempo real. ¿Qué enfoque minimiza el tiempo entre que un nuevo pedido se escribe en DynamoDB y QuickSight puede acceder a esos nuevos datos?

La opción correcta es usar Amazon Kinesis Data Firehose para entregar los datos de cambio de DynamoDB a Amazon S3 y configurar QuickSight para leer los datos de S3. DynamoDB Streams captura los cambios a nivel de elemento en una tabla de DynamoDB. Kinesis Data Firehose puede suscribirse a estos streams y entregar los datos de forma continua a Amazon S3 con una latencia mínima (generalmente segundos), lo que permite que QuickSight acceda a datos casi en tiempo real desde S3. Usar AWS Glue para exportar datos de DynamoDB a S3 introduciría una latencia mayor, ya que Glue Jobs suelen ejecutarse de forma programada. Enviar cambios a Kinesis Data Streams y luego a S3 requeriría una configuración adicional para mover los datos de Kinesis a S3, lo cual Firehose simplifica. Hacer que QuickSight llame a una API de DynamoDB directamente no es escalable ni eficiente para grandes volúmenes de datos y actualizaciones continuas, y QuickSight no está diseñado para consultar directamente bases de datos transaccionales en tiempo real de esta manera.