1. 概述

人臉識別技術在最近幾年得到了長足進步，目前在人臉識別領域業界領先的廠家識別準確率均達到了99%以上，因此大量人臉相關的應用場景開始逐步落地，例如人臉支付、人員布控、尋找失蹤人口等，此外，結合人臉的追蹤技術，也開始出現了分析人流走向、分析景點旅客行走規律、人員行為偏好分析等。這些應用雖然表現形式多樣，但最終都是基于人臉特征檢索這一技術實現的。

首先介紹一下人臉特征是什么。目前圖像識別算法能夠在一張照片中發現人臉，并能夠對人臉中的輪廓進行識別和標記，算法使用這些標記點構造出表示該張人臉的特征的矩陣，這個過程稱為人臉特征提取，得到的矩陣稱為人臉特征矩陣，在工程上，特征矩陣一般以一維矩陣表示，以二進制數組的方式進行存儲。

當需要確認兩張人臉照片是否同一個人時，可以通過上述公式計算這兩張人臉的特征矩陣之間的相似度，以此作為兩個人臉的相似度，當相似度超過一定閾值時，就認為是同一個人，該閾值是經驗值，不同廠家的特征提取算法不同，得到的經驗值也會不同。提高閾值，會提高準確率(認為是同一個人的情況下判斷正確的占比)，但會降低查全率(能匹配到的人臉在人臉庫中全部匹配人臉的占比)。因此在不同的應用場景下，由于準確率和查全率的權重不同，導致了閾值也會不同。如在尋找失蹤人口的場景，是寧可找錯也不應放過的，閾值就會相應調低，讓更多相似的人臉能被看到；在人臉支付場景，準確率是最重要的，那么閾值相應就會較高，當然也會導致匹配失敗的次數增多。

把大量人臉特征集中存儲可形成特征庫，若要判斷一個人在不在這個特征庫中，只需要拿這個人的人臉照片對應的人臉特征，跟特征庫里每個特征計算相似度，把相似度超過閾值的特征對應的照片找出即可。通過一個特征來比對一個特征庫的場景，往往稱為人臉1:N比對，與之對應的兩個特征庫之間的比對，往往稱為人臉M:N比對。

算法場景通常會提供如下的M:N比對接口：

接口實現兩個特征庫之間的比對，如上圖中4個特征的庫和3個特征的庫的比對，可得到12個相似度。當要實現1:N時，只需讓其中一個特征庫只包含一個特征即可。此前基于E5-2640V3 CPU(16物理核)實測1:N，每秒可實現1.5億對特征比對。一般通過C++調用該接口完成比對。

2. 性能指標要求

在今年某地市的項目中，系統從一萬多人臉攝像機中采集人臉抓拍圖片進行特征提取后形成特征庫，業務層需要實現人臉檢索功能。其中數據規模為：每天約2000萬張人臉抓拍圖，圖片平均約30KB，人臉特征約600字節，即每月6億個特征，每月特征庫單副本約占用350GB空間，數據需要存儲1年，人臉檢索要求1:1億在3秒內響應，需要支持10個并發，需要支持根據時間、攝像機編號、相似度閾值來過濾人臉。

當然這是在最近才提出的性能指標要求，兩年前，在人臉相關項目還沒有大面積落地時，對人臉檢索的性能指標要求還在千萬級以下的人臉比對，而且只需支持1-3個并發，但也由于當時沒有可參考的案例，業務場景處于摸索階段，因此在人臉檢索上需要支持更豐富的檢索條件，如除了時間和攝像機編號外，還需要支持根據性別、年齡段、是否戴帽子、是否戴眼鏡等條件過濾數據。

下面將從最簡單的方案講起，逐步推進到支持千萬級、億級人臉比對的方案，讓大家對方案的演進有個整體的了解。

3. 解決方案演進

3.1 人臉動態庫方案

在內部驗證階段，使用單機存儲固定特征個數(可能是一千萬個)的特征庫，每個特征對應記錄ID、時間戳、攝像機編號等信息。每天新增的特征形成一個單獨的小特征庫，每天定時把小特征庫合并到大特征庫，并把大特征庫中最舊的同量特征刪除，保持特征庫的大小。在檢索時先對全庫進行1:N，根據閾值過濾出部分記錄后，再抽取對應記錄的額外信息，與頁面檢索條件進行匹配，返回結果。

優點：由于是單機系統，方案實現和維護都比較簡單

缺點：單機支持的特征數量有限，無法橫向擴展，檢索并發度低，過濾條件無法靈活變化

3.2 ES分布式人臉檢索方案

