頭條數(shù)據(jù)聚合優(yōu)化實(shí)踐

1、 頭條數(shù)據(jù)聚合優(yōu)化實(shí)踐CSDN云計算 微信號 CSDNcloud功能介紹 CSDN作為國內(nèi)最專業(yè)的云計算服務(wù)平臺，提供云計算、大數(shù)據(jù)、虛擬化、數(shù)據(jù)中心、OpenStack、CloudStack、Hadoop、Spark、機(jī)器學(xué)習(xí)、智能算法等相關(guān)云計算觀點(diǎn)，云計算技術(shù)，云計算平臺，云計算實(shí)踐，云計算產(chǎn)業(yè)咨詢等服務(wù)。業(yè)務(wù)背景介紹中華萬年歷的頭條數(shù)據(jù)是根據(jù)推薦算法聚合而成的數(shù)據(jù)，包括ALS算法數(shù)據(jù)、用戶畫像數(shù)據(jù)、時效數(shù)據(jù)、非時效數(shù)據(jù)、定投數(shù)據(jù)、驚喜數(shù)據(jù)、頻道數(shù)據(jù)、熱榜數(shù)據(jù)、用戶相關(guān)閱讀推薦數(shù)據(jù)等。啟動方式分為冷啟動和用戶畫像啟動。冷啟動：無用戶畫像或用戶畫像得分8分。用戶畫像：根據(jù)用戶瀏覽頭條數(shù)據(jù)給

2、用戶打的一系列標(biāo)簽，標(biāo)簽采用Long型的數(shù)字進(jìn)行標(biāo)記，譬如娛樂285L,旅游1127L。時效數(shù)據(jù)：和時間相關(guān)的數(shù)據(jù)，會隨著時間的推移自動消失，譬如新聞、娛樂。非時效數(shù)據(jù)：和時間不相關(guān)的數(shù)據(jù)，會長期存在，譬如養(yǎng)生。定投數(shù)據(jù)：通過管理后臺手動投放的數(shù)據(jù)，一般為固定位置數(shù)據(jù)，如廣告、帖子。驚喜數(shù)據(jù)：排除畫像之外的數(shù)據(jù)。頻道數(shù)據(jù)：多個標(biāo)簽下的數(shù)據(jù)組合而成的數(shù)據(jù)。頻道是標(biāo)簽的父類，一個頻道對應(yīng)包涵多個標(biāo)簽，標(biāo)簽是用戶畫像組成的基本單位。熱榜數(shù)據(jù)：根據(jù)用戶點(diǎn)擊實(shí)時上傳的日志計算得分較高的數(shù)據(jù)。用戶相關(guān)閱讀推薦數(shù)據(jù)：根據(jù)用戶點(diǎn)擊實(shí)時上傳的日志計算相關(guān)聯(lián)的數(shù)據(jù)。數(shù)據(jù)存儲頭條的數(shù)據(jù)都是從合作方抓取的，通過定時調(diào)

3、用第三方API進(jìn)行抓取。抓取的數(shù)據(jù)經(jīng)過頻道標(biāo)簽分類后存儲到mysql數(shù)據(jù)庫。頭條服務(wù)會每隔一段時間把數(shù)據(jù)庫里面的數(shù)據(jù)reload到redis中，然后再從redis中reload到本地內(nèi)存中。數(shù)據(jù)的聚合就是把內(nèi)存中的數(shù)據(jù)按照算法進(jìn)行組裝。為什么要經(jīng)過兩次的數(shù)據(jù)reload，因?yàn)槲覀兊慕涌诜?wù)是支持水平擴(kuò)展的，如果單一的從數(shù)據(jù)庫reload的話，數(shù)據(jù)庫的連接壓力會隨著服務(wù)節(jié)點(diǎn)的增加而增大，數(shù)據(jù)加載不一致的機(jī)率會也會增加。使用redis進(jìn)行中間過渡可以把數(shù)據(jù)庫的壓力分擔(dān)到redis，畢竟redis的并發(fā)能力高于mysql，訪問速度也高于mysql。數(shù)據(jù)reload到本地內(nèi)存會經(jīng)過篩選分類，即每種數(shù)據(jù)

