一、HBase基礎與存儲的優勢
HBase主要具有五大核心優勢，即海量存儲、列式存儲、易擴充、高并發以及稀疏矩陣。HBase所能夠應用的場景包括對象存儲、使用者畫像推薦、聊天消息實時流、索引、報表以及軌迹資料和監控資料等。
二、HBase應用分享
這裡主要分享一下HBase在人臉識别場景中的應用。在京東，人臉識别主要應用于無人超市、動态廣告牌以及AR試裝鏡等項目中。人臉識别主要可以分為離線人臉識别和線上人臉識别兩個方面。分别而言，離線人臉識别包括人臉屬性識别，包括性别、年齡以及表情等的識别，其次是小場景人臉識别，比如手機人臉識别等，小場景人臉識别速度比較高，資料和模型都存儲在本地。第三個就是人臉個數檢測，比如通過攝像頭判斷和分析某區域的客流量。對于線上人臉識别而言，需要對人臉資訊進行錄入，其次還有人臉搜尋，比如常用的門禁場景。第三就是人臉校驗，比如身份證與本人的對應識别。
日志記錄
對于離線人臉識别而言，隻需要将資料儲存在本地即可，不需要在雲端進行比對，而需要定期将資料批量寫入伺服器。而對于人臉搜尋這樣的場景，比如門禁場景，當人去刷臉的時候，用戶端會扣取圖檔中的人臉圖，先判斷圖檔中是否有人，如果有人才會去雲端進行多線程搜尋，隻要其中一個線程能夠搜尋成功就認為搜尋成功，之後就可以打開門禁。以上這些都屬于日志批量寫入的場景。
其次是列式存儲場景，一些資料可能存在交叉，但是又不完全一樣，比如上圖中的6種場景，人臉搜尋、人臉檢驗、人臉校驗、人臉屬性檢測、人臉特征以及人臉活體等。在京東基于HBase的人臉識别實踐中，主表的RowKey設計使用的data_time_uuid，其中time為最大時間減去目前時間，這樣使得最新的資料放在最上面，而uuid則是随機id。因為直接通過主表查詢資料比較麻煩，是以根據不同的業務次元建立不同的索引表，索引表中存儲了目前的主表的RowKey。是以可以按照不同的業務次元找索引表，進而找到主表中的資料。
三、HBase資料分析
如下圖所示，在剛開始的時候，按照不同的類型、不同的時間和不同的使用者進行統計，寫不同的work，如果統計的次元越多，那麼work就越多，那麼當需求無限增加，那麼就需要使用更多地任務。并且這樣一來使得任務管理變得異常繁瑣。
是以，對于上述部分進行了如下圖所示的改進。上層的各種應用将會把資料寫入到HBase裡面，同時實時地接入Kafka直接進入資料倉庫裡面，此外，資料倉庫每天會增量地将HBase中的資料增量地抽取過去。
如下圖所示的是資料倉庫的設計，當将資料抽取過來之後需要對于資料進行清洗。因為有些字段沒有作用，是以需要進行清洗之後，按照次元進行劃分，最後按照需求歸入到不同應用裡面提供服務。
HBase中的資料将會主要應用于兩個方面，其一是統計報表，離線查詢基于Hive實作，是以這樣就比較友善。另外一個方面就是實時資料大屏，需要将資料實時寫入HBase，并對外提供API服務。
四、HBase使用中遇到的問題
在使用HBase的過程中也遇到了很多的問題，第一個就是因為項目是基于Spring實作的，但由于Spring HBase性能較差，發現當資料量變大之後，其讀寫性能變得很差，主要原因就是經常會出現需要重新連接配接的情況，根據這樣的情況，在實踐中選用了原生的API。其次，還出現了HBase的熱點問題，在實踐中采用預分區的方式進行了解決。
因為HBase具有諸多優勢，是以非常适合大資料場景下的資料存儲應用，比如目前比較熱門的人臉識别場景，人臉識别分為線上和離線兩種，各種方案具有不同的業務特點，而基于HBase的資料存儲方案，能夠滿足多種需求。雖然目前而言，在項目實踐中，HBase也需要面對性能以及熱點問題等諸多挑戰，但是往往都能夠找到應對之道。