Un'azienda registra milioni di ordini ogni giorno in Amazon DynamoDB. I nuovi ordini vengono aggiunti continuamente man mano che i clienti li inviano. Uno scienziato dei dati deve produrre previsioni sui periodi di punta e creare una dashboard di Amazon QuickSight che mostri i dati degli ordini quasi in tempo reale. Quale approccio minimizza il tempo tra la scrittura di un nuovo ordine su DynamoDB e la possibilità per QuickSight di accedere a tali nuovi dati?

L'opzione corretta è utilizzare Amazon Kinesis Data Firehose per consegnare i dati di modifica di DynamoDB ad Amazon S3 e configurare QuickSight per leggere i dati di S3. Questo approccio sfrutta le DynamoDB Streams per catturare le modifiche ai dati in tempo quasi reale. Kinesis Data Firehose può quindi acquisire questi dati di streaming e consegnarli in modo efficiente a S3, che funge da data lake. QuickSight può connettersi direttamente a S3, consentendo l'analisi dei dati quasi in tempo reale con una latenza minima. Le altre opzioni sono meno efficienti per i dati quasi in tempo reale: L'esportazione tramite AWS Glue è tipicamente un processo batch e introdurrebbe una latenza maggiore. L'invio delle modifiche a Kinesis Data Streams e poi a S3 è un approccio valido, ma Kinesis Data Firehose è specificamente progettato per semplificare e automatizzare la consegna dei dati di streaming a destinazioni come S3, riducendo la complessità operativa. Far sì che QuickSight chiami un'API per leggere direttamente da DynamoDB non è un pattern consigliato per l'analisi di grandi volumi di dati, poiché potrebbe sovraccaricare DynamoDB e non è ottimizzato per le capacità analitiche di QuickSight.