随着工业4.0时代的到来，工业互联网和企业的智能化、信息化都将不断推进，传统的工业实时数据库和关系数据库已经难以完全胜任工业大数据的存储，
了解HBase
HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。
与传统数据库的相比，
（1）线性扩展，随着数据量增多可以通过节点扩展进行支撑；
（2）数据存储在hdfs上，备份机制健全；
（3）通过zookeeper协调查找数据，访问速度快。
HBase实战案例
为了更好的介绍HBase在人工智能场景下的使用，下面我们
目前，该公司的业务场景里面有很多面板相关的特征数据，每张面板数据大概3.2k。这些面板数据又被分成很多组，每个面板特征属于某个组。组和面板的数据分布如下：
——43%左右的组含有1张面板数据；
——47%左右的组含有2~9张面板数据；
——其余的组面板数范围为10~10000张。
现在的业务需求主要有以下两类：
——根据组的id查找该组下面的所有面板数据；
——根据组id+面板id查找某个面板的具体数据。
原有方案：MySQL+OSS
之前业务数据量比较小的情况使用的存储主要为MySQL以及OSS(对象存储)。相关表主要有面板组表group和面板表face。表的格式如下：
因为每个面板组包含的玻璃特征数相差很大(1~10000)，所以基于上面的表设计，我们需要
我们如果需要根据面板组id查找该组下面的所有面板，那么需要从MySQL中读取很多行的数据，从中获取到组和面板对应的关系，然后到OSS里面根据面板id获取所有相关的特征数据。
这样的查询导致链路非常长。从上面的设计可看出，如果查询的组包含的面板张数比较多的情况下，那么我们需要从MySQL里面扫描很多行，然后再从OSS里面拿到这些特征数据，
HBase解决方案：
针对这两个问题，格创东智的大数据团队进行了分析，认为这是
——HBase拥有动态列的特性，支持万亿行，百万列；
——HBase支持多版本，所有的修改都会记录在HBase中；
——HBase 2.0引入了MOB(Medium-Sized Object)特性，支持小文件存储。
HBase的MOB特性针对文件大小在1k~10MB范围的，比如图片，短视频，文档等，具有低延迟，读写强一致，检索能力强，水平易扩展等关键能力。
上面我们创建了名为glass的表，IS_MOB属性说明列簇c将启用MOB特性，MOB_THRESHOLD是MOB文件大小的阈值，单位是字节，这里的设置说明文件大于2k的列都当做小文件存储。大家可能注意到上面原始方案中采用了OSS对象存储，那我们为什么不直接使用OSS存储面板特征数据呢，如果有这个疑问，可以看看下面表的性能测试：
String CF_DEFAULT="c";根据上面的对比，使用HBase MOB特性来存储小于10MB的对象相比直接使用对象存储有一些优势。
我们现在来看看具体的表设计，使用面板id作为列名。我们只使用了HBase的一张表就替换了之前方面的三张表！虽然我们启用了MOB，但是具体插入的方法和正常使用一样，代码片段如下：
Put put=new Put(groupId.getBytes());
用户如果需要根据面板组id获取所有面板数据，可以使用下面方法：
这样我们可以拿到某个组id对应的所有面板数据。如果需要根据组id+面板id查找某个面板的具体数据，看可以使用下面方法：
经过上面的改造，在2台HBaseWorker节点内存为32GB，核数为8，每个节点挂载四块大小为250GB的SSD磁盘，并写入100W行，每行有1W列，读取一行的时间在100ms-500毫秒左右。在每行有1000个face的情况下，读取一行的时间基本在20-50毫秒左右，相比之前的10秒提升200~500倍。
从下面这张对比表，我们可以清楚的看到
现在，我们已经将面板特征数据存储在Cloudera HBase之中，这个只是数据应用的第一步，如何将隐藏在这些数据背后的价值发挥出来？这就得
