Простой тест Потоковый конвейер (при запуске Dataflow) :: данные не проходят через

Question

Я пишу простой потоковый конвейер (Apache Beam 2.11 SDK, Python 2.7.10) и запускаю его в средстве выполнения потоков данных, читая форму Pub / Sub >> примените поэлементный луч .Map () transsform >> sink toBigQuery (код https://github.com/vibhorj/gcp/blob/master/df/streaming.py)

. Как видно на скриншоте ниже, он просто застрял на шаге 2, преобразование map (). Входные коллекции прочитали 265 элементов, но выходные коллекции пустые. Несмотря на то, что данныеВодяной знак для этого шага прогрессирует почти в реальном времени!

Ничего не передается в BQ либо (я подтвердил это, выполнив запрос: SELECT * FROM sw.payload). Может кто-нибудь объяснить, что не так в моем кодеэто препятствует тому, чтобы форма данных проходила через шаги конвейера ? Я ожидал, что вещи будут передаваться в приемник BQ практически в реальном времени, так как сообщения публикуются в PubSub.

Я не использую никаких преобразований группировки / агрегатов и, следовательно,не вижу причин, по которым оконные функции / триггеры могут здесь вызывать какие-либо проблемы (поправьте меня, если я ошибаюсь!).

Заранее спасибодля любой подсказки, чтобы это исправить!

: ОБНОВЛЕНИЕ : написал другой конвейер с нуля, и, кажется, он работает нормально, в течение <10 секунд данные обнаружились в BQ!для этого конвейера данные, похоже, застряли в буфере потоков BQ (см. снимок экрана, взятый @ 22: 15: 00).Найден другой связанный поток SO <a href="https://stackoverflow.com/questions/53157437/streaming-buffer-google-bigquery/55075762"> Потоковый буфер - Google BigQuery , но это также не решает мои проблемы!

Answer 1

Я хотел бы добавить некоторые данные в качестве контекста:

В настоящее время я транслирую Pub / Sub-> Dataflow-> BigQuery, и задержки минимальны.

SELECT CURRENT_TIMESTAMP(), MAX(ts)
  , TIMESTAMP_MILLIS(CAST(JSON_EXTRACT(ARRAY_AGG(message ORDER BY ts DESC LIMIT 1)[OFFSET(0)], '$.mtime') AS INT64))
FROM `pubsub.meetup_201811` 

2019-03-08 23:29:59.050310 UTC
2019-03-08 23:29:57.620443 UTC
2019-03-08 23:29:57.504 UTC

Посмотрим:

• 23: 29: 57.504 - время исходного сообщения, установленное источником.
• 23: 29: 57.620443 - отметка времени добавляется сценарием, который читает из источника и передает в pub / sub
• 23: 29: 59.050310 - текущее время

Это показывает менее 2 секунд от моего сценария до BigQuery.

Позвольте мне снова выполнить этот запрос:

2019-03-08 23:36:48.264672 UTC
2019-03-08 23:36:47.020180 UTC
2019-03-08 23:36:46.912 UTC

Здесь мы можем видеть менее 1,2 секунды между сценарием и запросом.

И третий раз:

2019-03-08 23:40:13.327028 UTC
2019-03-08 23:40:12.428090 UTC
2019-03-08 23:40:12.255 UTC

1,1 секунды.

Обратите внимание на мои настройки для этого конвейера:

• Plain Pub / Sub.
• Поток данных в BigQuery, предоставляемый шаблоном GCP (Java).
• Каким-то образом Dataflow сообщает о более медленном конвейере, чем то, что мы на самом деле видим.

Answer 2

Преобразования Apache Beam в Чтение / Запись из источников данных имеют ряд оптимизаций / уловок.

Преобразование Apache Beam, которое выполняет потоковые вставки в BigQuery, не является исключением. выполняет пакетирование строк перед записью в BigQuery. Это может добавить несколько секунд, чтобы данные были доступны для запроса.

Это также тот случай, когда BigQuery выполняет ряд фоновых задач для оптимизации запросов. Потоковые вставки добавляются в специальный буфер, который затем загружается в таблицу. Это может добавить дополнительную задержку для доступности данных.

FWIW, 1-2 часа звучит как слишком большая задержка.

---

Ознакомьтесь с интересным сообщением в блоге о жизни потоковой вставки

Answer 3

Кажется, теперь работает как ожидалось. Похоже, что были некоторые периодические проблемы, данные застревали в потоковых буферах BQ на несколько часов, а также не могли ставиться в очередь с помощью обычного оператора SELECT ...