近幾年來，人工智慧逐漸火熱起來，特別是和大資料一起結合使用。人工智慧的 主要場景又包括影象能力、語音能力、自然語言處理能力和使用者畫像能力等等。 這些場景我們都需要處理海量的資料，處理完的資料一般都需要儲存起來，這些資料的特點主要有如下幾點:
大:資料量越大，對我們後面建模越會有好處;
稀疏:每行資料可能擁有不同的屬性，比如使用者畫像資料，每個人擁有屬性相差很大，可能使用者 a 擁有這個屬性，但是使用者 b 沒有這個屬性;那麼我們希望儲存的系統能夠處理這種情況，沒有的屬性在底層不占用空間，這樣可以節約大量的空間使用;
列動態變化:每行資料擁有的列數是不一樣的。
為了更好的介紹 hbase 在人工智慧場景下的使用，下面以某人工智慧行業的客戶案例進行分析如何利用 hbase 設計出乙個快速查詢人臉特徵的系統。
目前該公司的業務場景裡面有很多人臉相關的特徵資料，總共 3400 多萬張，每 張人臉資料大概 3.2k。這些人臉資料又被分成很多組，每個人臉特徵屬於某個 組。目前總共有近 62w 個人臉組，每個組的人臉張數範圍為 1 ~ 1w 不等，每 個組裡面會包含同乙個人不同形式的人臉資料。組和人臉的分布如下:
43%左右的組含有 1 張人臉資料;
47%左右的組含有 2 ~ 9 張人臉資料;
其餘的組人臉數範圍為 10 ~ 10000。
現在的業務需求主要有以下兩類:
根據人臉組 id 查詢該組下面的所有人臉;
根據人臉組 id +人臉 id 查詢某個人臉的具體資料。
1. mysql + oss 方案
為 mysql 以及 oss(物件儲存)。相關表主要有人臉組表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 獲取所有人臉相關的特徵資料，如下圖的左部分所示。
我們從上圖的查詢路徑可以看出，這樣的查詢導致鏈路非常長。從上面的設計可看出，如果查詢的組包含的人臉張數比較多的情況下，那麼我們需要從 mysql裡面掃瞄很多行，然後再從 oss 裡面拿到這些人臉的特徵資料，整個查詢時間 在 10s 左右，遠遠不能滿足現有業務快速發展的需求。
由於 mysql 不支援動態列的特性，所以屬於同乙個人臉組的資料被拆成多行儲存。
針對上面兩個問題，我們進行了分析，得出這個是 hbase 的典型場景，原因如下:
hbase 擁有動態列的特性，支援萬億行，百萬列;
hbase 支援多版本，所有的修改都會記錄在 hbase 中;
我們可以使用這三個功能重新設計上面 mysql+oss 方案。結合上面應用場景的兩大查詢需求，我們可以將人臉組 id 作為 hbase 的 rowkey，系統的設計如 上圖的右部分顯示，在建立表的時候開啟 mob 功能，如下:
上面我們建立了名為 face 的表，is_mob 屬性說明列族 c 將啟用 mob 特性， mob_threshold 是 mob 檔案大小的閾值，單位是位元組，這裡的設定說明檔案大於 2k 的列都當做小檔案儲存。大家可能注意到上面原始方案中採用了 oss 物件儲存，那我們為什麼不直接使用 oss 儲存人臉特徵資料呢，如果有這個疑問，可以看看下面表的效能測試:
根據上面的對比，使用 hbasemob特性來儲存小於10mb的物件相比直接使用 物件儲存有一些優勢。我們現在來看看具體的表設計，如下圖:
上面 hbase 表的列族名為 c，我們使用人臉 id 作為列名。我們只使用了 hbase 的一張表就替換了之前方面的三張表!雖然我們啟用了 mob，但是具體插入的方法和正常使用一樣，**片段如下:
使用者如果需要根據人臉組 id 獲取所有人臉的資料，可以使用下面方法:
這樣我們可以拿到某個人臉組 id 對應的所有人臉資料。如果需要根據人臉組 id+ 人臉 id 查詢某個人臉的具體資料，看可以使用下面方法:
經過上面的改造，在 2 臺 hbase worker 節點記憶體為 32gb，核數為 8，每個節 點掛載四塊大小為 250gb 的 ssd 磁碟，並寫入 100w 行，每行有 1w 列，讀 取一行的時間在 100ms-500ms 左右。在每行有 1000 個 face 的情況下，讀取一行的時間基本在 20-50ms 左右，相比之前的 10s 提公升 200~500 倍。
下面是各個方案的對比效能對比情況。
3. 使用 spark 加速資料分析
我們已經將人臉特徵資料儲存在 hbase 之中，這個只是資料應用的第一步，如 何將隱藏在這些資料背後的價值發揮出來?這就得借助於資料分析，在這個場景 就需要採用機器學習的方法進行聚類之類的操作。我們可以借助 spark 對儲存於 hbase 之中的資料進行分析，而且 spark 本身支援機器學習的。但是如果直接採用開源的 spark 讀取 hbase 中的資料，會對 hbase 本身的讀寫有影響的。
針對這些問題，我們可以對 spark 進行了相關優化，比如直接讀取 hfile、運算元下沉等;通過 sql 服務 thriftserver、作業服務livyserver 簡化 spark 的使用等。 目前這套 spark 的技術棧如下圖所示。
通過 spark 服務，我們可以和 hbase 進行很好的整合，將實時流和人臉特徵挖掘整合起來，整個架構圖如下:
通過 spark 服務，我們可以和 hbase 進行很好的整合，將實時流和人臉特徵挖 掘整合起來，整個架構圖如下:
我們可以收集各種人臉資料來源的實時資料，經過 spark streaming 進行簡單的 etl 操作;其次，我們通過 sparkmlib 類庫對剛剛試試收集到的資料進行人臉 特徵挖掘，最後挖掘出來的結果儲存到 hbase 之中。最後，使用者可以通過訪問 hbase 裡面已經挖掘好的人臉特徵資料進行其他的應用。
HBase 在人工智慧場景的使用
近幾年來，人工智慧逐漸火熱起來，特別是和大資料一起結合使用。人工智慧的主要場景又包括影象能力 語音能力 自然語言處理能力和使用者畫像能力等等。這些場景我們都需要處理海量的資料，處理完的資料一般都需要儲存起來，這些資料的特點主要有如下幾點 為了更好的介紹 hbase 在人工智慧場景下的使用，下面以某人...
人工智慧帶來的場景變革
人工智慧是讓機器像人一樣能行動和思考。人工智慧是第四次工業革命中主要內容之一。人類從農耕到發明蒸汽機需要幾千年，從蒸汽機到電力技術到發明經歷了兩三百年，從電力技術到資訊科技用了一百多年的時間，從資訊科技到移動網際網路就幾十年。目前我們正處於移動網際網路時代邁向智慧型互聯的階段 第四次工業革命。第四次...
人工智慧的應用 製造業人工智慧8大應用場景
從應用層面來看，一項人工智慧技術的應用可能會包含計算智慧型 感知智慧型等多個層次的核心能力。工業機械人 智慧型手機 無人駕駛汽車 無人機等智慧型產品，本身就是人工智慧的載體，其硬體與各類軟體結合具備感知 判斷的能力並實時與使用者 環境互動，無不是綜合了多種人工智慧的核心能力。智慧型語音互動產品 人臉...