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

OSS(Object Storage
Service)俗称对象存储,主要提供图片、文档、音频、视频等二进制文件的海量存储功能。目前除了公有云提供对象存储服务外,一般私有云比较关心一些开源的分布式对象存储解决方案,本文列举了一些常见的技术方案供参考。

TableStore是阿里云自研的在线数据平台,提供高可靠的存储,实时和丰富的查询功能,适用于结构化、半结构化的海量数据存储以及各种查询、分析。

  • 大:数据量越大,对我们后面建模越会有好处;
  • 稀疏:每行数据可能拥有不同的属性,比如用户画像数据,每个人拥有属性相差很大,可能用户A拥有这个属性,但是用户B没有这个属性;那么我们希望存储的系统能够处理这种情况,没有的属性在底层不占用空间,这样可以节约大量的空间使用;
  • 列动态变化:每行数据拥有的列数是不一样的。

概念普识

在众多大数据场景中,爬虫类型的数据非常适合存储在TableStore。主要是因为爬虫类型数据的一些特征和TableStore和匹配:

为了更好的介绍 HBase
在人工智能场景下的使用,下面以某人工智能行业的客户案例进行分析如何利用
HBase 设计出一个快速查找人脸特征的系统。

块存储

爬虫数据一般都是抓取的互联网上的某个行业或领域的数据,数据规模和这个行业的数据规模有关,比如资讯类,每时每刻都在产生大量新闻报道,这个数据规模可能在10
TB到100
TB级别,如果考虑到历史存量数据,那么规模可能会更大。这么大量的数据存储已经不适合用单机的关系型数据库了,也不适合分库分表了,而需要一款分布式NoSQL数据库,这样可以将数据按一定的路由规则分布到不同机器上,实现自动的水平扩展,非常适合存储海量数据,尤其是爬虫类。

目前该公司的业务场景里面有很多人脸相关的特征数据,总共3400多万张,每张人脸数据大概
3.2k。这些人脸数据又被分成很多组,每个人脸特征属于某个组。目前总共有近62W个人脸组,每个组的人脸张数范围为
1 ~
1W不等,每个组里面会包含同一个人不同形式的人脸数据。组和人脸的分布如下:

通常SAN(Storage Area
Network)结构的产品属于块存储,比如我们常见的硬盘、磁盘阵列等物理盘。

爬虫的数据一般来源于多个数据源,比如资讯数据可以来自人民网、新浪或者腾讯,每个数据源的数据特征不可能完全一样,每家有每家的特殊性,这样就会出现每一行数据的属性列有差异,虽然可以归一化处理后,可以将通用的属性列统一,但是不同数据源还是会存在一定差异性。如果为每个数据源建立一张表,那么工作量就会非常大,也不适合。这时候,就需要用到宽行和稀疏列功能,既能保证列数无上限,也能保证不同行不同列,还可以不额外增加存储成本和运维成本。

  • 43%左右的组含有1张人脸数据;
  • 47%左右的组含有 2 ~ 9张人脸数据;
  • 其余的组人脸数范围为 10 ~ 10000。

文件存储

爬虫数据的存储后,一般有两个出口,一个是数据处理程序,数据处理程序会读取最新的爬虫数据,然后按照自定义的处理逻辑做数据加工,处理完后会新数据写入原表或新表。

现在的业务需求主要有以下两类:

一般NAS(Network Attached
Storage)产品都是文件级存储,如Ceph的CephFS,另外
GFS、HDFS等也属于文件存储 。

数据处理完之后,数据可以提供给下游企业客户或终端用户使用了,场景的查询需求有下列几种:

  • 根据人脸组 id 查找该组下面的所有人脸;
  • 根据人脸组 id +人脸 id 查找某个人脸的具体数据。

对象存储

  • 多种属性列组合查询。比如全网简历信息里面,通过年龄、学历、专长查询,且每个人查询的条件可能都完全不一样,需要多种属性列的自由组合查询。
  • 分词查询。不管是咨询类,还是简历类,都有大量的文本描述,这部分内容都需要支持分词后再查询。
  • 排序能力。比如资讯类数据中,查询某个新闻后,需要按时间逆序返回,越新的数据价值越大。
  • 随机读能力。如果是用来做全局数据分析或处理,那么随机读是一种必须要有的能力。
  • 轻量级统计分析。比如资讯类,想查看某个热点新闻的传播时间段和趋势,就需要统计每个时间段的此类新闻出现次数。这些查询能力,在传统的关系型数据库或者开源NoSQL中都无法提供。

之前业务数据量比较小的情况使用的存储主要为 MySQL 以及
OSS。相关表主要有人脸组表group和人脸表face。表的格式如下:

