基于HBase的工业大数据存储实战物品追踪系统中的CAN协议应用

基于HBase的工业大数据存储实战物品追踪系统中的CAN协议应用

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

了解HBase

HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。它利用Hadoop HDFS作为其文件存储系统,并通过MapReduce进行海量数据处理。与Google Bigtable相比,虽然两者都是基于Bigtable设计,但有显著差异:前者使用的是普通硬件配置,而后者则需要特殊硬件支持;而且,它们使用不同的协同服务,比如ZooKeeper替代Chubby。

与传统数据库相比,HBASE具备多重优势:

线性扩展,即使数据量增多,也能通过增加节点来提供支撑。

数据存储在hdfs上,因此备份机制健全。

通过zookeeper协调查询过程,可以快速访问速度。

HBase实战案例

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

案例背景

该公司业务场景中涉及大量面板相关特征,每张面板约有3.2k字节大小,这些面板被分组,其中43%左右包含一张面板,47%包含2-9张,而剩余组数范围从10到10000个。业务需求主要包括:

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

根据组id+面板id查找某个具体面的信息。

原方案采用MySQL+OSS(对象存储),但由于每个群体内含有的玻璃数量极度不均匀,该方案存在两个问题:

MySQL表结构无法合理利用空间效率,因为相同group_id对应于不同数量的人脸图片,因此需要创建许多行来记录这些关系。

查询操作较慢,因为首先需要从MySQL读取很多行,然后再从OSS获取相关特征,这导致链路长且查询时间较长(约10秒)。

解决方案:引入HBase

针对这两个问题,由于以上提到的缺陷,大数据团队决定采用基于ColumnFamily(列族)的分布式NoSQL解决方案——Apache Hbase。在这个新的设计中,将每个FaceID视作单独的一个列名,并将整个表开启MOB功能,以便优化小文件读写能力。此外,由于只有少数几个FaceID会达到MB级别,所以没有必要开启MOB,但是可以根据实际情况调整阈值,从而提高查询效率。

表设计

CREATE 'glass' (NAME => 'c', IS_MOB => true, MOB_THRESHOLD => 2048)

这样我们就可以直接将FaceID作为列名,同时保持良好的空间效率并减少了读取时间。这意味着用户如果想要获取指定group_id下所有face_images所需执行一次Get操作即可,不再需要像之前那样扫描大量行或者访问多种不同类型的事务日志。如果你想知道更多关于这个案例或其他技术细节,请继续关注我们的后续文章!