由于業務之初并不清楚實際應用場景中哪些檢索條件是用戶離不開的，只有在不斷的實踐迭代中摸索真正能落地的使用方式，因此豐富、靈活的檢索條件在當時是相對重要的。考慮現已用戶的檢索條件過濾數據后形成特征庫，再用待搜索的人臉跟特征庫做1:N。因此第一步需要使用能夠支持靈活搜索，并且搜索性能極佳的引擎，基于公司技術棧和業界常用的搜索引擎考慮，最終敲定為ElasticSearch搜索引擎。

ES沒有提供查詢后在服務端對結果進行二次處理的接口，并且其源碼中寫死了最多只可返回5000條記錄，若根據搜索條件過濾出來的人臉在百萬級，按照源生接口，就算改大了返回記錄數的限制，也只能是先匯聚到客戶端，然后由客戶端在本地做1:N。這會導致ES和客戶端之間的帶寬占用過高，并且單單是網絡傳輸也要耗費不少時間。

當然，客戶端可以跟ES Node部署在一起，由客戶端提供人臉檢索服務，應用端請求時，客戶端直接對本機的ES Node發起請求，匯總的人臉在本機內部拷貝，可避免網絡傳輸的問題。但是依舊存在如下問題：

1)ES對檢索結果是組裝為List對象再處理后返回到客戶端的，對內存消耗較大；

2)客戶端獲取檢索結果還是通過網卡，雖然服務器內部傳輸避免了帶寬損耗，但內存拷貝是免不了的；

3)ES端檢索時需要匯總全部匹配的結果到查詢節點，這部分的帶寬是免不了的；

4)檢索性能受限于單機性能，無法橫向擴展。

為了避免上面的問題，最好就能在每個ES Node內部檢索到特征數據后，把形成List的過程變為直接寫到事先分配好的堆外內存ByteBuffer中，緊接著通過JNI的方式調用本機的C++接口，傳入ByteBuffer內存塊地址，直接在本機完成1:N比對，然后才把比對結果包裝為ES Node響應對象返回到ES查詢節點，在查詢節點內部完成相似度的排序和取TopN操作，最終返回給客戶端。這個過程如上圖所示，其中為了使線看起來沒那么多，C++ 1:N的結果返回到ES Node的箭頭只在一臺服務器上畫了，實際上其他服務器同樣有這樣的箭頭。

優點：

1)不需要形成List對象，直接在本機形成內存塊，節省了內存，也減少了內存拷貝；

2)1:N是每個節點并行做的，僅返回相似度超過閾值的記錄到查詢節點，帶寬消耗極小，查詢節點處理幾乎不耗時間，因此可橫向擴展；

3)ES自身提供了副本和查詢負載均衡機制，大大節省了運維和接口開發工作量；

4)能支持幾乎全部的ES檢索功能，查詢條件靈活，頁面可隨時修改檢索條件而不需要修改后端實現代碼。

缺點：

1)需要為ES增加一種查詢類型，實現在Node中檢索后直接寫ByteBuffer和調用C++接口做1:N的邏輯，需要深度修改ES源碼；

2)由于是通過JNI調用C++接口，若C++程序異常了，會直接導致ES Node的JVM掛掉。

但是也應注意到該方案并不能避免從ES的Share拷貝記錄到ByteBuffer。由于進行人臉比對所需讀取的記錄數往往在百萬級以上，若這些記錄不在系統緩存中，就會導致需要到磁盤隨機讀取數據，IO消耗嚴重。實測單機使用7200轉普通硬盤并且沒有系統緩存的情況下，要在ES中隨機加載100萬條記錄，需要約60s-80s，而實際應用場景中，需要比對的人臉數據往往大多不在緩存中，因此需要優化從Share拷貝記錄到ByteBuffer的過程。

當時采用了如下方案(簡稱內存ES方案)：

單機上啟動2個ES進程，一個ES進程的數據目錄設置在硬盤中，另外一個ES進程的數據目錄設置在使用tmpfs在內存中模擬的內存文件系統中，N臺服務器共2*N個ES進程組成集群。關閉ES的自動分配和自動平分片功能，按月創建人臉Index，每個Index設置3個副本，3個副本中其中一個分配到使用內存文件系統的ES進程中，另外兩個副本分配到其他服務器上使用磁盤存儲的ES進程中，創建Index的操作專門開發工具實現。對于人臉比對檢索請求，修改客戶端選擇分片的邏輯為優先檢索使用內存存儲的ES分片(通過節點名稱約定實現)，只有當內存存儲的ES分片異常時才選用磁盤存儲的分片。具體實施如上圖所示。

