Воспроизведение данных в конвейер Apache Beam через Google Cloud Pub / Sub без перегрузки других подписчиков.

Question

Что я делаю: Я строю систему, в которой одна тема Cloud Pub / Sub будет прочитана десятками конвейеров Apache Beam в потоковом режиме.Каждый раз, когда я развертываю новый конвейер, он должен сначала обрабатывать исторические данные за несколько лет (хранящиеся в BigQuery).

Проблема: Если я буду воспроизводить исторические данные в теме при каждом развертыванииновый конвейер (как предложено здесь ), он также будет доставлен во все остальные конвейеры, которые в данный момент читают эту тему, что будет расточительно и очень дорого.Я не могу использовать Cloud Pub / Sub Seek (как предложено здесь ), поскольку в нем хранится не более 7 дней истории (более подробная информация здесь ).

Вопрос: Каков рекомендуемый шаблон для воспроизведения исторических данных в новых потоковых конвейерах Apache Beam с минимальными издержками (и не вызывающий проблем времени / водяных знаков)?

Текущие идеи: В настоящее время я могу придумать три подхода к решению проблемы, однако ни один из них не выглядит очень элегантным, и я не видел ни одного из них, упомянутых в документации, общих схем ( часть 1 или часть 2 ) или в другом месте.Это:

1. В идеале я мог бы использовать Flatten для объединения ReadFromPubSub в реальном времени с одноразовым BigQuerySource, однако я вижу трипотенциальные проблемы: а) я не могу учесть данные, которые уже были опубликованы в Pub / Sub, но еще не попали в BigQuery, б) я не уверен, что BigQuerySource может быть случайно выполнен повторно, если конвейерперезапускается, и c) я не уверен, работает ли BigQuerySource в потоковом режиме (согласно таблице здесь ).

2. Я создаю отдельную тему воспроизведения для каждогоpipe и затем используйте Flatten , чтобы объединить ReadFromPubSub s для основной темы и темы воспроизведения для конкретного конвейера.После развертывания конвейера я преобразовываю исторические данные в тему воспроизведения для конкретного конвейера.

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

Answer 1

Из трех ваших идей:

• Первая не будет работать, потому что в настоящее время Python SDK не поддерживает неограниченное чтение из ограниченных источников (то есть вы не можете добавить ReadFromBigQuery до потокового конвейера).

• Третий звучит слишком сложно и, возможно, дорого.

Я считаю, что ваша лучшая ставка накак вы и сказали, нужно переиграть вашу таблицу в дополнительную тему PubSub, которую вы сгладили с основной темой, как вы правильно указали.

Я проверю, есть ли лучшее решение, но пока, вариант #2 должен сделать свое дело.

---

Кроме того, я бы отсылал вас к интересному разговору от Lyft о том, как сделать это для их архитектуры (во Flink).