4、在內(nèi)存中都會有對應(yīng)的一個數(shù)據(jù)池，這些數(shù)據(jù)池是通過reload循環(huán)迭代分進(jìn)去的。數(shù)據(jù)池分為：新池子：存放新抓取的非實(shí)效數(shù)據(jù)，數(shù)據(jù)結(jié)構(gòu)為Set老池子：存放有點(diǎn)擊率、pv的數(shù)據(jù)，數(shù)據(jù)結(jié)構(gòu)為List視頻池子：存放所有的視頻數(shù)據(jù)，數(shù)據(jù)池結(jié)構(gòu)為List非實(shí)效標(biāo)簽池子：存放標(biāo)簽對應(yīng)的非實(shí)效條目id,數(shù)據(jù)結(jié)構(gòu)為Multimap早期數(shù)據(jù)更新方式數(shù)據(jù)更新主要存在兩個地方的更新：redis和local。對新抓取的數(shù)據(jù)在api服務(wù)接口中采用spring quartz每隔一段時間從redis中讀取一次然后同步到local。redis中的數(shù)據(jù)則是通過一個單獨(dú)的bg模塊，同樣采用spring quartz定時任務(wù)每隔一段時

5、間從mysql中讀取，然后同步到redis中。除了新抓取的數(shù)據(jù)外，在每個api服務(wù)中還有每秒更新pv、click的定時任務(wù)。由于我們抓取的數(shù)據(jù)分為自動上架和手動上架，手動上架需要運(yùn)營人員審核通過后才能在客戶端展示,對自動上架不符合要求的數(shù)據(jù)也需要做下架處理，按照上面的更新方式顯然不能立即生效。值得思考的問題：api節(jié)點(diǎn)較多怎么保證每個本地內(nèi)存中的數(shù)據(jù)是否一致能否有針對性的更新，不用每次都reload所有數(shù)據(jù)能否分離api中的定時任務(wù)到bg模塊能否及時響應(yīng)數(shù)據(jù)變化自動更新遇到的問題數(shù)據(jù)更新丟失。bg在更新redis數(shù)據(jù)時是先添加原數(shù)據(jù)然后再建立索引，原數(shù)據(jù)采用String數(shù)據(jù)結(jié)構(gòu)，bean的ID

6、作為key，序列化的對象作為value。索引采用Set數(shù)據(jù)結(jié)構(gòu)，value存放的是bean的id。每次更新數(shù)據(jù)時會刪除索引然后重新創(chuàng)建。如果頭條接口服務(wù)正在reload數(shù)據(jù)的時候發(fā)生bg更新任務(wù)則會導(dǎo)致reload到local中的數(shù)據(jù)丟失。reload時間過長。頭條服務(wù)在啟動的時候不會立即初始化數(shù)據(jù)，而是通過用戶觸發(fā)，異步的完成加載。為了避免大量用戶并發(fā)reload操作采用Cache對操作進(jìn)行緩存，設(shè)置緩存時間的大小。值得注意的是如果緩存設(shè)置的時間小于加載的時間則同樣會造成并發(fā)的reload。占用內(nèi)存較大,耗費(fèi)CPU。隨著抓取的數(shù)據(jù)越來越多，非實(shí)效的數(shù)據(jù)也越積越多，最終導(dǎo)致內(nèi)存中的數(shù)據(jù)越來越大

7、，從redis中讀取數(shù)據(jù)進(jìn)行反序列化需要耗費(fèi)大量的cpu。雖然限制讀取數(shù)據(jù)的條數(shù)可以避免這個問題，但是數(shù)據(jù)是糅合在一起的，被限制的一部分?jǐn)?shù)據(jù)可能是對用戶最有價值的數(shù)據(jù)。業(yè)務(wù)數(shù)據(jù)分離由于數(shù)據(jù)種類較多，數(shù)據(jù)量較大，每次變更一條數(shù)據(jù)重新reload全部數(shù)據(jù)會導(dǎo)致內(nèi)存和CPU迅速上升，尤其是全局的臨時變量替換、json的反序列化。這樣做不僅重復(fù)加載，而且還會因?yàn)槠渌鼣?shù)據(jù)加載的失敗而影響到所需要的數(shù)據(jù)，沒有做到有針對性的更新。尤其在定投廣告數(shù)據(jù)時，廣告需要很長時間才能出現(xiàn)，或是因?yàn)闆]有加載進(jìn)來不出現(xiàn)，這樣就直接影響到了收入，肯定是不允許的。為了減少更新的數(shù)據(jù)量，把數(shù)據(jù)按照業(yè)務(wù)進(jìn)行分離，每次更新一條數(shù)據(jù)只

