Informazioni sul monitoraggio dei processi di streaming di AWS Glue
Il monitoraggio dei processi di streaming è una parte fondamentale della creazione delle pipeline di ETL. Oltre a utilizzare l'interfaccia utente Spark, è possibile utilizzare Amazon CloudWatch per monitorare i parametri. Di seguito è riportato un elenco di parametri di streaming emessi dal framework AWS Glue. Per un elenco completo di tutti i parametri AWS Glue, consulta la pagina Monitoraggio di AWS Glue con i parametri di Amazon CloudWatch.
AWS Glue utilizza un framework di streaming strutturato per elaborare gli eventi di input. Puoi utilizzare l'API Spark direttamente nel tuo codice o sfruttare il valore ForEachBatch fornito da GlueContext, che pubblica questi parametri. Per comprendere questi parametri, dobbiamo prima capire windowSize.
windowSize: windowSize è l'intervallo di microbatch fornito. Se specifichi una dimensione della finestra di 60 secondi, il processo di streaming di AWS Glue aspetterà 60 secondi (o più, se il batch precedente non è stato completato entro tale lasso di tempo) prima di leggere i dati in un batch dall'origine di streaming e applicare le trasformazioni fornite in ForEachBatch. Questo valore viene chiamato anche intervallo di attivazione.
Esaminiamo i parametri in modo più dettagliato per comprendere le caratteristiche di integrità e prestazioni.
Nota
Questi parametri vengono emessi ogni 30 secondi. Se il valore windowSize fornito è inferiore a 30 secondi, i parametri riportati sono un'aggregazione. Ad esempio, supponiamo che il valore windowSize fornito sia di 10 secondi e che si stiano elaborando costantemente 20 record per microbatch. In questo scenario, il valore del parametro emesso per numRecords sarebbe 60.
Un parametro non viene emesso se per esso non sono disponibili dati. Inoltre, nel caso del parametro del ritardo del consumatore, è necessario abilitare la funzionalità per ottenere i parametri associati.
Come ottenere le prestazioni migliori
Spark cercherà di creare per ogni shard un'attività da cui leggere nel flusso Amazon Kinesis. I dati in ogni shard diventano una partizione. Quindi distribuirà queste attività tra gli esecutori/worker, a seconda del numero di core di ciascun worker (il numero di core per worker dipende dal tipo di worker selezionato, come G.025X, G.1X e così via). Tuttavia, il modo in cui le attività vengono distribuite non è deterministico. Tutte le attività vengono eseguite in parallelo sui rispettivi core. Se sono presenti più shard rispetto al numero di core esecutori disponibili, le attività vengono messe in coda.
È possibile utilizzare una combinazione dei parametri precedenti e del numero di shard per fornire agli esecutori un carico stabile con un certo margine per eventuali picchi. Si consiglia di eseguire alcune iterazioni del processo per determinare il numero approssimativo di worker. Per un carico di lavoro instabile/con picchi, puoi ottenere il medesimo risultato impostando il dimensionamento automatico e il numero massimo di worker.
Imposta il valore di windowSize in base ai requisiti SLA della tua azienda. Ad esempio, se la tua azienda richiede che i dati elaborati non possano essere più vecchi di 120 secondi, imposta un valore di windowSize di almeno 60 secondi, in modo che il ritardo medio dei consumatori sia inferiore a 120 secondi (consulta la sezione precedente sul ritardo dei consumatori). A questo punto, in base a numRecords e al numero di shard, pianifica la capacità in DPU assicurandoti che il valore di batchProcessingTimeInMs sia inferiore al 70% del valore di windowSize per la maggior parte del tempo.
Nota
Gli shard caldi possono causare una distorsione dei dati, il che significa che alcuni shard/partizioni risultano molto più grandi di altri. Ciò può far sì che alcune attività eseguite in parallelo richiedano più tempo, cosicché alcune attività restano indietro. Di conseguenza, il batch successivo non può iniziare fino al completamento di tutte le attività del precedente, il che influirà sul valore di batchProcessingTimeInMillis e sul ritardo massimo.
