來源：之家技術

1. 之家廣告系統業務流程

之家車智投廣告系統的核心業務流程如圖：

· 平臺運營透過運營系統配置廣告，包括設定投放點位、投放城市、投放時間段、投放關鍵詞等定向條件。

· 配置完成後，廣告被存放到廣告庫，用於構建索引庫，以供廣告檢索引擎召回使用。

· 當C端發起廣告請求，廣告引擎會進行一系列操作，包括召回、排序和過濾等邏輯，最終篩選出要展示的廣告。

· 使用者點選廣告後，觸發廣告扣費流程，當廣告預算到達限額時，會觸發廣告下線處理。

· 最後，產品或運營人員可以透過車智慧系統檢視並匯出相關廣告曝光和點選的資料包表。

在處理海量廣告庫中的資料時，廣告index索引系統需要快速篩選出幾個或幾十個符合條件的廣告，以滿足實時性要求。本文將對車智投index索引系統的設計進行簡要介紹，以幫助大家更好地瞭解廣告索引召回的處理過程。

2. index索引系統介紹

在介紹索引系統之前，我們需要先了解一下目前車智投廣告的資料投放模型。

廣告客戶通常會建立多個廣告計劃，每個計劃對應一個較長週期的KPI，例如預算和投放地域。每個廣告計劃包含多個廣告組，用於實現更精細的投放控制，並設定不同的定向條件。廣告素材是廣告曝光所展示的文字、圖片或影片等，一般由廣告客戶提供，可以屬於不同的廣告組。廣告檢索、排序等都是基於廣告組粒度進行的，而廣告的倒排索引也是基於廣告組層級建立。

index索引系統是廣告投放引擎的子系統，為廣告投放提供定向檢索服務。它從眾多的投放計劃中快速篩選出符合當前頁面瀏覽量（PV）的計劃組，並提供實時化的索引更新功能。在廣告系統中，大部分欄位需要支援實時更新，例如計劃/廣告組狀態和預算上下線狀態等。舉個例子，當一個廣告組由可投放狀態變為暫停狀態時，如果該變更沒有及時在索引中生效，就會導致大量無效的廣告被投放出來。

2.1

index系統架構

系統採用多執行緒模型，主要包括主執行緒、Kafka執行緒、MySQL執行緒和Dump執行緒。

主執行緒負責接收廣告伺服器的請求並進行處理，並回應服務請求；

Kafka執行緒負責處理投放計劃的實時更新訊息，確保索引資料及時更新；

MySQL執行緒負責從MySQL中讀取最新的全量投放計劃資料，以保持索引的準確性和完整性。

Dump執行緒定期將記憶體中的索引資料匯出到檔案中，以便在需要時進行恢復和備份。

瞭解Index索引系統的基本架構後，下面將介紹底層索引結構的組成，包括索引的建立、更新和查詢等操作的實現原理。

2.2

索引邏輯結構

索引邏輯結構總體包含4部分，以下為結構的詳細介紹。

1、廣告組到docid對映

每個廣告組都會被分配一個數值型的docid，並且生成規則採用自增量的方式。例如，如果有100個廣告組，則它們的docid分別為0、1、2、…、97、98、99。系統中的索引操作，包括新建、更新和查詢等，都是基於這些docid來進行的。為了儲存廣告組的docid和其對應的索引關係，系統使用了hash表作為記憶體結構。這樣可以快速地進行索引對映和查詢操作。

2、正排表

正排表是一種陣列結構，用於儲存廣告資料並支援主鍵到文件的隨機訪問。它按照順序依次儲存每個docid對應的詳細廣告資料，包括廣告組id、廣告客戶id、計劃id、預算、計費方式、用途、投放方式、優先順序、廣告型別、訂單型別和廣告素材等資訊。在檢索過程中，先根據廣告組id從對映表中取得對應的docid後，再透過該docid從正排表陣列中獲取詳細的廣告資料，正排表採用陣列結構進行記憶體儲存，使得可以快速地根據主鍵進行隨機訪問。

3、倒排hash表

倒排表用於儲存索引及索引對應的廣告狀態資料，它由hash表和bitmap點陣圖組成。

hash表：提供了快速的插入和查詢操作，可以將儲存和查詢索引資料的時間消耗大大降低，並且幾乎可以看作是常數時間。hash表採用陣列加連結串列的實現方式，透過雜湊函式將索引對映到對應的位置，以實現快速的索引儲存和檢索。

bitmap點陣圖：將廣告文件ID（docid）對映到點陣圖中的相應位置，使用一個bit位（0或1）來表示廣告是否存在。在擁有數以萬級廣告資料的情況下，使用點陣圖標識廣告狀態非常節省儲存空間。同時，利用位運算（如AND、OR、XOR、NOT）可以高效處理多個點陣圖資料，例如查詢同時滿足多個定向條件的廣告組資料，只需對對應的點陣圖進行AND運算即可。

