近幾年來(lái)，人工智能逐漸火熱起來(lái)，特別是和大數(shù)據(jù)一起結(jié)合使用。人工智能的主要場(chǎng)景又包括圖像能力、語(yǔ)音能力、自然語(yǔ)言處理能力和用戶畫(huà)像能力等等。這些場(chǎng)景我們都需要處理海量的數(shù)據(jù)，處理完的數(shù)據(jù)一般都需要存儲(chǔ)起來(lái)，這些數(shù)據(jù)的特點(diǎn)主要有如下幾點(diǎn)：

♦ 大：數(shù)據(jù)量越大，對(duì)我們后面建模越會(huì)有好處;

♦ 稀疏：每行數(shù)據(jù)可能擁有不同的屬性，比如用戶畫(huà)像數(shù)據(jù)，每個(gè)人擁有屬性相差很大，可能用戶A擁有這個(gè)屬性，但是用戶B沒(méi)有這個(gè)屬性;那么我們希望存儲(chǔ)的系統(tǒng)能夠處理這種情況，沒(méi)有的屬性在底層不占用空間，這樣可以節(jié)約大量的空間使用;

♦ 列動(dòng)態(tài)變化：每行數(shù)據(jù)擁有的列數(shù)是不一樣的。

為了更好的介紹 HBase 在人工智能場(chǎng)景下的使用，下面以某人工智能行業(yè)的客戶案例進(jìn)行分析如何利用 HBase 設(shè)計(jì)出一個(gè)快速查找人臉特征的系統(tǒng)。

 

 

目前該公司的業(yè)務(wù)場(chǎng)景里面有很多人臉相關(guān)的特征數(shù)據(jù)，總共3400多萬(wàn)張，每張人臉數(shù)據(jù)大概 3.2k。這些人臉數(shù)據(jù)又被分成很多組，每個(gè)人臉特征屬于某個(gè)組。目前總共有近62W個(gè)人臉組，每個(gè)組的人臉張數(shù)范圍為 1 ~ 1W不等，每個(gè)組里面會(huì)包含同一個(gè)人不同形式的人臉數(shù)據(jù)。組和人臉的分布如下：

♦ 43%左右的組含有1張人臉數(shù)據(jù);
♦ 47%左右的組含有 2 ~ 9張人臉數(shù)據(jù);
♦ 其余的組人臉數(shù)范圍為 10 ~ 10000。

現(xiàn)在的業(yè)務(wù)需求主要有以下兩類(lèi)：

♦ 根據(jù)人臉組 id 查找該組下面的所有人臉;
♦ 根據(jù)人臉組 id +人臉 id 查找某個(gè)人臉的具體數(shù)據(jù)。

MySQL + OSS 方案

之前業(yè)務(wù)數(shù)據(jù)量比較小的情況使用的存儲(chǔ)主要為 MySQL 以及 OSS(對(duì)象存儲(chǔ))。相關(guān)表主要有人臉組表group和人臉表face。表的格式如下：

group表：

 

 

face表：

 

 

其中 feature 大小為3.2k，是二進(jìn)制數(shù)據(jù) base64 后存入的，這個(gè)就是真實(shí)的人臉特征數(shù)據(jù)。

現(xiàn)在人臉組 id 和人臉 id 對(duì)應(yīng)關(guān)系存儲(chǔ)在 MySQL 中，對(duì)應(yīng)上面的 group 表;人臉 id 和人臉相關(guān)的特征數(shù)據(jù)存儲(chǔ)在 OSS 里面，對(duì)應(yīng)上面的 face 表。

因?yàn)槊總�(gè)人臉組包含的人類(lèi)特征數(shù)相差很大(1 ~ 1W)，所以基于上面的表設(shè)計(jì)，我們需要將人臉組以及每張人臉特征id存儲(chǔ)在每一行，那么屬于同一個(gè)人臉組的數(shù)據(jù)在MySQL 里面上實(shí)際上存儲(chǔ)了很多行。比如某個(gè)人臉組id對(duì)應(yīng)的人臉特征數(shù)為1W，那么需要在 MySQL 里面存儲(chǔ) 1W 行。

