一、背景

　　在視頻推薦場(chǎng)景中，一方面我們需要讓新啟用的視頻盡可能快的觸達(dá)用戶，這一點(diǎn)對(duì)于新聞?lì)惖膬?nèi)容尤為關(guān)鍵；另一方面我們需要快速識(shí)別新物品的好壞，通過(guò)分發(fā)的流量，以及對(duì)應(yīng)的后驗(yàn)數(shù)據(jù)，來(lái)判斷新物品是否值得繼續(xù)分發(fā)流量。

　　而這兩點(diǎn)對(duì)于索引先驗(yàn)數(shù)據(jù)和后驗(yàn)數(shù)據(jù)的延遲都有很高的要求。下文將為大家介紹看點(diǎn)視頻推薦的索引構(gòu)建方案，希望和大家一同交流。文章作者：紀(jì)文忠，騰訊QQ端推薦研發(fā)工程師。

　　注：這里我們把視頻創(chuàng)建時(shí)就帶有的數(shù)據(jù)稱為先驗(yàn)數(shù)據(jù)，如tag，作者賬號(hào)id等，而把用戶行為反饋的數(shù)據(jù)稱為后驗(yàn)數(shù)據(jù)，如曝光、點(diǎn)擊、播放等。

　　二、看點(diǎn)視頻推薦整體架構(gòu)

　　從數(shù)據(jù)鏈路來(lái)看此架構(gòu)圖，從下往上來(lái)看，首先視頻內(nèi)容由內(nèi)容中心通過(guò)消息隊(duì)列給到我們，經(jīng)過(guò)一定的處理入庫(kù)、建索引、生成正排/倒排數(shù)據(jù)，這時(shí)候在存儲(chǔ)層可召回的內(nèi)容約有1千萬(wàn)條。

　　然后經(jīng)過(guò)召回層，通過(guò)用戶畫像、點(diǎn)擊歷史等特征召回出數(shù)千條視頻，給到粗排層；粗排將這數(shù)千條視頻打分，取數(shù)百條給到精排層；精排再一次打分，給到重排；重排根據(jù)一定規(guī)則和策略進(jìn)行打散和干預(yù)，最終取10+條給到用戶；

　　視頻在用戶側(cè)曝光后，從上之下，是另一條數(shù)據(jù)鏈路：用戶對(duì)視頻的行為，如曝光、點(diǎn)擊、播放、點(diǎn)贊、評(píng)論等經(jīng)過(guò)上報(bào)至日志服務(wù)，然后通過(guò)實(shí)時(shí)/離線處理產(chǎn)生特征回到存儲(chǔ)層，由此形成一個(gè)循環(huán)。

　　基于此架構(gòu)，我們需要設(shè)計(jì)一套召回/倒排索引，能夠以實(shí)時(shí)/近實(shí)時(shí)的延遲來(lái)處理所有數(shù)據(jù)。

　　三、方案設(shè)計(jì)

　　在舊方案中，索引是每半小時(shí)定時(shí)構(gòu)建的，無(wú)法滿足近實(shí)時(shí)的要求。在分析這個(gè)索引構(gòu)建的方案時(shí)，我們遇到的主要挑戰(zhàn)有：

　　數(shù)據(jù)雖不要求強(qiáng)一致性，但需要保證最終一致性；

　　后驗(yàn)數(shù)據(jù)寫入量極大，看點(diǎn)用戶行為每日達(dá)到百億+；

　　召回系統(tǒng)要求高并發(fā)、低延遲、高可用。

　　1. 業(yè)界主流方案調(diào)研

　　通過(guò)對(duì)比業(yè)界主流方案，我們可以看到，基于Redis的方案靈活性較差，直接使用比較困難，需要進(jìn)行較多定制化開發(fā)，可以首先排除。

　　因此我們可選擇的方案主要在自研或者選擇開源成熟方案。經(jīng)過(guò)研究，我們發(fā)現(xiàn)如果自研索引開發(fā)成本較高，而簡(jiǎn)單的自研方案可能無(wú)法滿足業(yè)務(wù)需求，完善的自研索引方案所需要的開發(fā)成本往往較高，往往需要多人的團(tuán)隊(duì)來(lái)開發(fā)維護(hù)，最終我們選擇了基于ES的索引服務(wù)。

　　至于為什么選擇基于ES，而不是選擇基于Solr，主要是因?yàn)镋S有更成熟的社區(qū)，以及有騰訊云PaaS服務(wù)支持，使用起來(lái)更加靈活方便。

　　2. 數(shù)據(jù)鏈路圖

　　（1）方案介紹

　　如下圖所示：

