Il servizio gestito da Amazon per Apache Flink era precedentemente noto come Analisi dei dati Amazon Kinesis per Apache Flink.
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à.
Contropressione
Flink utilizza la contropressione per adattare la velocità di elaborazione dei singoli operatori.
L'operatore può avere difficoltà a continuare a elaborare il volume di messaggi che riceve per diverse ragioni. L'operazione potrebbe richiedere più risorse della CPU di quante ne abbia a disposizione l'operatore. Quest'ultimo può attendere il completamento delle operazioni di I/O. Se un operatore non è in grado di elaborare rapidamente gli eventi, crea una contropressione negli operatori a monte che alimentano l'operatore lento. Ciò causa un rallentamento degli operatori a monte, il che può propagare ulteriormente la contropressione alla fonte e far sì che la sorgente si adatti alla velocità di trasmissione effettiva complessiva dell'applicazione, rallentando anche quest'ultima. Per una descrizione più approfondita della contropressione e del suo funzionamento, consulta Come Apache Flink™ gestisce la contropressione
Individuare gli operatori più lenti all'interno di un'applicazione consente di ottenere informazioni fondamentali per comprendere la causa principale dei problemi di prestazioni dell'applicazione. Le informazioni relative alla contropressione sono rese visibili tramite la dashboard di Flink
A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)
Una volta identificato l'operatore lento, prova a individuare i motivi di tale fenomeno. Talvolta le ragioni potrebbero essere molteplici e l'individuazione del problema rivelarsi complessa, tanto da richiedere diversi giorni dedicati ad attività di debugging e profilazione. Di seguito sono riportati alcune delle cause più ovvie e comuni, alcune delle quali sono ulteriormente descritte di seguito:
l'operatore esegue un I/O lento, ad esempio chiamate di rete (valuta di ricorrere all'utilizzo di AsyncIO);
i dati hanno subìto un disallineamento e un operatore riceve più eventi rispetto agli altri (esamina il numero di messaggi in entrata/in uscita dalle singole attività secondarie (ad esempio istanze dello stesso operatore) nella dashboard di Flink).
Questa operazione richiede l'impiego di molte risorse; se non vi è alcun disallineamento dei dati, è consigliabile aumentare orizzontalmente le operazioni legate alla CPU o alla memoria e aumentare
ParallelismPerKPU
per le operazioni legate all'I/OLog dettagliato nell'operatore: è consigliabile ridurlo al minimo per le applicazioni di produzione o considerare, invece, di inviare l'output di debug a un flusso di dati.
Test della produttività con il Discarding Sink
Il discarding sink
Sostituire tutti i sink di un'applicazione con un discarding sink e creare una fonte fittizia che genera dati simili a quelli di produzione consente di misurare la massima velocità di trasmissione effettiva dell'applicazione relativamente a una determinata impostazione di parallelismo. È inoltre possibile aumentare il parallelismo per verificare che l'applicazione si dimensioni in maniera corretta e non presenti ostacoli che emergono solo a velocità di trasmissione effettiva più elevate (ad esempio, a causa del disallineamento dei dati).