我們?nèi)绻�需要根�?jù)人臉組 id 查找該組下面的所有人臉，那么需要從 MySQL 中讀取很多行的數(shù)據(jù)，從中獲取到人臉組和人臉對(duì)應(yīng)的關(guān)系，然后到 OSS 里面根據(jù)人臉id獲取所有人臉相關(guān)的特征數(shù)據(jù)，如下圖的左部分所示。

 

 

我們從上圖的查詢路徑可以看出，這樣的查詢導(dǎo)致鏈路非常長(zhǎng)。從上面的設(shè)計(jì)可看出，如果查詢的組包含的人臉張數(shù)比較多的情況下，那么我們需要從 MySQL 里面掃描很多行，然后再?gòu)?OSS 里面拿到這些人臉的特征數(shù)據(jù)，整個(gè)查詢時(shí)間在10s左右，遠(yuǎn)遠(yuǎn)不能滿足現(xiàn)有業(yè)務(wù)快速發(fā)展的需求。

HBase 方案

上面的設(shè)計(jì)方案有兩個(gè)問(wèn)題：

♦ 原本屬于同一條數(shù)據(jù)的內(nèi)容由于數(shù)據(jù)本身大小的原因無(wú)法存儲(chǔ)到一行里面，導(dǎo)致后續(xù)查下需要訪問(wèn)兩個(gè)存儲(chǔ)系統(tǒng);

♦ 由于MySQL不支持動(dòng)態(tài)列的特性，所以屬于同一個(gè)人臉組的數(shù)據(jù)被拆成多行存儲(chǔ)。

針對(duì)上面兩個(gè)問(wèn)題，我們進(jìn)行了分析，得出這個(gè)是 HBase 的典型場(chǎng)景，原因如下：

♦ HBase 擁有動(dòng)態(tài)列的特性，支持萬(wàn)億行，百萬(wàn)列;

♦ HBase 支持多版本，所有的修改都會(huì)記錄在 HBase 中;

♦ HBase 2.0 引入了 MOB(Medium-Sized Object) 特性，支持小文件存儲(chǔ)。HBase 的 MOB 特性針對(duì)文件大小在 1k~10MB 范圍的，比如圖片，短視頻，文檔等，具有低延遲，讀寫(xiě)強(qiáng)一致，檢索能力強(qiáng)，水平易擴(kuò)展等關(guān)鍵能力。

我們可以使用這三個(gè)功能重新設(shè)計(jì)上面 MySQL + OSS 方案。結(jié)合上面應(yīng)用場(chǎng)景的兩大查詢需求，我們可以將人臉組 id 作為 HBase 的 Rowkey，系統(tǒng)的設(shè)計(jì)如上圖的右部分顯示，在創(chuàng)建表的時(shí)候打開(kāi) MOB 功能，如下：

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

上面我們創(chuàng)建了名為 face 的表，IS_MOB 屬性說(shuō)明列簇 c 將啟用 MOB 特性，MOB_THRESHOLD 是 MOB 文件大小的閾值，單位是字節(jié)，這里的設(shè)置說(shuō)明文件大于 2k 的列都當(dāng)做小文件存儲(chǔ)。大家可能注意到上面原始方案中采用了 OSS 對(duì)象存儲(chǔ)，那我們?yōu)槭裁床恢苯邮褂?OSS 存儲(chǔ)人臉特征數(shù)據(jù)呢，如果有這個(gè)疑問(wèn)，可以看看下面表的性能測(cè)試：

 

 

根據(jù)上面的對(duì)比，使用 HBase MOB特性來(lái)存儲(chǔ)小于10MB的對(duì)象相比直接使用對(duì)象存儲(chǔ)有一些優(yōu)勢(shì)。

我們現(xiàn)在來(lái)看看具體的表設(shè)計(jì)，如下圖：

 

 

上面 HBase 表的列簇名為c，我們使用人臉id作為列名。我們只使用了 HBase 的一張表就替換了之前方面的三張表!雖然我們啟用了 MOB，但是具體插入的方法和正常使用一樣，代碼片段如下：

