Облачный поток данных Каково точное определение свежести и задержки?

Question

Проблема:

При использовании Cloud Dataflow мы получаем 2 метрики (см. эту страницу ):

1. Системная задержка
2. свежесть данных

Они также доступны в Stackdriver под следующими именами (выдержка из здесь ):

system_lag: текущая максимальная продолжительность, в течение которой элемент данных ожидает обработки, в секундах.

data_watermark_age: возраст (время после отметки времени события) самого последнего элемента данных, который был полностью обработан конвейером.

Но эти описания все еще очень расплывчаты:

1. что означает "ожидание обработки"? сколько времени сообщение ждет в pubsub? или общее время ожидания внутри конвейера?
2. «максимальная продолжительность»: после обработки этого максимального элемента метрика будет скорректирована?
3. «время с момента отметки времени события» означает ли это, что если мое событие было помещено в pubsub с отметкой времени t1 и оно вытекает из одного конца конвейера с отметкой времени t2, конвейер находится в точке t1? Я думаю, что могу предположить, что, если метрика находится в t1, все до t1 можно предположить обработанным.

Вопрос:

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

Answer 1

Эти показатели заведомо хитры. Подробное описание их работы можно увидеть в этом выступлении члена команды Beam / Dataflow .

Конвейеры разделены на серии вычислений, которые происходят в памяти, и вычислений, которые требуют сериализации ваших данных в какое-то хранилище данных. Например, рассмотрим следующий конвейер:

with Pipeline() as p:
  p | beam.ReadFromPubSub(...)  \
    | beam.Map(parse_data)
    | beam.Map(into_key_value_pairs) \
    | beam.WindowInto(....) \
    | beam.GroupByKey() \
    | beam.Map(format_data) \
    | beam.WriteToBigquery(...)

Этот конвейер будет разбит на две ступени . Этап - это серия вычислений, которые можно применять в памяти.

Первый этап переходит от ReadFromPubSub к операции GroupByKey. Все, что находится между этими двумя PTransforms, может быть сделано в памяти. Для выполнения GroupByKey данные должны быть записаны в постоянное состояние (и, следовательно, в новый источник).

Второй этап проходит от GroupByKey до WriteToBigQuery. В этом случае данные считываются из «источника».

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

-

Отвечая на ваши вопросы:

1. Что ожидает обработки?

Ответ

Сколько времени элемент ожидает в PubSub. В частности, сколько времени элемент ожидает внутри любого источника в конвейере.

Рассмотрим более простой конвейер:

ReadFromPubSub -> Map -> WriteToBigQuery.

Этот конвейер выполняет следующие операции для каждого элемента: Read an item from PubSub -> Operate on it -> Insert to BigQuery -> **Confirm to PubSub that the item has been consumed**.

Теперь представьте, что служба BigQuery не работает в течение 5 минут. Это означает, что PubSub не будет получать подтверждения ни для одного из элементов в течение 5 минут. Следовательно, эти элементы на некоторое время застрянут в PubSub.

Это означает, что задержка системы (а также показатель актуальности данных) будет увеличиваться до 5 минут, пока блокируются записи BQ.

2. Корректируется ли максимальная продолжительность после обработки?

Ответ

Это верно. Например, рассмотрим предыдущий конвейер снова: BQ не работает в течение 5 минут. Когда BQ возвращается, в него может быть записана большая партия элементов, и подтверждается как прочитанное из PubSub. Это резко сократит задержку системы (и актуальность данных) до нескольких секунд.

3. Сколько времени прошло с отметки времени события?

Ответ

В качестве атрибута сообщения для PubSub может быть указана временная метка события. Это немного хитрая концепция, но по сути:

Для каждого этапа есть водяной знак выходных данных. Водяной знак выходных данных T указывает, что вычисление обработало все элементы со временем события до T. Самым последним водяным знаком выходных данных может быть самый ранний входной водяной знак из всех вычислений в восходящем направлении. Однако выходной водяной знак может быть задержан, если есть некоторые входные данные, которые еще не были обработаны.

Этот показатель, конечно, эвристический. Если какая-то точка данных поступает очень поздно, то актуальность данных будет сдерживаться.

-

Я бы посоветовал вам проверить разговор Славы . Это касается всех этих понятий.