基于Hbase的车联网海量数据存储
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
对于数据库的优化，不可忽略的部分就是进行预分区以 及对行键进行优化，针对不同的数据结构需要采取的分区方 式和行键的设计都是不同的。面对车联网的海量数据，行键 的设计和预分区都是十分重要。在对行键进行设计时，会对 核心字段进行简化并在最开始就约定实现的规则，在后期就 依循着规则来生成行键。选取的行键要求能对存储和查询 存在一定的优化效果 ，而在当前的大数据量存储的系统中 ， 核心是进行存储的优化。面对行量数据存储的场景，本文选 择了将核心字段处理后拼接到行键里面，同时对行键进行散 列化，使行键能够尽可能地散落在不同的 Region 里面，避免 热点现象的出现。
在所搭建的平台上对上述的优化进行测试，实验数据来 自于内部的报文模拟器。为验证优化后的中间件拥有更好 的性能，采用如下方法进行测试：
（1）启动报文模拟器稳定向 Kafka 发送报文； （2）开启 PVO 中间件拉取 Kafka 的报文并对报文进行处 理； （3）将数据存储到 Hbase 里面； （4）通过 Cloudera Manager 的读请求监控观测数据处理
- 60 -
电脑与电信 ∙ 网络与通信
按照以上的策略测试有行键设计的方案和没有行键的 设计方案，以 Cloudera Manager 中对 Hbase 写数据的监控数 据作为对比，通过对比两者的差异来比较两种设计方案的优 劣。实验结果如图 2 所示，横轴为数据开始输入的时间，纵轴 为一分钟内平均的数据请求数量。
车载终端采集的数据是实时 、不间断的 ，要求实时处理 层稳定可靠、不宕机。而 PVO 层的处理能力是有限的，如果 不进行获取消费数据的限制可能会导致数据出现延时，当前 数据还未处理完全 ，后面的数据又进来了 ，当完全堆积在 PVO 的内存后会导致程序压力过大，降低程序的运行速度， 严重情况下甚至会导致宕机。为了处理这个问题，选择在中 间件添加计数器进行数据消费的控制。
中图分类号：TP311.13
文献标识码：A
文章编号：1008 - 6609 (2021) 05 - 0059 - 04
1 引言
在当前的交通运输领域中 ，车联网(IoV) 属于物联网 (IoT)内最典型的应用 ，但因汽车的使用存在周期性 ，使得数 据的产生也存在周期性，汽车数据的海量产生会固定出现在 早高峰和晚高峰期间。每天汽车产生的海量大数据存储达 到了日增数据 15TB，而如此巨量的数据在每日的产生并不 是均匀分布而是周期性的产生，在短时时间里面会产生大量 的数据。为了应对数据波动性产生对集群存储性能的影响， 部分研究者从算法上希望能够解决 Hbase 数据不平衡的问 题，比如通过对预先对数据进行采集分析后再进行数据的分 配[1,2]，还有对 Hbase 的原有算法进行优化，这些方法很好地解 决了数据的不均衡问题，实现了 Hbase 的最大化利用，但是面 对 TB 级别的数据其对 cpu 和集群性能的损耗是巨大的。部 分研究者对数据进行了预处理[3-5]，通过对数据的特征进行提 取，预估不同分区的负载情况，然后提前对 region 进行拆分 或是保证热点数据分布在不同的分区，保证 Hbase 的负载平 衡 ，同样面对 TB 级别的数据 ，其 cpu 的消耗成为了新的瓶 颈。近些年来，面对大数据量的存储，高并发的场景，普遍会 采用 Kafka 作为中间件，因为 Kafka 作为消息中间件所采取 的消息消费模式是发布-订阅的消息模式 ，面对不同的消费 者，Kafka 的分布式消息读取可以很好地支持到它们，相对于 以往的消息队列，Kafka 单点的生产者和消费者拥有显著的
优越性，能够做到百万级的读写速率，其吞吐量更高，性能更 加优越，同时它能将数据写入磁盘的同时将数据复制到集群 里面，这些处理不仅保证了数据的持久化更使数据的容错性 得到了保障[6]。
基于以上背景，为解决海量数据存储在 Hbase 中的存储 问题，本文研究出一种基于 Hbase 的海量数据存储方案。考 虑到车联网数据的特殊性本文采用了相应的行键设计和预 分区 。 [7-11]
（1）剔除缺失数据 ，缺失数据指的是当上传的时候有些 车辆的信息没有被录入到系统里面，当查询该车辆或是该种 车架信息的时候 ，该车辆的信息不存在 ，这些信息将无法录 入数据库中。
（2）区分不同状态信息 ，汽车数据中有部分是属于报警 数据 ，在这些数据在中间件处理的时候就需要被识别出来 ，
——————————————
2 数据预处理与表设计
2.1 数据预处理 研究采用的数据来自实际传输进来的报文，原始数据包
包含每辆车采集的该车编号信息、采集时间、各个部分的埋 点信息等 480 个信号。经过对原始数据的分析，确认了不同 数据拥有不同的价值 ，以及不同数据的归类不同 ，而大量的 信息让处理的成本更高，为了提高这些信息的利用价值和保 证核心数据的不缺失，需要对数据先进行简单的处理后再存 储进入 Hbase 数据库里面，处理的具体步骤如下：
电脑与电信 ∙ 网络与通信
基于 Hbase 的车联网海量数据存储
李 星 邬少飞*
（武汉工程大学计算机科学与工程学院，湖北 武汉 430000）
摘 要：针对如何处理车联网数据的峰值问题，提出了一种基于 Hbase 的车联网海量数据存储的中间件控制方案。首先
报文通过 Kafka 传递到中间件，再对传递至中间件的数据进行计数器处理，限制对 Kafka 的拉取消费；其次对传递至中间件的数
储于一个列簇里面 ，将核心的数据如车辆定位 、定位时的详 细时间、汽车移动速度、汽车的油量、汽车的里程数等数据封 装入一条 Json 字符串里，当需要处理时再提取字符串进行处 理，这样就仅需要一个列，可以极大减轻存储的压力。
当创建一个 Hbase 表的时候，如果不指定预分区 Region， 默认是只会创建一个 Region。当海量数据写入 Hbase 的时 候，所有的数据都会写入默认的 Region 里面，直至 Region 的 空间消耗完，然后进行拆分操作，将一个 Region 划分为两个 小的 Region。这样处理将会造成两个问题：一是数据存储在 单一的 Region 中，更容易出现单节点故障，这会影响到入库 的性能 ；二是该行为会导致磁盘的拆分 ，而拆分操作将使大 量的集群 I/O 资源被消耗掉。为了解决这些问题，本文结合 Rowkey 的设计确定预分区的方案。选择在全表创建 10 个分 区，分区的划分使用 HexStringSplit 算法实现。
为了达到这样的存储效果，当前系统采用的行键设计方 案是：
第一，对车辆的 vin 码的前四位进行了 md5 处理，将数据 散列开；
第二，在后面添加车辆的 vin 码（20 位）； 第三，添加数据类型（15 位）再加上采集时间（18 位，前 14 位为年月日时分秒，第 15 位为 N 表示设备上没有上传采 集时间，由系统自动加上当前时间作为采集时间）； 第四，加随机数（4 位，解决同一时间上传一个数据包，里 头包含两个告警数据导致数据覆盖的问题）。 最终的行键设计方案如表 1 所示。
作者简介：李星（1996-），男，湖北孝感人，硕士研究生，研究方向为大数据技术。 *通讯作者：邬少飞（1979-），男，湖北武汉人，博士，副教授，研究方向大数据技术。
- 59 -
电脑与电信 ∙ 网络与通信
然后及时通过报警系统将数据上传，关于这部分数据的存储 需要先通告报警系统后再录入系统。
（3）剔除失效数据，当数据传输过程中存在数据的累计， 如所处环境的网络信号差，导致后期上传的数据的接收时间 相同 ，对于这种数据仅取发送时间距离当下最近的数据 ，对 于其他数据不进行存储，以防数据之间的冲突。 2.2 行键表达式及行键生成算法
主机名 cdh5-node4 cdh5-node7 cdh5-33 10.0.11.36 10.0.11.37 10.0.11.38
表 2 集群配置 角色 Master, RegionServer,HDFS NameNode, HDFS DataNode RegionServer,HDFS NameNode RegionServer,HDFS NameNode RegionServer,HDFS NameNode
3 数据处理优化
数据实时处理是车联网海量数据存储的核心层。车联 网数据的处理对于实时性的要求是极强的，在一定时间里面 若数据没有处理完全 ，那么这一帧数据就会失效 ，因为只有 满足实时性才能实现对车辆的实时监控 ，并做出及时的反 馈 。 面 对 传 统 平 台 处 理 海 量 数 据 存 在 的 高 延 迟 、高 并 发 问 题，本文选择了开发新的 PVO 中间件担任 Kafka 到 Hbase 中 间的数据实时处理工作。
据进行筛选处理，确保数据都是有效的数据，然后进行存储；最后针对车联网海量数据的应用场景选择能够满足需求的行键设
计以及表结构设计。经实验表明，该中间件控制方案在存储的稳定性上比没有控制方案的具有优越性，该行键设计方案对比
没有行键设计的方案在性能上具有显著的性能提升。
关键词：Hbase；车联网；kafka
详细处理流程如图 1。这里首先对 PVO 的性能进行压 力测试，待内存消耗完，测试出其最大的承受数据量为 DEFAULT_MAX_BLOCKING_SIZE。 PVO 会 在 对 Kafka 数 据 进行消费的同时用 Scheduled 算法对消费数据进行监控，当 大流量涌入并超过最大承受量的时候就会进入等待期同时 进行警告，等待期满发现内存释放出来后会立刻继续进行消 费。此外 ，当出现网络波动等问题时也会导致数据处理延 迟，导致数据的堆积，针对这样的问题，在处理数据前还会调 取 Hbase 的数据存入耗时，当前面的数据存储时间过长时，会 先让进程等待 ，同时进行警报处理 ，方便后期对问题进行排 查和维护 ，直到等待期满后再重复进行判断 ，判断通过后再 进行数据处理。
表 1 行键最终方案
车辆号字段
时间字段 校验字段
vin 码 MD5 4 字节
车辆识别码 20 字节
数据类型+ 采集时间 33 位
随机数 4位
2.3 表的设计和预分区 相对于其他的数据而言，车联网的大批量数据更多是直
接存储进入 Hbase 中，其 90%以上的操作都是写入操作，而且 数据量极其巨大，面对这样的场景可以直接将所有的数据存
为确认当前设计的 Hbase 行键方案是有效的且能够提升 存储的性能 ，这里采取了相同的数据集进行输入测试 ，控制 数据集是相同的 ，数量也相同 ，唯一变化的就是行键是否进 行设计，详细的测试流程如下：
（1）设置每组实验的数据总量为 100w 条，监测数据发送 时 Cloudera Manager 中 Hbase 读写监控展示的数据，截取前 30 分钟作为展出数据；
（2）每组对比实验采用随机模拟的报文数据； （3）每组实验重复三次，取最终存储效率的平均值绘图。
由图 2 可知，在前两分钟里面数据的写入会快速达到最 大峰值 ，然后就在该峰值处波动 ，直到数据存储完毕没有数 据录入的最后两分钟数据写入才会大幅降低。同样是写入 100w 数据，两者的时间消耗不同，但是两种方案都呈现了性 能达到峰值后的稳定性，这显示了 Hbase 对于海量数据存储 的适用性，符合长期高性能稳定的运行要求。同时，图 2 中也 可以看见无行键设计的方案每秒请求数在 3w 左右就达到了 峰值 ，而有行键设计的方案直到 6w 才到达数据存储的峰 值。实验说明，在 Hbase 的表设计中，是否针对存储做合理的 行键设计，对数据的存储性能影响较大。 4.2 中间件优化性能验证
图 2 存储效率对比
图 1 数据处理流程图
4 实验与结果分析
为了验证上述 Hbase 表设计和数据处理优化的性能，通 过实验对其进行评测。实验使用的操作系统均为 centos 6.10，所搭建的 Hbase 集群部署在 Cloudera Manager 上面，版 本为 5.13.1。CDH 版本为 5.13.1，hadoop 版本为 2.6.0，HDFS 版本为 2.6.0，Hbase 版本为 1.2.0。Hbase 集群的详细配置如 表 2 所示。 4.1 行键设计方案的性能验证
在所搭建的平台上对上述的优化进行测试，实验数据来 自于内部的报文模拟器。为验证优化后的中间件拥有更好 的性能，采用如下方法进行测试：
（1）启动报文模拟器稳定向 Kafka 发送报文； （2）开启 PVO 中间件拉取 Kafka 的报文并对报文进行处 理； （3）将数据存储到 Hbase 里面； （4）通过 Cloudera Manager 的读请求监控观测数据处理
- 60 -
电脑与电信 ∙ 网络与通信
按照以上的策略测试有行键设计的方案和没有行键的 设计方案，以 Cloudera Manager 中对 Hbase 写数据的监控数 据作为对比，通过对比两者的差异来比较两种设计方案的优 劣。实验结果如图 2 所示，横轴为数据开始输入的时间，纵轴 为一分钟内平均的数据请求数量。
车载终端采集的数据是实时 、不间断的 ，要求实时处理 层稳定可靠、不宕机。而 PVO 层的处理能力是有限的，如果 不进行获取消费数据的限制可能会导致数据出现延时，当前 数据还未处理完全 ，后面的数据又进来了 ，当完全堆积在 PVO 的内存后会导致程序压力过大，降低程序的运行速度， 严重情况下甚至会导致宕机。为了处理这个问题，选择在中 间件添加计数器进行数据消费的控制。
中图分类号：TP311.13
文献标识码：A
文章编号：1008 - 6609 (2021) 05 - 0059 - 04
1 引言
在当前的交通运输领域中 ，车联网(IoV) 属于物联网 (IoT)内最典型的应用 ，但因汽车的使用存在周期性 ，使得数 据的产生也存在周期性，汽车数据的海量产生会固定出现在 早高峰和晚高峰期间。每天汽车产生的海量大数据存储达 到了日增数据 15TB，而如此巨量的数据在每日的产生并不 是均匀分布而是周期性的产生，在短时时间里面会产生大量 的数据。为了应对数据波动性产生对集群存储性能的影响， 部分研究者从算法上希望能够解决 Hbase 数据不平衡的问 题，比如通过对预先对数据进行采集分析后再进行数据的分 配[1,2]，还有对 Hbase 的原有算法进行优化，这些方法很好地解 决了数据的不均衡问题，实现了 Hbase 的最大化利用，但是面 对 TB 级别的数据其对 cpu 和集群性能的损耗是巨大的。部 分研究者对数据进行了预处理[3-5]，通过对数据的特征进行提 取，预估不同分区的负载情况，然后提前对 region 进行拆分 或是保证热点数据分布在不同的分区，保证 Hbase 的负载平 衡 ，同样面对 TB 级别的数据 ，其 cpu 的消耗成为了新的瓶 颈。近些年来，面对大数据量的存储，高并发的场景，普遍会 采用 Kafka 作为中间件，因为 Kafka 作为消息中间件所采取 的消息消费模式是发布-订阅的消息模式 ，面对不同的消费 者，Kafka 的分布式消息读取可以很好地支持到它们，相对于 以往的消息队列，Kafka 单点的生产者和消费者拥有显著的
优越性，能够做到百万级的读写速率，其吞吐量更高，性能更 加优越，同时它能将数据写入磁盘的同时将数据复制到集群 里面，这些处理不仅保证了数据的持久化更使数据的容错性 得到了保障[6]。
基于以上背景，为解决海量数据存储在 Hbase 中的存储 问题，本文研究出一种基于 Hbase 的海量数据存储方案。考 虑到车联网数据的特殊性本文采用了相应的行键设计和预 分区 。 [7-11]
（1）剔除缺失数据 ，缺失数据指的是当上传的时候有些 车辆的信息没有被录入到系统里面，当查询该车辆或是该种 车架信息的时候 ，该车辆的信息不存在 ，这些信息将无法录 入数据库中。
（2）区分不同状态信息 ，汽车数据中有部分是属于报警 数据 ，在这些数据在中间件处理的时候就需要被识别出来 ，
——————————————
2 数据预处理与表设计
2.1 数据预处理 研究采用的数据来自实际传输进来的报文，原始数据包
包含每辆车采集的该车编号信息、采集时间、各个部分的埋 点信息等 480 个信号。经过对原始数据的分析，确认了不同 数据拥有不同的价值 ，以及不同数据的归类不同 ，而大量的 信息让处理的成本更高，为了提高这些信息的利用价值和保 证核心数据的不缺失，需要对数据先进行简单的处理后再存 储进入 Hbase 数据库里面，处理的具体步骤如下：
电脑与电信 ∙ 网络与通信
基于 Hbase 的车联网海量数据存储
李 星 邬少飞*
（武汉工程大学计算机科学与工程学院，湖北 武汉 430000）
摘 要：针对如何处理车联网数据的峰值问题，提出了一种基于 Hbase 的车联网海量数据存储的中间件控制方案。首先
报文通过 Kafka 传递到中间件，再对传递至中间件的数据进行计数器处理，限制对 Kafka 的拉取消费；其次对传递至中间件的数
储于一个列簇里面 ，将核心的数据如车辆定位 、定位时的详 细时间、汽车移动速度、汽车的油量、汽车的里程数等数据封 装入一条 Json 字符串里，当需要处理时再提取字符串进行处 理，这样就仅需要一个列，可以极大减轻存储的压力。
当创建一个 Hbase 表的时候，如果不指定预分区 Region， 默认是只会创建一个 Region。当海量数据写入 Hbase 的时 候，所有的数据都会写入默认的 Region 里面，直至 Region 的 空间消耗完，然后进行拆分操作，将一个 Region 划分为两个 小的 Region。这样处理将会造成两个问题：一是数据存储在 单一的 Region 中，更容易出现单节点故障，这会影响到入库 的性能 ；二是该行为会导致磁盘的拆分 ，而拆分操作将使大 量的集群 I/O 资源被消耗掉。为了解决这些问题，本文结合 Rowkey 的设计确定预分区的方案。选择在全表创建 10 个分 区，分区的划分使用 HexStringSplit 算法实现。
为了达到这样的存储效果，当前系统采用的行键设计方 案是：
第一，对车辆的 vin 码的前四位进行了 md5 处理，将数据 散列开；
第二，在后面添加车辆的 vin 码（20 位）； 第三，添加数据类型（15 位）再加上采集时间（18 位，前 14 位为年月日时分秒，第 15 位为 N 表示设备上没有上传采 集时间，由系统自动加上当前时间作为采集时间）； 第四，加随机数（4 位，解决同一时间上传一个数据包，里 头包含两个告警数据导致数据覆盖的问题）。 最终的行键设计方案如表 1 所示。
作者简介：李星（1996-），男，湖北孝感人，硕士研究生，研究方向为大数据技术。 *通讯作者：邬少飞（1979-），男，湖北武汉人，博士，副教授，研究方向大数据技术。
- 59 -
电脑与电信 ∙ 网络与通信
然后及时通过报警系统将数据上传，关于这部分数据的存储 需要先通告报警系统后再录入系统。
（3）剔除失效数据，当数据传输过程中存在数据的累计， 如所处环境的网络信号差，导致后期上传的数据的接收时间 相同 ，对于这种数据仅取发送时间距离当下最近的数据 ，对 于其他数据不进行存储，以防数据之间的冲突。 2.2 行键表达式及行键生成算法
主机名 cdh5-node4 cdh5-node7 cdh5-33 10.0.11.36 10.0.11.37 10.0.11.38
表 2 集群配置 角色 Master, RegionServer,HDFS NameNode, HDFS DataNode RegionServer,HDFS NameNode RegionServer,HDFS NameNode RegionServer,HDFS NameNode
3 数据处理优化
数据实时处理是车联网海量数据存储的核心层。车联 网数据的处理对于实时性的要求是极强的，在一定时间里面 若数据没有处理完全 ，那么这一帧数据就会失效 ，因为只有 满足实时性才能实现对车辆的实时监控 ，并做出及时的反 馈 。 面 对 传 统 平 台 处 理 海 量 数 据 存 在 的 高 延 迟 、高 并 发 问 题，本文选择了开发新的 PVO 中间件担任 Kafka 到 Hbase 中 间的数据实时处理工作。
据进行筛选处理，确保数据都是有效的数据，然后进行存储；最后针对车联网海量数据的应用场景选择能够满足需求的行键设
计以及表结构设计。经实验表明，该中间件控制方案在存储的稳定性上比没有控制方案的具有优越性，该行键设计方案对比
没有行键设计的方案在性能上具有显著的性能提升。
关键词：Hbase；车联网；kafka
详细处理流程如图 1。这里首先对 PVO 的性能进行压 力测试，待内存消耗完，测试出其最大的承受数据量为 DEFAULT_MAX_BLOCKING_SIZE。 PVO 会 在 对 Kafka 数 据 进行消费的同时用 Scheduled 算法对消费数据进行监控，当 大流量涌入并超过最大承受量的时候就会进入等待期同时 进行警告，等待期满发现内存释放出来后会立刻继续进行消 费。此外 ，当出现网络波动等问题时也会导致数据处理延 迟，导致数据的堆积，针对这样的问题，在处理数据前还会调 取 Hbase 的数据存入耗时，当前面的数据存储时间过长时，会 先让进程等待 ，同时进行警报处理 ，方便后期对问题进行排 查和维护 ，直到等待期满后再重复进行判断 ，判断通过后再 进行数据处理。
表 1 行键最终方案
车辆号字段
时间字段 校验字段
vin 码 MD5 4 字节
车辆识别码 20 字节
数据类型+ 采集时间 33 位
随机数 4位
2.3 表的设计和预分区 相对于其他的数据而言，车联网的大批量数据更多是直
接存储进入 Hbase 中，其 90%以上的操作都是写入操作，而且 数据量极其巨大，面对这样的场景可以直接将所有的数据存
为确认当前设计的 Hbase 行键方案是有效的且能够提升 存储的性能 ，这里采取了相同的数据集进行输入测试 ，控制 数据集是相同的 ，数量也相同 ，唯一变化的就是行键是否进 行设计，详细的测试流程如下：
（1）设置每组实验的数据总量为 100w 条，监测数据发送 时 Cloudera Manager 中 Hbase 读写监控展示的数据，截取前 30 分钟作为展出数据；
（2）每组对比实验采用随机模拟的报文数据； （3）每组实验重复三次，取最终存储效率的平均值绘图。
由图 2 可知，在前两分钟里面数据的写入会快速达到最 大峰值 ，然后就在该峰值处波动 ，直到数据存储完毕没有数 据录入的最后两分钟数据写入才会大幅降低。同样是写入 100w 数据，两者的时间消耗不同，但是两种方案都呈现了性 能达到峰值后的稳定性，这显示了 Hbase 对于海量数据存储 的适用性，符合长期高性能稳定的运行要求。同时，图 2 中也 可以看见无行键设计的方案每秒请求数在 3w 左右就达到了 峰值 ，而有行键设计的方案直到 6w 才到达数据存储的峰 值。实验说明，在 Hbase 的表设计中，是否针对存储做合理的 行键设计，对数据的存储性能影响较大。 4.2 中间件优化性能验证
图 2 存储效率对比
图 1 数据处理流程图
4 实验与结果分析
为了验证上述 Hbase 表设计和数据处理优化的性能，通 过实验对其进行评测。实验使用的操作系统均为 centos 6.10，所搭建的 Hbase 集群部署在 Cloudera Manager 上面，版 本为 5.13.1。CDH 版本为 5.13.1，hadoop 版本为 2.6.0，HDFS 版本为 2.6.0，Hbase 版本为 1.2.0。Hbase 集群的详细配置如 表 2 所示。 4.1 行键设计方案的性能验证