Правильно, комбинаторы неупорядочены. Это связано с тем, что неупорядоченное объединение имеет большой смысл в модели Beam, которая позволяет использовать поздние данные (что бы вы хотели, чтобы поведение было в вашем случае, в случае получения поздних данных?), А также потому, что оно допускает очень эффективную реализацию и в в большинстве случаев это все, что нужно.
Один из способов решить эту проблему для вашего случая, пожертвовав некоторой эффективностью, является реализация пользовательских CombineFn, где:
- аккумулятора, а также тип вывода, является «список входных элементов, отсортированных по отметка времени».
- Вставка элемента в аккумулятор вставляет его в отсортированный список
- Слияние двух аккумуляторов объединяет отсортированные списки.
- Извлечение выходного сигнала из аккумулятора является функцией идентификации.
В основном вы будете использовать зерноуборочный поддерживать упорядоченный список значений для каждого ключа, и вы получите PCollection<KV<K, List<V>>>, к которому можно применить ParDo с складкой.
Похоже, что это сработает, но со временем состояние со временем будет расти - я надеялся на решение, где мне нужно было только поддерживать агрегированное состояние. –
Я думаю, что для моего случая использования нормально применять события в обработке временного порядка - так что мне не нужно было бы опоздать, так как поздние события просто заходили в открытое в то время окно, которое было получено, не так ли? –
Итак: учитывая предстоящий API состояния (BTW это скоро?: -D) Я бы мог иметь ParDo, который сохраняет текущее состояние за ключ в глобальном окне и просто применяет события по мере их появления ... если там тоже не заказывается, и в этом случае мне придется (я думаю) 1) хранить фиксированные временные окна на основе времени обработки; 2) GroupByKey; 3) помещено в новое глобальное окно; и 4) имеют сортировку ParDo и применяют события. Я думаю. –