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à.
Informazioni sul monitoraggio dei lavori di AWS Glue streaming
Il monitoraggio dei processi di streaming è una parte fondamentale della creazione delle pipeline di ETL. 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 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 si specifica 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 inForEachBatch. 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 unstable/spiky carico di lavoro puoi fare lo stesso impostando la scalabilità automatica e il numero massimo di lavoratori.
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). Da lì, a seconda del numero numRecords e del numero di frammenti, pianifica la capacità in modo da DPUs assicurarti di occupare meno del 70% del tuo batchProcessingTimeInMs windowSize tempo per la maggior parte del tempo.
Nota
Gli hot shard possono causare la distorsione dei dati, il che significa che alcuni shards/partitions sono molto più grandi degli 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.
