[Idea] 关于进一步细化 OpenRank 计算周期的可行性

[frank-zsy]

目前全域 OpenRank 和社区 OpenRank 均以自然月为单位进行计算，但也有不少人提出希望可以进一步细化 OpenRank 的计算间隔，以股市为例，股价是实时变化的，而对于股票的长期分析一般可以细化到天。

目前提出一种按照每日进行全域 OpenRank 计算的可能方案，涉及到几个重要的点：

• 全域节点的衰减比例。目前全域 OpenRank 计算中，所有节点无论是否活跃每月都有固定 85% 的衰减，以避免 OpenRank 全域价值的无限增长。如果计算周期是按天进行，那么此时的衰减比例要做一定的调整，可以是 0.85^(1/30)，大概是 0.995。即每天所有节点的衰减比例是 99.5%。
• 开发者节点的新增 OpenRank 值。目前全域 OpenRank 计算中，所有新增节点的初值均为 0，需要由开发者节点活跃为网络带来新增价值。目前使用的归一化方法是 sigmod 归一化，横轴平移 44.08，即全月全域所有开发者活跃度的上四分位数均值 88.16 的一半。但如果使用按天计算，这里的参数需要做相应调整。2024 年每日全域所有开发者的活跃度上四分位数均值是 55.38，即横轴平移需调整为 27.69。但这种变化带来的影响目前不可知，体感上而言，这种方式下按天计算的全域 OpenRank 总值增长可能比按月要快，也可能是等价的，不是很确定。
• 工程实现。如果按天计算且与按月计算的结果基本相同，则按天更新是完全可行的，因为按月计算每次计算大约只需要十分钟左右即可完成，而按天计算的网络规模要小很多，速度也会更快。但工程实现方面需要有一些改变，在按月计算中，我们每月计算当月活跃仓库和开发者后，不活跃的仓库和开发者节点也会把衰减结果存回表中待用。但按天计算会导致活跃仓库的数据点很多，如果为每个在当天不活跃的仓库和开发者也存储衰减后的数据，会导致大量的存储浪费和表的扩张。因此需要修改 OpenDigger 中的实现方法，不再存储当天不活跃的仓库和开发者的衰减数据，而是在计算时动态从历史数据中获取。PS. 目前全域 OpenRank 表中正常数据和衰减数据比例大概为三比一。
• 数据说明：目前全域 OpenRank 计算使用自然月数据，而且使用的 UTC 时区，与中国时区有 8 小时的时差。当按月计算时，该时差导致的数据差异是可以忽略不计的，但按天计算时 8 小时的时差占到一天的三分之一，可能会使大家有非常明显的体感差异。当然中国也可能不会，因为差异的八小时为 0-8 时，此时活跃度并不高。但例如美国可能会有比较明显的差异感受。因此需要额外的数据说明来让大家理解这种差异的原因。

解决上述问题后，是有可能将全域 OpenRank 计算更换到按天更新的级别的，当然按天更新会带来较大的硬件压力和开销。