#google-cloud-dataflow #apache-beam
# #google-cloud-поток данных #apache-beam
Вопрос:
У меня есть конвейер, который работает с потоком данных Google и считывается из паба / суб. Я использую метрики, в основном счетчики, чтобы получить представление о том, сколько событий было обработано. Общая идея заключается в том, что он считывает сообщения protobuf из pubsub, десериализует их и сбрасывает в разные таблицы BigQuery. У меня есть счетчик в ParDo, который выполняет десериализацию, а также счетчик в ParDo, который выполняет вставки в BQ. В большинстве случаев разница между конечным счетчиком и начальным счетчиком велика, примерно на 40%. Время обработки на этапах конвейера постоянно увеличивается, но свежесть данных и системная задержка для конвейера действительно невелики, примерно около 30 секунд…
Почему это происходит? Что-то связано со счетчиками? 
Вы можете увидеть size_ok метрику, которая является первой метрикой из конвейера, и если вы суммируете все приведенные ниже метрики, вы даже не приблизитесь к этому числу.
Мой вопрос в том, почему существует такая большая разница между метрикой size_ok, которая представляет собой общее количество событий, которые начали обрабатываться, и inserts метриками. Если вы суммируете все метрики вставки, они не могут суммировать до 6,6 миллионов событий, как показано size_ok
Комментарии:
1. Можете ли вы уточнить, о чем именно у вас есть вопросы? Вы спрашиваете, почему может быть несоответствие в метриках size_ok и inserts? Или вас беспокоят показатели времени работы / свежести данных / задержки системы? И если это последнее, что вы думаете об этих показателях?
2. Используете ли вы идентификатор с меткой времени при чтении в PubSub? beam.apache.org/releases/javadoc/2.26.0/org/apache/beam/sdk/io /… Если да, может ли разница быть связана с поздними данными?
3. Я не использую его, потому что сообщения представляют собой сериализованные байты protobuf… Итак, сначала мне нужно их декодировать, и я использую временную метку из декодированного сообщения.