关于大数据:MRS-IoTDB时序数据库的总体架构设计与实现

MRS IoTDB 时序数据库的总体架构设计与实现

MRS IoTDB 是华为 FusionInsight MRS 大数据套件最新推出的时序数据库产品，其当先的设计理念在时序数据库畛域展现出越来越弱小的竞争力，失去了越来越多的用户认可。为了大家更好地理解 MRS IoTDB，本文将会系统地为大家介绍 MRS IoTDB 的前因后果和性能个性，重点为大家介绍 MRS IoTDB 时序数据库的整体架构设计与实现。

1. 什么是时序数据库

时序数据库是工夫序列数据库的简称，指的是专门对带工夫标签（依照工夫的程序变动，即工夫序列化）的数据进行存储、查问、剖析等解决操作的专用数据库系统。艰深来说，时序数据库就是专门用来记录例如物联网设施的温度、湿度、速度、压力、电压、电流以及证券买入卖出价等随着工夫演进一直变动的各类数值（测点、事件）的数据库。

以后，随着大数据技术倒退和利用的不断深入，以物联网 IoT(Internet Of Things)、金融剖析为代表的两类数据，体现出随着工夫的演进连续不断地产生大量传感器数值或事件数据。工夫序列数据 (time series data) 就是以数据 (事件) 产生的时刻（工夫戳）为时间轴造成的连续不断的数值序列。例如某物联网设施不同时刻的的温度数据形成一个工夫序列数据：

无论是机器产生的传感器数据，还是人类流动产生的社会事件数据，都有一些独特的特色：

（1）采集频率高：每秒采集几十次、上百次、十万次乃至百万次；

（2）采集精度高：起码反对毫秒级采集，有些须要反对微秒级和纳秒级采集；

（3）采集跨度大：7*24 小时继续一直地间断采集几年、乃至数十年数据；

（4）存储周期长：须要反对时序数据的长久存储，甚至对有些数据须要进行长达上百年的永恒存储（例如地震数据）；

（5）查问窗口长：须要反对从毫秒、秒、分钟、小时到日、月、年等不同粒度的工夫窗口查问；也须要反对万、十万、百万、千万等不同粒度的数量窗口查问；

（6）数据荡涤难：工夫序列数据存在乱序、缺失、异样等简单状况，须要专用算法进行高效实时处理；

（7）实时要求高：无论是传感器数据还是事件数据，都须要毫秒级、秒级的实时处理能力，以确保实时响应和应急解决能力；

（8）算法业余强：工夫序列数据在地震、金融、电力、交通等不同畛域，都有很多垂直畛域的业余时序剖析需要，须要利用时序趋势预测、类似子序列剖析、周期性预测、工夫挪动均匀、指数平滑、工夫自回归剖析以及基于 LSTM 的时序神经网络等算法进行业余剖析。

从时序数据的独特特色能够看出，工夫序列非凡的场景需要给传统的关系数据库存储和大数据存储都带来了挑战，无奈是采纳关系数据库进行结构化存储，还是采纳 NoSQL 数据库进行存储，都无奈满足海量时序数据高并发实时写入和查问的需要。因而，迫切需要一种专门用于存储工夫序列数据的专用数据库，时序数据库的概念和产品就这样诞生了。

须要留神的是：时序数据库不同于时态数据库和实时数据库。时态数据库 (Temporal Database) 是一种可能记录对象变动历史，即可能保护数据的变动经验的数据库，比方 TimeDB。时态数据库是对传统关系数据库中工夫记录的工夫状态进行细粒度保护的零碎，而时序数据库齐全不同于关系数据库，只存储不同工夫戳对应的测点值。无关时序数据库与时态数据库的更具体比照，后续将会发文专门介绍，在此不再详述。

时序数据库也不同于实时数据库。实时数据库诞生于传统工业，次要是因为古代工业制作流程及大规模工业自动化的倒退，传统关系数据库难以满足工业数据的存储和查问需要。因而，在 80 年代中期，诞生了实用于工业监控畛域的实时数据库。因为实时数据库诞生早，在扩展性、大数据生态对接、分布式架构、数据类型等方面存在局限，然而也有产品配套齐全、工业协定对接残缺的劣势。时序数据库诞生于物联网时代，在大数据生态对接、云原生反对等方面更有劣势。

时序数据库与时态数据库、实时数据库的根本比照信息如下：

2．什么是 MRS IoTDB 时序数据库