　　這個(gè)方案從數(shù)據(jù)鏈路上分為兩大塊。

　　第一塊，先驗(yàn)數(shù)據(jù)鏈路，就是上半部分，我們的數(shù)據(jù)源主要來(lái)自內(nèi)容中心，通過(guò)解析服務(wù)寫入到CDB中。其中這個(gè)鏈路又分為全量鏈路和增量鏈路。

　　全量鏈路主要是在重建索引時(shí)才需要的，觸發(fā)次數(shù)少但也重要。它從DB這里dump數(shù)據(jù)，寫入kafka，然后通過(guò)寫入服務(wù)寫入ES。

　　增量鏈路是確保其實(shí)時(shí)性的鏈路，通過(guò)監(jiān)聽binlog，發(fā)送消息至kafka，寫入服務(wù)消費(fèi)kafka然后寫入ES。

　　第二塊，是后驗(yàn)數(shù)據(jù)鏈路?？袋c(diǎn)的用戶行為流水每天有上百億，這個(gè)量級(jí)直接打入ES是絕對(duì)扛不住的。所以我們需要對(duì)此進(jìn)行聚合計(jì)算。

　　這里使用Flink做了1分鐘滾動(dòng)窗口的聚合，然后把結(jié)果輸出到寫模塊，得到1分鐘增量的后驗(yàn)數(shù)據(jù)。在這里，Redis存儲(chǔ)近7天的后驗(yàn)數(shù)據(jù)，寫模塊消費(fèi)到增量數(shù)據(jù)后，需要讀出當(dāng)天的數(shù)據(jù)，并于增量數(shù)據(jù)累加后寫回Redis，并發(fā)送對(duì)應(yīng)的rowkey和后驗(yàn)數(shù)據(jù)消息給到Kafka，再經(jīng)由ES寫入服務(wù)消費(fèi)、寫入ES索引。

　　（2）一致性問(wèn)題分析

　　這個(gè)數(shù)據(jù)鏈路存在3個(gè)一致性問(wèn)題需要小心處理：

　　第一，Redis寫模塊這里，需要先讀出數(shù)據(jù)，累加之后再寫入。先讀后寫，需要保證原子性，而這里可能存在同時(shí)有其他線程在同一時(shí)間寫入，造成數(shù)據(jù)不一致。

　　解決方案1是通過(guò)redis加鎖來(lái)完成；解決方案2如下圖所示，在kafka隊(duì)列中，使用rowkey作為分區(qū)key，確保同一rowkey分配至同一分區(qū)，而同一只能由同一消費(fèi)者消費(fèi)，也就是同一rowkey由一個(gè)進(jìn)程處理，再接著以rowkey作為分線程key，使用hash算法分線程，這樣同一rowkey就在同一線程內(nèi)處理，因此解決了此處的一致性問(wèn)題。另外，通過(guò)這種方案，同一流內(nèi)的一致性問(wèn)題都可以解決。

　　第二，還是Redis寫模塊這里，我們知道Redis寫入是需要先消費(fèi)kafka的消息的，那么這里就要求kafka消息commit和redis寫入需要在一個(gè)事務(wù)內(nèi)完成，或者說(shuō)需要保證原子性。

　　如果這里先commit再進(jìn)行redis寫入，那么如果系統(tǒng)在commit完且寫入redis前宕機(jī)了，那么這條消息將丟失掉；如果先寫入，在commit，那么這里就可能會(huì)重復(fù)消費(fèi)。

　　如何解決這個(gè)一致性問(wèn)題呢？我們通過(guò)先寫入redis，并且寫入的信息里帶上時(shí)間戳作為版本號(hào)，然后再commit消息；寫入前會(huì)比較消息版本號(hào)和redis的版本號(hào)，若小于，則直接丟棄；這樣這個(gè)問(wèn)題也解決了。

　　第三，我們觀察到寫入ES有3個(gè)獨(dú)立的進(jìn)程寫入，不同流寫入同一個(gè)索引也會(huì)引入一致性問(wèn)題。這里我們可以分析出，主要是先驗(yàn)數(shù)據(jù)的寫入可能會(huì)存在一致性問(wèn)題，因?yàn)楹篁?yàn)數(shù)據(jù)寫入的是不同字段，而且只有update操作，不會(huì)刪除或者插入。

　　舉一個(gè)例子，上游的MySQL這里刪除一條數(shù)據(jù)，全量鏈路和增量鏈路同時(shí)執(zhí)行，而剛好全量Dump時(shí)剛好取到這條數(shù)據(jù)，隨后binlog寫入delete記錄，那么ES寫入模塊分別會(huì)消費(fèi)到插入和寫入兩條消息，而他自己無(wú)法區(qū)分先后順序，最終可能導(dǎo)致先刪除后插入，而DB里這條消息是已刪除的，這就造成了不一致。

