Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Il monitoraggio dei processi di streaming è una parte fondamentale della creazione della ETL pipeline. Oltre a utilizzare l'interfaccia utente Spark, puoi anche utilizzare Amazon CloudWatch per monitorare le metriche. Di seguito è riportato un elenco delle metriche di streaming emesse dal framework. AWS Glue Per un elenco completo di tutte le AWS Glue metriche, consulta Monitoraggio AWS Glue tramite i CloudWatch parametri Amazon.
AWS Glue utilizza un framework di streaming strutturato per elaborare gli eventi di input. Puoi utilizzare Spark API direttamente nel tuo codice o sfruttare il ForEachBatch
provider byGlueContext
, che pubblica queste metriche. Per comprendere questi parametri, dobbiamo prima capire windowSize
.
windowSize: windowSize
è l'intervallo di microbatch fornito. Se specificate una dimensione della finestra di 60 secondi, il processo di AWS Glue streaming aspetterà 60 secondi (o più se il batch precedente non è stato completato entro tale data) prima di leggere i dati in un batch dalla sorgente 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 metrico 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 funzione 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 la windowSize
in SLA base alle esigenze 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). Da lì, a seconda del numero numRecords
e del numero di frammenti, pianifica la capacità in modo da DPUs assicurarti che la tua batchProcessingTimeInMs
sia inferiore al 70% del tuo per la windowSize
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.