Название в значительной степени подводит итог всему этому. Независимо от того, насколько короткой я установил ширину окна, GroupByKey никогда не срабатывает при выполнении задания в DirectRunner. При использовании DataflowRunner все работает должным образом.
Apache Beam GroupByKey никогда не срабатывает при использовании DirectRunner
comment
Есть ли какие-нибудь обновления по этой проблеме? Я наблюдаю такое же поведение в луче 2.5.0.
- person xiu shi schedule 29.08.2018
comment
Только когда я последний раз проверял. Я прибег к запуску на Dataflow runner.
- person Kakaji schedule 08.09.2018
Ответы (1)
GroupByKey по умолчанию запускает конкретное окно, когда водяной знак ввода PCollection достигает конца этого окна. Если он не срабатывает, это означает, что водяной знак входа PCollection не продвигается, или, возможно, он продвигается, но все ваши данные в конечном итоге отбрасываются с опозданием.
Причины этого зависят от того, как производится PCollection. Я предполагаю, что вы, возможно, читаете это прямо из PubSubIO.read(). Вычислить водяной знак для PubSub сложно (особенно, если вы используете настраиваемый атрибут отметки времени); есть некоторые известные проблемы с этим вычислением в Direct runner; Средство выполнения потока данных заменяет другую реализацию во время выполнения, которая вычисляет водяной знак более точно (но все еще несовершенно).
К сожалению, в настоящее время у нас нет инструментов для отслеживания прогресса водяного знака в прямом запуске. Вы можете попробовать отладить это, добавив несколько операторов журнала в PubsubUnboundedSource.PubsubReader.getWatermark(). Вы также можете добавить ParDo между чтением и GBK и распечатать временные метки событий, которые вы в конечном итоге получите (c.timestamp()).
Вы также можете попробовать настроить стратегию работы с окнами, чтобы не сбрасывать поздние данные, см. Управление данными с опозданием.
person
jkff
schedule
07.11.2017
