你的工业互联网平台还差一个分布式时序数据库

说起工业互联网，你可能会想到偌大的生产车间，精密的制造仪器以及复杂的控制平台，这些设备彼此互联，每时每刻都在产生数据，而工业互联网平台需要实时监控和采集这些依赖于时间而变化的时序数据，并做多维度的查询、分析和预测。

显然传统的关系型数据库并不能完全满足工业互联网平台的数据处理需求，时序数据平台应运而生。 本文中，网易大数据专家范欣欣 将从主要业务场景、体系架构和核心技术三方面来带你了解 时序数据平台。

上图为数据的整体架构，大部分公司都是差不多的：

• 原始数据： MySQL、服务端的Log、APP-Data、Sensor，大家知道现在穿戴设备很多，比如手表等，这样都会产生很多数据，这些数据都称为时序数据，随着时间的变化不断产生数据；

• 数据采集层： Sqoop（网易有自研传输工具）、DataStream、SDK、Gataway；

• 数据加工层： 数据存在Kafka里，再经过一些流计算处理（Flink、Sparkstreaming）；

• 数据存储分析层：

1. 离线存储分析平台： 技术栈包括最底层的HDFS、Kudu、GP等数据存储，在这之上要做很多的计算，包括Hive、Spark、Impala等，他的应用场景包括数仓报表、机器学习、模型训练等；

2. 在线存储计算平台： 应用的业务场景包括，交易订单，优惠券，用户画像等，这里主要应用的是HBase；

3. 时间序列存储计算平台： 应用场景包括，业务设备监控，实时广告平台，物联网应用，相关的技术包括OpenTSDB、Druid、InfluxDB等。

所以会根据不同的业务使用不同的平台来处理相关的数据，对于我们来说最大的工作是在数据存储端。

时序数据主要包括时间列、维度列和指标列，这3列缺一不可（特别是时间列）。

工业互联网时代，会源源不断产生各种各样的时序数据，时序数据平台有以下几种典型场景：

1. 系统监控：

• 物理机、云主机、容器：CPU、内存、IO等

• 组件服务：数据库集群、Kafka集群、HBase集群

• 查看指定Hadoop任务耗用内存、CPU、IO利用率等

• 查看集群消耗资源TopN任务、节点等

• 统计集群任务执行耗时

• 应用调用次数，错误占比，页面加载延迟统计、地域统计分析

• 慢加载追踪，慢SQL

• 异常会话追踪

• 调用链全息排查

• 全局调用拓扑

• 链路依赖项分析梳理

• 电商

• 业务大盘：查看单量，金额，发货等业务指标

• 异常大盘：查看超卖，库存校准耗时，商品回调耗时，各种类型下单错误等异常指标

• 广告：

• 广告曝光点击消耗实时统计

• 流量地域分配

下面以基础系统监控服务为例，举例描述两个应用场景：

1. 物理机基础硬件指标监控

2. HBase-RegionServe指标监控

直观地看，以上数据的横坐标都是时间戳，即设备随着时间不断吐数据。

时序数据应用场景的核心特征：

1. 时间区间查询，最近时间区的数据的查询频率远大于历史数据；

2. 多维条件查询，即多维字段随机组合查询；

3. 支持TTL机制，数据可以自动过期；

4. 支持高压缩率，数据压缩比要达到10以上；

5. 支持高效聚合

6. 支持集群可扩展，服务高可用，数据高可靠。

2、

时序数据平台的架构体系

时序序列平台以监控类系统体系架构为例，如下图所示：

将多数据来源的数据（如Agent采集器，打点日志、流式数据，IoT Hub等），通过Kafka工具（分布式消息队列系统）进行流式处理，汇集到网易时序数据平台上。

3、

时序数据平台的核心技术

在上述架构体系中，数据库作为其核心环节。考虑到DDB（分布式MySQL）实时写入性能不足，HBase/ES等开源NoSQL平台多维查询以及聚合计算等功能不够；针对海量时序数据这类应用场景，因此需要专门的时序数据库。

现有市场上较成熟的时序数据库主要包括Druid、OpenTSDB、InfluxDB等。网易结合以上各类时序数据库的优缺点，自主研发分布式时序数据库平台，支持高性能写入和读取，支持多维条件查询，支持聚合计算，且运行开销较小，可私有化、分布式部署。

