工业大数据存储实战基于HBase的物品跟踪与管理系统设计
随着工业4.0时代的到来，工业互联网和企业的智能化、信息化都将不断推进，传统的工业实时数据库和关系数据库已经难以完全胜任工业大数据的存储，以HBase为代表的NoSQL数据库正在蓬勃发展，其完全分布式特征、高性能、多副本和灵活的动态扩展等特点，使得HBase在工业大数据的存储上拥有强大的优势，打破了流程工业生产中的数据壁垒效应，促进了生产水平和管理水平的大幅提升。本期格物汇，就来给大家介绍HBase数据库及格创东智相关实战案例。
了解HBase
HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。它利用Hadoop HDFS作为其文件存储系统，将海量数据处理由MapReduce进行。与Google Bigtable相比，虽然两者都是基于Bigtable设计，但有显著差异：前者使用的是普通硬件配置，而后者则需要特殊硬件支持；前者的文件系统是基于HDFS，而后者的文件系统是GFS；前者的协同服务是ZooKeeper，而后者的协同服务是Chubby。此外,HBase具备线性扩展能力，可以通过增加节点来支持大量数据；其数据安全性也非常高，可以通过备份机制确保重要信息不丢失。而且，由于其高度分散，它可以提供快速访问速度。
HBase实战案例
为了更好地展示在人工智能领域中如何运用HBASE，本文选取某半导体显示公司作为案例分析如何设计一个快速查找面板特征系统。
业务场景
该公司涉及大量面板相关特征，每张面板包含3.2k二进制数据，这些面板被分成不同的组，每个组对应一系列面的组合。具体来说：
大约43%的情况下，有1张面板属于某个组。
大约47%的情况下，有2至9张面板属于某个组。
剩余情况下的每个组可能含有的 面板数范围从10至10000。
业务需求主要包括两个方面：
根据"组id"查询该组下的所有面的信息。
根据"组id"加上"面id"查询指定的一个具体面的详细信息。
原有方案：MySQL+OSS
之前由于业务量较小，一般使用MySQL以及OSS（对象存储）来管理这些资料。主要表结构如下：
CREATE TABLE group (
group_id VARCHAR(12),
PRIMARY KEY (group_id)
);
CREATE TABLE face (
glass_id VARCHAR(255),
group_id VARCHAR(12),
feature TB7B3695BA051CASBA,
PRIMARY KEY (glass_id, group_id)
);
其中feature字段保存的是3.2k大小二进制格式化后的实际面的特征。在这个设计中，对于每个不同“face”ID，我们分别创建了一行记录，即使它们属于相同的一类“group”。这样，当需要根据“group ID”找到所有相关面的资料时，我们就必须扫描很多行，并且再次从OSS获取这些对应ID上的特定功能。这导致查询过程十分复杂并且耗时长，大约需要10秒钟，比当前要求快得多，因此无法满足新的业务需求。
HBase解决方案
针对现有的MySQL+OSS设计方案存在的问题——即不能有效地整合相同类别内的大量单独记录，以及因为限制无法实现动态列—我们采用了以下策略：
使用动态列允许我们为每一项或多项功能添加新属性而无需重新组织表结构。
多版本控制允许跟踪任何变更并保持历史记录完整性。
引入MOB（Medium-Sized Object）功能支持小型文件（如图片或短视频）的低延迟读写操作，同时保证强一致性检索能力和水平扩展性。
因此，在这种情境下，我们决定重构整个解决方案，并结合应用场景中的两种关键查询需求，将“face id”作为主键Rowkey。在创建表的时候打开MOB功能，如下所示：
create 'glass', {NAME=>'c', IS_MOB=>true, MOB_THRESHOLD=>2048}
这意味着名为“glass”的表将启用MOB模式，并设置阈值为2048字节以上的小对象默认处理为MBOB对象类型。然后，我们可以直接在这一行中添加所有相关faces' features到同一条记录里，只需一次网络请求即可完成搜索任务，从而极大地提高了效率与速度。对于搜索操作，如寻找具有给定groupId的一切faces' features只需执行一次Get操作即可得到结果，不再像原来那样逐行扫描 MySQL 或 Oss 数据库，从而极大减少了响应时间并提高了用户体验质量。此外，因为我们的新增加逻辑能够通过简单修改现有代码实现，所以没有增加额外开销，也未影响已部署应用程序运行正常的情况，让开发团队更加容易适应变化并持续创新产品改进计划，为未来商业增长奠定坚实基础。
