日吞吐万亿,腾讯云时序数据库CTSDB解密

一、背景

随着移动互联网、物联网、大数据等行业的高速发展,数据在持续的以指数级的速度增长,比如我们使用手机访问互网络时的行为数据,各种可穿戴设备上报的状态数据,工厂中设备传感器采集的指标数据,传统互联网公司的监控数据等。实际上,这些按照时间顺序记录系统、设备状态变化的数据都是时序数据(Time Series),它普遍存在于互联网、物联网、IT基础设施中。

得益于软硬件技术的快速发展,处理如此庞大的时序数据集的成本在持续降低,更多公司开始持续收集、分析数据,用于异常处理、趋势预测、精准营销、风险控制等场景,希望利用数据的潜在价值,提高公司盈利能力和竞争力。这里举两个例子:

1.下图为某共享单车在旧金山某热门区域的车辆借还情况。通过分析该区域车辆的历史借还数据,单车公司可优化热点时间段的车辆补给。

Q1

2. 下图为某互联网服务的出入流量历史记录。从图中可以明显看到入流量(蓝色线)在某时间段有毛刺,服务提供商可基于此段时间排查服务有无异常。可以进一步基于流量监控做告警,使运维人员能够及时处理线上问题。

q2

二、传统时序数据解决方案存在大量问题

传统的时序数据解决方案及问题如下:

1. MySQL等关系型数据库:

。 写入吞吐低:单机写入吞吐低,很难满足时序数据千万级的写入压力;

。 存储成本大:对于时序数据压缩不佳,需占用大量机器资源;

。 维护成本高:单机系统,需要在上层人工的分库分表,维护成本高;

。 查询性能差:适用于交易处理,海量数据的聚合分析性能差。

2. Hadoop、Spark等批处理系统

。 数据延迟高:离线批处理系统,数据从产生到可分析,耗时数小时、甚至天级;

。 查询性能差:不能很好的利用索引,依赖批处理任务,查询耗时一般在分钟级以上。

3. HBase

。 多维分析能力差:HBase可以较好的满足写入压力,但对于非RowKey前缀的查询性能较差;

。 维护成本:使用HBase需要同时维护HBase和Hadoop等系统,且HBase的稳定性会进一步加大维护成本。

三、写入、存储、查询多环节优化,时序数据库优势明显

1. 时序数据模型及特点

在引入时序数据库之前,先要了解「时序数据」的模型及特点。

1.1 时序数据的数学模型

前面介绍了时序数据的场景,也说明了分析时序数据的意义及传统方案。那么时序数据该怎样存储呢?数据的存储要考虑其数学模型和特点,时序数据当然也不例外。这里以一段时序数据为例,介绍下时序数据的数学模型。

下列数据记录了一段时间内某集群里各机器上各端口的出入流量,每半小时记录一个观测值:

q3

。 metric: 相关联的数据集合,类似于关系型数据库中的 table;

。 point: 一个时序数据点,类似于关系型数据库中的 row;

。 timestamp: 时间戳,表征时序数据产生的时间点;

。 tag: 维度列,用于描述设备/系统的属性,表明是哪个设备/模块产生的,一般不随着时间变化;

。 field: 指标列,用于描述设备/系统状态的变化,随时间平滑波动。

1.2 时序数据特点

。 数据模式: 时序数据随时间增长,相同设备/系统的维度信息不变,指标平滑变化,这点从上面的Network表的数据变化可以看出。

。 写入: 持续高并发写入,无更新操作:时序数据库面对的往往是百万甚至千万数量级终端设备的实时数据写入(如摩拜单车2017年全国车辆数为千万级),但数据大多表征设备状态,写入后不会更新。

。 查询: 按不同维度对指标进行统计分析,且存在明显的冷热数据,一般只会频繁查询近期数据。

2. 时序数据库

2.1 时序数据库

时序数据库是管理时序数据的专业化数据库,并针对时序数据的特点对写入、存储、查询等流程进行了优化,从而解决时序数据处理难题:

。 存储成本:

o 利用维度重复、时间递增、指标平滑变化等特性,合理选择编码压缩算法,提高数据压缩比;