工业大数据存储实战基于HBase的物品追踪系统建设
随着工业4.0时代的到来，工业互联网和企业的智能化、信息化都将不断推进，传统的工业实时数据库和关系数据库已经难以完全胜任工业大数据的存储，以HBase为代表的NoSQL数据库正在蓬勃发展，其完全分布式特征、高性能、多副本和灵活的动态扩展等特点，使得HBase在工业大数据的存储上拥有强大的优势，打破了流程工业生产中的数据壁垒效应，促进了生产水平和管理水平的大幅提升。本期格物汇，就来给大家介绍HBase数据库及格创东智相关实战案例。
了解HBase
HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。它利用Hadoop HDFS作为其文件存储系统，将海量数据处理由MapReduce进行。与Google Bigtable相比，它使用Zookeeper作为协同服务，而不是Chubby。在传统数据库中，HBASE具备线性扩展能力，即随着数据量增多可以通过节点扩展进行支撑；其次，它把数据存储在hdfs上，有健全备份机制；最后，它通过zookeeper协调访问速度快。
HBase实战案例
为了更好地展示如何利用HBase设计一个快速查找面板特征系统，我们以某半导体显示企业为案例。该公司业务场景涉及大量面板相关特征，每张面板约3.2k字节，这些面板被分组，其中43%左右有1张面板，每个组含有的 面板数量从2到9不等，还有一部分组包含10至10000张。这类业务需求主要包括根据组id查找所有面的特征，以及根据组id加上单独一张面的id查找具体的一张面的信息。
原有方案：MySQL+OSS
之前由于业务规模较小，上述表主要是基于MySQL以及OSS（对象存储）实现。其中group表用于保存每个群集ID，并且glass表用于记录玻璃ID与对应群集ID之间以及玻璃ID与其关联特征之间关系。此外，由于每个群集中包含玻璃数目差异巨大，所以需要将玻璃ID及其对应行数均存在MySQL中，对应的是group表；而玻璃ID及其相关特征则分别存在OSS中，对应的是face表。
然而，由于这种设计方式会导致对于相同群集内所有玻璃查询时，在MySQL读取大量行并获取该群集下的所有玻璃，然后再从OSS中获取这些具体玻璃下所需特别类型的人工智能功能所需参数，这种链路长度很长，从而导致整个查询时间达到十秒之久，不足以满足现有快速增长需求。
HBase解决方案
针对这个问题，我们采用了以下措施：
使用动态列支持万亿行百万列。
支持多版本记录所有修改历史。
引入MOB(Medium-Sized Object)功能适合小文件，如图片或短视频，可以提供低延迟读写操作，同时保持强一致性检索能力强且易于水平扩展。
结合应用场景两大查询需求，将每个Group ID设置为RowKey，并在创建Glass 表时打开MOB功能，如下所示：
create 'glass', {NAME=>'c', IS_MOB=>true, MOB_THRESHOLD=>2048}
这样我们就能够避免像之前那样因为原始方案的问题而出现的问题，比如同一条原始数据无法一次性完整保存，因为它们太过庞大，而现在我们可以轻松地根据Group ID找到所有Face 数据，而且这些都是在单一位于后端服务器上的地方完成处理，无需跨越不同的网络请求路径去不同的地方寻求必要资源，从而极大的提高了效率并简化了程序结构。这也意味着我们的用户不必担心他们需要做出的请求必须经过许多复杂步骤才能得到答案，他们只需要简单地访问一个地方即可获得想要得到的一切信息，从而减少用户等待时间，让他们更加满意，最终使我们的产品变得更加吸引人。在未来，如果新的挑战或者新技术出现，我们就能迅速调整策略，以确保我们的产品始终处于竞争力前沿。