MRS IoTDB 是华为 FusionInsight MRS 大数据套件中的时序数据库产品，在深度参加 Apache IoTDB 社区开源版的根底上推出的高性能企业级时序数据库产品。IoTDB 顾名思义，是针对 IoT 物联网畛域推出的专用时序数据库软件，是由清华大学发动的国产 Apache 开源软件。自 IoTDB 诞生之初，华为就深度参加 IoTDB 的架构设计和外围代码奉献，对 IoTDB 集群版的稳定性、高可用和性能优化投入了大量人力并提出了大量的改良倡议和奉献了大量的代码。

IoTDB 在设计之初，全面剖析了市面上的时序数据库相干产品，包含基于传统关系数据库的 Timescale、基于 HBase 的 OpenTSDB、基于 Cassandra 的 KariosDB、基于时序专属构造的 InfluxDB 等支流时序数据库，借鉴了不同时序数据在实现机制方面的劣势，造成了本人独特的技术劣势：

（1）反对高速数据写入

独有的基于两阶段 LSM 合并的 tLSM 算法无效保障了 IoTDB 即便在乱序数据存在的状况下也能轻松实现单机每秒千万测点数据的并发写入能力。

（2）反对高速查问

反对 TB 级数据毫秒级查问

（3）性能齐备

反对 CRUD 等残缺的数据操作（更新通过对同一设施同一时间戳的测点数据笼罩写入来实现，删除通过设置 TTL 过期工夫来实现），反对频域查问，具备丰盛的聚合函数，反对相似性匹配、频域剖析等业余时序解决。

（4）接口丰盛，简略易用

反对 JDBC 接口、Thrift API 接口和 SDK 等多种接口。采纳类 SQL 语句，在规范 SQL 的语句上减少了对于工夫滑动窗口的统计等时序解决罕用的性能，提供了零碎应用效率。Thrift API 接口反对 Java、C\C++、Python、C# 等多语言接口调用。

（5）低存储老本

IoTDB 独立研发的 TsFile 时序文件存储格局，专门针对时序解决解决做了优化，基于列式存储，反对显式的数据类型申明，不同数据类型主动匹配 SNAPPY、LZ4、GZIP、SDT 等不同的压缩算法，可实现 1:150 甚至更高的压缩比（数据精度进一步升高的状况下），极大地升高了用户的存储老本。例如某用户原来用 9 台 KariosDB 服务器存储的时序数据，IoTDB 用 1 台等同配置的服务器即可轻松实现。

（6）云边端多状态部署

IoTDB 独有的轻量级架构设计保障了 IoTDB 能够轻松实现“一套引擎买通云边端，一份数据兼容全场景”。在云服务中心，IoTDB 能够采纳集群部署，充分发挥云的集群解决劣势；在边缘计算地位，IoTDB 能够在边缘服务器上部署单机 IoTDB，也能够部署大量节点的集群版，具体视边缘服务器配置而定；在设施终端，IoTDB 能够 TsFile 文件的状态间接嵌入到终端设备的本地存储中，并间接被设施终端的间接读写 TsFile 文件，不须要 IoTDB 数据库服务器的启动运行，极大地缩小了对终端设备解决能力的要求。因为 TsFile 文件格式凋谢，终端任意语言和开发平台能够间接读写 TsFile 的二进制字节流，也能够利用 TsFile 自带的 SDK 进行读写，对外甚至能够通过 FTP 将 TsFile 文件发送到边缘或云服务中心。

（7）查问剖析一体化

IoTDB 一份数据同时反对实时读写与分布式计算引擎剖析，TsFile 与 IoTDB 引擎的松耦合设计保障了一方面 IoTDB 能够利用专有的时序数据处理引擎对时序数据进行高效写入和查问，同时 TsFile 也能够被 Flink、Kafka、Hive、Pulsar、RabbitMQ、RocketMQ、Hadoop、Matlab、Grafana、Zeepelin 等大数据相干组件进行读写剖析，极大地晋升了 IoTDB 的查问剖析一体化能力和生态扩大能力。

3. MRS IoTDB 的整体架构

MRS IoTDB 在 Apache IoTDB 已有架构的根底上，交融 MRS Manager 弱小的日志治理、运维监控、滚动降级、平安加固、高可用保障、灾备复原、细粒度权限管控、大数据生态集成、资源池优化调度等企业级外围能力，对 Apache IoTDB 内核架构尤其是分布式集群架构做了大量的重构优化，在稳定性、可靠性、可用性和性能方面做了大量的零碎级加强。