在內存文件系統中的分片在檢索時，從Share拷貝記錄到ByteBuffer就變成了從內存拷貝到內存，避免了磁盤IO，大大提高了性能。但是內存拷貝雖然快，但也只是針對大塊數據而言的，從Share中讀取數據是隨機讀取，經過實際測試發現，單機從存儲在內存文件系統的Share中讀取記錄的速度上限約為250萬條/秒。也就是說，如果要求單并發對1千萬人臉做比對在1秒內響應，不算其他步驟耗時的情況下，至少也要4臺服務器才能支撐。

由于該集群專門用來做人臉檢索，因此Index中只包含檢索條件字段和特征字段，與另外的一個包含完整字段的集群(簡稱全量ES集群)進行數據同步，數據采集網關把數據同時發往這兩個ES集群中。在發生宕機情況時，內存中的數據會全部丟失，因此需要在啟動服務器之后，通過專門的運維工具把原本在該服務器上的分片創建出來，并等待其他節點中的磁盤分片自動同步數據。

缺點：

1)運維非常麻煩，內存ES集群異常恢復時往往需要讀取大量數據，嚴重拖慢ES性能；

2)因為需要把1/3的分片數放到內存文件系統中，因此需要消耗大量內存，對于128GB內存的服務器，最多只能劃分40GB內存來存放分片，因為ES自身的正常運行也需要消耗大量內存，這就使得單機可存儲的數據量極少，如果按前面所說的每天2000萬個特征1個月單單是特征就要350GB內存，那就需要9臺128GB內存的服務器才能放得下；

3)為了使人臉比對不影響普通查詢的性能，全量ES集群和內存ES集群應部署到不同的服務器組上，這樣無形中又需要消耗更多的服務器；

4)單機內存拷貝速度依然較慢，需要大量服務器才能支撐大規模的人臉比對；

5)ES自身在對單個字段進行多值匹配時，耗時呈現指數型增長趨勢，當匹配值個數超過100時，單單是該字段的匹配耗時就在秒級耗時了，而實際場景中用戶往往會選擇大量的攝像機來進行檢索，這樣會嚴重拉低ES檢索性能。

3.3 基于RocksDB的分布式特征索引方案

隨著應用場景的逐漸清晰和對人臉識別到的其他特征準確度的認識，發現實際在使用人臉檢索功能時，其實基本只會使用時間段+攝像機編號+人臉照片這三個條件來檢索人臉，因此靈活的檢索條件這一項變得不那么重要了。此外，實踐中發現ES方案在做人臉檢索時，其實絕大多數耗時集中在根據條件進行搜索和從Share中拷貝數據形成特征庫這兩步，真正進行1:N消耗的時間幾乎可忽略不計。

前面提到，基于高性能CPU能實現1秒完成1:1.5億的比對，假設這樣的場景：用戶需要檢索24小時范圍里全部攝像機抓拍的人臉里是否出現了某個性別為男性的人。按照每天2000萬特征來算，假設這24小時里性別為男性的記錄是1000萬，ES方案中加載1000萬特征需要4秒，1:1000萬需要0.066秒，不算其他耗時則總耗時約為4.066秒；若先不過性別條件，用24小時全部的人臉比對完后，以超過閾值的記錄去判斷是否男性，則1:2000萬需要0.133秒，超過閾值的幾百個人臉再去判斷性別假設需要0.5秒，則總耗時約為0.633秒。需要檢索的時間范圍越長，則性能差異越大。

因此，關鍵需要有一個能先根據時間段+攝像機編號初步過濾特征庫的引擎，先進行人臉比對，然后再做條件匹配。其實這更像是方案一的升級版。具體方案如上圖所示。持久化存儲使用RocksDB，引擎啟動后會在內存中緩存一定時間段的全量特征庫用于人臉比對，數據以作為為索引對特征數據分塊存儲，相同索引的數據平均分布在多臺機器上(即數據寫入時對于相同索引的數據集，按照節點數均分，發往全部的節點上)，實時寫入時內存庫和RocksDB雙寫。此外還實現了數據副本機制。

選擇RocksDB的原因：在本方案中由于數據寫入是雙寫，引擎的主要壓力在數據寫盤，RocksDB采用LSM樹存儲引擎，數據寫入性能較好，提供了索引機制，并且提供了C++訪問接口，能大大降低開發難度。

在上圖的數據中，假設檢索時間范圍2018-01-01 06:00:00到2018-01-01 06:30:00，攝像機編號為4401150002的人臉，則定位到每個節點的紅色內存塊(如下圖所示)，全部節點并行比對人臉，如下圖所示，最終匯總到接收查詢請求的節點。

