南方电网CGSII项目推广实施已经完成，为了方便查看各个供电局对系统各功能的使用情况，暴露使用系统中的各种问题，提出对营销系统实用化监控建设方案，构建了业务监控平台。业务监控平台提出了一系列的使用化评估方法，构建出一套实用化评估模型，实用化评估模型使用大量的监控数据进行综合计算，得出评价结果。为了支撑实用化评估模型，需要构建一个针对监控数据结构特点的数据仓库。
一、现有方案
业务监控平台现阶段接入了营销系统、生产系统,每天接收到的监控数据达到TB级别,监控数据的存储面临巨大的压力。在业务监控平台的最初设计中，考虑到容量和成本，同时为了方便开发人员处理数据，使用Greenplum数据库作为数据仓库。Greenplum是基于postgresql的分布式数据库,维护人员需要关注Greenplum集群服务器的软硬件状况，关注的重点有Standby master的同步状态、统计信息收集、表倾斜、表膨胀、和报错信息，及时发现和及时处理故障，才能使数据库高效运行，这大大增加的维护人员的工作压力。随着监控数据的不断增加，数据库压力不断增大，业务监控平台也越来越慢，后续人资系统、物资系统和基建系统也需要接入到业务监控平台，需要寻找更加有效的数据存储方式来构建监控数据仓库。
二、业务监控平台监控数据的特点
业务监控平台的监控数据主要通过探针技术，在各个服务上的关键方法中织入采集数据的代码来获取到。在一个请求到达时，生成一个全局唯一的traceId，将处理一个请求调用到的方法和服务串连起来，同一个traceId的记录就是一次请求的处理记录，监控数据本质上是各个系统的运行日志。监控数据存入到数据仓库后，每天的定时任务再对数据进行汇总，以后的指标计算都是使用的汇总数据，在监控数据产生后基本只会读取一次，用户很少回去查看原始的监控数据，人去分析很难得到有意义的结论，只要保留最近一段时间内的数据。
三、时序数据库
时间序列数据库，Time Series Database，简称为时序数据库，时间序列数据是历史烙印，是不可变的、以时间排序的，并且数据到达服务器的顺序并不影响正确性，根据数据本身可以直接进行排序和去重。以时间作为坐标将数据点连接成线，最为多维度报表，可以揭示数据的趋势性、规律性、异常性。需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。目前的时序数据库有InfluxDB、OpenTSDB、TDengine等，他们数据模型基本统一，包含Metric:指标名称、Timestamp：时间戳、Tags：维度组合、Fields：指标值。在划分列时语言划分维度列和指标列，这样划分的好处是可以做一些存储上的优化，不需要用户像使用关系型数据库那样手动建立索引。时序数据库的特点：
• 写入平稳、持续、高并发高吞吐：时序数据的写入是比较平稳的，这点与应用数据不同，应用数据通常与应用的访问量成正比，而应用的访问量通常存在波峰波谷。时序数据的产生通常是以一个固定的时间频率产生，不会受其他因素的制约，其数据生成的速度是相对比较平稳的。
• 写多读少：时序数据上95%-99%的操作都是写操作，是典型的写多读少的数据。这与其数据特性相关，例如监控数据，你的监控项可能很多，但是你真正去读的可能比较少，通常只会关心几个特定的关键指标或者在特定的场景下才会去读数据。
• 实时写入最近生成的数据，无更新：时序数据的写入是实时的，且每次写入都是最近生成的数据，这与其数据生成的特点相关，因为其数据生成是随着时间推进的，而新生成的数据会实时的进行写入。数据写入无更新，在时间这个维度上，随着时间的推进，每次数据都是新数据，不会存在旧数据的更新，不过不排除人为的对数据做订正。
• 按时间范围读取：通常来说，你不会去关心某个特定点的数据，而是一段时间的数据。
• 数据量大：拿监控数据来举例，如果我们采集的监控数据的时间间隔是1s，那一个监控项每天会产生86400个数据点，若有10000个监控项，则一天就会产生864000000个数据点。在物联网场景下，这个数字会更大。整个数据的规模，是TB甚至是PB级的。
• 冷热分明：时序数据有非常典型的冷热特征，越是历史的数据，被查询和分析的概率越低。
• 具有时效性：时序数据具有时效性，数据通常会有一个保存周期，超过这个保存周期的数据可以认为是失效的，可以被回收。一方面是因为越是历史的数据，可利用的价值越低；另一方面是为了节省存储成本，低价值的数据可以被清理。
四、相关产品
InfluxDB是使用GO语言编写的分布式时序、时间和指标数据库，存储引擎上最终使用了自研的 Time Structured Merge Tree。Time Structured Merge Tree (TSM) 和 Log Structured Merge Tree (LSM) 的名字都有点误导性，关键并不是树，也不是日志或者时间，而是 Merge。 写入的时候，数据先写入到内存里，之后批量写入到硬盘。读的时候，同时读内存和硬盘然后合并结果。 删除的时候，写入一个删除标记，被标记的数据在读取时不会被返回。 后台会把小的块合并成大的块，此时被标记删除的数据才真正被删除，这个过程叫做 Compaction。 相对于普通数据，有规律的时间序列数据在合并的过程中可以极大的提高压缩比。InfluxDB支持使用sql查询，方便开发人员改造现有代码。InfluxDB早期是完全开源的，后来为了维持公司运营，闭源了集群版本，所以现在的开源版本只支持一个节点。
Elasticsearch（后文简称es）是市面上能够在检索、加载和分布式计算三个方面都做得一流的数据库。而且是开源并且免费的。es优秀的性能和分布式能力，有很多人将其作为时序数据库使用，es也经常与logstash、Kibana一起组成日志收集平台，提供日志收集、存储、搜索与展示等功能。ES自动可以将海量数据分散到多台服务器上去存储和检索海联数据的处理，分布式以后，就可以采用大量的服务器去存储和检索数据，在秒级别对大量数据进行搜索和分析。Elasticsearch的关注点在于快速检索数据，所以原生不支持事务，数据可靠性有所下降，相对于其他只做时序数据库的产品来说，没有列值相同合并，磁盘空间占用大一些。
TDengine是国内团队在吸取了众多关系型数据库、nosql数据库、流式计算引擎、消息队列等软件的优点后自主开发的产品，主要面向工业物联网时序场景，写入数据量可预测写多读少的场景。TDengine通过模块支持时序数据库，还有缓存、消息队列等功能，是处理互联网大数据的工具包。在社区中评价TDengine最多的一个词是“性能超强”，口碑似乎很不错，TDengine2.0版本将集群功能也开源了，可以使用集群部署进一步提高处理能力。
五、结语
监控数据具有时间序列数据的特点，更加适合使用时序数据库存储。监控的数据量特别巨大，在使用关系数据库存储时，在计算各种约束和存储时会有不必要的资源浪费。在软件开发中使用一个技术和中间件，使用其带来的功能和便利时，必须要承担带来的技术债，在选择像数据存储这样需要横贯整个软件系统的中间件时，更加需要仔细考虑其优缺点，是否适合使用的场景和开发人员对这个产品的掌握程度。
