Как решить проблемы со стабильностью в Google Dataflow

У меня есть задание Dataflow, которое стабильно работает несколько месяцев. Последние 3 дня или около того у меня проблемы с работой, она застревает по прошествии определенного времени, и единственное, что я могу сделать, это остановить работу и начать новую. Это произошло через 2, 6 и 24 часа обработки. Вот последнее исключение:

java.lang.ExceptionInInitializerError
at org.apache.beam.runners.dataflow.worker.options.StreamingDataflowWorkerOptions$WindmillServerStubFactory.create (StreamingDataflowWorkerOptions.java:183)
at org.apache.beam.runners.dataflow.worker.options.StreamingDataflowWorkerOptions$WindmillServerStubFactory.create (StreamingDataflowWorkerOptions.java:169)
at org.apache.beam.sdk.options.ProxyInvocationHandler.returnDefaultHelper (ProxyInvocationHandler.java:592)
at org.apache.beam.sdk.options.ProxyInvocationHandler.getDefault (ProxyInvocationHandler.java:533)
at org.apache.beam.sdk.options.ProxyInvocationHandler.invoke (ProxyInvocationHandler.java:158)
at com.sun.proxy.$Proxy54.getWindmillServerStub (Unknown Source)
at org.apache.beam.runners.dataflow.worker.StreamingDataflowWorker.<init> (StreamingDataflowWorker.java:677)
at org.apache.beam.runners.dataflow.worker.StreamingDataflowWorker.fromDataflowWorkerHarnessOptions (StreamingDataflowWorker.java:562)
at org.apache.beam.runners.dataflow.worker.StreamingDataflowWorker.main (StreamingDataflowWorker.java:274)
Caused by: java.lang.RuntimeException: Loading windmill_service failed:
at org.apache.beam.runners.dataflow.worker.windmill.WindmillServer.<clinit> (WindmillServer.java:42)
Caused by: java.io.IOException: No space left on device
at sun.nio.ch.FileDispatcherImpl.write0 (Native Method)
at sun.nio.ch.FileDispatcherImpl.write (FileDispatcherImpl.java:60)
at sun.nio.ch.IOUtil.writeFromNativeBuffer (IOUtil.java:93)
at sun.nio.ch.IOUtil.write (IOUtil.java:65)
at sun.nio.ch.FileChannelImpl.write (FileChannelImpl.java:211)
at java.nio.channels.Channels.writeFullyImpl (Channels.java:78)
at java.nio.channels.Channels.writeFully (Channels.java:101)
at java.nio.channels.Channels.access$000 (Channels.java:61)
at java.nio.channels.Channels$1.write (Channels.java:174)
at java.nio.file.Files.copy (Files.java:2909)
at java.nio.file.Files.copy (Files.java:3027)
at org.apache.beam.runners.dataflow.worker.windmill.WindmillServer.<clinit> (WindmillServer.java:39)

Похоже, на устройстве не осталось места, но разве это не должно управляться Google? Или это как-то ошибка в моей работе?

ОБНОВЛЕНИЕ: Рабочий процесс выглядит следующим образом:

  • Чтение массовых данных из PubSub (до 1500 / с)
  • Отфильтровать некоторые сообщения
  • Сохранение окна сеанса по ключу и группировка по нему
  • Сортируйте данные и делайте расчеты
  • Вывести данные в другой PubSub

person carens    schedule 06.07.2020    source источник
comment
Поток данных выполняется на воркерах, которые являются стандартными машинами GCE со специальным образом, но если в рабочем процессе вы загружаете файлы и не удаляете их, вы можете столкнуться с проблемами хранения. Можете ли вы поделиться своим рабочим процессом, чтобы мы могли лучше понять, что вы делаете?   -  person Iñigo    schedule 06.07.2020
comment
Я добавил рабочий процесс.   -  person carens    schedule 06.07.2020
comment
Вы разрешаете данные с опозданием? Если так, то как долго? Вы используете движок потоковой передачи?   -  person Iñigo    schedule 06.07.2020
comment
Ошибка No space left on device действительно похожа на проблему с загрузкой файлов, а не с их удалением.   -  person robertwb    schedule 07.07.2020
comment
Итак, что представляет собой загрузка файла при использовании Beam / Dataflow?   -  person carens    schedule 07.07.2020
comment
@ Iñigo Стандартные настройки для позднего свидания. Я использую окна сеанса с перерывом в 5 минут. Нет потокового движка; Я пробовал, но сработало еще хуже.   -  person carens    schedule 07.07.2020
comment
Худший? нормально: If a streaming job uses Streaming Engine, then the default is 30 GB; otherwise, the default is 400 GB. В 10 раз меньше места на устройствах, вы быстрее выходите из строя   -  person guillaume blaquiere    schedule 07.07.2020
comment
Сейчас я пытаюсь запустить задание в одном потоке (--numberOfWorkerHarnessThreads = 1). Это кажется многообещающим. Работа может легко идти в ногу с сообщениями pubsub, а использование ЦП и вывод очень плавные. Со стандартными настройками он был очень резким, иногда не выводил вывод на некоторое время, а затем внезапно выводил 1 миллион сообщений за раз.   -  person carens    schedule 07.07.2020


Ответы (1)


Вы можете увеличить емкость хранилища в параметре вашего конвейера. Посмотрите на этот diskSizeGb на этой странице

Кроме того, чем больше данных вы храните в памяти, тем больше вам потребуется памяти. Это относится к окнам: если вы никогда их не закрываете или если вы допускаете запаздывание данных в течение слишком долгого времени, вам понадобится много памяти для хранения всех этих данных.

Настройте конвейер или тип вашей машины. Или оба!

person guillaume blaquiere    schedule 06.07.2020
comment
Как мне активно закрывать окна? Я использую окна сеанса с 5-минутным перерывом. - person carens; 07.07.2020
comment
Сессия окна закрывается, когда достигается длительность перерыва + разрешить задержку данных. - person guillaume blaquiere; 07.07.2020
comment
Я не установил допустимую задержку. По умолчанию 0, т.е. нет допустимого опоздания? - person carens; 07.07.2020
comment
да. У вас одновременно открыто много окон? У вас много данных в каждом окне? - person guillaume blaquiere; 07.07.2020
comment
Около 25000 открытых окон с примерно 100 сообщениями в каждом. Каждое сообщение имеет размер около 200 байт. - person carens; 07.07.2020
comment
Считаю, что обзор конвейера необходим. Даже если вы используете диск большего размера, возникнет проблема, например, утечка памяти. Вы можете поделиться им здесь, если нет ничего конфиденциального, или попытаться воспроизвести минимальный конвейер с помощью только базового преобразования (но, если есть утечка памяти, минимальный конвейер не может выйти из строя, как настоящий ..) - person guillaume blaquiere; 07.07.2020