微博使用者興趣建模系統由實時系統和離線挖掘系統兩個子系統構成。因為每時每刻都有大量微博使用者發布新的微博，實時系統需要及時抽取興趣詞和使用者興趣分類，而離線挖掘系統的目的則是優化使用者興趣系統效果。
1、實時抽取系統
當微博經過語義處理單元處理後，已經由原始的自然語言方式轉換為由焦點詞和分類構成的語義表示。每條微博有兩個關鍵的key:微博id和使用者id，經過語義處理後，系統實時將微博插入「feed語義表示redis資料庫」中，每條記錄以微博id為key，value則包含對應的uid以及焦點詞向量和分類向量。考慮到每天每個使用者可能會發布多條微博，為了能夠有效控制「feed語義表示redis資料庫」資料規模在一定範圍，系統會監控「feed語義表示redis資料庫」大小，當大小超出一定範圍時，即將微博資料根據使用者id進行合併進入「user語義表示redis資料庫」。
在使用者不活躍時段，系統會將「user語義表示redis資料庫」的內容和儲存在mysql中的使用者歷史興趣資訊進行合併，在合併時會考慮時間衰減因素，將當日微博使用者新發表的內容和歷史內容進行融合。為了增加系統效率，會設立乙個歷史資訊快取redis資料庫，首先將部分使用者的歷史資料讀入記憶體，在記憶體完成合併後寫入mysql進行資料更新。
2、離線挖掘系統
出於精準定位使用者興趣的目的，在實時抽取系統已經通過「焦點詞抽取」以及歷史合併時採取一些特殊合併策略來優化演算法，但是通過實際資料分析發現，有些使用者的興趣詞向量還包含不少噪音，主要原因在於：微博使用者在發布微博或者**微博時有很大的隨意性，並非每條使用者發布的微博都能夠表示使用者的興趣，比如使用者**一條「有獎**」的微博，目的在於希望能夠通過**中獎，所以其微博內容並不能反映使用者興趣所在。為了能夠更加精準地從使用者發布內容定位使用者興趣詞，通過對實時系統累積的使用者歷史興趣進行離線挖掘系統來進一步優化系統效果。
但是問題在於：如何知道兩條微博是否語義相近？更具體而言，通過實時抽取系統累積的使用者興趣已經以若干興趣詞的表示方式存在，那麼問題就轉換成：如何知道兩個單詞是否語義相近？如何將語義相近的興趣詞進行聚類？如何判別聚類後的興趣詞哪些可以保留哪些需要過濾？
通過圖挖掘演算法來解決上述問題，將某個使用者歷史累計的興趣詞構建乙個語義相似圖，任意兩個單詞之間的語義相似性通過計算單詞之間的上下文相似性來獲得，如果兩個單詞上下文相似性高於一定值則在圖中建立一條邊。然後在這個圖上執行pagerank演算法來不斷迭代給單詞節點打分，當迭代結束後，將得分較高的單詞保留作為能夠表達使用者興趣的興趣詞，而將其他單詞作為噪音進行過濾。
在具體實現時，因為每次運算都是在單個使用者基礎上，記錄之間無耦合性，所以非常適合在hadoop平台下使用mapreduce來分布計算，加快運算效率。
android新浪微博呼叫使用者微博介面
根據上篇認證通過後，可以呼叫api中的開放介面.一般我們開發的應用都是要顯示一些企業的微博資訊，如我之前開發的 萬事達卡 顯示萬事達人微博.我們要注意一點 一般我們都是根據screen name設定查詢微博的.片段 這裡也可以把前面我們oauth認證時候的authconsumer傳過來，就不用這些步...
新浪微博的儲存思路整理架構分享 微博架構的回顧
最近這段時間工作上的變動有點大,五月份也閒了下來一直在思考自己接下來的方向,並對這一年來的學習進行總結.對於架構上的深入是這一年多來最主要的沉澱,從小公司到大公司,從小流量的站點的架構設計到大流量乃至超大流量的架構設計,記錄下來,分享出來。在分享自己的那點料之前,先來分享下大神tim yang的關於...
讀《微博推薦架構的演進》有感
這周繼續研究微博架構，本篇隨便的重點是微博架構的演變。微博 weibo 是一種通過關注機制分享簡短實時資訊的廣播式社交網路平台。微博使用者通過關注來訂閱內容，在這種場景下，推薦系統可以很好地和訂閱分發體系進行融合，相互促進。微博兩個核心基礎點 一是使用者關係構建，二是內容傳播，微博推薦一直致力於優化...