Ограничение количества значений на ключ

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

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

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

Есть ли стандартный способ или передовая практика для этого?


apache-beam google-cloud-dataflow dataflow
person Narek    schedule 14.07.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

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

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

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

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

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

person Ben Chambers    schedule 15.07.2016