1. String CF_DEFAULT = "c";
2. Put put = new Put(groupId.getBytes());
3. put.addColumn(CF_DEFAULT.getBytes(),faceId1.getBytes(), feature1.getBytes());
4. put.addColumn(CF_DEFAULT.getBytes(),faceId2.getBytes(), feature2.getBytes());
5. ……
6. put.addColumn(CF_DEFAULT.getBytes(),faceIdn.getBytes(), featuren.getBytes());
7. table.put(put);

用戶如果需要根據(jù)人臉組id獲取所有人臉的數(shù)據(jù)，可以使用下面方法：

1. Get get = new Get(groupId.getBytes());
2. Result re=table.get(get);

這樣我們可以拿到某個(gè)人臉組id對(duì)應(yīng)的所有人臉數(shù)據(jù)。如果需要根據(jù)人臉組id+人臉id查找某個(gè)人臉的具體數(shù)據(jù)，看可以使用下面方法：

1. Get get = new Get(groupId.getBytes());
2. get.addColumn(CF_DEFAULT.getBytes(), faceId1.getBytes())
3. Result re=table.get(get);

經(jīng)過(guò)上面的改造，在2臺(tái) HBase worker 節(jié)點(diǎn)內(nèi)存為32GB，核數(shù)為8，每個(gè)節(jié)點(diǎn)掛載四塊大小為 250GB 的 SSD 磁盤(pán)，并寫(xiě)入 100W 行，每行有1W列，讀取一行的時(shí)間在100ms-500ms左右。在每行有1000個(gè)face的情況下，讀取一行的時(shí)間基本在20-50ms左右，相比之前的10s提升200~500倍。

下面是各個(gè)方案的對(duì)比性能對(duì)比情況。

 

 

使用 Spark 加速數(shù)據(jù)分析

我們已經(jīng)將人臉特征數(shù)據(jù)存儲(chǔ)在阿里云 HBase 之中，這個(gè)只是數(shù)據(jù)應(yīng)用的第一步，如何將隱藏在這些數(shù)據(jù)背后的價(jià)值發(fā)揮出來(lái)?這就得借助于數(shù)據(jù)分析，在這個(gè)場(chǎng)景就需要采用機(jī)器學(xué)習(xí)的方法進(jìn)行聚類(lèi)之類(lèi)的操作。我們可以借助 Spark 對(duì)存儲(chǔ)于 HBase 之中的數(shù)據(jù)進(jìn)行分析，而且 Spark 本身支持機(jī)器學(xué)習(xí)的。但是如果直接采用開(kāi)源的 Spark 讀取 HBase 中的數(shù)據(jù)，會(huì)對(duì) HBase 本身的讀寫(xiě)有影響的。

針對(duì)這些問(wèn)題，阿里云 HBase 團(tuán)隊(duì)對(duì) Spark 進(jìn)行了相關(guān)優(yōu)化，比如直接讀取 HFile、算子下沉等;并且提供全托管的 Spark 產(chǎn)品，通過(guò)SQL服務(wù)ThriftServer、作業(yè)服務(wù)LivyServer簡(jiǎn)化Spark的使用等。目前這套 Spark 的技術(shù)棧如下圖所示。

 

 

通過(guò) Spark 服務(wù)，我們可以和 HBase 進(jìn)行很好的整合，將實(shí)時(shí)流和人臉特征挖掘整合起來(lái)，整個(gè)架構(gòu)圖如下：

 

 

我們可以收集各種人臉數(shù)據(jù)源的實(shí)時(shí)數(shù)據(jù)，經(jīng)過(guò) Spark Streaming 進(jìn)行簡(jiǎn)單的 ETL 操作;其次，我們通過(guò) Spark MLib 類(lèi)庫(kù)對(duì)剛剛試試收集到的數(shù)據(jù)進(jìn)行人臉特征挖掘，最后挖掘出來(lái)的結(jié)果存儲(chǔ)到 HBase 之中。最后，用戶可以通過(guò)訪問(wèn) HBase 里面已經(jīng)挖掘好的人臉特征數(shù)據(jù)進(jìn)行其他的應(yīng)用。

標(biāo)簽： Mysql ssd 大數(shù)據(jù) 代碼 數(shù)據(jù)分析

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。