騰訊音樂知識圖譜搜尋實踐

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

音樂知識圖譜介紹
圖資料庫選型
專案架構介紹
知識圖譜搜尋功能應用舉例
總結與展望

音樂知識圖譜介紹

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

1. 音樂資料分類

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

內容方面有歌曲、綜藝、影視、專輯等；
歌手方面有歌手資訊、歌手之間的關係，包括組合、相似等；
歌手和歌手內容之間的關係有演唱、作詞、作曲等。

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

(1) 複雜搜尋需求實現

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

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

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

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

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

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

搜尋召回，是基於文字匹配的，召回之後會涉及相關性排序，相對來說比較複雜，精準度不足，可能過度召回。搜尋召回的流程比較複雜，排序策略也相對複雜。

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

圖資料庫選型

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

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

開源非付費，考慮到成本及原始碼可控性，選擇擁抱開源；
分散式框架可擴充套件，隨著資料的增加和減少，後臺必須是可擴充套件的；
高效能毫秒級多跳查詢，要做到毫秒級的線上響應；
支援千億級規模資料量；
支援資料批次匯入匯出。

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

第一類，以Neo4j為代表的，只有單機版本，效能比較優秀，但是不滿足分散式可擴充套件性要求。Neo4j的商業版本支援分散式，但是卻是收費的。
第二類，JanusGraph、HugeGraph這類資料庫，支援分散式可擴充套件的，他們的共同特點是在現有的圖譜上增加了通用的圖語義解釋層，受到儲存層架構的限制，儲存層是外部資料庫實現，不支援計算下推的功能，導致效能較差。
第三類，以NebulaGraph為代表，這一類資料庫都實現了自己的儲存層，支援計算下推，做了效率上的最佳化，效能提升很多。

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

專案架構介紹

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之後的資料全部進行補發。

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

1. 配置化召回

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

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

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

2. 業務應用

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

校歌搜尋：當用戶搜尋大學校名和校歌組合時，召回對應的學校的校歌；
歌手場景：當用戶搜尋歌手名字的時候，返回歌手所在組合，以及合唱過知名歌曲的合作歌手等；
影視場景：當用戶搜尋影視主題曲、片尾曲、插曲等等的時候，返回對應的影視的歌曲。

總結與展望

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

精彩問答

Q：在搜尋過程中有考慮音訊資訊嗎？

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

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

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

Q：全量索引版本切換雙buffer記憶體是否會翻倍？

A：實際上我們索引切換的過程中是沒有雙buffer的，是按每一個分片下的每一個副本進行逐個切換，切換的時候會進行動態的解除安裝，所以並沒有佔用額外的記憶體。

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

A：是線上選擇截斷，如果離線截斷會導致資料丟失，這樣是沒辦法回溯的。截斷也是分片的，向量檢索也是可以分片之後，做並行檢索。

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

在文末分享、點贊、在看，給個3連擊唄~

分享嘉賓：