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

了解HBase

HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。它利用Hadoop HDFS作为其文件存储系统，将海量数据处理能力通过MapReduce框架实现。与Google Bigtable不同的是,HBASE使用Zookeeper作为协同服务，而不是Chubby。此外，尽管两者都是基于Bigtable设计，但它们在实现细节上有所差异。

与传统数据库相比,HBASE具备多重优势：线性扩展能力，可以根据需求增加节点；通过Distributed File System（如HDFS）进行备份机制设计；利用Zookeeper提供的一致性服务提高访问速度。

HBase实战案例

为了更好地理解如何在人工智能场景中应用HBase，我们将以某半导体显示企业为案例分析格创东智大数据团队是如何利用HBase快速查找面板特征系统。

业务场景描述

该公司涉及大量面板相关特征数据，每张面板约3.2k字节，并且被分组，每个面板特征属于一个组。组间分布如下：

43%左右的组含1张面板。

47%左右包含2~9张。

剩余部分每个群体包含10~10000张。

业务需求主要包括：

根据组id查找该组下所有面的panel data。

根据group id + panel id查找指定panel具体data。

原有方案：MySQL+OSS

之前由于业务规模较小，上述问题使用MySQL+OSS解决。这一方案包括两个表：group表(glass) 和 face表(featue)，其中glass_id用于记录group_id对应关系，而feature是指实际玻璃特征二进制表示后的base64编码形式（大小约3.2k）。

由于每个group可能包含极少或很多玻璃数（1~10000），这种设计导致需要创建大量行以保持完整信息，这会显著影响查询效率，因为当需要根据face_id获取所有glass_data时需先从MySQL读取rows然后再去OSS获取feature_data，这种链路长且耗时，对于复杂查询来说时间延迟达到十秒以上远未能满足当前业务增长要求。

HBASE解决方案

针对现有的挑战，由于原始方案存在以下缺陷：

数据拆分导致无法一行内存储大量内容。

MySQL不支持动态列操作，所以相同group下的glass_data被拆成多行保存。

考虑到这些问题，大数据团队认为这是典型适用场合选择采用NoSQL-Hbase技术解决之道。理由如下：

Hbase支持动态列结构，可以万亿行百万列；

支持版本控制，对所有修改记录；

自带MOB(Medium-Sized Object)功能适合小文件，如图片短视频文档等，有低延迟读写强一致检索能力强易扩展等优点。在这个基础上，我们可以重新设计原本方案，将glass_groupID作为RowKey，在创建表的时候打开MOB功能，如下：

CREATE 'Glass', {NAME => 'c', IS_MOB => true, MOB_THRESHOLD => 2048}

这里我们创建名为Glass 的表，其中IS_MOB属性说明列簇c 将启用MOB 特性，并设置了MOB_THRESHOLD 为2048，即超过这个阈值的小文件视作MB对象处理。在原始方案中采用了OSS 对象存储，那为什么不直接使用OSS 存储呢？答案见下方“对比属性”部分：

对比属性

| 属性 | 对象存储云 | HBASE建模能力 |

|---------------|-------------|----------------|

| K/V | | |

| 表 | | |

| 稀疏表 | | |

| SQL | | |

| 全文索引 | | |

| 时空图 || |

对于小对象尤其是在访问频率低的情况下，它们提供了一些优势，比如成本计费方式更经济，更适合高并发高吞吐量环境。但若干次请求次数计费，则成本较高。而对于复杂查询情况，比起普通对象则有10倍以上性能提升，因此最终决定采用hbase-mob模式来替代原来mysql-oos模式，以此来减少瓶颈问题并提高整体查询效率，从而满足目前急剧增长的人口统计学研究工作需求。