（1）接口兼容性：

进一步欠缺北向接口和南向接口，反对 JDBC、Cli、API、SDK、MQTT、CoAP、Https 等多种拜访接口，进一步欠缺类 SQL 语句，兼容大部分 Influx SQL，反对批量导入导出

（2）分布式对等架构：

MRS IoTDB 在基于 Raft 协定的根底上，采纳了改良的 Multi-Raft 协定，并对 Muti-Raft 协定的底层实现进行了优化，采纳了 Cache Leader 等优化策略在保障无单节故障的根底上，进一步晋升 MRS IoTDB 数据查问路由的性能；同时，对强一致性、中等一致性和弱一致性策略进行了细粒度优化；对一致性哈希算法退出虚构节点策略防止数据歪斜，同时交融了查表与哈希分区的算法策略，在晋升集群高可用的根底上进一步保障集群调度的性能。

（3）双层粒度元数据管理：

 因为采纳了对等架构，元数据信息天然散布在集群所有节点上进行存储，然而因为元数据的存储量较大会带来内存的较大耗费。为了均衡内存耗费与性能，MRS IoTDB 采纳了双层粒度元数据管理架构，首先在所有节点间进行工夫序列组元数据的同步，其次在分区节点间进行工夫序列元数据的同步。这样在查问元数据的时候，首先会基于工夫序列组进行过滤树剪枝，大大减少搜查空间，而后在进一步在过滤后的分区节点进行工夫序列元数据的查问。

（4）本地磁盘高性能拜访：

MRS IoTDB 采纳专用的 TsFile 文件格式进行工夫序列优化存储，采纳列存格局进行自适应编码与压缩，反对流水线优化拜访和乱序数据高速插入

（5）HDFS 生态集成：

MRS IoTDB 反对 HDFS 文件读写，并对 HDFS 进行了本地缓存、短路读、HDFS I/ O 线程池等多种优化伎俩，全面晋升 MRS IoTDB 对 HDFS 的读写性能，同时，MRS IoTDB 反对华为 OBS 对象存储并进行了更加高性能的深度优化。

在 HDFS 集成的根底上，MRS IoTDB 反对 Spark、Flink、Hive 等 MRS 组件对 TsFile 的高效读写。

（6）多级权限管控：

反对存储组、设施、传感器等多级权限管控

反对创立、删除、查问等多级操作

反对 Kerberos 认证

反对 Ranger 权限架构

（7）云边端部署：

反对云边端灵便部署，边缘局部能够基于华为的 IEF 产品进行对接，也能够间接部署在华为的 IES 中。

MRS IoTDB 集群版反对动静扩缩容，能够为云边端提供更加灵便的部署反对。

4. MRS IoTDB 的单机架构

4.1 MRS IoTDB 的根底概念

MRS IoTDB 次要聚焦在 IoT 物联网畛域的设施传感器测点值的实时处理，因而，MRS IoTDB 的基础架构设计以设施、传感器为外围概念，同时为了便于用户应用和 IoTDB 治理工夫序列数据，减少了存储组的概念，上面为大家别离解释一下：

存储组(Storage Group): IoTDB 为了治理时序数据提出的一个概念，相似于关系数据库中的数据库的概念。从用户角度，次要用于对设施数据进行分组治理；从 IoTDB 数据库角度，存储组又是一个并发管制和磁盘隔离的单位，不同存储组之间能够并行读写。

设施 (Device)：对应事实世界中的具体物理设施，例如：电厂某制作单元、风力发电机、汽车、飞机发动机、地震波采集仪器等。在 IoTDB 中, device 是时序数据一次写入的单位，一次写入申请局限在一个设施中。

传感器(Sensor): 对应事实世界中的具体物理设施本身携带的传感器，例如：风力发电机设施上的风速、转向角、发电量等信息采集的传感器。在 IoTDB 中，Sensor 也称为测点（Measurement），具体指传感器采集的某时刻的传感器值，在 IoTDB 外部采纳的模式进行列式存储。

存储组、设施、传感器的关系如上面的例子：

工夫序列 (Time Series): 相似于关系数据库中的一张表，不过这张表次要有工夫戳(Timestamp)、设施 ID(Device ID)、测点值(Measurement) 三个次要字段。为了便于对工夫序列的设施信息进行更多形容，IoTDB 还减少了 Tag 和 Field 等扩大字段，其中 Tag 反对索引，Field 不反对索引。在有的时序数据库中，又称为工夫线，示意记录某设施某传感器值随着工夫一直变动的值，造成一条沿着时间轴一直追加测点值的工夫线。

