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

上一章聊到时序数据是什么样，物联网行业中的时序数据的特色：存量数据大、新增数据多（采集频率高、设备量多）。详情请见：

时序数据库 Apache-IoTDB 源码解析以前言（一）

打一波广告，欢迎你们访问 IoTDB 仓库，求一波 Star 。

这一章主要想聊一聊：

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

聊到这里，咱们基本介绍了行业内的特色，做为数据库须要解决的痛点，以及 IoTDB 在完成功能的同时所具备的自身的优点。同时还简单介绍了 IoTDB 的基础架构，朴实无华且枯燥。那么 TsFile 到底是什么样的结构才能完成以上所介绍的高速写入、高压缩比、高速查询呢？Native API 又是什么？欢迎继续关注。。。