基于HBase的工业大数据存储实战探索现场总线技术在物品追踪中的应用
随着工业4.0时代的到来，工业互联网和企业的智能化、信息化都将不断推进，传统的工业实时数据库和关系数据库已经难以完全胜任工业大数据的存储，以HBase为代表的NoSQL数据库正在蓬勃发展，其完全分布式特征、高性能、多副本和灵活的动态扩展等特点，使得HBase在工业大数据的存储上拥有强大的优势，打破了流程工业生产中的数据壁垒效应，促进了工业生产水平和生产管理水平的大幅提升。本期格物汇，就来给大家介绍HBase数据库及格创东智相关实战案例。
了解HBase
HBase是一个高可靠性、高性能、面向列、可伸缩的大规模分布式存储系统。利用HBase技术，可在廉价PC服务器上搭建起结构化存储集群。其目标是仅需使用普通硬件配置就能够处理由成千上万行和列所组成的大型数据。
与Google Bigtable不同,HBASE不仅仅是Bigtable的一个开源实现，它还有很多不同的设计理念，比如：
Google Bigtable使用GFS作为其文件存储系统，而HBASE则利用Apache Hadoop HDFS作为其文件存储系统。
Google运行MAPREDUCE来处理Bigtable中的海量数据，而HBASE同样利用Apache Hadoop MapReduce来处理自己的海量数据。
Google Bigtable采用Chubby作为协同服务，而HBASE则依赖于Zookeeper作为协同服务。
与传统数据库相比,HBASE具备以下多重优势：
线性扩展，可以通过增加节点进行支持。
数据可以直接在hdfs上备份，保证了备份机制健全。
通过zookeeper协调访问速度快。
基于这些优点，我们将探索如何运用场景总线技术，以及它如何应用于物品追踪中，并展示一个实际案例：某半导体显示企业如何利用场景总线技术加速查找面板特征，这一过程涉及大量面板特征以及对这些特征进行分类分组的问题。
案例分析
该公司业务场景中包含大量面板相关特征，每张面板有3.2k字节大小，这些面板被分组，其中43%左右属于单一面的群组（含1张面板），47%左右属于多个面的群组（含2~9张），剩余为10~10000张面的复杂群组。在现有的业务需求中，有两个主要查询类别：
根据group_id查找所有关联面的panel_data；
根据group_id + panel_id查找具体panel_data。
原有方案：MySQL+OSS
之前由于业务量较小，对于主表结构采取了MySQL + OSS(对象存储)方案。其中，group表用于保存group_id信息，而face表用于保存玻璃id与glass_id对应关系。此外，将每个玻璃id与其关联的一系列feature_base64编码后的二进制数据一起保存至OSS之中。然而，由于每个玻璃类型下可能存在数量级从几十到数千甚至更高的情况，这种方法导致对于相同group_id下的glass_type查询效率极低，因为需要扫描大量行并且跨越两种不同的库（MySQL & OSS）完成这个操作。这导致整个查询时间达到10秒以上，从而无法满足当前快速增长的事业部需求。
解决方案：转向使用Hbase
为了解决这一问题，我们可以考虑将这两个表合并为一个具有动态列能力且适合小文件存放（MOB）的新表。这允许我们根据glass_type创建column family，并使得每个rowkey对应一个唯一的glass_type，同时记录所有相关features，如下所示：
CREATE TABLE glass (
group_key,
CF_DEFAULT: {
COLUMN => 'features',
MOB => true,
MOB_THRESHOLD => 2048 // 表示当cell value 大于或等于2048字节时，该column会被视作small object (MOB)
}
);
这样做可以极大地减少读写请求次数，因为我们不再需要遍历整个 MySQL 中 group 表获取 glass id 后，再去 OSS 中搜索 features。如果用户想要根据 group_key 获取所有 glass 的 features，只需执行一次 Get 请求即可，不必担心因过滤条件限制而影响性能。此外，此设计还提供了一致性检查，以确保没有遗漏任何 row 或 cell 的情况发生，从而提高了整体系统稳定性。
