Ограничение количества значений для каждой клавиши

Question

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

Сейчас мы рассматриваем 3 варианта:

1. Меньшие Окна - мы думаем, что, возможно, все еще есть проблемы с этим, так как события могут прийти в кластер вместе со временем.
2. Добавление случайного значения в каждую клавишу для разделения ключей вверх - это также не идеально, потому что, когда у нас меньше событий, мы будем иметь слишком мало значений для каждого ключа. Также мы не можем настроить количество разделов, когда число событий увеличивается экспоненциально.
3. Некоторое причудливое срабатывание или использование объединителя - возможно, лучшее решение, но не знаете, как это сделать.

Существует ли стандартный способ или наилучшая практика для этого?

Answer 1

Возможны все варианты, хотя это и идеально, частично зависит от того, что вы потом вычисляете и используете ли вы пакетный конвейер на ограниченных данных или потоковый конвейер на неограниченных данных.

1. Вы можете создать собственный WindowFn, что ограниченное количество элементов в каждом окне. Например, вы можете назначить каждый элемент окну, например (1, [startTime, endTime)). Затем вы объединяете несколько окон вместе, добавляя их количество. Вы перестанете сливаться, когда счет слишком высок.

2. Случайное разделение ключей - хороший способ обеспечить разбиение на разделы и обеспечить лучший порядок распределения кода между машинами.

3. Вы можете использовать триггер, такой как «AfterPane.elementCountAtLeast (500)», чтобы выводить панели из ~ 500 элементов. Если единственной проблемой был размер iterable в DoFn, это должно помочь. Это также даст больше/более ранних выходов, что может быть или не быть желательным.

4. Если вычисление в ParDo является ассоциативной и коммутативной, написание CombineFn даст гораздо меньше данных, хранящихся и улучшит общую производительность трубопровода как для партии и потокового видео.

Если вы можете описать свой вопрос, который может помочь вам в решении одного из этих решений. В противном случае мы предлагаем начать с CombineFn, если это возможно, и посмотреть, нужно ли после этого продолжить другие пути.