基于HBase的工业大数据存储实战物品现场总线技术应用案例
随着工业4.0时代的到来，工业互联网和企业的智能化、信息化都将不断推进，传统的工业实时数据库和关系数据库已经难以完全胜任工业大数据的存储，以HBase为代表的NoSQL数据库正在蓬勃发展，其完全分布式特征、高性能、多副本和灵活的动态扩展等特点，使得HBase在工业大数据的存储上拥有强大的优势，打破了流程工业生产中的数据壁垒效应，促进了生产水平和管理水平的大幅提升。本期格物汇，就来给大家介绍HBase数据库及格创东智相关实战案例。
了解HBase
HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，它利用Hadoop HDFS作为其文件存储系统。与Google Bigtable不同的是,HBASE不仅仅是Bigtable的一个开源实现，它还有很多不同的设计理念，比如它使用MapReduce进行海量数据处理，而不是像Bigtable那样使用GFS。
与传统数据库相比，HBASE具备多重优势：
线性扩展：随着数据量增多，可以通过节点扩展进行支撑。
数据存储在hdfs上，备份机制健全。
通过zookeeper协调服务找到数据，访问速度快。
HBase实战案例
为了更好地介绍HBase在人工智能场景下的应用，我们将以某半导体显示企业为案例分析格创东智大数据团队如何利用HBase设计出一个快速查找面板特征系统。
该公司业务场景中有大量面板相关特征数据，每张面板通常包含3.2k个二进制特征，这些面板又被分组，每个面板属于某个组。组和面的分布如下：
大约43% 的组只含一张面板。
大约47% 的组含有2至9张面的集合。
其余的小部分群里面的成员数量范围从10至10000名。
业务需求主要包括两类查询：
根据group id查找该组下所有面的集合；
根据group id + face id查找某一张具体面的详细信息。
原方案：MySQL+OSS
之前，由于业务规模较小，一般采用MySQL以及OSS（对象存储）作为主要存储方式。相关表主要有group表（face_group）以及face表（glass_face）。每条记录格式如下：
group 表：
group_id (size: 12)
face 表：
glass_id (size: 12)
feature_TB_7B_3695BA051CASBA (size: 3,200 bytes)
其中feature是二进制格式后的真实玻璃特征值。在这个设计中，将玻璃ID及其对应关系存在于MySQL中，对应于group表；玻璃ID及其关联特征值则存在于OSS中，对应于face表。如果需要根据玻璃ID查找该玻璃所在群里的所有玻璃，那么需要先从MySQL读取许多行，然后根据这些线索前往OSS获取相应材料。这导致链路非常长，并且当查询涉及到具有大量子集成员的情况时，此类查询时间可能会达到10秒左右，不足以满足当前商业快速增长需求。
HBase解决方案
针对这个问题，我们可以考虑重新构建基于两个问题的一系列改进建议：
1. MySQL+OSS设计方案存在两个关键问题：首先，由于单行不能容纳原始大小，因此后续检索必须访问两个不同的库；其次，由於mysql不支持動態欄位，所以同一個組內資料被拆成多個行儲存。此外，还因为没有提供对于小文件操作优化，从而影响了整体性能表现。而这些都是典型场景适合使用hbase解决的问题，因为hbase支持动态列数百万级别，以及版本控制功能使得修改历史记录变得更加简单有效，而且引入MOB(Medium-SizedObject)技术，使得小文件操作更加高效且易用性更强。
因此，在考虑到以上几个因素后，我们决定采纳以下步骤进行实际应用测试：
a) 使用glass ID作为rowkey，并打开MOB功能创建一个名为glass_table的事务日志类型:
create 'glass_table', {NAME=>'c', IS_MOB=>true, MOB_THRESHOLD=>2048}
b) 在现有的程序逻辑内替换掉原本用于写入/读取/更新/删除操作代码，同时确保新的代码能够正常工作并维持旧有的预期行为;
c) 对比属性对象云hbase建模能力KVKV、表格、稀疏表、SQL语句执行能力前缀搜索过滤器列表performance优越率特别适合对小对象低延迟要求;
结论
总结来说，本文讨论了如何结合实际情况选择合适的大型结构化数据库解决方案，并展示了一种基于NoSQL非结构化模式(HBASE)的心形图解析算法实现方法。在文章最后，我们还提出了若干建议，以提高未来项目开发过程中的效率并减少成本。
