时序数据库与NB时序特征

一、背景

1.  时序特征

时序特征是对时序数据经过一定的聚合处理得到可应用于个性化推荐系统（《浅谈NB推荐系统架构》）的特征，比如该用户近n小时点击的spu的平均价格，比如该用户最近半小时停留时长>2s的类目id序列等。

2.  时序数据

时序数据是按时间顺序记录系统、设备状态变化、用户行为事件的数据。它普遍存在于IT基础设施、运维监控系统、物联网和推荐系统（或特征平台）中。时序数据揭示了终端的状态变化、系统的稳定性、业务的发展趋势、事件的流转过程、行为趋势等，可广泛应用于异常发现与定位、决策支持等方面，可用于个性化推荐。

3.  时间序列数据库（以下都简称时序数据库）

时序数据库是针对时序数据的特点对写入、存储、查询等流程进行优化的专业化数据库。

二、希望解决的问题：

1.长序列的存储，用于回放、趋势分析。

原流程：序列特征存储在Redis的话长度上限不够。

新流程：时间序列数据库没有序列长度限制。

2.具有更好的实时性。

原流程：目前的近n xx序列特征使用flink窗口更新是小时或者天级更新的。

新流程：使用时间序列数据库的可以实现秒级更新延时。

3.灵活的生产时序特征。

原流程：新增一种近n天（小时/秒）xx序列特征，就需要开发量flink任务。并且依赖特征抽取服务从原序列append上新事件生成新的序列特征。

新流程：基于时间序列数据库，直接在特征管理平台配置下指定特征的参数，即可生成。

三、基本概念—时序数据组成

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

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

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

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

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

四、基本概念—时序数据特点

1.  流式写入，数据量大

拿监控数据来举例，如果我们采集的监控数据的时间间隔是1s，那一个监控项每天会产生86400个数据点，若有10000个监控项，则一天就会产生864000000个数据点。在物联网场景下，这个数字会更大。整个数据的规模，是TB甚至是PB级的。

2.  按时间窗连续读取，冷热分明

最近的数据被读取的概率高

历史数据查询少，粗粒度查询的概率高

3.  时效性高

时序数据具有时效性，数据通常会有一个保存周期，超过这个保存周期的数据可以认为是失效的，可以被回收。一方面是因为越是历史的数据，可利用的价值越低；另一方面是为了节省存储成本，低价值的数据可以被清理。

五、基本概念—传统方案

1.  MySQL：在海量的时序数据场景下存在如下问题

a.  存储成本大：对于时序数据压缩不佳，需占用大量机器资源；

b.  维护成本高：单机系统，需要在上层人工的分库分表，维护成本高；

c.  写入吞吐低：单机写入吞吐低，很难满足时序数据超大规模的写入压力；

d.  查询性能差：适用于交易处理，海量数据的聚合分析性能差。

2.  Hadoop生态（Hadoop、Spark等）

a.  数据延迟高：离线批处理系统，数据从产生到可分析，耗时数小时、甚至天级；

b.  查询性能差：不能很好的利用索引，依赖MapReduce任务，查询耗时一般在分钟级。

3.  时间序列数据库：

时间序列数据往往是由百万级甚至千万级终端设备产生的，写入并发量比较高，属于海量数据场景。时间序列数据库完美支持时序数据的读、写、存储。

六、时序数据库业内方案

1.  阿里云InfluxDB，基于Time Structured Merge Tree (TSM)

a.  写入的时候，数据先写入到内存里，之后批量写入到硬盘。

b.  读的时候，同时读内存和硬盘然后合并结果。

c.  删除的时候，写入一个删除标记，被标记的数据在读取时不会被返回。

d.  后台会把小的块合并成大的块，此时被标记删除的数据才真正被删除

e.  相对于普通数据，有规律的时间序列数据在合并的过程中可以极大的提高压缩比。

