当前位置:主页 > 新闻热点 >正文

HBase在人工智能场景的使用

作者: 丈哥 分类: 新闻热点 发布时间: 2019-01-11 09:32

近几年来,人工智能逐渐火热起来,特别是和大数据一起结合使用。人工智能的主要场景又包括图像能力、语音能力、自然语言处理能力和用户画像能力等等。这些场景我们都需要处理海量的数据,处理完的数据一般都需要存储起来,这些数据的特点主要有如下几点:

♦ 大:数据量越大,对我们后面建模越会有好处;

♦ 稀疏:每行数据可能拥有不同的属性,比如用户画像数据,每个人拥有属性相差很大,可能用户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表:

face表:

其中 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 功能,如下:


本文链接地址:https://www.0471seo.com/news/1550.html
  • 上一篇:<<以内部视角来观察10个数据分析的成功案例

  • 下一篇:电商搜索算法技术的演进>>
  • 如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!