基于HBase的工业大数据存储实战物品现场总线技术十种选择
随着工业4.0时代的到来,工业互联网和企业的智能化、信息化都将不断推进,传统的工业实时数据库和关系数据库已经难以完全胜任工业大数据的存储,以HBase为代表的NoSQL数据库正在蓬勃发展,其完全分布式特征、高性能、多副本和灵活的动态扩展等特点,使得HBase在工业大数据的存储上拥有强大的优势,打破了流程工业生产中的数据壁垒效应,促进了生产水平和管理水平的大幅提升。本期格物汇,就来给大家介绍HBase数据库及格创东智相关实战案例。
了解HBase
HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。它利用普通硬件配置就能处理由成千上万行和列组成的大型数据。与Google Bigtable有很多不同之处,比如使用的是Hadoop HDFS而不是GFS,以及通过MapReduce来处理海量数据,而不是直接运行MAPREDUCE。
与传统数据库相比,HBASE具备多重优势:
线性扩展,可以根据需求增加节点。
数据存储在hdfs上,有健全备份机制。
通过zookeeper协调服务,访问速度快。
HBase实战案例:快速查找面板特征
为了更好地介绍HBase在人工智能场景下的应用,我们以某半导体显示企业为案例,将分析如何利用HBase设计一个快速查找面板特征系统。
案例背景
该公司业务场景中含有大量面板相关特征,每张面板数据约3.2k,这些面板又被分为不同的组,每个面的特征属于某个组。目前业务需求主要包括:
根据组id查询该组下所有面的数据。
根据组id+faceid查询某个面的具体数据。
原方案分析
原有的解决方案是MySQL+OSS,由于每个组包含数量不一致(1~10000)的玻璃特征数,所以基于表设计需要将玻璃对应关系存入MySQL中,对应group表;玻璃id及其相关特征data则存在OSS中,对应face表。但由于MySQL不支持动态列且需拆分同一条数据至多行存储,因此后续查询会涉及链式操作,从MySQL读取许多行,然后到OSS获取这些feature data,这导致整个查询时间较长达10秒左右,不足以满足现有业务快速发展需求。
Hbase解决方案
针对这两个问题,大数据团队认为这是典型使用场景,因为:
Hbase支持动态列适合万亿行百万列。
支持多版本记录所有修改历史。
Hbase 2.0引入MOB(Medium-Sized Object)功能适合小文件(1k~10MB)如图片短视频文档等低延迟读写强一致检索能力强易扩展能力强特色应用于此类情况,如图片视频等文件大小介于1K到10M之间时可以考虑采用MOB功能进行优化,以达到更好的性能表现。
团队重新设计原方案,将panel_group_id作为RowKey,并打开MOB功能创建glass表:
create 'glass', {NAME=>'c', IS_MOB=>true, MOB_THRESHOLD=>2048}
这里创建名为glass 的表,其中IS_MOB属性说明列簇c 将启用MOB 特性,MOB_THRESHOLD 是 MOB 文件大小阈值单位字节,该设置意味着当文件超过2KB 时 当作小文件 存储。在原始方案中采用 OSS 对象 存储,那么为什么不直接用 OSS 存储 panel_feature_data 呢?如果有人提出这个疑问,可以查看以下性能比较:
| 属性 | 对象存储云 | HBASE建模能力 |
|-------------|---------------|----------------|
| K/V | | |
| 表 | | |
| 稀疏表 | | |
| SQL | | |
| 全文索引 | | |
| 时空 || ||
|| || ||
|| || ||
|| || ||
|| || ||
|| || ||
||||||||||||||
|| |
对象类型通用<10MB StringCF_DEFAULT=c;根据以上对比,我们发现使用 HBASE 的 MOB 功能 来保存小于 10MB 的对象相比直接使用对象存储有一些优势。现在我们看看具体实现方法,与正常操作一样,只是在插入或更新时指定 column family 和 row key 即可。这使得用户可以根据 group id 获取所有 glass data 使用单独的一种方法:Get get = new Get(groupId.getBytes()); table.get(get);
总结来说,在实际项目开发过程中,无论是因为传统关系型数据库不足以支撑当前大规模复杂结构化或非结构化数据集,或是希望提高运维效率降低成本,都可能会考虑选择类似 NoSQL 数据库(HBASE)这样的工具。此外,还需要结合实际业务场景以及技术选型进行综合考量,以确保最佳结果。此次分享还未结束,请继续关注接下来更多精彩内容!