• 92409

    文章

  • 775

    评论

  • 17

    友链

  • 最近新加了换肤功能,大家多来逛逛吧~~~~
  • 喜欢这个网站的朋友可以加一下QQ群,我们一起交流技术。

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

撸了今年阿里、腾讯和美团的面试,我有一个重要发现.......>>

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

时序数据库 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 存储,那么由于行式存储,所以在取回数据时候就会非常影响效率,这个介绍到 TsFile 模块时候再聊。

2.2 存量数据大

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

3 年大约就会存储 3TB 数据,可能你觉得 3T 数据对于时下最热的大数据来讲并不是一个非常庞大的数字,但如果整个数据里面不包含任何图片、音视频甚至都没有文字,全部是由整数、浮点数堆积起来的,那你可以试想一下:你和一个 DBA 说我们系统要支持 3T 整型数据,我想他肯定是拍拍脑门,点上一根香烟,需要冷静的思考思考人生了。

2.3 采集频率高

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

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

2.4 不同数据库遇到的问题

不同数据库对比图

IoTDB

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

  1. 高速写入
  2. 高效压缩
  3. 多维度查询,降采样、时序分割查询等
  4. 查询低延迟高效
  5. 提高数据质量,乱序、空值等
  6. 对接现有大数据生态

IoTDB 功能特点

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 究竟是什么样的结构才能完成以上所介绍的高速写入、高压缩比、高速查询呢?欢迎继续关注。


695856371Web网页设计师②群 | 喜欢本站的朋友可以收藏本站,或者加入我们大家一起来交流技术!

欢迎来到梁钟霖个人博客网站。本个人博客网站提供最新的站长新闻,各种互联网资讯。 还提供个人博客模板,最新最全的java教程,java面试题。在此我将尽我最大所能将此个人博客网站做的最好! 谢谢大家,愿大家一起进步!

转载原创文章请注明出处,转载至: 梁钟霖个人博客www.liangzl.com

0条评论

Loading...


发表评论

电子邮件地址不会被公开。 必填项已用*标注

自定义皮肤
注册梁钟霖个人博客