数据文件按时间auto rolling

[zptan]

文档在此: 数据收集

问题

目前cris收集数据不会auto rolling，这意味着

• 无法做到按天切割数据进行传输
• 不方便清理旧数据，硬盘占用会持续增加，直至用完

提议

我目前的思路是：为RecordFile加上auto rolling机制(暂时仅考虑按天)，对外层的caller透明

• 为RecordFile加一个field today_，表示当前日期，e.g., 20230224，启动时设置，并创建相应目录
• 对于每个对RecordFile::Write()的调用，都计算当时的日期，与today_比较
  • 如果相同，说明是同一天，写入数据
  • 如果不同，说明已经是新的一天
    1. 关闭当前LevelDB，会触发Compact()，如果数据量比较大，这里可能会比较耗时，是否需要优化要看实际耗时情况
    2. 更新today_，并创建相应目录与LevelDB目录，写入数据

https://github.com/cyfitech/cris-core/blob/ebe55b6e6a5c05b15847c3810b8031fa0c11a47d/src/msg_recorder/record_file.h#L44-L48

我设想的行情数据目录层次结构如下 https://github.com/cyfitech/cris-base/issues/146

[zptan]

@chenhao94 @maoxiaoyun1963 @xkszltl @yanglu1225 你们觉得怎么样？

[xkszltl]

无法做到按天切割数据进行传输

是的这是一个比较大的问题，我本来想的是定期snapshot出来，只roll snapshot，但确实没法支持delta传输。 或者可以考虑另外写个比较俩leveldb生成delta的工具。

不方便清理旧数据，硬盘占用会持续增加，直至用完

我觉得旧数据不该清理，收到的数据都是很珍贵的

[xkszltl]

如果不同，说明已经是新的一天

要小心时钟不单调的情况

[zptan]

我觉得旧数据不该清理，收到的数据都是很珍贵的

数据肯定要传到咱们自己的机器上，但线上机器的数据不能持续增加，硬盘空间有限

[xkszltl]

线上的确实需要，但这块我觉得要先估算一下数据量在做，小时/天/周级别的rolling需求实现方式上很可能不一样，越短越接近streaming，而长了可能不需要，反而定期重启避免有什么东西慢慢泄露或者跑飞了更符合业务需求。

[zptan]

线上的确实需要，但这块我觉得要先估算一下数据量在做，小时/天/周级别的rolling需求实现方式上很可能不一样，越短越接近streaming，而长了可能不需要，反而定期重启避免有什么东西慢慢泄露或者跑飞了更符合业务需求。

我们只有by day的需求，按天重启听起来不是个合适的办法

[zptan]

线上的确实需要，但这块我觉得要先估算一下数据量在做

我之前收过HUOBI FUTURE_BTC_USD_THIS_QUARTER的数据，接近5天时间，660MB（默认，Snappy压缩），平均每天~130MB，服务上线后会收集top100 活跃的交易对，BTC_USD算是最活跃的交易对，但是总体的数据size每天至少是GB这个量级

如果其他交易所的交易比HUOBI更活跃，那数据就更多

[xkszltl]

• 如果rolling的考虑是size，那是否应该按照大小切割？
• 按天rolling如何解决我问的时钟不单调的问题

[zptan]

如果rolling的考虑是size，那是否应该按照大小切割？

我们的需求是按天拿数据做回测，按size切割不是不行，但数据拿回本地后还需要按天切割，还不如一开始就按时间切割

按天rolling如何解决我问的时钟不单调的问题

@maoxiaoyun1963 确认以本机收到数据的时间（本机时间）为准，可以用chrono steady_clock

[xkszltl]

但数据拿回本地后还需要按天切割

数据拿回本地应该合并起来吧？切了干嘛？

确认以本机收到数据的时间（本机时间）为准

本机的钟也会变哦，steady_clock的话保证跨进程/reboot的单调性吗？

[zptan]

但数据拿回本地后还需要按天切割

数据拿回本地应该合并起来吧？切了干嘛？

因为回测需求是按天使用，支持获取两个日期之间的数据，并不是存起来就可以了

而且本地存储也不是无限的，我们预计保存近一年的数据，超过期限的数据要删除，也需要时间戳

本机的钟也会变哦，steady_clock的话保证跨进程/reboot的单调性吗？

我查到Linux下steady_clock的实现使用的是clock_gettime(CLOCK_MONOTONIC)，后者文档里写着

A nonsettable system-wide clock that represents monotonic time...

既然是system-wide，那应该没问题吧

[xkszltl]

是会倒挂的，你可以依赖这个去切，但不能假设一天只有exactly 1份，有可能0，有可能多份，回传和merge的逻辑要能处理。

On Linux, that point corresponds to the number of seconds that the system has been running since it was booted.

[xkszltl]

我们预计保存近一年的数据，超过期限的数据要删除，也需要时间戳

本地存储的边际成本（只算盘体）￥200/TB，MTBF>5年，年均一杯咖啡，很便宜的，我觉得没有删除的必要。

[xkszltl]

我们可以先存1PB再考虑删除的事情。 数据也是资产，说不定哪天我们用不上了还能拿来卖呢。

[zptan]

我们可以先存1PB再考虑删除的事情。 数据也是资产，说不定哪天我们用不上了还能拿来卖呢。

这个没问题

[zptan]

是会倒挂的，你可以依赖这个去切，但不能假设一天只有exactly 1份，有可能0，有可能多份，回传和merge的逻辑要能处理。

On Linux, that point corresponds to the number of seconds that the system has been running since it was booted.

没明白，如果我以日期（例如，20230224）为LevelDB文件目录名，那么拿到时间戳算出来的时间的日期就是一个确定的值，打开对应的LevelDB文件目录，那一天只可能有一个目录，为什么会有多个？

如果你指的是这个时间戳有较小概率在边界出现偏差，那偏差的值能有多大，几秒？这个精度偏差我觉得没问题，我们不会马上把前一天的数据传走，@maoxiaoyun1963

[xkszltl]

就用你以日期命名的这个例子。 当前过了A-day，有一个目录A，进入了B-day，有一个写了一半的B。 如果重启一下，日期倒退了一天，从B变成A，东西是不是就又会被往A里写了？ 那么此时，是否需要确保：

• 写A的时候不能清空/覆盖既有的A
• 即便A已经传回来了，A里新增的东西还能被回传

如果你不依赖外部时钟，而是做成基于计数器的，时钟只是作为一个”可以切一刀了“的提醒，而重启之后也当做切了一刀，那就没这些问题。

拥有单调且同步的时钟是个很强的假设，拥有严格单调且同步的时钟物理上是不可能的，所以逻辑上尽量避免对时钟的强依赖。

[zptan]

如果重启一下，日期倒退了一天，从B变成A，东西是不是就又会被往A里写了？

为啥重启后日期倒退了一天？

[xkszltl]

为啥重启后日期倒退了一天？

那为啥不会呢？

可能是因为对时，可能是因为调表，可能是因为新的kernel清除了一些配置换了个时区，可能是BIOS电池空了。 原因各种各样，有的会日常发生，有的是个意外，也许都是小概率事件，但既然需要把单调性作为正确性的必要条件，那就要证单调性的存在。