【时序数据库】十分钟系列

2017年时序数据库忽然火了起来。开年2月Facebook开源了beringei时序数据库；到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了，而早在2016年7月，百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB。时序数据库作为物联网方向一个非常重要的服务，业界的频频发声，正说明各家企业已经迫不及待的拥抱物联网时代的到来。

时序数据库介绍

1.存储

1.1背景

百度无人车在运行时需要监控各种状态，包括坐标，速度，方向，温度，湿度等等，并且需要把每时每刻监控的数据记录下来，用来做大数据分析。每辆车每天就会采集将近8T的数据。这些海量数据需要快速存储（效率+成本），以及高效多纬度分组聚合查询，，那么时序数据库会是一个很好的选择。

1.2时序数据库

1.2.1整体介绍

时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线，往过去看可以做成多纬度报表，揭示其趋势性、规律性、异常性；往未来看可以做大数据分析，机器学习，实现预测和预警。

时序数据库就是存放时序数据的数据库，并且需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。

对比传统数据库仅仅记录了数据的当前值，时序数据库则记录了所有的历史数据。同时时序数据的查询也总是会带上时间作为过滤条件。

12.2 基本概念（不同的时序数据库称呼略有不同）

metric: 度量，相当于关系型数据库中的table。

data point: 数据点，相当于关系型数据库中的row。

timestamp：时间戳，代表数据点产生的时间。

field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个field。一般情况下存放的是会随着时间戳的变化而变化的数据。

tag: 标签，或者附加信息。一般存放的是并不随着时间戳变化的属性信息。timestamp加上所有的tags可以认为是table的primary key。

如上图，度量为Wind，每一个数据点都具有一个timestamp，两个field：direction和speed，两个tag：sensor、city。它的第一行和第三行，存放的都是sensor号码为95D8-7913的设备，属性城市是上海。随着时间的变化，风向和风速都发生了改变，风向从23.4变成23.2；而风速从3.4变成了3.3。

 1.3时序数据库遇到的挑战

很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题，但少量数据是展现的纬度有限，细节少，可置信低，更加不能用来做大数据分析。很明显时序数据库是为了解决海量数据场景而设计的。

可以看到时序数据库需要解决以下几个问题

（1）时序数据的写入：如何支持每秒钟上千万上亿数据点的写入。

（2）时序数据的读取：又如何支持在秒级对上亿数据的分组聚合运算。

（3）成本敏感：由海量数据存储带来的是成本问题。如何更低成本的存储这些数据，将成为时序数据库需要解决的重中之重。

1.4数据单机存储和分布式存储

14.1单机存储

传统数据库存储采用的都是B tree，这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式。我们知道磁盘寻道时间是非常慢的，一般在10ms左右。磁盘的随机读写慢就慢在寻道上面。对于随机写入B tree会消耗大量的时间在磁盘寻道上，导致速度很慢。对于90%以上场景都是写入的时序数据库，B tree很明显是不合适的。业界主流都是采用LSM tree替换B tree，比如Hbase, Cassandra等nosql中。

LSM tree包括内存里的数据结构和磁盘上的文件两部分。分别对应Hbase里的MemStore和HLog；对应Cassandra里的MemTable和sstable。

LSM tree操作流程如下：

（1）数据写入和更新时首先写入位于内存里的数据结构。为了避免数据丢失也会先写到WAL文件中。

（2）内存里的数据结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的文件不会被修改。

（3）随着磁盘上积累的文件越来越多，会定时的进行合并操作，消除冗余数据，减少文件数量。

如上图“Hbase LSM tree结构”，可以看到LSM tree核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能，避免了随机写入。但同时也牺牲了读取性能，因为同一个key的值可能存在于多个HFile中。为了获取更好的读取性能，可以通过bloom filter和compaction得到。

14.2分布式存储

时序数据库面向的是海量数据的写入存储读取，单机是无法解决问题的。所以需要采用多机存储，也就是分布式存储。分布式存储首先要考虑的是如何将数据分布到多台机器上面，也就是 分片（sharding）问题。分片问题由分片方法的选择和分片的设计组成。

（1）分片方法

哈希分片：这种方法实现简单，均衡性较好，但是集群不易扩展。

一致性哈希：这种方案均衡性好，集群扩展容易，只是实现复杂。代表有Amazon的DynamoDB和开源的Cassandra。

范围划分：通常配合全局有序，复杂度在于合并和分裂。代表有Hbase。

 （2）分片设计

按照“ metric+tags分片+时间范围 ”分片，这样相同metric和tags的数据会分配到一台机器上连续存放，顺序的磁盘读取是很快的。根据时间范围再将数据分成几段，分别存储到不同的机器上，这样对于大范围时序数据就可以支持并发查询，优化查询速度。

2.预处理

 使用预处理能有效的降低采样聚合函数查询对系统的瞬时查询压力，实现数据计算一次多次查询，同时也能有效的降低查询延迟，提高用户体验。但是对大量原始数据的查询，时序数据库依然会遇到性能、高延时等挑战。

2.1时序数据库查询

时序数据的查询分为两种：原始数据的查询和时序数据聚合运算的查询。前者主要用于大数据分析的元数据；后者主要用来对数据做分析，例如dashboard等UI工具使用聚合查询展示数据分析结果。通常数据分析的查询范围广，查询的数据量大，从而导致查询的延时比较高，而往往分析工具又要求查询延时低，大数据量低延时是时序数据查询面临的主要问题。

2.2时序数据库查询优化

2.2.1 聚合运算查询延时计算

时序数据的存储主要包含单机和分布式存储。时序数据根据分片规则（通常使用metric+tags+时间范围），将分片存储在单机或者分布式环境中。聚合运算查询时，根据查询条件查询所有的数据分片，所有的分片按照时间戳合并形成原始数据结果，当查询条件包含聚合运算时，会根据采样窗口对数据进行聚合运算，最后返回运算结果。 

数据聚合运算查询延时的计算可以粗略的描述如下：聚合运算查询延时估算=数据分片的查询合并 + 聚合运算 + 数据返回

2.2.2 聚合运算查询优化

针对聚合运算的查询可以从两个方向进行优化：分布式聚合查询和数据预处理。

（1）分布式聚合查询

分布式聚合查询通过并发使用多个节点并行查询和计算来提高性能，减少了分片查询以及聚合运算的时间，保证了时序数据分析结果秒级返回。

（2）数据预处理

数据预处理则是通过空间换时间的思路，将数据根据查询规则预先计算，查询时直接返回少量的聚合运算结果来保证更低的查询延时。

2.3 时序数据查询的预处理

参考文档：

十分钟看懂时序数据库（I）-存储

十分钟看懂时序数据库（II）- 预处理

十分钟看懂时序数据库（III）- 压缩

十分钟看懂时序数据库（IV）- 分级存储

十分钟看懂时序数据库（V）- 分布式计算