　　那么這里如何解決該問(wèn)題呢？其實(shí)分析到問(wèn)題之后就比較好辦，常用的辦法就是利用Kfaka的回溯能力：在Dump全量數(shù)據(jù)前記錄下當(dāng)前時(shí)間戳t1，Dump完成之后，將增量鏈路回溯至t1即可。而這段可能不一致的時(shí)間窗口，也就是1分鐘左右，業(yè)務(wù)上是完全可以忍受的。

　　線上0停機(jī)高可用的在線索引升級(jí)流程如下圖所示：

　　（3）寫入平滑

　　由于Flink聚合后的數(shù)據(jù)有很大的毛刺，導(dǎo)入寫入ES時(shí)服務(wù)不穩(wěn)定，cpu和rt都有較大毛刺，寫入情況如下圖所示:

　　此處監(jiān)控間隔是10秒，可以看到，由于聚合窗口是1min，每分鐘前10秒寫入達(dá)到峰值，后面逐漸減少，然后新的一分鐘開始時(shí)又周期性重復(fù)這種情況。

　　對(duì)此我們需要研究出合適的平滑寫入方案，這里直接使用固定閾值來(lái)平滑寫入不合適，因?yàn)闃I(yè)務(wù)不同時(shí)間寫入量不同，無(wú)法給出固定閾值。

　　最終我們使用以下方案來(lái)平滑寫入：

　　我們使用自適應(yīng)的限流器來(lái)平滑寫，通過(guò)統(tǒng)計(jì)前1分鐘接收的消息總量，來(lái)計(jì)算當(dāng)前每秒可發(fā)送的消息總量。具體實(shí)現(xiàn)如下圖所示，將該模塊拆分為讀線程和寫線程，讀線程統(tǒng)計(jì)接收消息數(shù)，并把消息存入隊(duì)列；令牌桶數(shù)據(jù)每秒更新；寫線程獲取令牌桶，獲取不到則等待，獲取到了就寫入。最終我們平滑寫入后的效果如圖所示：

　　在不同時(shí)間段，均能達(dá)到平滑的效果。

　　四、召回性能調(diào)優(yōu)

　　1. 高并發(fā)場(chǎng)景優(yōu)化

　　由于存在多路召回，所以召回系統(tǒng)有讀放大的問(wèn)題，我們ES相關(guān)的召回，總qps是50W。這么大的請(qǐng)求量如果直接打入ES，一定是扛不住的，那么如何來(lái)進(jìn)行優(yōu)化呢？

　　由于大量請(qǐng)求的參數(shù)是相同的，并且存在大量的熱門key，因此我們引入了多級(jí)緩存來(lái)提高召回的吞吐量和延遲時(shí)間。

　　我們多級(jí)緩存方案如下圖所示：

　　這個(gè)方案架構(gòu)清晰，簡(jiǎn)單明了，整個(gè)鏈路: 本地緩存(BigCache)<->分布式緩存(Redis)<->ES。

　　經(jīng)過(guò)計(jì)算，整體緩存命中率為95+%，其中本地緩存命中率75+%，分布式緩存命中率20%，打入ES的請(qǐng)求量大約為5%。這就大大提高了召回的吞吐量并降低了RT。

　　該方案還考慮緩了存穿透和雪崩的問(wèn)題，在線上上線之后，不久就發(fā)生了一次雪崩，ES全部請(qǐng)求失敗，并且緩存全部未命中。起初我們還在分析，究竟是緩存失效導(dǎo)致ES失敗，還是ES失敗導(dǎo)致設(shè)置請(qǐng)求失效，實(shí)際上這就是經(jīng)典的緩存雪崩的問(wèn)題。

　　我們分析一下，這個(gè)方案解決了4點(diǎn)問(wèn)題：

　　本地緩存定時(shí)dump到磁盤中，服務(wù)重啟時(shí)將磁盤中的緩存文件加載至本地緩存。

　　巧妙設(shè)計(jì)緩存Value，包含請(qǐng)求結(jié)果和過(guò)期時(shí)間，由業(yè)務(wù)自行判斷是否過(guò)期；當(dāng)下游請(qǐng)求失敗時(shí)，直接延長(zhǎng)過(guò)期時(shí)間，并將老結(jié)果返回上游。

　　熱點(diǎn)key失效后，請(qǐng)求下游資源前進(jìn)行加鎖，限制單key并發(fā)請(qǐng)求量，保護(hù)下游不會(huì)被瞬間流量打崩。

