物联网行业的基本系统架构

from: https://my.oschina.net/u/3374539/blog/3164203?from=20200209

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 等等，它们总存在这一点或多点的让你觉得就是不满足的地方，如下图：

IoTDB

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

1. 高速写入


2. 高效压缩


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


4. 查询低延迟高效


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


6. 对接现有大数据生态

IoTDB 功能特点

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

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，一种基于本地文件。