新浪微博使用者興趣建模系統架構
author: 張俊林
/*作者注：這是2011年左右新浪微博個人興趣模型的技術架構，所以你從中是看不到目前很多流行的NoSQL平臺的，因為它們那時候還沒出生呢，現在應該有了很大變化了，不過以新浪微博對技術的重視程度，說不定還是這套在運轉也說不定@^@。*/
在微博環境下，構建微博使用者的個人興趣模型是非常重要的一項工作。首先，從可行性方面而言，微博是一個使用者登入後才能正常使用的應用，而且使用者登入後會有閱讀/釋出/關注等多種使用者行為資料，所以微博環境是一個構建使用者興趣模型的非常理想的環境，因為圍繞某個特定使用者可以收集到諸多的個性化資訊。另外，從使用者興趣建模的意義來說，如果能夠根據使用者的各項資料構建精準的個人興趣模型，那麼對於各種個性化的應用比如推薦、精準定位廣告系統等都是一種非常有用的精準定位資料來源，可以在此基礎上構建各種個性化應用。
事實上，新浪微博在2011年前已經構建了一套比較完善的使用者興趣建模系統，目前這套系統挖掘出的個人興趣模型資料已經應用在10多項各種應用中。對於每個微博使用者，通過對使用者釋出內容以及社交關係挖掘，可以得出很多有益的資料，具體而言，每個微博使用者的興趣描述包含以下三個方面：使用者興趣標籤、使用者興趣詞和使用者興趣分類。
使用者興趣標籤是通過微博使用者的社交關係推匯出的使用者可能感興趣的語義標籤；使用者興趣詞是通過對使用者釋出微博或轉發微博等內容屬性來挖掘使用者潛在興趣；使用者興趣分類則是在定義好的三級分類體系中，將使用者的各種資料對映到分類體系結構中，比如某個使用者可能對“體育/娛樂明星”這幾個類別有明顯興趣點。以上三種個性化資料，使用者興趣標籤和使用者興趣詞是細粒度的使用者興趣描述，因為可以具體對應到實體標籤一級，而使用者興趣分類則是一種粗粒度的使用者興趣模型。本文主要從體系結構角度來簡介使用者興趣詞以及使用者興趣分類這兩類使用者興趣的挖掘系統架構。
|微博使用者興趣建模系統整體架構
微博使用者興趣建模系統整體架構如圖1所示，其由實時系統和離線挖掘系統兩個子系統構成。因為每時每刻都有大量微博使用者釋出新的微博，實時系統需要及時抽取興趣詞和使用者興趣分類，而離線挖掘系統的目的則是優化使用者興趣系統效果。
圖1.微博使用者興趣建模系統整體架構統
每當有使用者釋出新的微博，則這條微博作為新資訊進入實時Feed流佇列，為了增加系統快速處理能力，實時系統由多臺機器的分散式系統構成，通過Round Robin演算法將實時Feed流佇列中新發布的微博根據釋出者的UID分發到分散式系統的不同機器中，為了保證系統的容錯性，由Master主機和Slave機器組成一個機器組，監控系統實時監控機器和服務的執行狀態，一旦發現Master機器故障或者服務故障，則實時將服務切換到Slave機器，當故障機器恢復時，監控系統負責將服務切換回Master 機器。
離線挖掘系統是構建在Hadoop系統上的，通過MapReduce任務來執行挖掘演算法，目標是優化使用者興趣詞挖掘效果。
|實時抽取系統
對於實時抽取系統來說,每臺伺服器可以承載大約1億使用者的使用者興趣挖掘。當用戶釋出微博後，此資訊實時進入原始Feed流佇列中，語義處理單元針對每條微博快速進行語義計算，語義處理單元採取多工結構，依次對微博進行分詞，焦點詞抽取以及微博分類計算。焦點詞抽取與傳統的關鍵詞抽取有很大差異，因為微博比較短小，如果採取傳統的TF.IDF框架抽取關鍵詞效果並不好，所以我們提出了焦點詞抽取的概念，不僅融合傳統的TF.IDF等計算機制，也考慮了單詞在句中出現位置，詞性，是否命名實體，是否標題等十幾種特徵來精確抽取微博所涉及的主體內容，避免噪音詞的出現。微博分類則通過統計分類機制將微博分到內部定義的多級分類體系中。
當微博經過語義處理單元處理後，已經由原始的自然語言方式轉換為由焦點詞和分類構成的語義表示。每條微博有兩個關鍵的Key:微博ID和使用者ID，經過語義處理後，系統實時將微博插入“Feed語義表示Redis資料庫”中，每條記錄以微博ID為key，value則包含對應的UID以及焦點詞向量和分類向量。考慮到每天每個使用者可能會發布多條微博，為了能夠有效控制“Feed語義表示Redis資料庫”資料規模在一定範圍，系統會監控“Feed語義表示Redis資料庫”大小，當大小超出一定範圍時，即將微博資料根據使用者ID進行合併進入“User語義表示Redis資料庫”。
圖 2 單機實時抽取系統
在使用者不活躍時段，系統會將“User語義表示Redis資料庫”的內容和儲存在Mysql中的使用者歷史興趣資訊進行合併，在合併時會考慮時間衰減因素，將當日微博使用者新發表的內容和歷史內容進行融合。為了增加系統效率，會設立一個歷史資訊快取Redis資料庫，首先將部分使用者的歷史資料讀入記憶體，在記憶體完成合並後寫入mysql進行資料更新。
|離線挖掘系統
出於精準定位使用者興趣的目的，在實時抽取系統已經通過“焦點詞抽取”以及歷史合併時採取一些特殊合併策略來優化演算法，但是通過實際資料分析發現，有些使用者的興趣詞向量還包含不少噪音，主要原因在於：微博使用者在釋出微博或者轉發微博時有很大的隨意性，並非每條使用者釋出的微博都能夠表示使用者的興趣，比如使用者轉發一條“有獎轉發”的微博，目的在於希望能夠通過轉發中獎，所以其微博內容並不能反映使用者興趣所在。為了能夠更加精準地從使用者釋出內容定位使用者興趣詞，我們通過對實時系統累積的使用者歷史興趣進行離線挖掘系統來進一步優化系統效果。
離線挖掘的基本邏輯是:微博使用者釋出的微博有些能夠代表個人興趣,有些不能代表個人興趣。離線挖掘的基本目標是對實時系統累積的個人興趣詞進行判別，過濾掉不能代表個人興趣的內容，只保留能夠代表個人興趣的興趣詞。我們假設如果使用者具有某個興趣點，那麼他不會只發布一條與此相關的微博，一般會發布多條語義相近的微博，通過是否經常釋出這個興趣類別的微博可以作為過濾依據。比如假設某個使用者是蘋果產品忠實使用者，那麼他可能會經常釋出蘋果產品相關內容。
但是問題在於：如何知道兩條微博是否語義相近？更具體而言，通過實時抽取系統累積的使用者興趣已經以若干興趣詞的表示方式存在，那麼問題就轉換成：如何知道兩個單詞是否語義相近？如何將語義相近的興趣詞進行聚類？如何判別聚類後的興趣詞哪些可以保留哪些需要過濾？
我們通過圖挖掘演算法來解決上述問題，將某個使用者歷史累計的興趣詞構建一個語義相似圖，任意兩個單詞之間的語義相似性通過計算單詞之間的上下文相似性來獲得，如果兩個單詞上下文相似性高於一定值則在圖中建立一條邊。然後在這個圖上執行Pagerank演算法來不斷迭代給單詞節點打分，當迭代結束後，將得分較高的單詞保留作為能夠表達使用者興趣的興趣詞，而將其他單詞作為噪音進行過濾。
圖3 興趣詞語義相似圖
圖3是興趣詞語義相似圖的一個具體示例，通過這個圖可以看出，如果使用者某個興趣比較突出，則很容易形成一個連線密集的子圖，通過在語義相似圖上執行Pagerank演算法，語義相近的興趣詞會形成得分互相促進加強的作用，密集子圖越大，其相互增強作用越明顯，最後得分也會越高，所以通過這種方法可以有效識別噪音和真正的使用者興趣。
在具體實現時，因為每次運算都是在單個使用者基礎上，記錄之間無耦合性，所以非常適合在hadoop平臺下使用MapReduce來分佈計算，加快運算效率。
|小結
使用者興趣建模在微博環境下有著非常重要的作用，一個好的使用者興趣建模系統可以有效支援個性化推薦、搜尋以及個性化廣告推送系統。本文主要從體系結構角度，簡介了微博使用者興趣建模分散式體系結構，並介紹了其中比較關鍵的資料探勘演算法。
