分享嘉賓：Elvin 騰訊音樂 高級工程師

導讀：近幾年來，圖數據在計算機領域得到了廣泛的應用。互聯網數據量指數級增長，大數據技術、圖數據方面的應用增長很快，各家互聯網大廠都在圖數據分析和應用方面大量投入。為了讓我們的搜索更加智能化，騰訊音樂也借助了知識圖譜。今天和大家分享下騰訊音樂在圖譜檢索與業務實踐方面的探索，主要包括以下幾大部分：

音樂知識圖譜介紹

圖數據庫選型

項目架構介紹

知識圖譜搜索功能應用舉例

總結與展望

01音樂知識圖譜介紹

首先和大家介紹下音樂知識圖譜的相關知識。

1. 音樂數據分類

圖狀數據廣泛存在，其中與音樂相關的業務數據主要有以下三類：

內容方面有歌曲、綜藝、影視、專輯等；

歌手方面有歌手信息、歌手之間的關系，包括組合、相似等；

歌手和歌手內容之間的關系有演唱、作詞、作曲等。

2. 音樂知識圖譜的應用場景

(1) 復雜搜索需求實現

音樂知識圖譜不僅可以做簡單的搜索，還可以實現復雜搜索需求。例如要查詢周杰倫的男女對唱的歌曲有哪些，如果要實現這個查詢，需要對周杰倫的歌曲進行一定的過濾，歌手的數量要等于2，另一位歌手的性別是女性，還要考慮基于播放量、歌手權重等等的排序。在傳統關系型數據要實現這個功能很復雜。利用知識圖譜就比較簡單了，先找到歌手周杰倫，查找周杰倫的所有歌曲中滿足2人合唱，另一個歌手性別是女性的，只要兩跳就可以實現復雜的搜索查詢。

(2) 搜索結果的相關推薦

可以根據搜索的關鍵詞，查詢圖譜中的實體節點，根據實體節點查詢出關聯的節點，用關聯的節點給出推薦的結果。例如用戶搜索周華健，可以通過關聯信息推薦出李宗盛。如果通過搜索引擎，很難推薦出李宗盛，而用知識圖譜，只要兩跳，周華健歌手到對應組合（縱貫線），從組合再到另一歌手李宗盛，只要兩跳。

(3) 基于知識計算給出答案

可以根據知識圖譜的計算來給出一些答案，通過圖譜的關聯信息，實體上下位信息，實體屬性信息，查詢出相應的答案。例如用戶搜索劉德華90年年代的歌曲，用知識圖譜的話，只要歌手劉德華，時間90年代歌曲，兩個聯合起來就可以得到結果。

3. 搜索召回和知識圖譜召回優缺點

搜索召回，是基于文本匹配的，召回之后會涉及相關性排序，相對來說比較復雜，精準度不足，可能過度召回。搜索召回的流程比較復雜，排序策略也相對復雜。

知識圖譜召回，是基于實體之間的關系進行查詢，可以做到精準召回，也沒有過召回，召回的流程可以很短，也就是幾條圖查詢的語句。另外，知識圖譜還具備一定的推理能力。

02圖數據庫選型

要實現圖查詢，首先得做圖數據庫的選型。

圖數據庫的選型，需要考慮以下幾點因素：

開源非付費，考慮到成本及源碼可控性，選擇擁抱開源；

分布式框架可擴展，隨著數據的增加和減少，后臺必須是可擴展的；

高性能毫秒級多跳查詢，要做到毫秒級的在線響應；

支持千億級規模數據量；

支持數據批量導入導出。

我們對比了8個數據庫，對優缺點進行了分析，對這些數據庫進行了分類：

第一類，以Neo4j為代表的，只有單機版本，性能比較優秀，但是不滿足分布式可擴展性要求。Neo4j的商業版本支持分布式，但是卻是收費的。

第二類，JanusGraph、HugeGraph這類數據庫，支持分布式可擴展的，他們的共同特點是在現有的圖譜上增加了通用的圖語義解釋層，受到存儲層架構的限制，存儲層是外部數據庫實現，不支持計算下推的功能，導致性能較差。

第三類，以NebulaGraph為代表，這一類數據庫都實現了自己的存儲層，支持計算下推，做了效率上的優化，性能提升很多。

從上圖看到綜合性能測試數據。我們通過1度鄰居（跟點直接相連的點），2度鄰居，共同鄰居，這三個方面來對數據庫性能進行測試，可以看到Nebula不管是單機性能，還是集群性能，都要遠超于其他競品。考慮到性能，社區活躍度，版本迭代速度，語言上的通用性，我們最終選擇了Nebula數據庫做為我們項目的圖數據庫。

03項目架構介紹

1.?在線層

包含以下模塊：

Storaged負責具體數據的存儲，包括點數據、邊數據，以及相關的索引；

Metad負責存儲圖數據的meta信息，例如數據庫的schema、addition等；

Nebula graphd負責數據計算的邏輯層，是無狀態的，可以進行平行擴展，內部執行計算引擎來完成查詢的整個過程。

Nebula proxy是我們新增的模塊，作為整個nebula模塊的代理層，可以接受外部的命令，并對圖數據進行操作，包括圖的查詢，更新，刪除。另外，nebula proxy也負責協議的轉換，集群的心跳和路由注冊。

由于單集群有重建數據的需求，也為了防止機房故障，我們選擇雙集群來支撐整個服務的可用性。