8、reload對應(yīng)的數(shù)據(jù)種類。更細(xì)粒度的數(shù)據(jù)更新可以針對到某一條。由于本系統(tǒng)數(shù)據(jù)已經(jīng)按業(yè)務(wù)進(jìn)行了拆分，數(shù)據(jù)量在合理的范圍內(nèi)，做整體替換實(shí)現(xiàn)更加簡單。業(yè)務(wù)數(shù)據(jù)分離是為了保證最小的數(shù)據(jù)變動，我們按照業(yè)務(wù)需求把一條sql拆分了多條sql，每條sql完成對應(yīng)的數(shù)據(jù)加載，同樣內(nèi)存中的數(shù)據(jù)也做了細(xì)化。內(nèi)存中的數(shù)據(jù)和redis中的數(shù)據(jù)同步是通過redis的訂閱發(fā)布實(shí)現(xiàn)的。整體結(jié)構(gòu)如圖：推薦數(shù)據(jù)遷移到Redis雖然數(shù)據(jù)分離解決了一部分reload的問題，但推薦數(shù)據(jù)是個大的數(shù)據(jù)塊，需要把所有非實(shí)效的數(shù)據(jù)都加載進(jìn)來，內(nèi)存壓力很大。當(dāng)初把數(shù)據(jù)緩存在本地是為了提高客戶端的訪問效率，但當(dāng)數(shù)據(jù)增加到一定程度時，每次進(jìn)行數(shù)據(jù)

9、替換都會產(chǎn)生占用內(nèi)存較大的臨時變量，老的變量會被java虛擬機(jī)自動回收，所以在數(shù)據(jù)reload的過程中g(shù)c會變得更加頻繁。分析解決辦法：1、增加機(jī)器內(nèi)存無疑需要增加成本；2、使用增量更新，即針對變化的數(shù)據(jù)直接在內(nèi)存中進(jìn)行修改，不做整體的reload替換，但這樣做又引出了新的問題，怎樣保證每個節(jié)點(diǎn)的數(shù)據(jù)是否一致，更新失敗怎么處理，怎么做到數(shù)據(jù)有效的監(jiān)控；3、把數(shù)據(jù)遷移到redis。如果按照方法2去實(shí)現(xiàn)的話等于是又要造一個redis，所以最終采用了把數(shù)據(jù)遷移到redis的方式。數(shù)據(jù)存儲主要分為基礎(chǔ)數(shù)據(jù)和索引數(shù)據(jù)，索引數(shù)據(jù)是有序的id Set集合，索引按照推薦策略進(jìn)行了分類，如新聞、頻道、曝光、ct

10、r等，通過調(diào)用大數(shù)據(jù)平臺來更新索引的分類和Set集合元素的score值，用以保證推薦數(shù)據(jù)的準(zhǔn)確性。為了減少redis的連接次數(shù)，每次推薦都會計算出足夠多的數(shù)據(jù)存放到用戶的閱讀緩存中，如果用戶閱讀緩存中的數(shù)據(jù)不夠了會重新觸發(fā)聚合計算。數(shù)據(jù)抓取頭條的數(shù)據(jù)來源是API接口抓?。ń?jīng)過授權(quán)），之前的方式都是針對每一種數(shù)據(jù)源在bg模塊中進(jìn)行單獨(dú)開發(fā)，然后在xml中配置quartz定時運(yùn)行任務(wù),沒有做到數(shù)據(jù)監(jiān)控和可視化管理。如果要停止或修改某一個數(shù)數(shù)據(jù)源的抓取任務(wù)必須停止整個bg服務(wù)然后再修改代碼或quartz配置文件。修改后的數(shù)據(jù)抓取框架：獨(dú)立出一個專門的數(shù)據(jù)抓項(xiàng)目ulike，通過后臺管理，實(shí)現(xiàn)任務(wù)的可配置化。Mgr 后臺管理，管理數(shù)據(jù)源配置和任務(wù)配置,查看抓取的數(shù)據(jù)以及監(jiān)控信息。Mysql 存儲Mgr的管理信息Scheduler 負(fù)責(zé)任務(wù)調(diào)度Redis 調(diào)度通過redis發(fā)布訂閱傳給Processor命令，對任務(wù)進(jìn)行操作。Proc