门路(Path)：IoTDB 结构了一个以 root 为根节点、把存储组、设施、传感器串联在一起的树形构造，从 root 根节点通过存储组、设施到传感器叶子节点，形成了一条门路。如下图所示：

虚拟存储组：因为存储组的概念具备用户对设施分组和零碎进行并发管制的双重作用，二者的适度耦合会造成用户的不同应用形式对系统并发管制的影响。例如：用户把不相干的所有设施数据都放到一个存储组中，IoTDB 对这个存储组加锁进行并发管制，限度了数据的并发读写能力。为了是实现存储组与并发管制的绝对松耦合，IoTDB 设计了虚拟存储组这个概念，把对存储组的并发管制细粒度拆分到虚拟存储组这个粒度，从而缩小了并发管制的粒度。

4.2 MRS IoTDB 的根本架构

单机 MRS IoTDB 次要不同的存储组形成，每个存储组是一个并发管制和资源隔离单位，每个存储组外面包含了多个 Time Partition。其中，每个存储组对应一个 WAL 预写日志文件和 TsFile 时序数据存储文件。每个 Time Partition 中的时序数据先写入 Memtable，同时记入 WAL，定时异步刷盘到 TsFile，具体实现机制后续会给大家具体介绍。MRS IoTDB 单机的根本架构如下：

5. MRS IoTDB 的集群架构

5.1 基于 Multi-Raft 的分布式对等架构
MRS IoTDB 集群是齐全对等的分布式架构，既基于 Raft 协定防止了单点故障问题，又通过 Multi-Raft 协定防止了繁多 Raft 共识组带来的单点性能问题，同时对分布式协定的底层通信、并发管制和高可用机制做了进一步优化。

首先，整个集群的所有节点形成一个元数据组(MetaGroup)，只用于保护存储组的元数据信息。例如下图蓝灰色框所示的一个 4 节点的 IoTDB 集群，全副 4 个节点形成一个元数据组(MetaGroup)；

其次，依据数据正本数结构数据组。例如正本数为 3，则结构一个包含 3 个节点的数据组(DataGroup)。存储组用于存储工夫序列数据及对应的元数据。

分布式系统中通常以多正本的形式实现数据的牢靠存储。同一份数据的多个正本存储在不同的节点中且必须保障统一，因而须要应用 Raft 共识协定来保证数据的一致性，它将一致性的问题拆分成了几个绝对独立的子问题，即领导者选举、日志复制、一致性保障等。Raft 协定中有以下重要的概念:

(1)Raft 组。Raft 组中有一个通过选举产生的 leader 节点，其余节点是 follower。当一个写入申请到来时，首先要提交给 leader 节点解决，leader 节点先在本人的日志外面记录下这个写入申请，而后将这条日志散发到 follower 节点。

(2)Raft 日志。Raft 通过日志的形式保障操作不会失落，日志中保护了一个 Commit 编号和 Apply 编号。如果一条日志被 Commit，就代表目前集群中超过半数的节点都收到并长久化了这条日志。如果一条日志被 Apply，就示意以后节点执行了这条日志。当某些节点呈现故障并从新复原时，该节点的日志就会落后于 leader 的日志。则在这个节点追上 leader 的日志之前，它不能向外界失常提供服务。

5.2 元数据分层治理
元数据管理策略是 MRS IoTDB 分布式设计中的要点。在进行元数据管理策略设计时首先要思考元数据在读写流程中的用处:

写入数据时须要元数据进行数据类型、权限等合法性检查；
查问数据时须要元数据进行查问路由。同时，因为时序数据场景中元数据宏大，还须要思考元数据对内存资源的耗费。

现有的元数据管理策略要么采纳将元数据交由元数据节点专门治理的形式，这种办法会升高读写性能; 要么采纳在集群所有节点全量保留元数据的形式，这种形式会耗费大量的内存资源。

为了解决上述问题，MRS IoTDB 设计了双层粒度元数据管理策略，其核心思想是通过将元数据拆分为存储组和工夫序列两层别离治理：

(1)存储组元数据：元数据组 (MetaGroup) 蕴含了查问数据时的路由信息，存储组（Storage Group）的元数据信息在集群所有节点上全量保留。存储组的粒度较大，一个集群外部的存储组数量级远远小于工夫序列的数量级。因而在集群所有节点上对这些存储组元数据的保留，大大减少了内存的占用。

