| 编辑推荐: |
文章主要介绍了实时处理和针对时序数据优化存储的OpenTSDB组成的工业数据平台的详细方案。
本文来自于微信公众号IluvatarCoreX，由火龙果软件微微编辑、推荐。 |
|
最近，时间序列数据库的概念越来越火，它是一种面向带有时间序列信息数据的优化存储方案。金融股票、IoT、互联网、IT系统运维等行业领域的海量数据产生时就带有时间序列特征，因此它们非常适合作为时序数据库的应用场景。
在针对IoT行业客户设计数据存储方案的需求下，由于工业数据的特殊性，我们倾向关注压缩比、实时读写、扩展这3个平台能力。
·追求高压缩比
智能制造领域的工业数据中，大部分场景是处理传感器的实时数据，数据以秒甚至毫秒的频度实时产生。一个传感器每秒的数据按照1Byte的产生，每台有1000个大型设备，每秒就是1K左右的数据量，如果有1000台，那么每秒就是1M，一天的数据量就接近100G。因此，数据膨胀带来的存储压力，是IoT信息化和数字化发展的主要痛点。
·实时读写效率
工业数据本身带有实时性的特点，同时业务也是偏实时的，比如故障预测、设备健康状况监控等，依赖数据的时效性。实时读写是满足业务的基础。
·平台的扩展能力
设备的更新换代以及业务范围的扩大，业务数据量可能在短期内就有数倍的增长，对存储和计算的扩展需求也是刚性的，所以务必充分考虑系统的扩展性。
出于以上考虑，时序数据库由于其对时间序列数据的压缩、对高并发读写的支持，成为我们在工业数据存储领域的首选方案。
1.数据库的选型
从数据库选型本身，我们在OpenTSDB、InfluxDB、PostgreSQL 3者之间做了比较。
考虑到OpenTSDB的底层扩展能力，我们最终选择了OpenTSDB。
2.关于OpenTSDB
OpenTSDB是一个java语言开发的开源时序数据库，底层存储依赖HBase。
如OpenTSDB官网介绍，有3个主要的特性。
·带有时间信息的存储
·可扩展的存储和并发写能力
·提供HTTP接口和可视化组件
OpenTSDB提供REST API作为数据写入的接口，是一个介于HBase列式存储和业务数据之间的存储中间件。同时，OpenTSDB也是一个优秀的HBase客户端，可以根据自己的压缩策略把时序数据持久化到HBase。OpenTSDB的应用架构如下：
图1： OpenTSDB的架构
对OpenTSDB来说就是3层架构：
1、数据源：来自于机器、web页面等，是数据采集的过程
2、TSD进程：OpenTSDB启动后的守护进程。通过REST API接口或者CLI接口，OpenTSDB的TSD进程响应发给OpenTSDB的数据请求。然后TSD进程通过HBase的REST
API接口向HBase写入数据或者读取数据
3、HBase：HBase响应TSD发起的请求。
事实上，OpenTSDB内部封装了一个HBase客户端asynchbase。asynchbase支持异步请求，OpenTSDB得以维护一个rpc
queue，批量的把point发送给HBase，asynchbase保证了OpenTSDB高并发实时写入数据的需求。
以1小时的数据为例，在实际存储上，OpenTSDB把1小时的数据整合成1个key-value对，存到HBase中。我们都知道HBase使用的关键就是Rowkey的设计，HBase自己帮用户设计好Rowkey以及存储表。
OpenTSDB生成的rowkey
[salt]<metric_uid><timestamp><tagk1><tagv1>[...<tagkN><tagvN>]
图2：OpenTSDB在HBase中的存储结构
同一个metric中tag值相同的数据以1小时为粒度使用一个共同的rowkey，3600个秒级的数据则合并到一起是作为1个value，OpenTSDB的压缩效果最主要因为这个过程。
具体的存储样例如下：
3.基于OpenTSDB的实时存储架构
在我们的面向工业数据的解决方案中，OpenTSDB高并发写的能力满足了实时流处理架构对底层存储的实时写要求。如下图展示的整体技术框架中，包括了日志采集、日志处理、数据存储以及数据导出与展示等模块。
数据的采集与分发：业务软件产生的日志通过Apache flume+Kafka收集和分发
数据流处理：SparkStreaming实时的从Kafka中获取数据和计算
数据存储：OpenTSDB+HBase+HDFS在响应10W+以上的并发写的同时，理论上能无限的扩展
数据应用：预测、监测与分析
图3：基于OpenTSDB的实时工业数据平台
除了用OpenTSDB来保存工业时序数据外，关系型数据库作为业务数据和系统运行数据的持久化存储。将来作为扩展，也可以使用分布式的关系型存储，组成融合的存储方案。
4.架构详细
4.1 Flume数据收集
Flume+Kafka都是高吞吐的数据通道，单个Flume 代理的收集能力能达到10MB/s，6个节点的Kafka吞吐能达到100MB/s以上。
图4：Apache Flume+Kafak
不管是分布式的多Flume 代理还是多层次的Flume 代理结构，都能持续扩展数据收集能力。
4.2 OpenTSDB的并发处理能力
Kafka和Spark都具备分布式的扩展能力，OpenTSDB虽然没有高可用和集群方案，但是因为每个进程都可以作为独立的工作节点，所以可以在各个Spark
Worker所属的集群启动多OpenTSDB实例，达到负载均衡的效果。
图5：OpenTSDB的多节点
4.3 HBase的RegionServer
由于RegionServer及其中的region可以分散写请求，所以HBase能够高并发写。因为有内存缓存机制，在热数据被flush到HDFS中时会产生较高的IO请求，所以合理控制flush的节奏是维持HBase性能稳定性的关键。
图6：OpenTSDB的底层存储服务
4.4 OpenTSDB的数据查询
作为一个列式存储的NoSQL数据库，OpenTSDB使用HBase作为存储方案，能满足写的同时，面对类似宽表的查询场景，需要把各个列数据合并成表，因此也带来了一些计算消耗。
图7 OpenTSDB中存储数据的导出
我们在实际应用中，没有实现JOIN，而是取巧于有序的时间特征，使用append的方式把多列数据拼接成一个多列的表。
5．调优与性能
我们使用6个节点集群，经过各项调优后，各个组件的性能数据如下：
6.总结
本文中介绍的由实时处理和针对时序数据优化存储的OpenTSDB组成的工业数据平台方案，支持高并发写和无限的横向扩展。工业数据使用时序数据作为统一的数据存储标准，具备通用性。方案中还有着性能提升的空间；在数据平台基础上，增加更多的实时的数据服务，并且提供高效的数据查询组件，是我们以后的努力方向。
| 
