Flink Time Characteristic e AutoWatermarkInterval

Question

In Apache Flink, setAutoWatermarkInterval(interval)produce filigrane per gli operatori a valle in modo che anticipino l'ora dell'evento.

Se la filigrana non è stata modificata durante l'intervallo specificato (non sono arrivati ​​eventi) il runtime non emetterà alcuna filigrana? D'altra parte, se un nuovo evento è arrivato prima dell'intervallo successivo, verrà immediatamente emessa una nuova filigrana o verrà messa in coda / in attesa fino al raggiungimento dell'intervallo setAutoWatermarkInterval successivo.

Sono curioso di sapere quale sia la migliore configurazione AutoWatermarkInterval (soprattutto per sorgenti ad alta velocità): più questo valore è piccolo, maggiore sarà il ritardo tra il tempo di elaborazione e il tempo dell'evento, ma al limite di un maggiore utilizzo BW per inviare le filigrane . È vero vero?

D'altra parte, se ho usato env.setStreamTimeCharacteristic (TimeCharacteristic.IngestionTime), il runtime Flink assegnerà automaticamente timestamp e filigrane (i timestamp corrispondono all'ora in cui l'evento è entrato nella pipeline del flusso di dati Flink, ovvero l'operatore di origine), tuttavia anche con ingestionTime possiamo definire ancora un timer del tempo di elaborazione (nella funzione processElement) come mostrato di seguito:

long timer = context.timestamp() + Timeout.
context.timerService().registerProcessingTimeTimer(timer);

dove context.timestamp () è l'ora di importazione impostata da Flink.

Grazie.

Answer 1

AutoWatermarkInterval influisce solo sui generatori di filigrane che prestano attenzione ad esso. Hanno anche l'opportunità di generare una filigrana in combinazione con l'elaborazione degli eventi.

Per quei generatori di filigrane che utilizzano autoWatermarkInterval (che è sicuramente il caso normale), stanno raccogliendo prove per quale dovrebbe essere la prossima filigrana come effetto collaterale dell'assegnazione di timestamp per ogni evento. Quando viene attivato un timer (in base a autoWatermarkInterval), il generatore di filigrana viene quindi chiesto dal runtime di Flink di produrre la filigrana successiva. La filigrana non era in attesa da qualche parte, né era in coda, ma piuttosto viene creata su richiesta, in base alle informazioni che erano state memorizzate dall'assegnatore del timestamp, che in genere è il timestamp massimo visto finora nello stream.

Sì, le filigrane più frequenti significano più overhead per comunicarle ed elaborarle e una latenza inferiore. Devi decidere come gestire questo compromesso tra throughput / latenza in base ai requisiti dell'applicazione.

È sempre possibile utilizzare i timer del tempo di elaborazione, indipendentemente dalla TimeCharacteristic. (A proposito, a un livello basso, l'unica cosa che fanno le filigrane è attivare i timer del tempo degli eventi, siano essi nelle funzioni di processo, nelle finestre, ecc.)