时序数据流场景下的高效时间转化算法

孙景乐　王成华

摘要：该文针对时序数据的特点提出一种高效的时间转化为字符串格式的算法，该文算法在时序数据场景下转化效率是Linux系统API（strftime）的4倍以上，在极端非序列场景下也接近系统的API效率（0.986倍），综合性能优于系统API，在日常开发过中可作为系统API的替代函数使用。

关键词：时序数据;时间格式转换;Linux  系统;API;strftime

中图分类号：TP311    文献标识码：A

文章编号：1009-3044（2021）03-0127-02

1前言

在分散控制系统[1]以及其他监测系统中，时间戳是监测数据的重要属性，且数据具有按照时间顺序发生的特点[2-3]。Linux系统下，时间的完整格式一般由两个32位的整数表示①，第一个整数表示距离1970年1月1日0时0分0秒的秒数[4]，第二个整数表示相对于第一个数的微秒数。但是这种时间格式对于人类来说不直观，在存入历史库或在界面显示数据时，需要将整数格式的时间转化为直观的字符串格式。在Linux平台下，系统API函数strftime[5]可以将时间转化为字符串格式。虽然该函数已经过充分优化，具有较高的效率，但高频率调用系统API函数会导致用户CPU占用率和系统CPU占用率升高，极端情况下可达100%，导致系统不能正常运行。本文利用strftime函数，在转化的机制上提出一种改进的时间转换算法，时序场景下效率可提高4倍多。

2算法原理及实现逻辑

该算法与时序数据时间戳的特点密切相关，本算法充分利用了数据的时序性，并结合计算机数据处理的特性实现。

2.1 软件开发过程的时间处理方法

当前主流的操作系统主要有Windows和Linux系统，两种操作系统提供的日期时间表示方法思路也非常类似，都是通过使用整数表示距离某个历史特定时刻的100纳秒数或秒数。当在用户界面显示时间戳时，需要将时间的整数形式转化为人类更容易理解的字符串格式，例如，“2020年6月10日 13：35：40.622”。Windows系统和Linux系统都提供从整数格式转化为字符串格式的API函数。

2.2 时序系统的特点

在监测系统中，监测点数据一般都是按照时间顺序周期采集，例如50毫秒采集一次或更长的间隔采集一次，所以在一秒之内，时间戳的秒级时间数值不变，仅毫秒和微秒在变化。例如，当前某监测点在“2020-6-6 18：30：12.100秒采集一次数据，后面每隔50毫秒采集一次数据，在[“2020-6-6 18：30：12.000”， “2020-6-6 18：30：13.000”）之间时间戳的秒都是”2020-6-6 18：30：12”，变化的仅仅是毫秒级别的时间，所以不需要对每个时间戳都调用系统API对时间戳进行转化，可以充分前面的转化结果，避免重复转化，提高效率。特别在监测点数高达数十万，甚至数百万的大型系统中，一秒内会产生大量的数据，进行时间格式转化的频率非常高。

2.3  高效算法的基本思路

根据时序数据的时间戳特点，提出了更高效的时间转化算法，思路如下：

1）分配缓存空间，存放最近n（一般为n=2即可）秒时间内的转化结果，存放数据包括秒数及对应的时间字符串;

2）针对当前要处理的时间戳，先在缓存中查找是否已经转化过该时刻的秒数。如果已转化，则直接利用转化好的字符串与时间戳中小于秒的部分（毫秒或微秒等）进行字符串拼接，得到一个完整的字符串格式的时间戳;如果找不到，则调用系统API进行格式转化，并将转化结果替换掉缓存中最旧的转化结果，然后拼接毫秒和微秒部分的字符串，最后输出完整的时间字符串格式，算法的流程图如图1所示。

2.4 极端情况下的本文算法效率分析

该算法是根据时序数据的特点提出的，所以针对时序数据会有较高的效率。如果在极端非时序数据情况下，则需要对该算法的效率进行分析。所谓极端情况，即任意相邻两次的时间差都大于缓冲次数n，在缓冲区中不能找到已有转化，所以每次转化都需要调用系统API进行转换。此时，本文算法的效率就退化为比直接调用系统API效率略低的算法。之所以比系统API效率低是因为快速算法比直接调用系统API多执行了在缓冲区查找转化结果的过程。由于缓冲区次数n一般为2，所以查找时间非常短，所以即使在极端情况下，快速算法的效率也接近系统API的效率，后面的实验数据也充分验证了这一点。

4性能验证

4.1实验方案

实验方案分为两部分：一种是在时序数据环境下进行效率对比，另一种是在极端情况下进行效率对比。

1）时序数据场景下对比

因为该算法是与数据的时序性密切相关的，所以实验过程中数据的变化也模拟了时序系统的特点。给定一个时间初始值t0（由秒和微秒两部分组成），每间隔1秒，t0中的秒部分增加1秒，微秒的数值部分每执行一次转化后都会发生变化。

2）极端非时序场景下对比

该情况下时间的秒数采用随机产生的方法，新的时间能在缓存中找到的概率非常低，几乎每次都需要调用系统API函数进行转化。

4.2实验环境

实验环境是在VMWare虚拟机上的Linux操作系统（Ubuntu18），两种算法都是在同一环境下比较，所以可以保证实验结果的客观性。

4.3实验结果

实验中分别调用系统API和本文算法进行时间格式转化，在相同的运行环境下分别运行约10秒、20秒和30秒，统计两个算法执行时间转化的次数，计算每次的平均运行速度，最后在计算综合平均速度进行比较，实验数据如表1所示。

本文算法的三次综合平均速度为：1036.5万次/秒，系统API算法的三次综合平均速度为238.9万次/秒。实验数据表明，本文算法的运行效率远远高于系统API算法的效率，大约是系统API算法的4.34倍。

非时序情况下，本文算法平均计算速度为235.6万次/秒，是系统API效率的0.986倍，略低于系统API的效率。

5 總结

在具有时序特点的监控系统场景下将时间格式转化为字符串格式，本文算法的效率是系统API函数（strftime）的4倍多;在极端情况下，本文算法的效率是系统API算法效率的0.986倍，效率基本相同。所以，在日常开发过程中，该快速算法完全可以用来替代直接调用系统API函数。

注释：

不同的系统采用的时间机制不同，本文主要以Linux系统下的时间表示方法进行叙述.

参考文献：

[1] 百度百科. 分散控制系统[EB/OL].[2020-08-04]. https：//baike.baidu.com.

[2] 王红涛，王志超，陈峰，等.基于时序数据库的工业大数据应用研究[J].重型机械，2020（4）：17-21.

[3] 林志达，张华兵，张今革.基于时序数据库的监控数据存储方法研究[J].电子元器件与信息技术，2020，4（1）：73-74，100.

[4] 百度百科. unix时间戳[EB/OL].[2020-08-04]. https：//baike.baidu.com.

[5] 小丁木. linux中常用时间和字符串之间相互转化[EB/OL]. （2017-07-11）[2020-07-04]. https：//www.cnblogs.com/xiaodingmu/p/7152396.html.

【通联编辑：闻翔军】