Как экспорт Continuous-Data определяет время проглатывания в случае, если вход является запросом

Question

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

UPDATE

Добавление этого обновления, поскольку мне нужно больше разъяснений по поводу ответа @ yifat.

Итак, допустим, мой запрос относится к трем таблицам t1, t2, t3. Я создал следующую диаграмму, чтобы изобразить мою путаницу: -

Как видно на диаграмме, текущий экземпляр выполнения в любом случае будет гарантировать, что он получит данные для всех 3 таблиц с момента последнего экспортированного курсора. Так, как добавление принудительной латентности имеет значение? Диаграмма проиллюстрирует то, что я не правильно понял. Спасибо.

Answer 1

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

Например, предположим, что запрос inner объединяет таблицу T1 с таблицей T2 по ключу K, и вы ожидаете, что записи для того же K в обеих таблицах появятся примерно в одно и то же время. Теперь предположим, что в момент времени t0 происходит вход в T1 с ключом K1, в момент времени t2 происходит вход в T2 с ключом K1, и между ними в момент t1 выполняется непрерывный экспорт. В этом случае при экспорте будет отсутствовать K1 в наборе результатов, поскольку он выполняет внутреннее соединение, а у T2 еще нет K1. Следующий цикл экспорта также не будет включать эту запись, поскольку он будет включать только записи, которые были приняты после t1, но не включают K1 в T1. Принудительная задержка вызывает некоторую задержку для курсора, так что включаются только записи старше ForcedLatency. В этом примере записи в T1 будут «ждать» записи в T2.

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