如果输入是查询,连续数据导出如何确定摄取时间

How does Continuous-Data export determine Ingestion time in case the input is a query

每当定义连续导出实体时,它都会将查询作为其输入。如果查询只是一个 table 名称,就很容易理解导出是如何发生的。 table 中记录的摄取时间必须在导出实体 运行 时针对不同的时间点进行考虑。但是,如果查询是实际的 'query' 怎么办,我的意思是说正在使用各种管道运算符在 table 之上应用一些转换。在那种情况下,查询的结果是动态的,数据不会在任何地方被摄取。这是否意味着连续导出实际上只考虑查询中最左边实体的摄取时间,这显然是一些 table,因此显然确实将摄取时间存储为其记录的一部分。

更新

添加此更新,因为我需要对@yifat 的回答进行更多说明。

所以假设我的查询是指三个 tables t1、t2、t3。我创建了下图来描述我的困惑:-

正如您在图表中看到的那样,当前 运行 实例无论如何都会确保它将获取自上次导出游标以来所有 3 table 的数据。那么添加 forcedLatency 有什么不同呢?该图将说明我没有正确理解的内容。谢谢

连续导出保存上次导出的数据库游标,每个连续导出作业仅考虑自该数据库游标以来摄取的记录。这适用于查询引用的 all tables,无论查询包含多少个运算符和哪些运算符。因此,如果您的查询包含连接,建议将 forcedLatency 选项设置为参与连接的 table 的最大预期延迟。

例如,假设查询 inner 在键 K 上将 table T1 与 table T2 连接起来,并且您希望在两个 tables 大约在同一时间到达。现在假设在时间 t0,有一个使用密钥 K1 的摄取到 T1,在时间 t2,有一个使用密钥 K1 的摄取到 T2,并且在时间 t1 之间连续导出运行。在这种情况下,导出将错过结果集中的 K1,因为它执行内部联接而 T2 还没有 K1。下一个导出周期也不会包含此记录,因为它只会包含在 t1 之后摄取的记录,而 T1 中不包含 K1。 Forced latency 强制对游标进行一些延迟,以便仅包括比 ForcedLatency 更早的记录。在此示例中,T1 中的记录将为 T2 中的记录"wait"。

如果导出查询包含单个 table,则不需要 forcedLatency。 如果您不希望所有 table 都限定在数据库游标范围内,您可以使用 'over' 参数指定应考虑哪些 table。如果您要加入维度 table 并希望每个查询考虑 all 记录,这将很有用。