时序数据库Apache-IoTDB源码解析之系统架构

Posted OSC开源社区

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了时序数据库Apache-IoTDB源码解析之系统架构相关的知识,希望对你有一定的参考价值。

本文主要想聊一聊:

  1. 物联网行业的基本系统架构,及使用数据库遇到的需求与挑战

  2. IoTDB 的功能特点及系统架构


车联网


因为本人是在做车联网行业,所以对这个行业的信息了解更深入一些,能够拿到一些更具体的数字来说明这个行业的具体情况。在上一篇文中的数据是出于自己的理解,为了让大家容易明白而编造的数据,但实际情况要复杂的多。

1. 系统架构

1.1 系统简介

以上示意图可能非常简单,但我觉得足够表明一个整体架构。当一台设备、一辆车连接到协议网关后,便开始了真正的收发数据。一般通信的方式都是基于 tcp,搞一段二进制协议,所以协议网关基本要做的工作就是完成对连接的管理、完成对数据的收发及编解码。

当数据完成编解码之后一般会发往消息队列当中,一般都是 Kafka 之中。用来解耦生产和消费两端,提供一层缓冲,无论消费服务是死是活还是速度慢,包治百病,甚至还能治未病。

数据发往消息队列的过程中,或之后花活儿就多起来了。但主要的我认为无非还是三种处理方式:

  1. 需要将原始数据保存入库,这里的原始数据包含二进制数据和解码后的二进制数据。

  2. 流处理或批处理数据,在数据落到硬盘之前将能够提前计算的数据全部预先计算出来,这样做的好处是将来查询的时候如果和预计算的模型匹配,那就能非常快的得到结果。

  3. 离线处理,这里的应用就太广泛了,一般来讲都是将耗时比较大的放置离线计算来做。但是这里要声明一点,离线计算依然是越快越好,不能因为他叫离线计算所以在设计或开发阶段就不关注时效。

1.2 数据质量

上一章提到了基本的数据质量,但实际工作中,往往质量会出现各种意想不到的数据,下面是工程中影响数据质量的几个比较大的问题:

  1. 数据丢失,不管是在采集,上报,数据流转环节,都可能会带来一定的数据丢失比例。

  2. 数据乱序,数据在打包、上报、流转等环节均可能出现乱序,尤其是在补传数据中。

  3. 数据重复,数据重复发送,尤其是在网络不好时。

  4. 数据本身不准确,这个最突出的地方就是在 GPS 数据中,经常出现飘点、噪点等等。

2. 数据库的挑战

2.1 数据项多

汽车里具有非常复杂的电路系统和传感器设备,我印象当中的粗略估算应该是有 120 项左右,并且这些数据项并不是车内数据的全部。随着自动驾驶的到来,汽车的传感器会越来越多,数据项就会更多。

如果按照传统的 mysql 存储,那么由于行式存储,所以在取回数据时候就会非常影响效率,之后介绍到 IoTDB 的文件格式的时候再聊。

2.2 存量数据大

我们按照宝马汽车 2019 销售量估计,252 万辆,我们假定 4 年前就已经具备了联网模块那就是 1000 万辆汽车。按照每条数据 1K,每天采样上传 1 次,应该是 每天 9G 数据。但因为车不可能一直都点火开,所以要假设一个 30% 的在线率,那就是 3G 数据。

3 年大约就会存储 3TB 数据,可能你觉得 3T 数据对于时下最热的大数据来讲并不是一个非常庞大的数字,但如果整个数据里面不包含任何图片、音视频甚至都没有文字,全部是由整数、浮点数堆积起来的,那你可以试想一下这个数据库里面到底有多少数据,如果你一个不小心执行了 count(*) 你觉得会卡死不?

2.3 采集频率高

汽车不同于其他传感器的地方是,他是一个处在时刻运动当中的物体,如果需要做一些高阶的计算模型,比如说:碰撞检测、行驶轨迹纠偏等,那么相应的数据采集频率有可能要达到秒级。

当然我说完这句话,可能你感触并不是很深,但是结合前面说到的两点:120项数据、1000万辆车,将采集频率提高到 1 秒一采集,那么这个频率下,一天产生的数据大小就是 259T。这时候你找 DBA 说,哥们我们的需求要 1 天写入 259T 数据,我觉得反正我是没脸找人家,让产品去跟 DBA 聊吧。

2.4 大数据分析需求

现有时序数据库都无法支持大数据分析框架,都需要通过数据库的 Api 把数据从数据库往数据仓库导出后再存一份,数据量直接翻倍。举个例子,我如果需要对 Mysql 中的数据进行 MapReduce 计算,那么只能是将数据通过 JDBC 接口导出到 Hbase 或 Hdfs 上,然后执行计算,可能你觉得这很正常,但按照上面提到的数据量,数据复制之后你公司里可能就需要每天支撑 500T 数据。

2.4 不同数据库遇到的问题

我们公司也采用了多种尝试,从开始的 MySql 到 MongoDB 再到 Hbase 等等,它们总存在这一点或多点的让你觉得就是不满足的地方,如下图:

时序数据库Apache-IoTDB源码解析之系统架构


IoTDB


到此为止,整体需求基本明确,作为一款物联网的时序数据库需要处理的问题:

  1. 高速写入

  2. 高效压缩

  3. 多维度查询,降采样、时序分割查询等

  4. 查询低延迟高效

  5. 提高数据质量,乱序、空值等

  6. 对接现有大数据生态

IoTDB 功能特点

时序数据库Apache-IoTDB源码解析之系统架构

IoTDB 完成了上述问题中的几乎所有功能,而且可以灵活对接多生态,高性能优势等。那么 IoTDB 是如何完成这些优势项,如何做到?

IoTDB 架构描述

时序数据库Apache-IoTDB源码解析之系统架构

对照上面的图,大致了解一下 IoTDB 的结构,逻辑上被分为 3 个大部分,其中:

  1. Engine 是完整的数据库进程,负责 sql 语句的解析,数据写入、查询、元数据管理等功能。

  2. Storage 是底层存储结构,类似于Mysql 的 idb 文件

  3. Analyzing Layer 是各种连接器,暂不涉及细节。

Engine 和 Storage 中主要包含:

  1. IoTDB Engine,也就是代码中的 Server 模块.

  2. Native API,他是高效写入的基石,代码中的 Session 模块

  3. JDBC,传统的 JDBC 连接调用方式,代码中的 JDBC 模块

  4. TsFile,这是整个数据库的一个特色所在,传统的数据库如果使用 Spark 做离线分析,或者 ETL 都需要通过数据库进程对外读取,而 IoTDB 可以直接迁移文件,省去了来回转换类型的开销。TsFile 提供了两种读写模式,一种基于 HDFS,一种基于本地文件。


时序数据库Apache-IoTDB源码解析之系统架构



觉得不错,请点个在看

以上是关于时序数据库Apache-IoTDB源码解析之系统架构的主要内容,如果未能解决你的问题,请参考以下文章

时序数据库 Apache-IoTDB 源码解析之文件索引块

Dubbo原理和源码解析之服务暴露

Dubbo原理何源码解析之服务暴露

时序数据库连载系列: 时序数据库一哥InfluxDB之存储机制解析

Dubbo原理和源码解析之服务引用

互联网级监控系统必备-时序数据库之Influxdb集群及踩过的坑