加入收藏 | 设为首页 | 会员中心 | 我要投稿 湖南网 (https://www.hunanwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 教程 > 正文

HBase在人工智能场景的行使

发布时间:2018-11-23 06:01:22 所属栏目:教程 来源:明惠
导读:近几年来,人工智能逐渐火热起来,出格是和大数据一路团结行使。人工智能的首要场景又包罗图像手段、语音手段、天然说话处理赏罚手段和用户画像手段等等。这些场景我们都必要处理赏罚海量的数据,处理赏罚完的数据一样平常都必要存储起来,这些数据的特点首要有如下几点:
副问题[/!--empirenews.page--]

近几年来,人工智能逐渐火热起来,出格是和大数据一路团结行使。人工智能的首要场景又包罗图像手段、语音手段、天然说话处理赏罚手段和用户画像手段等等。这些场景我们都必要处理赏罚海量的数据,处理赏罚完的数据一样平常都必要存储起来,这些数据的特点首要有如下几点:

大:数据量越大,对我们后头建模越会有甜头;

稀少:每行数据也许拥有差异的属性,好比用户画像数据,每小我私人拥有属性相差很大,也许用户A拥有这个属性,可是用户B没有这个属性;那么我们但愿存储的体系可以或许处理赏罚这种环境,没有的属性在底层不占用空间,这样可以节省大量的空间行使;

列动态变革:每行数据拥有的列数是纷歧样的。

为了更好的先容 HBase 在人工智能场景下的行使,下面以或人工智能行业的客户案例举办说明怎样操作 HBase 计划出一个快速查找人脸特性的体系。

HBase在人工智能场景的行使

今朝该公司的营业场景内里有许多人脸相干的特性数据,总共3400多万张,每张人脸数据或许 3.2k。这些人脸数据又被分成许多组,每小我私人脸特性属于某个组。今朝总共有近62W小我私人脸组,每个组的人脸张数范畴为 1 ~ 1W不等,每个组内里会包括统一小我私人差异情势的人脸数据。组和人脸的漫衍如下:

  • 43%阁下的组含有1张人脸数据;
  • 47%阁下的组含有 2 ~ 9张人脸数据;
  • 别的的组人脸数范畴为 10 ~ 10000。

此刻的营业需求首要有以下两类:

  • 按照人脸组 id 查找该组下面的全部人脸;
  • 按照人脸组 id +人脸 id 查找某小我私人脸的详细数据。

MySQL + OSS 方案

之前营业数据量较量小的环境行使的存储首要为 MySQL 以及 OSS(工具存储)。相干表首要有人脸组表group和人脸表face。表的名目如下:

group表:

HBase在人工智能场景的行使

face表:

HBase在人工智能场景的行使

个中 feature 巨细为3.2k,是二进制数据 base64 后存入的,这个就是真实的人脸特性数据。

此刻人脸组 id 和人脸 id 对应相关存储在 MySQL 中,对应上面的 group 表;人脸 id 和人脸相干的特性数据存储在 OSS 内里,对应上面的 face 表。

由于每小我私人脸组包括的人类特性数相差很大(1 ~ 1W),以是基于上面的表计划,我们必要将人脸组以及每张人脸特性id存储在每一行,那么属于统一小我私人脸组的数据在MySQL 内里上现实上存储了许多行。好比某小我私人脸组id对应的人脸特性数为1W,那么必要在 MySQL 内里存储 1W 行。

我们假如必要按照人脸组 id 查找该组下面的全部人脸,那么必要从 MySQL 中读取许多行的数据,从中获取到人脸组和人脸对应的相关,然后到 OSS 内里按照人脸id获取全部人脸相干的特性数据,如下图的左部门所示。

HBase在人工智能场景的行使

我们从上图的查询路径可以看出,这样的查询导致链路很是长。从上面的计划可看出,假如查询的组包括的人脸张数较量多的环境下,那么我们必要从 MySQL 内里扫描许多行,然后再从 OSS 内里拿到这些人脸的特性数据,整个查询时刻在10s阁下,远远不能满意现有营业快速成长的需求。

HBase 方案

上面的计划方案有两个题目:

  • 本来属于统一条数据的内容因为数据自己巨细的缘故起因无法存储到一行内里,导致后续查下必要会见两个存储体系;
  • 因为MySQL不支持动态列的特征,以是属于统一小我私人脸组的数据被拆成多行存储。

针对上面两个题目,我们举办了说明,得出这个是 HBase 的典范场景,缘故起因如下:

  • HBase 拥有动态列的特征,支持万亿行,百万列;
  • HBase 支持多版本,全部的修改城市记录在 HBase 中;
  • HBase 2.0 引入了 MOB(Medium-Sized Object) 特征,支持小文件存储。HBase 的 MOB 特征针对文件巨细在 1k~10MB 范畴的,好比图片,短视频,文档等,具有低耽误,读写强同等,检索手段强,程度易扩展等要害手段。

我们可以行使这三个成果从头计划上面 MySQL + OSS 方案。团结上面应用场景的两大查询需求,我们可以将人脸组 id 作为 HBase 的 Rowkey,体系的计划如上图的右部门表现,在建设表的时辰打开 MOB 成果,如下:

  1. create 'face', {NAME => 'c', IS_MOB => true, MOB_THRESHOLD => 2048} 

上面我们建设了名为 face 的表,IS_MOB 属性声名列簇 c 将启用 MOB 特征,MOB_THRESHOLD 是 MOB 文件巨细的阈值,单元是字节,这里的配置声名文件大于 2k 的列都当做小文件存储。各人也许留意到上面原始方案中回收了 OSS 工具存储,那我们为什么不直接行使 OSS 存储人脸特性数据呢,假若有这个疑问,可以看看下面表的机能测试:

HBase在人工智能场景的行使

按照上面的比拟,行使 HBase MOB特征来存储小于10MB的工具对比直接行使工具存储有一些上风。

我们此刻来看看详细的表计划,如下图:

HBase在人工智能场景的行使

(编辑:湖南网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读