2.  腾讯云时间序列数据库CTSDB，基于Elasticsearch，它本身的优点

a.  高性能

b.  易使用

c.  强大的聚合分析能力

d.  高可靠

e.  低成本

3.  腾讯云时间序列数据库CTSDB，基于Elasticsearch的优化

写入优化：

去除冗余的索引信息；

批量写入，优化数据刷盘策略等。

查询优化：

优化查询语句；

利用cache、routing等提高查询性能及并发。

存储优化：

去除冗余的原始数据存储；

使用合适的字段类型和属性等。

大致流程：写入数据缓存在内存buffer中，周期性刷盘或者数据达到一定量后刷盘。由于我们对数据做了routing，ES的查询过程如下： 查询条件 -> 根据routing做hash后确定shard -> 根据query对tag做hash后查询倒排索引，确定各个文档id -> 根据文档id从列存中取出数据 -> 聚合。

4.  性能对比

（图中es指代基于es实现的腾讯云ctsdb）

七、笔者的选择

InfluxDB早期是完全开源的，后来为了维持公司运营，闭源了集群版本。关闭了被选择的门。

腾讯云的CTSDB在持续维护中，联系运维与客服方便。

CTSDB性能与InfluxDB没有明显代差，腾讯云给出的性能对比是CTSDB加了索引和没有加索引的InfluxDB对比数据。

在性能差不多的情况下，考虑到联系腾讯云CTSDB的运维与客服更方便，最终选择腾讯云CTSDB。

八、CTSDB使用方式与时序特征的构建

1、  参考文档https://cloud.tencent.com/document/product/652/13611

2、  特征平台使用时间序列数据库构建时序特征的流程如下

流程详见：《从零搭建NB特征平台》https://www.prolightsfxjh.com/article/nb-feature-platform/

3.  具体的时序特征例子

a.  该用户近n天的点击文章类型序列

b.  该用户近n次点击的文章标题序列

c.  该用户近n小时点击的商品的最小价格

d.  该用户最近半小时停留时长>2s的类目id序列等。

4.  时序特征的聚合方式

对事件时间聚合，近n时间单位、近n次的数据。

对值聚合，序列、min、max、avg、value_count、sum等。

5、  待聚合数据的过滤

可配置对指定字段进行筛选过滤，比如停留时长>2s。

九、其它注意点

1、更新延时

可以配置为1秒。

refresh_interval具体含义，可以参照这篇哈，数值过小会增大集群压力

https://www.elastic.co/guide/cn/elasticsearch/guide/current/near-real-time.html

注： 

此类生成方式只适合时效性不是很高的特征（ 对序列特征的 延时要求本来就不高，1秒是可以接受的）。对于需要几十或者几百毫秒的，最近点击，最近xx之类的特征依然需要实时入库（不会进行聚合，而是每次直接覆盖写特征）。

2、查询延时

可能需要在更新的时候就做好预处理然后写入缓存、。

十、大致实现

1、消费者启动的时候执行一次建表命令

2、依然在特征抽取服务消费流式数据并通过特征构建代理用rest协议写tsdb。

3、特征查询的时候根据特征注册表的配置进行查询。返回序列特征。

十一、时序数据库的核心告警

1、平均磁盘使用率

2、平均JVM内存使用率

3、最大JVM内存使用率

4、平均CPU使用率

5、最大CPU使用率

6、查询拒绝率 （即查询失败率）

7、写入拒绝率 （即写入失败率）

8、  缓存命中率（热数据在内存，冷数据在磁盘，因此需要缓存命中率的监控）（暂未，在提需求中）

十二、  后记

后来使用的时候（2021-2022年）遇到的最大的问题是基于es的CTSDB的读性能不大好，以及一旦读崩溃了要半小时以上才能恢复（笔者被这里坑惨了），2年没有使用了，现在（2024）可能已经修复了。

如果对笔者的文章感兴趣的话，欢迎关注公众号。