在線層請求處理的流程為，cgi在接收到用戶請求后，將用戶請求傳給broker模塊，broker請求模版匹配生成相應的圖查詢語句，從Zookeeper中提取可用的集群，將查詢語句發給nebula proxy進行圖譜召回，nebula proxy將具體的查詢語句傳遞給nebula graphd, nebula graphd負責執行最終的語句，然后把結果返回給broker層，broker層補充一些前端顯示摘要后，將數據返回給前端做展示。

2. 離線層

音樂數據有實時的新增數據，例如新增發行的唱片，還有全量數據的更新，所以我們選擇了全量加增量的數據層方案。

(1) 全量數據生成方案

音樂很多數據存在數據庫中，先將數據從DB中dump出來后，由IndexBuilder模塊將數據格式轉換為所需的格式后形成一個全量的源數據，將全量的源數據上傳到HDFS后，通過運行spark任務，把數據轉為Nebula底層所需的數據文件，IndexMgr發現有新的常量數據生成后，將數據文件下載下來，將全量數據加載到NebulaProxy，這樣全量數據就生成好了。

(2) 實時數據的生成

每隔一段時間，通常是幾分鐘，將幾分鐘之內的業務修改數據dump出來后，轉為特定的格式，形成一個增量的源數據，增量的源數據存入到Kafka里面，可以用于數據的重發和恢復，DataSender從Kafka隊列里面拉取到最新的數據，通過NebulaProxy發送到集群，這樣增量數據就生效了。

這里涉及到了一個增量補發的問題，因為存量過程dump過程中要耗費很長時間，可能要花幾個小時，在全量數據dump過程中也有新的增量數據，這期間的增量數據可能并沒有進入到全量的數據當中。所以這里需要進行一個歷史增量的補發，從T0后（全量同步開始時間）的新增數據，不在全量數據中，需要將T0之后的數據全部進行補發。

04知識圖譜搜索功能應用舉例

1. 配置化召回

常規召回方式為：根據Query生成查詢語句，獲取召回結果，根據策略混排，召回結果展示。

這樣做的問題是，每做一次，每增加一種新的召回策略，以上四步都要重復，所以召回不夠靈活，業務改動大。

我們增加了一種新的基于Query模板的召回方式，就是根據模板生成對應的查詢語句，同時預先設置了一些常用的混排策略。比如我們配置一個學校加校歌的模板，當查詢校歌的時候，我們把學校的名字提取出來，填到查詢語句里面，形成一個完整的圖查詢語句。同時也預置了一些混排插入策略，填入對應的混排參數，就可以做到上線。這樣做的優點就是召回比較靈活，和搜索相比，召回上線的代價比較小。

2. 業務應用

我們最終上線了上圖這些業務，支持各類搜索場景。

校歌搜索：當用戶搜索大學校名和校歌組合時，召回對應的學校的校歌；

歌手場景：當用戶搜索歌手名字的時候，返回歌手所在組合，以及合唱過知名歌曲的合作歌手等；

影視場景：當用戶搜索影視主題曲、片尾曲、插曲等等的時候，返回對應的影視的歌曲。

05總結與展望

今天的討論從圖數據的選型開始，到schema分類定義，項目架構層設計，再到知識圖譜的搜索。結論是采用圖數據，可以很好的把專家經驗智能融入圖譜。通過圖數據技術實現的知識庫，增強了檢索、推薦、可視化等功能，騰訊音樂很好的對知識圖譜技術進行了應用，大大提高了客戶的搜索體驗感，增強了客戶黏度。讓我們擁抱AI技術，讓其更好地服務于生活。

06精彩問答

Q：在搜索過程中有考慮音頻信息嗎？

A：這個是有考慮的，我們可以通過音頻識別技術，首先去識別歌曲的一個大的分類流派，比如說像民謠搖滾流行這些流派，然后在線檢索的時候，我們會通過這種語音搜索去召回。另外，我們跟QQ音樂天津實驗室也有合作，比如像聽目前的金科視曲，后臺走的也是走我們的限量搜索，也是通過對音頻信息進行的召回。

Q：語義檢索結果排在第幾位？是怎么和關鍵詞檢索一起排序的？

A：首先我們會通過算法去挖掘某一個語義標簽跟某一首歌曲的相似度，語意搜索的話就可以通過語音標簽進行召回，優先把語義相似度高的結果排到前面。當然也會有一些奇異的情況，比如說像趙雷有一首歌叫民謠，民謠這首歌就是一個歌曲，它同時也是一個語義，我們排序的時候也會兼顧這種混排的效果，最下層排序，首先會把民謠的歌曲放在前面，因為它畢竟是一個比較知名歌手的歌曲，下面會把對應的語義的結構放在后面，然后我們在更上層會有基于算法的排序模型去給用戶推薦點擊量高的調前。

Q：全量索引版本切換雙buffer內存是否會翻倍？

A：實際上我們索引切換的過程中是沒有雙buffer的，是按每一個分片下的每一個副本進行逐個切換，切換的時候會進行動態的卸載，所以并沒有占用額外的內存。

Q：跨越截斷，是在index截斷好，還是在線選擇截斷？

A：是在線選擇截斷，如果離線截斷會導致數據丟失，這樣是沒辦法回溯的。截斷也是分片的，向量檢索也是可以分片之后，做并行檢索。

今天的分享就到這里，謝謝大家。