一、背景

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

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

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

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

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

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

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

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

　　三、方案設(shè)計

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

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

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

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

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

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

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

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

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

　　（1）方案介紹

　　如下圖所示：

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

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

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

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

　　第二塊，是后驗數(shù)據(jù)鏈路。看點的用戶行為流水每天有上百億，這個量級直接打入ES是絕對扛不住的。所以我們需要對此進行聚合計算。

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

　　（2）一致性問題分析

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

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

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

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

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

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

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

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

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

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

　　（3）寫入平滑

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

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

　　對此我們需要研究出合適的平滑寫入方案，這里直接使用固定閾值來平滑寫入不合適，因為業(yè)務(wù)不同時間寫入量不同，無法給出固定閾值。

　　最終我們使用以下方案來平滑寫入：

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

　　在不同時間段，均能達到平滑的效果。

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

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

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

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

　　我們多級緩存方案如下圖所示：

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

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

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

　　我們分析一下，這個方案解決了4點問題：

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

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

　　熱點key失效后，請求下游資源前進行加鎖，限制單key并發(fā)請求量，保護下游不會被瞬間流量打崩。

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

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

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

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

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

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

　　（2）請求結(jié)果過濾不需要的字段

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

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

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

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

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

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

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

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

　　五、結(jié)語

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

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

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

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