文章開頭所說的人臉檢索要求1:1億在3秒內響應，需要支持10個并發性能指標，換算下來是要達到1:3.333億秒內響應的效果，若按照單機1.5億/秒的比對速度，則至少需要3臺服務器。因此，本方案實際上已經能夠滿足性能指標要求，后面的3.4和3.5節介紹的方案是后續可能采用的方案，以應對未來可能的更大規模的人臉比對需求。

優點：

1)支持橫向擴展。任意一個比對請求都會使用全部的服務器的資源進行比對，理論上服務器數量與比對性能成正比關系；

2)能有效利用內存資源，在實際實施時，往往能使用80%的內存用于特征庫緩存，剩余內存用于超出緩存時間范圍之外的臨時數據緩存；

3)比對可基于特征庫緩存直接進行，實現內存零拷貝；

4)引擎是自研的，對于源碼完全掌控，出了問題更容易解決。

缺點：

1)需要自研整套分布式框架，實現內存管理和解決數據同步、一致性等問題。

3.4 基于小特征加速比對的檢索方案

一些廠家除了提供前面所說的約600字節的人臉特征外，還提供了50字節左右的小人臉特征，使用了更少的特征點來描述一張人臉。顯然，使用小特征在判別兩個人臉是否同一個人時，準確率比大特征低，但小特征庫能提供更高的比對性能(因為計算量更小)。因此可以通過小特征庫來加速大特征庫比對。

由于兩個特征矩陣的相似度計算主要為浮點運算，按照相似度計算公式，理論上特征長度變為原來的1/N，則單位時間比對次數變為原來的N倍。也就是說，若600字節大特征能做到1.5億條/秒的比對速度，則50字節的小特征理論上能做到18億/秒的比對速度。

具體方案見上圖。相比于3.3節方案，多出了小特征內存塊，小特征內存卡與大特征內存卡一一對應，使用相同的索引來標識。在檢索人臉時，首先根據查詢條件定位小特征內存塊，使用更低的相似度閾值進行人臉比對，根據匹配結果從對應的大特征內存塊中抽取特征組成大特征庫(方法可以是大小特征塊按ID有序排列，這樣記錄順序是相同的，另外可以是每個特征塊有單獨的ID索引，可快速定位行號)，進行第二次人臉比對，第二次比對使用客戶端傳入的閾值。

在該方案中，第一次比對后從大特征庫取的數據量較少，但基本為隨機讀取，因此可以考慮使用固態硬盤來存儲大特征塊以節省內存。

3.5 基于GPU優化的檢索方案

由于特征的比對主要是浮點運算，可考慮使用浮點運算能力更高的GPU來實現。在小特征50字節情況下，則8GB顯存約可存儲1.5億個特征，按一天2000萬特征計算，則8GB顯存可存儲7.5天數據，4張GPU卡則可存儲一個月數據，若N臺服務器上都插上4張GPU卡，則可以實現N個月特征的GPU比對提速效果。使用GPU后，還能帶來一個顯著的好處：更少的服務器，節省了機房空間。

上圖中在3.4節方案的基礎上，增加了顯存存儲小特征塊的部分。如果在顯存中存儲最近一個月的熱數據，在內存中存儲更舊日期的小特征，當檢索條件只落在最近一個月時，只需要GPU就能完成小特征的比對；若檢索條件涉及最近三個月，可在GPU中比對最近一個月的小特征，同時在CPU中比對第二三個月的小特征。在實際應用場景中，用戶絕大多數時間檢索的是最近一個月的數據，該方案能大大提高響應速度。

4 總結

本文從需求和性能優化的角度，為大家介紹了海量人臉特征檢索場景解決方案的演進過程，可以看到，不同的業務需求往往決定了具體的實現方案。可以預見，當前人臉比對性能逐漸不再是瓶頸，大量與人臉檢索相關的場景都能夠得以實現。如今用戶已經不滿足只能實現簡單的人臉檢索功能，他們希望能利用人臉比對的能力，實現諸如人群聚類、人員歸檔、陌生人行為分析等業務，這些業務最底層的邏輯是人臉聚類算法，即給出一個未知人員信息的特征庫，算法根據里面每個人的兩兩相似度，把相同的人的照片歸到一類中，實現特征集合的人員劃分。在公共安全領域，人員聚類將是下一個爆發的應用場景，值得大家關注。

原文鏈接：https://segmentfault.com/a/1190000019224111

總結

以上是生活随笔為你收集整理的从服务器检索时出错dfdferh01_大数据实战项目之海量人脸特征检索解决方案演进...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。