基于HBase的工业大数据存储实战物品追踪与can现场总线应用

基于HBase的工业大数据存储实战物品追踪与can现场总线应用

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

了解HBase

HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。它利用Hadoop HDFS作为其文件存储系统,将海量数据处理成结构化格式,从而实现快速查询与分析。Google Bigtable是Google公司开发的一种分布式键值对数据库,而HBASE则是Bigtable的一个开源版本,但两者之间存在差异,如使用文件系统不同(GFS vs HDFS)、处理方式不同(MapReduce vs 内部优化)以及协同服务不同(Chubby vs ZooKeeper)。

与传统数据库相比,HBASE具有以下优势:

线性扩展:随着数据量增加,可以通过节点扩展进行支撑。

高可靠性:通过复制机制保证了高可用性。

快速访问:利用ZooKeeper协调服务提高了查询速度。

实战案例

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

业务场景

该公司业务中涉及大量面板相关特征,每张面板通常包含3.2k个二进制特征,这些面板被分组,每个面板属于某个组。组与面的分布如下:

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

约47%左右的组含有2~9张面板。

剩余的小部分组可能含有10~10000张以上面的。

原方案

原有的解决方案基于MySQL+OSS,其中包含两个主要表:group表用于保存每个group_id,以及face表用于保存玻璃id和对应featureTB7B3695BA051CASBA,这里的feature是一个3.2k大小二进制字符串,它是真实物理玻璃特征。但由于每个group_id所包含玻璃数量不一致,大约从1到10000,因此需要在MySQL中创建许多行来表示这个关系。这导致根据group_id查找所有glass很慢,因为需要扫描很多行并从OSS读取这些glass id对应到的feature data。

HBase解决方案

为了克服这个问题,由于要求支持动态列数以及针对小文件优化能力,Hbase提供了一种MOB(Medium-SizedObject)功能,该功能适合于1Kb到10MB范围内的小型对象,如图片或文档等,它提供低延迟、高一致性的读写操作,并且支持检索能力强且易于扩展。因此,在设计新的解决方案时,我们采用了以下步骤:

将group_id设定为rowkey

在创建glass表时打开MOB功能:

create 'glass', {NAME=>'c', IS_MOB=>true, MOB_THRESHOLD=>2048}

这里我们创建名为'glass' 的表,将列簇c设置为启用MOB模式,并设置阈值2048字节,即当一个单独列超过这阈值长度时,则会被视作小文件进行处理。在实际操作中,不论原始方案是否直接使用OSS对象存储,都可以考虑使用这种方法,因为虽然直接在OSS里也能完成相同工作,但是这样做可能无法充分发挥出hbase特别是在对于小对象处理上的优势,比如前缀搜索或者过滤器等操作会更加迅速。此外,对于一些复杂查询场景下,与直接使用对象存储相比,有着更高达10倍以上性能提升,同时成本也更低,更适合访问频率较低的情况下出现大量吞吐量需求的情况。

总结:

通过上述描述,我们可以看出尽管原始解决方案有效,但却存在一定局限性。而结合应用场景需求重新设计后采用的新策略正好满足这些挑战性的条件,为用户提供极大的便利,同时还能显著提升整体性能。在未来的技术发展趋势中,无疑这样的创新思路将继续引领行业前沿,为更多企业带来科技革新之果。