该时序数据库的分布式集群结构与Hadoop，Hbase，Kudu等架构非常相似：多台服务器用来存储数据，并通过Raft保证数据的一致性。数据的分布式计算是在分布式节点（node）上完成的，每个node上的数据存储计算系统称之为shard server。在Shard Server的底层数据存储中，原始数据存一份，再按照索引的方式再存一份。

网易时序数据平台的数据存储方式是这样的：

1. DataBase中建立若干StorePolicy（类似 MySQL 数据库中的表结构） ，其作用为：

• 指定数据过期时间；

• 指定数据副本数量；

• 指定分片时间间隔。

2. 每个StorePolicy中，按照指定的时间间隔建立若干ShardGroup。 将最新写入的数据（称之为热数据）存到对应的ShardGroup中，再通过哈希分片的方式将该ShardGroup分片成若干个Shard，这些Shard会分布至整个集群。

以上图为例，同一时间段不同shard分布到不同的节点上。例如：左侧大方框中包含的6条记录，代表该时间段的记录分布在6个shard里；右侧小方框中的5和6，代表该shard共有2个副本，分别分布在集群中的5号节点和6号节点。

由此可以看出，同一时间段的多个shard是分布在多个节点上。这样做的好处是：查找指定时间段的数据时，只需要在相应节点中查到对应的shard里的数据即可，避免了全局遍历的情况。

3. 数据在shard中的存储方式：

(1) 时间线列式存储：

具体来说，SeriesKey相当于原始数据（DataSource），具有不同维度；存储的时候，所有的时间存到一起，所有的value单独存在一起，这种存储方法叫做列式存储。列式存储有两大好处：

• 每一列数据类型相同，因此压缩率非常高；

• 方便对列做聚合计算。

什么是列式存储？

传统的关系型数据库如Oracle、MySQL、SQL Server等，都采用的是行式存储法(Row-based)，在基于行式存储的数据库中，数据是按照行数据为基础逻辑存储单元进行存储的，每行中的数据在存储介质中以连续存储形式存在。

不同于行式存储，列式存储以列为基础单元，每列的数据在存储介质中以连续存储的形式存在。

针对海量分布式数据背景的OLAP（on-line analysis processing），列式存储可在内存中高效组装各列数据并形成关系集，可避免全表扫描，显著减少IO消耗。

(2) 倒排索引

支持 sql 语句进行条件筛选；在条件筛选的过程中，使用倒排索引方法，实现快速定位，可“直达用户需求”。

• 正排索引：key-value中，通过key去寻找value；

• 倒排索引：通过value（或包含value）去寻找对应的key。

正排索引需要首先对全局进行扫描遍历，进而从中做筛选；而倒排索引可以仅抽取符合条件的value值，节省大量的资源。

(3) shard自动扩容

数据库作为分布式系统，需要考虑系统的扩容（即增加节点）。

增加节点后，为保证数据存储的均衡，将不再更新的数据（即历史数据）作为cold shard，平均分布到集群的所有节点（包括新增加的节点）中，而实时更新的数据（即hot  shard，随时间不断写入）不做任何处理。

(4)  多级存储优化

考虑到时序数据的一个特点：热数据查询概率远大于冷数据。针对这一特性，做了如下两个优化：

1. 考虑到数据文件可能存在多级索引，针对冷数据，只加载一级索引即root索引；针对热数据，会加载所有索引。

2. 因此针对集群服务器配置方面，每个集群12块盘，只需要1块ssd用来存储hot shard即可，其余均使用普通hdd即可，最大程度降低硬件成本。

• cluster是整个集群，包含n个node；

• node通常掌控独立的资源，包括cpu等；一台机器可以多个node；

• shard一般是从数据角度来说。例如，1000条数据按id分，存10份，就是10个shard；

• shards分散在多个node上。

最后通过以上手段，来实现刚刚所说的时序数据应用场景的核心特征：时间区间查询，多维条件查询，支持TTL机制，支持高压缩率，支持高效聚合，支持集群可扩展，服务高可用，数据高可靠。

↓↓↓点击阅读原文，了解 网易云