Возможно ли, чтобы время события для экземпляра оператора стало меньше? - PullRequest
Новая
       9

Возможно ли, чтобы время события для экземпляра оператора стало меньше?

0 голосов
/ 31 мая 2018

Из раздела «Водяные знаки в параллельных потоках» в следующем URL-адресе мы знаем, что «текущее время события оператора является минимумом времени события его входных потоков» https://ci.apache.org/projects/flink/flink-docs-release-1.5/dev/event_time.html

Теперь, когда мы беремвремя события экземпляра окна (1) в качестве примера, и мы знаем, что время события равно 14 (мин (29,14)), однако что произойдет, если произойдет следующая последовательность событий водяного знака?

Что произойдет, еслисобытие 29 водяного знака прибывает в окно (1) до события 14 водяного знака?

Например, предположим, что событие 29 водяного знака сначала поступает в экземпляр окна (1), так как событие водяного знака 14 не достигло его, поэтомувремя события экземпляра окна (1) сначала было установлено равным 29, после этого предположим, что событие события водяного знака 14 также приходило в окно (1), затем время события экземпляра окна (1) было установлено равным 14?(Если это так, то время события окна (1) изменится с 29 на 14, станет меньше), также предположим, что после этого источник (2) сгенерировал водяной знак 39, а затем прибыл в экземпляр окна (1), затемвремя события экземпляра окна (1) будет установлено 29 или 39?

Ответы [ 3 ]

0 голосов
/ 01 июня 2018 
Such as suppose the watermark event 29 arrives at the window(1) instance 
firstly, as the watermark 14 event hasn't arrived it, so the event time of 
window(1) instance was set to 29 firstly ...

Это не правильно.Значение заполнителя Long.MIN_VALUE используется до тех пор, пока не будет получен первый правильный водяной знак.Таким образом, водяной знак для окна будет оставаться на Long.MIN_VALUE, пока из обоих входных потоков не будет получено большее значение.

0 голосов
/ 01 июня 2018

Наконец, я также получил ответ от источника, так же, как Дэвид сказал, что «водяной знак для окна будет оставаться в Long.MIN_VALUE, пока большее значение не поступит из обоих входных потоков».

https://github.com/apache/flink/blob/57b950796deebed46ae95f97152e09b2e2655de8/flink-streaming-java/src/main/java/org/apache/flink/streaming/api/operators/AbstractStreamOperator.java

public void processWatermark1(Watermark mark) throws Exception {
input1Watermark = mark.getTimestamp();
long newMin = Math.min(input1Watermark, input2Watermark);
if (newMin > combinedWatermark) {
  combinedWatermark = newMin;
  processWatermark(new Watermark(combinedWatermark));
}
}

public void processWatermark2(Watermark mark) throws Exception {
input2Watermark = mark.getTimestamp();
long newMin = Math.min(input1Watermark, input2Watermark);
if (newMin > combinedWatermark) {
  combinedWatermark = newMin;
  processWatermark(new Watermark(combinedWatermark));
}
}
0 голосов
/ 31 мая 2018

Короткий ответ: нет, в этом случае окно не станет меньше (и может фактически выдать исключение).

Именно здесь вступает в игру экстрактор водяных знаков BoundedOutOfOrderness .Используя это, вы настраиваете, какие временные метки могут быть «не в порядке», и это сгладит эти расхождения.По умолчанию с экстрактором AscendingTimestamp фактически было бы ошибкой получать метки времени, которые вышли из строя.

Кроме того, существует понятие «допустимая задержка», которое определяет, что происходит в случае, когда вы получаете отметки времени, которые ниже текущего водяного знака.

Например, если вы знаете, что ваш источник данных может иметь джиттер в 60 секунд (из-за задержек во время обработки, географического расстояния и т. Д.), Вы можете использовать ограниченный извлеченный из порядка извлечение со значением(TimeUnit.SECONDS, 60), что эффективно сдвинет все ваше окно назад на 60 с.Это позволит элементам располагаться в любом порядке в течение 60-х годов друг от друга.

Однако, если вы действительно ожидаете, что элементы будут приходить либо в точном порядке, либо с очень небольшим джиттером, но вы хотите принимать поздние элементы для обработки, вы можете использовать настройки Allowed Lateness чтобы определить, как должен вести себя ваш процесс при поступлении этих элементов. По умолчанию Flink просто удалит их, но вы можете настроить период времени, в течение которого Flink будет повторно запускать ваше окно для каждого входящего элемента.

Фундаментально все это зависит только от вашей конкретной ситуации, от того, насколько нервно и поздно вы ожидаете поступления данных, а также от того, как вы справляетесь с поздними элементами.Flink в значительной степени учитывает любую комбинацию настроек здесь.

...