HBase 在人工智慧場景的使用

近幾年來，人工智慧逐漸火熱起來，特別是和大資料一起結合使用。人工智慧的主要場景又包括影象能力、語音能力、自然語言處理能力和使用者畫像能力等等。這些場景我們都需要處理海量的資料，處理完的資料一般都需要儲存起來，這些資料的特點主要有如下幾點：

為了更好的介紹 hbase 在人工智慧場景下的使用，下面以某人工智慧行業的客戶案例進行分析如何利用 hbase 設計出乙個快速查詢人臉特徵的系統。

目前該公司的業務場景裡面有很多人臉相關的特徵資料，總共3400多萬張，每張人臉資料大概 3.2k。這些人臉資料又被分成很多組，每個人臉特徵屬於某個組。目前總共有近62w個人臉組，每個組的人臉張數範圍為 1 ~ 1w不等，每個組裡面會包含同乙個人不同形式的人臉資料。組和人臉的分布如下：

現在的業務需求主要有以下兩類：

group表：

group_id

size12

face表：

face_id

group_id

feature

"c5085f1ef4b3496d8b4da050cab0efd2"

1"cwi4s/ho/nm6h……"

其中 feature 大小為3.2k，是二進位制資料 base64 後存入的，這個就是真實的人臉特徵資料。

現在人臉組 id 和人臉 id 對應關係儲存在 mysql 中，對應上面的 group 表；人臉 id 和人臉相關的特徵資料儲存在 oss 裡面，對應上面的 face 表。

因為每個人臉組包含的人類特徵數相差很大（1 ~ 1w），所以基於上面的表設計，我們需要將人臉組以及每張人臉特徵id儲存在每一行，那麼屬於同乙個人臉組的資料在mysql 裡面上實際上儲存了很多行。比如某個人臉組id對應的人臉特徵數為1w，那麼需要在 mysql 裡面儲存 1w 行。

我們如果需要根據人臉組 id 查詢該組下面的所有人臉，那麼需要從 mysql 中讀取很多行的資料，從中獲取到人臉組和人臉對應的關係，然後到 oss 裡面根據人臉id獲取所有人臉相關的特徵資料，如下圖的左部分所示。

我們從上圖的查詢路徑可以看出，這樣的查詢導致鏈路非常長。從上面的設計可看出，如果查詢的組包含的人臉張數比較多的情況下，那麼我們需要從 mysql 裡面掃瞄很多行，然後再從 oss 裡面拿到這些人臉的特徵資料，整個查詢時間在10s左右，遠遠不能滿足現有業務快速發展的需求。

上面的設計方案有兩個問題：

針對上面兩個問題，我們進行了分析，得出這個是 hbase 的典型場景，原因如下：

我們可以使用這三個功能重新設計上面 mysql + oss 方案。結合上面應用場景的兩大查詢需求，我們可以將人臉組 id 作為 hbase 的 rowkey，系統的設計如上圖的右部分顯示，在建立表的時候開啟 mob 功能，如下：

create 'face',

上面我們建立了名為 face 的表，is_mob屬性說明列簇 c 將啟用 mob 特性，mob_threshold是 mob 檔案大小的閾值，單位是位元組，這裡的設定說明檔案大於 2k 的列都當做小檔案儲存。大家可能注意到上面原始方案中採用了 oss 物件儲存，那我們為什麼不直接使用 oss 儲存人臉特徵資料呢，如果有這個疑問，可以看看下面表的效能測試：

對比屬性

物件儲存

雲 hbase

建模能力

kvkv、**、稀疏表、sql、

全文索引、時空、時序、圖查詢

查詢能力

字首查詢

字首查詢、過濾器、索引效能優

優，特別對小物件有更低的延遲；在複雜

查詢場景下，比物件儲存有10倍以上的效能提公升

成本按流量，請求次數計費，

適合訪問頻率低的場景

託管式，在高併發，高吞吐場景有更低的成本

擴充套件性優

優適用物件範圍

通用<10mb

根據上面的對比，使用 hbase mob特性來儲存小於10mb的物件相比直接使用物件儲存有一些優勢。

我們現在來看看具體的表設計，如下圖：

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

string cf_default = "c";
put put = new put(groupid.getbytes());
put.addcolumn(cf_default.getbytes(),faceid1.getbytes(), feature1.getbytes());
put.addcolumn(cf_default.getbytes(),faceid2.getbytes(), feature2.getbytes());
……put.addcolumn(cf_default.getbytes(),faceidn.getbytes(), featuren.getbytes());
table.put(put);

使用者如果需要根據人臉組id獲取所有人臉的資料，可以使用下面方法：

get get = new get(groupid.getbytes());
result re=table.get(get);

這樣我們可以拿到某個人臉組id對應的所有人臉資料。如果需要根據人臉組id+人臉id查詢某個人臉的具體資料，看可以使用下面方法：

get get = new get(groupid.getbytes());
get.addcolumn(cf_default.getbytes(), faceid1.getbytes())
result re=table.get(get);

經過上面的改造，在2臺 hbase worker 節點記憶體為32gb，核數為8，每個節點掛載四塊大小為 250gb 的 ssd 磁碟，並寫入 100w 行，每行有1w列，讀取一行的時間在100ms-500ms左右。在每行有1000個face的情況下，讀取一行的時間基本在20-50ms左右，相比之前的10s提公升200~500倍。

下面是各個方案的對比效能對比情況。

對比屬性

物件儲存

mysql+物件儲存

hbase mob

讀寫強一致yn

y查詢能力弱強

強查詢響應時間高高

低運維成本低高

低水平擴充套件yy

y我們已經將人臉特徵資料儲存在阿里雲 hbase 之中，這個只是資料應用的第一步，如何將隱藏在這些資料背後的價值發揮出來？這就得借助於資料分析，在這個場景就需要採用機器學習的方法進行聚類之類的操作。我們可以借助 spark 對儲存於 hbase 之中的資料進行分析，而且 spark 本身支援機器學習的。但是如果直接採用開源的 spark 讀取 hbase 中的資料，會對 hbase 本身的讀寫有影響的。

針對這些問題，阿里雲 hbase 團隊對 spark 進行了相關優化，比如直接讀取 hfile、運算元下沉等；並且提供全託管的 spark 產品，通過sql服務thriftserver、作業服務livyserver簡化spark的使用等。目前這套 spark 的技術棧如下圖所示。

通過 spark 服務，我們可以和 hbase 進行很好的整合，將實時流和人臉特徵挖掘整合起來，整個架構圖如下：

我們可以收集各種人臉資料來源的實時資料，經過 spark streaming 進行簡單的 etl 操作；其次，我們通過 spark mlib 類庫對剛剛試試收集到的資料進行人臉特徵挖掘，最後挖掘出來的結果儲存到 hbase 之中。最後，使用者可以通過訪問 hbase 裡面已經挖掘好的人臉特徵資料進行其他的應用。

HBase 在人工智慧場景的使用

案例篇 HBase 在人工智慧場景的使用

人工智慧帶來的場景變革

人工智慧的應用製造業人工智慧8大應用場景

HBase 在人工智慧場景的使用

案例篇 HBase 在人工智慧場景的使用

人工智慧帶來的場景變革

人工智慧的應用 製造業人工智慧8大應用場景

相關推薦

人工智慧的應用製造業人工智慧8大應用場景