如何在时间尺度上为历史数据设置连续聚合



我想有物化数据自动计算作为新的(无论历史)数据来。

我的数据是由用户手动添加的历史时间序列(使用应用程序,但手动触发数据导入)。数据存储在提升为时间刻度的一个表中。每次用户添加大约36000行,采样率为100ms(大约一小时的数据)。第一个示例永远不会绑定到一个小时的开始,并且,数据的以下部分也不是强制绑定到前一部分(可能有间隙)。

我想要的是将数据物化到10分钟,1小时,1天的桶中,并且数据物化过程应该自动运行。

我的第一个困惑是我应该创建continuous_aggregate_policy后,我创建连续聚合。目前我不这么做。当我插入数据的第一部分(使用简单的INSERT)时,我可以看到数据成功具体化了(我通过设置timescaledb.materialized_only = true来检查这一点)。然后,当我添加更多的数据时,它没有实现。我找到了调度器作业(只有一个作业),并试图像SELECT alter_job(1, next_start => now());一样重新调度它,但没有发生任何事情,数据仍然没有实现(我看到last_run_status是成功的,last_successful_finish更改为我运行查询时的时刻)。然而,hypertable_schemahypertable_name字段是NULL,所以我想知道这个后台工作是否会做任何事情。

添加continuous_aggregate_policy看起来不合乎逻辑,如果我添加历史数据(如1小时长的数据,但1年)。据我所知,continuous_aggregate_policy只更新最近的数据。

我的选择是通过调用CALL refresh_continuous_aggregate('conditions', '2020-01-01', '2020-02-01');添加数据后手动实现数据吗?如果我在插入数据时不手动执行此操作,数据将不会具体化吗?在手动刷新的情况下,如果我的应用程序在提交新数据和调用连续聚合刷新查询之间由于某种原因失败,我担心可能出现数据不一致。在这种情况下,我可以在一个查询中完成这两个操作吗?如果这个查询失败了怎么办?如何知道数据是否已提交?许多起义问题…

我的项目的下一步将是自动化数据摄取,因此与用户的交互和该过程的监督被排除。

那么,为手动添加的历史数据自动创建物化数据的正确策略是什么?

注:在插入新数据后重新创建物化视图是不可行的,因为这需要几天的时间才能完成。

我假设TimescaleDB版本是2.x。在2.0之前,创建连续聚合视图总是创建相应的策略。这种变化和动机在Changes in TimescaleDB 2.0中有描述。

需要为每个连续聚合创建连续聚合策略,否则数据不会自动具体化到连续聚合中。我不确定你最初是如何将数据放入连续聚合的。

这个工作是关于什么的?您可以在timescaledb_information.jobs中查看现有的作业。TimescaleDB通常为遥测创建一个作业,所以它可能是。

当您创建一个策略来刷新连续聚合时,请确保选择一个刷新窗口,该窗口将在策略运行时覆盖新插入的数据。参见start_offsetend_offset参数。注意,只有完全覆盖的桶才会被刷新。覆盖旧数据应该不是问题,因为TimescaleDB会跟踪由于新插入或更新数据而导致的无效桶,并且不会刷新没有发生更改的桶。

最新更新