Un'azienda di giochi raccoglie eventi clickstream con Amazon Kinesis Data Streams e utilizza Kinesis Data Firehose per consegnare file JSON ad Amazon S3. Gli scienziati dei dati interrogano i dati più recenti in Amazon Athena. L'azienda vuole ridurre i costi delle query di Athena senza ricostruire la pipeline di dati esistente. Quale opzione minimizza lo sforzo di gestione pur soddisfacendo il requisito?

L'opzione corretta riduce i costi di Athena convertendo i dati in Parquet, un formato colonnare ottimizzato per le query, e raggruppando i file. Firehose può convertire direttamente in Parquet, minimizzando lo sforzo di gestione. L'impostazione di un prefisso S3 come YYYYMMDD e una dimensione del buffer elevata in Firehose crea file Parquet più grandi e partizionati, riducendo le scansioni di Athena. Un job AWS Glue ETL è necessario per convertire i dati storici esistenti da JSON a Parquet e unirli in file più grandi, garantendo che anche i dati passati beneficino dell'ottimizzazione. ALTER TABLE ADD PARTITION aggiorna Athena per riconoscere le nuove partizioni. Le opzioni errate presentano svantaggi: La creazione di un job Spark su EMR introduce complessità e costi di gestione di un cluster EMR. ALTER TABLE SET LOCATION sovrascriverebbe la posizione della tabella, perdendo l'accesso ai dati precedenti se non gestito correttamente. L'invio dei dati a un altro Kinesis Data Stream e l'uso di Amazon Managed Service for Apache Flink aggiungono complessità e costi a una pipeline già esistente. L'uso di AWS Lambda per la conversione in Parquet non è efficiente per grandi volumi di dati e può essere costoso.