在程式中，倒排表的資料結構定義如下：

CHstr類透過傳入的最大雜湊值、雜湊函式和比較函式來初始化，並提供了新增、刪除、匹配和遍歷等功能。其中，m_tables是一個指向雜湊表的指標，用於儲存倒排索引的資料。

在車智投廣告系統的業務上，倒排索引大致可以分為以下幾類：

廣告位屬性：包括廣告位ID、輪播數、廣告位尺寸（寬度*高度）、廣告位素材型別和計費型別等屬性。

頁面屬性：包括頁面所在省份、城市、品牌、車系和級別等屬性。

人群屬性：包括使用者所在省份、城市、投放時段、偏好品牌、偏好車系和偏好級別等屬性。

移動屬性：包括裝置平臺屬性，用於區分不同的移動裝置平臺。

搜尋屬性：包括關鍵詞，用於匹配使用者搜尋的關鍵詞與廣告內容的相關性。

狀態屬性：包括業務狀態和計費狀態。業務狀態表示產品或運營透過業務系統變更計劃或廣告組的狀態；計費狀態是後端引擎根據計劃到量情況判斷的上下線狀態。

4、docid狀態點陣圖

docid狀態點陣圖用於標識每個docid的有效性，其中0表示無效，1表示有效。透過點陣圖的方式，可以快速判斷一個docid是否存在，從而避免對無效的廣告進行不必要的處理。這種狀態點陣圖的設計在索引系統中起到了關鍵作用，能夠提高廣告投放的效率和準確性。透過位運算等高效操作，可以方便地對多個點陣圖資料進行處理，例如查詢同時滿足多個條件的廣告組資料。

索引的常見操作有以下幾種：

add：將新的文件新增到正排表和倒排索引中

update：修改已存在的文件內容，涉及正排表和倒排索引的變更

search：根據查詢列表查詢符合條件的文件集合並返回結果

2.3

索引新建

索引新建流程如圖所示：

假設有一個廣告組T，投放地域：北京、上海，關鍵詞：寶馬，投放裝置：移動端，計劃id：2305，CPC計費，單次點選價格2元，預算1萬，底層的索引結構構建過程步驟如下：

1、建立docid對映關係：將廣告組T分配給docid=3

2、遍歷廣告組T的所有索引詞，將對應bitmap的docid位設定為有效，並儲存索引詞和對應的bitmap。例如，地域#北京、地域#上海、關鍵詞#寶馬、投放裝置#移動，在對應的bitmap中標記相應的docid位為有效（紅色標識本次新的docid有效）

3、將廣告組T的其他資料儲存到正排表中

4、更新doc狀態bitmap的docid位為有效

索引詞的儲存使用了hash分桶方式，根據索引詞的雜湊值確定其所屬的儲存桶，並在該儲存桶中儲存對應的索引項。這樣一來，在查詢某個索引詞時，可以直接定位到對應的儲存桶，而無需遍歷整個索引結構，從而提高查詢效率和速度。同時，使用hash分桶還可以平衡索引的負載，使得不同的索引詞均勻地分佈在各個儲存桶中，提高整體效能和擴充套件性。

索引詞hash生成規則如下：

hash的基本原理是將任意長度的輸入透過hash演算法轉換成固定長度的輸出，也稱為雜湊值。由於雜湊值的長度是有限的，而輸入資料的長度是無限的，因此必然會存在不同的輸入資料經過雜湊演算法後得到相同的雜湊值，這就是所謂的雜湊衝突。當遇到雜湊衝突時，常用的解決方法是採用鏈地址法（Chaining）。鏈地址法使用一個連結串列陣列來儲存相應的資料，當發生衝突時，將衝突的資料新增到對應位置的連結串列中。

鏈地址在處理的流程如下：

新增一個元素的時候，首先計算元素key的hash值，確定插入陣列中的位置。如果當前位置下沒有重複資料，則直接新增到當前位置。當遇到衝突的時候，新增到同一個hash值的元素後面，行成一個連結串列。這個連結串列的特點是同一個連結串列上的Hash值相同。

在索引構建時，若索引詞hash值衝突，需要追加到連結串列後面：

鏈地址法的優點是簡單且易於實現，在處理雜湊衝突時具有較高的效率，然而，它也存在一些缺點，例如連結串列可能會變得很長，導致查詢效率下降。

2.4

索引修改

透過業務系統修改廣告計劃、廣告組等資訊時，會觸發索引的實時更新。更新索引時，首先根據已存在的廣告組找到對應的docid，並禁用所有bitmap（包括狀態bitmap和所有索引詞對應的bitmap）中的該docid位，使舊的索引失效。然後重新遍歷新的索引詞，設定對應bitmap的docid位為有效，以建立新的索引。最後，開啟狀態bitmap的docid位，使廣告組的新索引生效。