Восстановление сообщений PubSub Acked из потока данных после потери региона - PullRequest
Новая
       27

Восстановление сообщений PubSub Acked из потока данных после потери региона

1 голос
/ 10 марта 2020

Я читал о том, как DataFlow проверяет сообщения при чтении данных в потоковом режиме. Исходя из ответов здесь и здесь , кажется, что DataFlow «проверяет» сообщения по пакетам, пока он завершает пакет, он будет «подтверждать» сообщения в нем.

Путаница n - это то, что произойдет, если в конвейере участвует GroupByKey. Данные в пакете будут сохранены в мультирегиональном сегменте, и сообщения будут подтверждены. Тогда представьте, что весь регион рушится. Промежуточные данные все еще будут в корзине (потому что мы мультирегиональные).

При этом,

  1. Какие шаги необходимо предпринять, чтобы не потерять какие-либо данные?
  2. Любая рекомендация относительно того, как обращаться с этим активным / активным подходом, чтобы не потерять данные, когда регион полностью разрушен?

Пожалуйста, сообщите,

1 Ответ

3 голосов
/ 11 марта 2020

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

У нас есть несколько простых потоковых конвейеров потока данных, которые читают из PubSub и запись в PubSub без вызова GroupByKey, поэтому состояние контрольной точки не затрагивается, и сообщения принимаются только после доставки на выход topi c.

У нас есть другие конвейеры, которые читают из Pubsub и пишут в GCS или BigQuery. FileIO и BigQueryIO включают в себя несколько операций GroupByKey, поэтому мы уязвимы для потери данных, если сообщения с контрольными точками отбрасываются. У нас было несколько случаев, когда эти трубопроводы попадали в неисправимое состояние, которое требовало отмены. В этом сценарии ios нам пришлось засыпать часть данных с более раннего этапа нашей архитектуры данных.

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

...