同时兼顾着SAN高速直接访问磁盘特点及NAS的分布式共享特点的一类存储,一般是通过RESTful接口访问。

爬虫数据存储的方案已经演进了将近二十年了,千奇百怪的各种方案都有,主要的差异来源于两点:

group表:

开源解决方案介绍

  • 当前能获取到的存储系统能力。
  • 自身对系统可靠性、可用性的要求高低。我们下面以当前业界流行的开源系统为材料,打造一个爬虫数据存储的系统。

图片 1

Swift

当前业内的开源存储系统有两大类,一类是开源的关系型数据库,比如MySQL等,一类是NoSQL,比如HBase等。这两类数据存储系统都不能支持分词查询,那么还需要一个全文检索的系统,当前可选的有solr和Elasticsearch。

face表:

Swift 是 OpenStack
社区核心子项目,是一个弹性可伸缩、高可用的分布式对象存储系统,使用Python语言实现,采用
Apache 2.0 许可协议。

基于上述的素材,我们就可以搭建一个存储爬虫的系统了:

图片 2

Swift 提供一个基于RESTful HTTP接口的 Object Storage
API,用于创建,修改和获取对象和元数据。用户可以使用 Swift
高效、安全且廉价地存储大量数据。Swift 整体架构:

  • 首先,选择存储系统,MySQL和HBase都可以,如果使用MySQL,则需要分库分表,两者架构图差不多,这里我们就选择HBase。
  • 再次,选择查询系统,可选的solr和Elasticsearch,虽然是同一类型系统,但是Elasticsearch的目前更流行,那我们也选择Elasticsearch。这样,架构图大致如下:

其中 feature 大小为3.2k,是二进制数据 base64
后存入的,这个就是真实的人脸特征数据。

图片 3

图片 4

现在人脸组 id 和人脸 id 对应关系存储在 MySQL 中,对应上面的 group
表;人脸 id 和人脸相关的特征数据存储在 OSS 里面,对应上面的 face 表。

总的来说,企业如果想要建立可扩展的分布式对象存储集群,可以考虑 Swift。

大概解释下:

因为每个人脸组包含的人类特征数相差很大,所以基于上面的表设计,我们需要将人脸组以及每张人脸特征id存储在每一行,那么属于同一个人脸组的数据在MySQL
里面上实际上存储了很多行。比如某个人脸组id对应的人脸特征数为1W,那么需要在
MySQL 里面存储 1W 行。

Ceph

  • 流程:爬虫系统将抓取的数据写入HBase离线集群,然后数据处理系统周期性或流式的处理新到的数据,将处理后的结果写入HBase在线集群。HBase在线集群存储所有属性列的值,然后将需要查询的列通过co-processor发送给消息队列,最后再将消息队列中的数据被Elasticsearch消费,生成索引。最后,用户通过索引查询到PK,然后通过proxy到HBase在线集群读取这一行完整数据,最后返回给用户。
  • 数据存储集群有两个,一个是在线集群,一个是离线集群,原因是为了避免减少离线集群对在线查询的影响,因为离线系统重吞吐,而在线系统重延迟,所以,这里会分成两个集群,目的是挺高系统可用性。
  • 消息队列的目的是削峰填谷,减少对下游系统:Elasticsearch的压力,同时当Elasticsearch写入慢或者出故障后,不至于影响上游系统,目的也是为了提高系统可用性,避免单点故障导致整个系统雪崩。
  • Proxy的目的是减轻客户端工作量,提高易用性的工具,原因是爬虫数据是系数列,这些列不可能全部都在Elasticsearch中创建索引,只有部分需要查询、分析的属性列才会在Elasticsearch中建立索引,但是查询的时候也需要未建立索引的字段,这样就需要一个系统做反查和合并,就是先查Elasticsearch获取到PK,然后通过PK到HBase在线集群查询这一行完整数据。
  • 这个系统中,需要运维6个不同开源系统,运维压力比较大。

我们如果需要根据人脸组 id 查找该组下面的所有人脸,那么需要从 MySQL
中读取很多行的数据,从中获取到人脸组和人脸对应的关系,然后到 OSS
里面根据人脸id获取所有人脸相关的特征数据,如下图的左部分所示。

Ceph是一种高性能、高可用、可扩展的分布式存储系统,统一的对外提供对象存
储、块存储以及文件存储功能,底层使用C/C++语言。

最开始,我们说TableStore很适合存储爬虫数据,在介绍了开源系统的解决方案后,我们再来看一下TableStore的解决方案,以及相对于开源系统,可以为客户带来的收益。

发表评论

电子邮件地址不会被公开。 必填项已用*标注