Dataflow Pipeline - «Обработка застряла в шаге»по крайней мере <TIME>без вывода или завершения в состоянии закончить ... "

Question

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

Ниже приведены сообщения журнала, которые мы получаем:

Для BigQueryoutput:

Processing stuck in step <STEP_NAME>/StreamingInserts/StreamingWriteTables/StreamingWrite for at least <TIME> without outputting or completing in state finish
  at sun.misc.Unsafe.park(Native Method)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
  at java.util.concurrent.FutureTask.get(FutureTask.java:191)
  at org.apache.beam.sdk.io.gcp.bigquery.BigQueryServicesImpl$DatasetServiceImpl.insertAll(BigQueryServicesImpl.java:765)
  at org.apache.beam.sdk.io.gcp.bigquery.BigQueryServicesImpl$DatasetServiceImpl.insertAll(BigQueryServicesImpl.java:829)
  at org.apache.beam.sdk.io.gcp.bigquery.StreamingWriteFn.flushRows(StreamingWriteFn.java:131)
  at org.apache.beam.sdk.io.gcp.bigquery.StreamingWriteFn.finishBundle(StreamingWriteFn.java:103)
  at org.apache.beam.sdk.io.gcp.bigquery.StreamingWriteFn$DoFnInvoker.invokeFinishBundle(Unknown Source)

Для облачного хранилища output:

Processing stuck in step <STEP_NAME>/WriteFiles/WriteShardedBundlesToTempFiles/WriteShardsIntoTempFiles for at least <TIME> without outputting or completing in state process
  at sun.misc.Unsafe.park(Native Method)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
  at java.util.concurrent.FutureTask.get(FutureTask.java:191)
  at com.google.cloud.hadoop.util.AbstractGoogleAsyncWriteChannel.waitForCompletionAndThrowIfUploadFailed(AbstractGoogleAsyncWriteChannel.java:421)
  at com.google.cloud.hadoop.util.AbstractGoogleAsyncWriteChannel.close(AbstractGoogleAsyncWriteChannel.java:287)
  at org.apache.beam.sdk.io.FileBasedSink$Writer.close(FileBasedSink.java:1007)
  at org.apache.beam.sdk.io.WriteFiles$WriteShardsIntoTempFilesFn.processElement(WriteFiles.java:726)
  at org.apache.beam.sdk.io.WriteFiles$WriteShardsIntoTempFilesFn$DoFnInvoker.invokeProcessElement(Unknown Source)

Все приложения были удалены и повторно развернуты, но через некоторое время произошло то же самое (период от 3 до 4 часов).Некоторые из них работали более 40 дней, и они неожиданно занялись этим без каких-либо изменений в коде.

Я хотел бы попросить помощи, чтобы узнать причину этой проблемы.Вот следующие идентификаторы некоторых заданий потока данных с этими проблемами:

Застрял в выводе BigQuery: 2019-03-04_04_46_31-3901977107649726570

Застрял в выводе облачного хранилища: 2019-03-04_07_50_00-10623118563101608836

Answer 1

У меня та же проблема, я обнаружил, что наиболее распространенный случай - это то, что одно из заданий не удалось вставить в таблицу BigQuery или не удалось сохранить файл в корзину CGS (очень редко).Ответственная нить не перехватывает исключение и продолжает ждать задания.Это ошибка Apache Beam, и я уже создал для нее тикет.

https://issues.apache.org/jira/plugins/servlet/mobile#issue/BEAM-7693

Давайте посмотрим, исправят ли эту проблему ребята из Apache Beam (это буквально необработанное исключение).

Пока что я рекомендую проверить ограниченияваших данных до вставки.Так что имейте в виду такие вещи, как: 1) Максимальный размер строки (сейчас 2019 - 1 МБ для вставки потока и 100 МБ для пакета) 2) ТРЕБУЕМЫЕ значения, которые не приходят, должны создать мертвую букву раньше и не иметь возможности достичь задания 3)Если у вас есть неизвестные поля, не забудьте включить опцию ignoreUnknownFields (иначе они приведут к тому, что ваша работа умрет)

Я предполагаю, что у вас возникают проблемы только в часы пик, потому что наступает больше «неудовлетворенных» событий.

Надеюсь, это немного поможет

Answer 2

Как вы правильно указали, это, вероятно, связано с проблемой взаимоблокировки библиотеки Conscrypt, которая использовалась в качестве поставщика безопасности по умолчанию.Начиная с Beam 2.9.0, Conscrypt больше не является поставщиком безопасности по умолчанию .

Еще один вариант - перейти на Beam 2.4.0, где concerypt также не был поставщиком по умолчанию.

Для потоковых конвейеров вы можете просто обновить свой конвейер новым SDK, и все должно работать.

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