基于HBase的工业大数据存储实战

随着工业4.0时代的到来，工业互联网和企业的智能化、信息化都将不断推进，传统的工业实时数据库和关系数据库已经难以完全胜任工业大数据的存储，以Hbase为代表的NoSQL数据库正在蓬勃发展，其完全分布式特征、高性能、多副本和灵活的动态扩展等特点，使得Hbase在工业大数据的存储上拥有强大的优势，打破了流程工业生产中的"数据壁垒"效应的瓶颈,可以促进工业生产水平和生产管理水平的提高。本期格物汇，就来给大家介绍Hbase数据库及格创东智相关实战案例。

了解Hbase

Hbase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用Hbase技术可在廉价PC Server上搭建起大规模结构化存储集群。Hbase的目标是存储并处理大型的数据，更具体来说是仅需使用普通的硬件配置，就能够处理由成千上万的行和列所组成的大型数据。

Hbase是GoogleBigtable的开源实现，但是也有很多不同之处。比如：Google Bigtable使用GFS作为其文件存储系统，Hbase利用HadoopHDFS作为其文件存储系统；Google运行MAPREDUCE来处理Bigtable中的海量数据，Hbase同样利用Hadoop MapReduce来处理Hbase中的海量数据；Google Bigtable利用Chubby作为协同服务，Hbase利用Zookeeper作为协同服务。

与传统数据库的相比，Hbase具备多重优势：

1）线性扩展，随着数据量增多可以通过节点扩展进行支撑；

2）数据存储在hdfs上，备份机制健全；

3）通过zookeeper协调查找数据，访问速度快。

Hbase实战案例

为了更好的介绍 Hbase 在人工智能场景下的使用，下面我们以某半导体显示企业为案例，给大家分析格创东智大数据团队如何利用 Hbase 设计出一个快速查找面板特征的系统。

目前，该公司的业务场景里面有很多面板相关的特征数据，每张面板数据大概 3.2k。这些面板数据又被分成很多组，每个面板特征属于某个组。组和面板的数据分布如下：

——43%左右的组含有1张面板数据；

——47%左右的组含有 2 ~9张面板数据；

——其余的组面板数范围为 10 ~ 10000张。

现在的业务需求主要有以下两类：

——根据组的 id 查找该组下面的所有面板数据；

——根据组 id +面板id 查找某个面板的具体数据。

原有方案：MySQL+OSS

之前业务数据量比较小的情况使用的存储主要为 MySQL 以及 OSS(对象存储)。相关表主要有面板组表group和面板表face。表的格式如下：

group表：

group_idsize12

glass表：

glass_idgroup_idfeature"TB7B3695BA05"1"CASBA"

其中 feature（特征）大小为3.2k，是二进制数据 base64 后存入的，这个就是真实的面板特征数据。现在面板组 id 和面板id 对应关系存储在MySQL 中，对应上面的 group 表；面板 id 和面板相关的特征数据存储在 OSS 里面，对应上面的 face 表。

因为每个面板组包含的玻璃特征数相差很大(1 ~ 10000)，所以基于上面的表设计，我们需要将面板组以及每张面板特征id存储在每一行，那么属于同一个面板组的数据在MySQL 里面上实际上存储了很多行。比如某个组id对应的特征数为10000，那么需要在MySQL 里面存储 10000 行。

我们如果需要根据面板组 id 查找该组下面的所有面板，那么需要从 MySQL 中读取很多行的数据，从中获取到组和面板对应的关系，然后到 OSS 里面根据面板id获取所有相关的特征数据。

这样的查询导致链路非常长。从上面的设计可看出，如果查询的组包含的面板张数比较多的情况下，那么我们需要从 MySQL 里面扫描很多行，然后再从 OSS 里面拿到这些特征数据，整个查询时间在10秒左右，远远不能满足现有业务快速发展的需求。