导语：探讨了利用时序数据库管理系统应对上述问题的关键技术结合现有时序数据库管理系统在部分工业领域中的应用及关注度趋势对其未来发展方向进行了展望
时间序列数据（简称“时序数据”），顾名思义，是以时间顺序作为组织形式的数据。时序数据这一概念早期起源于金融行业，金融时序分析技术是考察金融变量随时间演变规律的关键技术，是金融量化分析的基础技术。对规模巨大的金融时间序列进行有效分析的前提是对时序数据进行有效管理。
当前，时序数据的概念已经渗透到各行各业。随着工业互联网、智能制造等领域的兴起，工业环境复杂度越来越高。在工业检测数据中，时序数据占据80%以上，且主要来源于各类实时监测设备。因此，对时序数据进行高效管理，对提高工业生产效率而言至关重要。时序数据库管理系统作为存储和管理时序数据的专业化数据库管理系统，受到了更多关注。
时序数据结构并不复杂，其典型特点是产生频率快、严重依赖于采集时间。对于少量时序数据，添加时间戳键值，将数据存储在传统数据库中即可，但在面对产生于终端设备的、写入并发量比较高的海量数据场景，传统数据库管理系统在存储与管理方面遇到了困难。常用的关系型数据库管理系统在时序数据压缩方面表现不佳，维护成本高，单机写入吞吐量低，难以应对交易处理等需要对海量数据进行聚合分析的场景。分布式计算框架（Hadoop、Spark等）虽然能够比较高效地处理海量数据，但在时序数据调用方面也存在问题：在离线批处理系统中，数据从产生到可分析的耗时长；查询性能差，索引利用效率低；依赖特定计算模式，兼容性不佳。因而，有必要为海量的时序数据设计相应的时序数据库管理系统，其需要解决的问题有：提高海量数据写入效率、降低数据压缩成本、有效支持时序数据统计分析等。
本文旨在探讨利用时序数据库管理系统应对上述问题的关键技术，并结合现有时序数据库管理系统的发展现状，展望其未来发展方向，以期为学术界和工业界从事相关领域研究的同仁提供参考。
1 时序数据库的关键术语
时序数据库中涉及很多术语，以下简要介绍部分关键术语。
（1）时间序列（series）：以一个或若干个指标作为采集对象，随着时间的流逝，源源不断地产生的数据。
（2）度量（metric）：与SQL中表的概念相似。
（3）标签键（tag key）：组成标签的键值对的键部分。是字符串，并存储了元数据。由于标签键可被索引，所以对其进行查询通常非常高效。
（4）标签值（tag value）：组成标签的键值对的值部分。其他特点与标签键相同。
（5）域（fields）：数值列。存放用户的时序数据。
（6）点（point）：表示单条数据记录，类似于关系型数据库中的一行记录。每个点都由一个度量、一个标签集合、一个域键、一个域值和一个时间戳组成；点由它所属的序列和时间戳唯一标识。
（7）时间戳（Timestamp）：与一个点关联的日期和时刻。
2 时序数据库的写入
本章从分布式存储出发，考虑LSM-Tree数据结构和TS引擎，形成了时序数据库进行高速数据写入的技术支撑。
2.1 分布式存储
通常，分布式数据库有两种分片（sharding）策略：范围分片（range sharding）和哈希分片（hash sharding）。前者适用于基于主键的范围扫描，后者适用于离散大规模写入以及随机读取。最简单的hash策略是采用取模法，该方法的弊病为取模基础需固定，一旦取模基础变化，就会发生数据重分布。可以采用更加复杂的一致性hash策略来缓解数据重分布影响。
对于时序数据库来说，基于时间的范围分片（time range sharding）是最合理的考虑，但如果仅仅使用time range sharding，会有写入存在热点的严重问题，基于time range sharding的时序数据库写入必然会落到最新的数据分片上，而旧的数据分片不会接收写入请求。对于对写入性能要求高的时序数据库来说，热点写入不是最优方案。
若要解决这个问题，可以使用hash进行再次分区。基于key的hash分区方案可以通过散列很好地解决热点写入的问题，但同时会引入如下问题：
（1）导致键范围扫描（key range scan）性能较差。按照series进行hash分区，就可以将相同series的时序数据放在一起，key range scan性能因此可以得到保证。
（2）hash分区的个数必须固定。如前所述，如果要改变hash分区数，会导致大量数据重分布（除非使用一致性hash算法）。
2.2 LSM-Tree
LSM-Tree是一种分层、有序、面向磁盘的数据结构，其核心思想是充分利用磁盘批量的顺序写比随机写性能高出很多的优势，如图1所示。
图1 磁盘写性能比较
围绕这一原理进行设计和优化，让磁盘写性能达到最优。这种设计虽然存在数据修改和删除的困难，但幸运的是，在时序存储的场景，不存在需要对数据进行修改和删除的情况。因此，LSM-Tree结构大大提高了数据的写入能力。但是，其查询性能受到一定的影响，因此写多读少也是适配场景重要的课题。
在 LSM-Tree 中，核心的磁盘数据结构是SSTable。SSTable是一种持久化的、有序且不可变的键值存储结构，它的key和value都是任意的字节数据，提供了按指定key查找和在指定范围的key区间迭代遍历的功能。SSTable内部包含了一系列可配置大小的block块，典型的大小是64 KB。
这些block块的index存储在SSTable的尾部，用于帮助快速查找特定的block。当一个SSTable被打开时，index会被加载到内存，然后根据key在内存index里面进行一个二分查找，查到对应偏移量之后，从磁盘把响应的块数据读取出来。
2.3 TS引擎
2.3.1 TS引擎核⼼基⽯
时序数据写入内存之后按照series key进行组织，即metric + tag set。可将series key视为一个数据源，不断产生时序数据，只要数据源还在，时序数据就会一直产生。
2.3.2 TS⽂件结构
T S 文件的组织和 HBase 中 的 HFile 基本相同，核心由时序数据存储（series data section）以及时序索引块（series index block）两个部分组成。
（1）时序数据存储。时序数据在内存中表示为一个map。map执行flush操作形成TSM文件。最简单的写入策略是将map中一个key对应的一系列时序数据在内存中构建成block，并持久化到文件。如果key对应的时序数据过大，可能导致存储数据块超过其阈值，因此在实际中可能会将同一个key对应的时序数据构建成多个连续的数据块，但同一个数据块中只存储同一个key的数据。另外，map按照key顺序排列并执行写入操作，是索引构建的基础。
（2）时序索引块。用户根据key查询某段时间内的时序数据，如果没有索引，就需要将整个TS文件加载到内存中进行查找，占用内存且效率低下。为了解决此问题，TS文件引入了索引，与HFile文件索引基本相同，由一系列series index block组成。
2.4 时序数据写⼊流程
数据写入引擎与倒排索引引擎一样，是一个LSM（Log Structured Merge）引擎，基本流
程是先写WAL（Write-Ahead Logging），再写cache，最后满足一定阈值条件之后将cache中的数据写入到文件。
2.4.1 WAL追加写⼊
时序数据首先格式化为WriteWALEntry对象，然后经过snappy压缩后写入WAL，并持久化到文件。
2.4.2 时序数据写⼊内存结构
（1）时序数据点格式化。将所有时序数据点按时间线形成一个map，即将相同key的时序数据集中放在一个list中。
（2）时序数据点写入cache。cache是一个crude hash ring，由256个数据划分构成，每个数据划分负责存储一部分key对应的值，即数据写入cache时根据hash结果映射到不同的数据划分。每个HashMap内部在写时需要加锁，可以减小锁粒度，提高写性能。
数据缓存刷新（data cache flush）流程如下：
（1）触发时机：一是当cache大小超过25 MB阈值大小；二是超过10 min阈值，没有时序数据写入WAL。
（2）基本流程：
① 内存中构建series data block。遍历内存map中的时序数据，对其时间列和数值列编码后，按照series data block的格式进行组织，当block大小超过一定阈值时，构建成功。
② 将构建好的series data block写入文件。使用输出流将内存中数据输出到文件。
③ 构建文件级别B+树索引。使用series data block在文件中的偏移量、总大小以及最小时间、最大时间构建index entry对象，写入内存series index block对象。一个key对应的所有时序数据都持久化完成后，一个series index block就构建完成，然后填充index block meta信息。接着，新建一个series index block，开始构建下一个key对应的数据索引信息。
3 数据压缩
时序数据库中的数据块均需要通过数据压缩来降低存储成本，不同类型的数据所需要的压缩算法不同。以下分别对时间戳、浮点数、整数、布尔值和字符串的压缩进行介绍。
3.1 时间戳压缩
delta-of-delta算法可以极大地降低数据存储成本，提高数据写入、查询性能。时间戳一般采用long类型进行存储，需要占用8字节的存储空间。优化方案为存储时间戳的差值。有2种常用的实现思路。
3.1.1 思路1
假设起始时间戳为1571889600000，delta的最大范围阈值为3 600 s。
表1 相邻时间戳差值
相邻两个时间戳的差值：
计算步骤如表1所示。
与起始时间戳的差值：
计算步骤如表2所示。
表2 与起始时间戳差值
每个delta的数值需要13 bit存储。因此以上时间戳数据共占用空间为64 + 13×4 = 116 bit。
3.1.2 思路2
思路2的优势是无需对块内数据依次遍历，但相比思路1可能需要更为频繁地更换起始时间，可根据实际需求选择合适方案。
表3 压缩方案
针对不同时间跨度的数据，Facebook Gorilla给出的通用处理方案如表3所示。
表4 压缩效果
delta-of-delta编码的压缩效果如表4所示。
delta-of-delta思 路2的算法原理为：计算相邻时间戳差值后，再进行差值的差值的计算并存储。占用存储空间对比如下。
delta算法：64 + 13×7 = 155 bit。
delta-of-delta算法（思路2） ：64 + 9×4 + 1×3 = 103 bit。
可见，delta-of-delta算法相比delta算法获得了更高的压缩率。在实际应用场景中，海量时序数据的时间戳都密集且连续，绝大部分满足deltaof-delta=0的条件，可以大幅度节省时间戳的存储空间。
该算法常用于监控数据中时间戳的压缩，可以大幅度降低存储成本和提高写入、查询性能。同时，该算法也存在一定的缺陷。因为该算法是不定长的压缩算法，所以解压后必须从数据块的首地址依次计算。
3.2 浮点数压缩
浮点数是用Facebook的Gotilla paper中的思想进行编码的。将XORS连续的值编码在一起，当这些值很接近时，产生一个小结果。然后，使用控制位存储增量，以指示异或值中有多少前导和尾零。压缩过程是一个字节流（位流）按照一定格式的不断追加。
3.3 整数压缩
整数压缩取决于原始数值的范围。首先使用ZigZag进行编码。原始值是正负整数交错出现的，编码后为正整数。如果所有ZigZag编码值小于simple8b.MaxValue，则使用simple8b编码。 如果有任何值大于simple8b.MaxValue，则使用原始值存储。
3.4 布尔值压缩
布尔值使用简单的位打包策略进行编码，每个布尔值使用1 bit。在块的开头，使用可变宽度编码存储已编码的布尔值数量。
3.5 字符串压缩
字符串使用Snappy压缩进行编码。每个字符串都是连续打包的，它们被压缩为一个更大的块。Snappy压缩算法借鉴了LZ77算法的思路，原理如下：
假设有一个序列 S=[9,1,2,3,4,5,1,2,3,4]，匹配发现子序列S2~5=[1,2,3,4]与S7~10=[1,2,3,4]是相同的，于是将该序列编码为S=[9,1,2,3,4,5,6,(2,4)]，其中2表示开始位置，4表示位数。Snappy的优点是速度快，压缩率合理，在众多开源项目中使用较为广泛。
4 时序数据库管理系统
由于时序数据库的重要性，工业界和学术界已经研发出一些时序数据库管理系统，包括OpenTSDB、Graphite、Prometheus、InfluxDB、CnosDB等。时序数据库的发展大致可以分为三个阶段：第一个阶段使用NoSQL作为后端，通过开发中间件进行时序数据的管理；第二个阶段，研究者们根据时序数据设计其独有的存储结构和读写体系；第三个阶段，研究者们设计了更加灵活的架构，使得时序数据库可以实现灵活的节点伸缩，真正实现了高效的分布式时序数据管理。
（ 1 ） OpenTSDB： OpenTSDB 基 于HBase，非常类似用于长期数据存储的ODS HBase存储层。他们都依赖于相似的表结构，并且对于优化水平区域可伸缩性也存在相似的结论。但是，我们发现高级监视工具所能支持的查询速度比基于磁盘的存储所能支持的查询速度更快。与OpenTSDB不同的是，ODS HBase层虽然确实对旧数据进行了时间汇总聚合，以节省空间，但与较新的ODS中的数据相比，这将导致更早存档的数据具有更短的时间粒度，而OpenTSDB将永久保留完整的分辨率数据。OpenTSDB还具有用于识别时间序列的更丰富的数据模型，每个时间序列由一组称为“标签”的任意键值对标识。
（2）Graphite：Graphite将时序数据以Whisper格式存储在本地磁盘上。此文件格式希望按固定的时间间隔对时序数据进行时间戳记，并且不支持时间序列中的抖动。使用Whisper，每个时间序列都存储在一个单独的文件中，新样本在一定时间后会覆盖旧样本。但是，由于该技术专注于磁盘存储，因此使用Graphite与Whisper相配合时，查询延迟可能会过高。
（3）Prometheus：Prometheus是一个开源的服务监控系统和时序数据库，具有高维度数据模型，底层以键值对的数据存储格式对时序数据进行存储，单个服务器节点自治，即使在故障情况下也可以查看系统中可用的统计信息。但是，该时序数据库在按请求计费数据时无法保证高度的准确性。
（4）InfluxDB：InfluxDB是一个新的开源时序数据库，其数据模型比OpenTSDB更加丰富。时间序列中的每个事件都可以具有完整的元数据集。尽管这种灵活性确实允许提供丰富的数据，但与仅在数据库中存储时间序列的方案相比，它必然导致更高的磁盘使用率。InfluxDB还包含将其构建为分布式存储集群的代码，从而允许用户水平扩展，而无需管理HBase/Hadoop集群。与其他系统一样，InfluxDB将数据保留在磁盘上，这比将数据保留在内存中的查询速度慢。
（5）CnosDB：CnosDB是一款国产的时序数据库管理系统，采用类LSM-Tree的组织形式将数据存储在磁盘上，每一个监控实例都可以在逻辑上区分开。数据以时间为单位进行物理分割，以实现每一个存储单元的生存周期的细粒度控制。每一个存储单元都是一个独立的存储引擎，这样可以保证使得数据查询和写入性能达到极致。CnosDB追求以下两条原则：
1）在Disk I/O性能一定的情况下，追求更高的Disk ByteFlow性能，同时最大程度地兼顾查询的性能；2）在无损的情况下，充分利用列存储的特性，实现有成本竞争力的磁盘占用压缩比；3）在有损的情况下，支持灵活的降准确度、降采样率机制，实现更大的磁盘压缩比。
5 时序数据库在工业中的应用举例
5.1 时序数据库应用于卷烟行业
时序数据库现已被广泛地运用于工业生产监控场景中。比如在卷烟行业，卷烟厂分为制丝车间和卷包车间两个车间。制丝车间的操作人员主要从事烟叶的加料、加香和切丝工作，其生产过程所涉及的数据，比如温度、水分、风量、流量、液位、频率等，就是典型的时序数据。这些数据的产生非常高频且具有实时性，每个监测点每秒会产生海量的数据和进行频繁的写入和存储操作。
时序数据库正是这种场景下的理想选择。相比关系型数据库，时序数据库存储空间占用小、写入性能优越且能实现较快速度的查询和较长时间的历史数据存储。因此，时序数据库可以帮助制丝车间中控管理系统更充分地利用数据。通过时序数据库的应用，卷烟厂可以绘制趋势曲线，从而较为完整地再现数据的实时变化情况。这些数据的精度和密度更高，可以帮助产品和设备进行更精准的质量分析。此外，针对卷烟厂制丝车间对生产环境要求高的特点，时序数据库可以帮助相关工作人员分析发生异常前后的数据或趋势曲线，来制定更准确而有效的应对措施。最后，大部分时序数据库生态是丰富而友好的，其拥有丰富的应用程序接口和服务可供共享调用，使制丝车间的生产和管理更加智能化。
5.2 时序数据库应用于装备制造业
在复杂装备的生产和设计过程中会产生海量的时序数据。由于这些数据此前采用关系型数据库进行存储，因此面临存储容量不足、检索查询缓慢以及实时数据展示不直观等问题。通过优化时序数据的读和写，时序数据库拥有了高效的数据存储和压缩性能，从而可以更好地解决上述场景数据存储所遇到的问题。
目前，在装备制造企业中，时序数据库能够帮助产品提升全生命周期的生产水平和管理水平，其可以统一地对当前系统和设备中的数据进行采集、储存、处理，并探寻数据之间的相关性。辅以回归模型和预测算法等，将助力生产工艺和产品质量的提升，从而增强企业的经济效益。此外，因为对时序数据来说，单点数据价值较低，而数据的变化趋势价值更大，所以时序数据库恰能帮助用户展示这种变化趋势，在散点图、折线图二者中选取能够最大程度揭示时序数据变化趋势的图表类型，实现时序数据的可视化。
6 时序数据库关注度趋势分析
近几年来，时序数据库发展十分迅猛。从2014年起，DB-Engines也把时序数据库作为独立的目录进行分类统计。
图2 DB-Engines统计不同类别数据库的关注度趋势
图2所示为DB-Engines统计的自2020年7月至今24个月，不同类别数据库的关注度趋势。可以看出时序数据库的关注度最高且整体趋势在上升，比2020年7月增长35.63%，是第二名图形数据库增长率的近1.5倍。
图3 DB-Engines统计时序数据库的关注度趋势
图3所示为DB-Engines统计的近几年来，不同时序数据库的关注度趋势。可以看到，从2015年开始，时序数据库产生了飞速发展：2017年 ，Facebook开源基于内存的Gorilla时序数据库（2015 年发布）原型项目beringei，开源基于PostgreSQL设计的TimescaleDB，阿里发布时序数据库TSDB；2018年，Amazon推出完全托管的Timestream。
由 第 4 章与图 3 可知， 2013 年发布的InfluxDB，由于其开源性、类SQL的InfluxQL查询语言的易用性、基于Go语言编写的无环境依赖性等优势，始终处于迭代更新的状态中，目前使用人数和关注度均为最高。
以InfluxDB为代表的垂直型时序数据库为当前时序数据库的主流，其处理时序数据时具备更高效的存储读取能力和更高效的压缩算法。InfluxDB的单机版本采用类似LSM Tree的TSM Tree存储结构，引入了series-key的概念，根据时间特征对数据实现了很好的分类，减少冗余存储，提高数据压缩率。
7 结论和展望
本文介绍了时序数据库的发展现状以及其中的一些关键技术，其中以数据写入和数据压缩技术为主。可以看到，近些年来，研究者们从时序数据的特点出发，提出了很多切实可行的分布式策略、存储结构、压缩算法，这使得时序数据的应用取得了巨大的飞跃。但是，与目前金融、物联网等领域中时序数据的大量涌现相比，时序数据库技术的发展还远远不够，还有大量问题有待研究。本文对相关结论和待解课题加以总结和展望如下：
（1）现有的时序数据库虽然能够在一定程度上满足业界的存储和管理需求，但是对于聚集计算却无能为力。随着工业界和学术界对时序数据分析需求的增长，未来时序数据管理的发展重点将是实现高效的聚集和统计计算，特别是基于极致高写入和高压缩的聚集计算。
（2）大规模时序数据库管理系统需要借助分布式处理技术。当前，尽管存在分布式时序数据库管理系统，但是其分布式架构还不够灵活，特别是对于时间序列的速度变化，还缺少在分布式系统中计算、存储等对资源灵活性变化较大的支持。因而，当前需要研究架构更加灵活和高效的柔性分布式时序数据库管理系统。
（3）尽管当前有一些压缩算法已被应用于时序数据库管理系统中，但是这些压缩算法以无损压缩为主，压缩比还难以满足要求，在压缩数据上进行查询处理的效率也还存在限制。考虑到时序数据存在强关联性，其压缩还有相当大空间，因而需要研究面向大规模时序数据、支持高效查询处理的无损和有损压缩算法。
（4）时序数据存在时变性、周期性等特点，数据分布等特征也可能随着时间发生变化，因而对时序数据的压缩、存储策略和对时序数据库系统参数的调优也应当随着这些因素的变化而发生变化，以保证系统的高性能。然而，当前时序数据压缩、存储策略的制定和时序数据库管理系统参数的设定主要依靠人工，难以自适应地满足时序数据的变化。因而，需要研发时序数据库系统的自主调优技术。
（ 5 ）当前基于 NVM 等新型存储设备和GPU、FPGA等处理器的时序数据库管理技术还少有提出。鉴于时序数据具有快速写入、规模巨大的特点，依赖传统硬件的时序数据处理在性能局限上越来越明显，这就需要新型硬件来突破这些限制，满足物联网等应用需求。
（6）金融、工业互联网等领域的时序数据及其工作负载在特点上各不相同，例如金融时间序列在回报率指标上有“尖峰厚尾”“波动聚集”等特征，而其他行业未必具有。尽管当前已经有一些物联网时序数据专用的时序数据库管理系统被提出，但是面向工业互联网中多种应用的时序数据库管理系统还有待提出。
作者：郑博，王煜彤，燕钰，王宏志
参与 CnosDB 社区交流群：
扫描下方二维码，加入 CC 进入 CnosDB 社区交流，CC 也会在群内分享直播链接