　　最后使用限流器兜底，如果系統(tǒng)整體超時(shí)或者失敗率增加，會(huì)觸發(fā)限流器限制總請(qǐng)求量。

　　2. ES性能調(diào)優(yōu)

　　（1）設(shè)置合理的primary_shards

　　primary_shards即主分片數(shù)，是ES索引拆分的分片數(shù)，對(duì)應(yīng)底層Lucene的索引數(shù)。這個(gè)值越大，單請(qǐng)求的并發(fā)度就越高，但給到上層MergeResult的數(shù)量也會(huì)增加，因此這個(gè)數(shù)字不是越大越好。

　　根據(jù)我們的經(jīng)驗(yàn)結(jié)合官方建議，通常單個(gè)shard為1~50G比較合理，由于整個(gè)索引大小10G，我們計(jì)算出合理取值范圍為1~10個(gè)，接下里我們通過(guò)壓測(cè)來(lái)取最合適業(yè)務(wù)的值。壓測(cè)結(jié)果如下圖所示：

　　根據(jù)壓測(cè)數(shù)據(jù)，我們選擇6作為主分片數(shù)，此時(shí)es的平均rt13ms，99分位的rt為39ms。

　　（2）請(qǐng)求結(jié)果過(guò)濾不需要的字段

　　ES返回結(jié)果都是json，而且默認(rèn)會(huì)帶上source和_id,_version等字段，我們把不必要的正排字段過(guò)濾掉，再使用filter_path把其他不需要的字段過(guò)濾掉，這樣總共能減少80%的包大小，過(guò)濾結(jié)果如下圖所示：

　　包大小由26k減小到5k，帶來(lái)的收益是提升了30%的吞吐性能和降低3ms左右的rt。

　　（3）設(shè)置合理routing字段

　　ES支持使用routing字段來(lái)對(duì)索引進(jìn)行路由，即在建立索引時(shí)，可以將制定字段作為路由依據(jù)，通過(guò)哈希算法直接算出其對(duì)應(yīng)的分片位置。

　　這樣查詢時(shí)也可以根據(jù)指定字段來(lái)路由，到指定的分片查詢而不需要到所有分片查詢。根據(jù)業(yè)務(wù)特點(diǎn)，我們將作者賬號(hào)id puin 作為路由字段，路由過(guò)程如下圖所示：

　　這樣一來(lái)，我們對(duì)帶有作者賬號(hào)id的召回的查詢吞吐量可以提高6倍，整體來(lái)看，給ES帶來(lái)了30%的吞吐性能提升。

　　（4）關(guān)閉不需要索引或排序的字段

　　通過(guò)索引模板，我們將可以將不需要索引的字段指定為"index":false，將不需要排序的字段指定為"doc_values":false。這里經(jīng)測(cè)試，給ES整體帶來(lái)了10%左右的吞吐性能提升。

　　五、結(jié)語(yǔ)

　　本文介紹了看點(diǎn)視頻推薦索引的構(gòu)建方案，服務(wù)于看點(diǎn)視頻的CB類型召回。其特點(diǎn)是，開發(fā)成本低，使用靈活方便，功能豐富，性能較高，符合線上要求。

　　上線以來(lái)服務(wù)于關(guān)注召回、冷啟動(dòng)召回、tag畫像召回、賬號(hào)畫像召回等許多路召回，為看點(diǎn)視頻帶來(lái)較大業(yè)務(wù)增長(zhǎng)。未來(lái)隨著業(yè)務(wù)進(jìn)一步增長(zhǎng)，我們會(huì)進(jìn)一步優(yōu)化該方案，目前來(lái)看，該技術(shù)方案還領(lǐng)先于業(yè)務(wù)一段時(shí)間。最后歡迎各位同學(xué)交流，歡迎在評(píng)論區(qū)留言。

北京愛品特SEO網(wǎng)站優(yōu)化提供專業(yè)的網(wǎng)站SEO診斷服務(wù)、SEO顧問(wèn)服務(wù)、SEO外包服務(wù)，咨詢電話或微信：13811777897 袁先生 可免費(fèi)獲取SEO網(wǎng)站診斷報(bào)告。

北京網(wǎng)站優(yōu)化公司 >> SEO資訊 >> SEO技術(shù)技巧 >> 騰訊看點(diǎn)視頻推薦索引構(gòu)建方案    本站部分內(nèi)容來(lái)源于互聯(lián)網(wǎng)，如有版權(quán)糾紛或者違規(guī)問(wèn)題，請(qǐng)聯(lián)系我們刪除，謝謝！