元数据组中的每个节点称为元数据持有者，采纳 Raft 协定来保障每个持有者与同组的其余持有者的数据一致性。

（2）工夫序列元数据：数据组 (DataGroup) 中的工夫序列元数据中蕴含了数据写入时须要的数据类型、权限等信息，这些信息保留在数据组所在节点（集群局部节点）上。因为工夫序列元数据的粒度较小，数量远远多于存储组元数据，因而这些工夫序列元数据保留在数据组所在的节点上，防止了不必要的内存占用，同时也能通过存储组元数据的一级过滤疾速定位，同时数据组的 Raft 一致性也防止了工夫序列元数据存储的单点故障。

数据组中的每个节点称为数据分区持有者，采纳 Raft 协定来保障每个持有者与同组的其余持有者的数据一致性。

该办法将元数据按存储组和工夫序列两层粒度别离在元数据持有者和数据分区持有者中治理，因为工夫序列数据和元数据在数据组内同步，因而每次数据写入不须要进行元数据的查看与同步操作，仅须要在批改工夫序列元数据时进行存储组元数据的查看与同步操作，从而进步零碎性能。例如创立一个工夫序列并进行 50 万次数据写入的操作中，元数据查看与同步操作从 50 万次降至 1 次。

5.3 元数据分布
依据元数据分层治理可知，元数据分为存储组元数据和工夫序列元数据。

存储组元数据在全集群所有的节点上都有正本，属于 MetaGroup 组。

工夫序列元数据只在对应的 DataGroup 上存储，存储一些工夫序列的属性，字段类型，字段形容等信息。工夫序列元数据的散布形式和数据分布形式一样，都是通过 slot hash 产生。

5.4 工夫序列数据分布

分布式系统实现中基于哈希环和环上查找算法将时序数据依照存储组进行分区。将集群各个节点按哈希值放到哈希环上，对于到来的一个工夫序列数据点，计算这个工夫序列名称所对应的存储组的哈希值并搁置到哈希环上，在环上按顺时针方向进行搜寻，找到的第 1 个节点就是要插入的节点。

应用哈希环进行数据分区时，容易呈现两个节点的哈希值的差较小的状况，因而在应用一致性哈希环的根底上引入虚构节点，具体做法是将每个物理节点虚构成若干个，并将这些虚构节点依照哈希值搁置到哈希环上，在很大水平上防止了数据歪斜的状况，使数据分布得更加平均。

首先，整个集群预设 10000 个 slot，平均将此 10000 个 slot 散布在各个 DataGroup 上。如下图所示，IoTDB 集群有 4 个 DataGroup，整个集群有 10000 个 slot，则均匀每个 DataGroup 有 10000/4=2500 个 slot. 因为 DataGroup 的数量等于集群节点数 4，也就相当于均匀每个节点 2500 个 slot.

其次，实现 slot 到 DataGroup、Time Partition 和 time series 的映射。

IoTDB 集群依据 raft 协定划分成多个 DataGroup 组，每一个 DataGroup 组中蕴含多个 slot，而每一个 slot 中蕴含多个 time partition，同时每一个 time partition 中蕴含多个 time series，形成关系如下图所示：

最初，通过 Hash 计算 slot 的值，实现输出存储组和工夫戳到 slot 的映射：

1）先按工夫范畴分区，利于工夫范畴查问：

TimePartitionNum = TimeStamp % PartitionInterval

其中 TimePartitionNum 是工夫分区的 ID,TimeStamp 是待插入测点数据的工夫戳，PartitionInterval 是工夫分区距离，默认是 7 天。

2）再按存储组分区，通过 Hash 计算出 slot 的值：

Slot = Hash(StorageGroupName + TimePartitionNum) % maxSlotNum

其中 StorageGroupName 是存储组的名字，TimePartitionNum 是第 1 步计算出的工夫分区 ID，maxSlotNum 是最大 slot 数，默认 10000。

Data Group 和 Storage Group 的关系如下图所示，其中节点 3 和节点 1 上的 Data Group 1 展现的是同一个 Data Group 散布在两个节点上的情景：

以上给大家介绍了 MRS IoTDB 的总体架构，下一篇文章将为大家进一步介绍集群架构的数据写入、数据查问、一致性协定的实现等技术细节，敬请期待。