當遊戲上知識圖譜，網易遊戲是如何應對大規模圖資料的管理問題，Nebula Graph 又是如何幫助網易遊戲落地遊戲內複雜的圖的業務呢？在本文，我們來一探究竟。
遊戲中的圖資料
目前網易遊戲大部分的產品都是線上遊戲，作為國際領先的頭部遊戲廠商，網易所吸引的線上玩家數量也是眾多的，那麼大量的玩家登入我們的遊戲勢必產生大量各種操作性資料。
如上圖中間顯示的交易資料——玩家可以購買商城裡的物品，或者直接購買其他玩家的物品；社交資料——加好友、點贊、刷禮物等等，有些遊戲中還會存在婚姻系統。此外，還有常見的對戰系統、發言系統——玩家在頻道內發表自己的見解，或者是整理自己的遊戲經驗變成遊戲攻略。
對遊戲設計和開發人員而言，各個遊戲內的系統都需要保證資源可以在系統內部正常的迴圈和流轉，以保證遊戲生態的平穩執行，我們稱之為系統迴圈。系統設計的話，它會產生系統迴圈圖，交易會產生交易網路，社交會產生社交網路，對戰會產生對戰關係網路，發言會產生 UGC 知識庫，產出攻略則會形成攻略知識庫。
這些豐富多樣的圖資料就是遊戲中無處不在的圖。
簡單來感受下網易遊戲玩家在遊戲中感受到的圖：
上圖是某款遊戲的商品系統，不知道 Nebula 的小夥伴有沒有喜歡收集皮膚，可能你玩的遊戲中會推送一些皮膚禮包，禮包裡會有若干件皮膚，但你想過沒有禮包裡的皮膚是隨機選取的嗎？肯定不是，作為遊戲製作方自然希望把好看的皮膚進行搭配，將不同玩家喜歡的皮膚放在一起推送給玩家。這時候，各個皮膚之間、皮膚與玩家之間便會產生聯絡。像上圖右邊的例子，玩家可能表達過對某件皮膚的喜歡，而它又和另一件皮膚比較搭，此時搭配第三件皮膚，從第三件皮膚的銷售情況中瞭解到，它與先前的兩件皮膚有比較高的同時購買率，那麼，這個時候通過圖結構可將這三件皮膚進行關聯，形成禮包推送給玩家，此時玩家對禮包的接受度和可能喜愛程度會更高。
上圖是某款遊戲裡的交易系統，網易旗下的有些遊戲非常注重資源的流通性，玩家可以採集各種資源，並且銷售給其他玩家來獲取利益。此外，玩家也可以選擇做一名中間商，直接倒賣資源，賺取差價。一般來說，遊戲製造方都鼓勵玩家進行這種主動的資源交換，因為這會維持遊戲生態的繁榮和穩定之餘給玩家帶去實際收益。但不能忽略的是當中存在非法交易，這些非法交易玩家會成立黑色的組織工作室，盜取他人的賬號，或者欺騙他人，將遊戲內的資源轉移給組織控制的黑產賬號，再在黑產賬號裡面銷贓，去攫取非法收益。像這種破壞其他玩家遊戲體驗和遊戲生態的行為，遊戲製作方一直在進行高壓的打擊。
剛說到非法交易的黑產鏈路，當中識別黑產銷贓賬號便是打擊非法交易的關鍵。像上圖右側所示，它是個黑色賬號的交易行為形成的特殊圖結構，一般來說黑色賬號會過多地從其他玩家那裡以低於市場的價格來獲取大量資源，又轉手賣出去，以這樣的圖結構進行輔助判斷，再結合其他的防黑產識別方式，就可以對黑產、黑色賬號進行比較精確的識別。
再看社交系統，簡單來說社交系統就是撮合原本陌生的人相互認識，再通過互動交流讓他們產生深厚的友情甚至愛情。那麼，怎麼撮合陌生人認識便是關鍵，像上圖的小黃和小紅，互相不認識。假如他們在遊戲內有一個甚至多個共同好友，此外，他們偏好的遊戲線上時段也一致都喜歡大半夜上線開黑。這個時候，基於這樣的圖結構，大家心中應該已經有了簡單的答案：應該撮合小黃和小紅相互認識。
遊戲中還有對戰匹配系統，MOBA（英文全稱：Multiplayer Online Battle Arena）可能是大家常玩的一種遊戲型別。玩過這類遊戲的玩家應該深有體會，MOBA 裡面匹配到的隊友水平對單場遊戲體驗發揮著至關重要的作用。那麼，怎麼給玩家匹配到更可能“不坑”的隊友，讓玩家開心地推塔對線呢？像上圖，為什麼會將藍色玩家和紅色玩家匹配到一起遊戲呢？當中的產品邏輯也許是藍色玩家的偏好位置是下路，紅色玩家的偏好位置是輔助，這兩個位置是絕佳的搭配。而他們又恰好在先前的某次遊戲裡組過隊並且獲勝了，加上他們又處於同一段位水平。這個時候，根據這樣的圖結構提示，把小藍和小紅匹配到一起，他們倆在一起的遊戲體驗想必也不會太差。
最後，來看一下游戲的攻略系統，當前大多遊戲的攻略是由遊戲運營人員或者遊戲社群內的 KOL，主動去輸出、整理到各類遊戲平臺。他們產出的遊戲攻略質量其實都很高，但因為內容釋出渠道比較分散，不易被玩家簡單地瀏覽、查詢，造成攻略的資源浪費。假如我們對這些攻略進行專家知識採集或者說知識抽取，形成攻略知識庫，把攻略知識庫接入遊戲內的提示、問答模組。當玩家產生疑問遇到困難時，像上圖那樣，如果玩家不知道怎麼給飯笥搭配御魂或者其他式神進行對戰，這時候遊戲系統可以根據攻略圖結構直接給出飯笥的搭配式神和御魂，並基於這個子圖進一步擴充套件，給出搭配式神和御魂的其他的資訊以便玩家獲得更好的遊戲體驗。
資料即服務
經過上面的例子，想必大家對網易遊戲的各類圖資料形式有了一定了解。在百款網易遊戲的持續迭代更新下以及新遊戲產品的上線的情況下，勢必會產生非常大規模的圖資料，那我們團隊是如何管理這樣大規模的圖資料，又是如何將這些資料利用好，將資料轉化有效服務的呢？在接下來這部分將會進行介紹。
在網易遊戲內部管理海量遊戲資料，不得不先提到諾亞平臺，本次分享介紹的圖資料管理和圖服務也是站在諾亞平臺巨人的肩膀上進行的。
網易·諾亞平臺
諾亞作為網易遊戲資料中臺的核心開發引擎，已經給公司內超過 200 款產品提供像上圖所示的資料治理、資料開發、資料服務、資料安全等廣泛而有深度的資料支撐。像資料治理它會有資料引入、資料處理、資料資產等模組；資料開發包含機器學習、流式計算、特徵計算、資料萃取；資料服務的話，會有服務開發、資料大屏、知識圖譜，這個是我們接下來會介紹的重點；資料安全的話，有資料保護、鷹眼、質量監控等各種各樣的子功能、子模組。這些模組不僅提高了資料開發的效率和質量，還為產品開拓了新的業務形式。像大規模的線上遊戲圖資料管理工作，基於全鏈路一站式的智慧資料開發平臺諾亞，也在短時間體驗到了它的高效。
技術選型
下面，進入喜聞樂見的“鞭打” JanusGraph 環節。
在圖資料的管理和服務方面，一開始網易遊戲並不是採用 Nebula Graph，而是 JanusGraph。想必很多用 JanusGraph 的技術團隊都沒有繞過一個坎，就是 JanusGraph 和它的衍生品。其實網易遊戲也一樣，在網易遊戲圖實踐的初期因為圖規模並不大，大約在 10^4 個節點和 10^6 條邊量級。在這種小規模圖資料的探索的階段，網易遊戲基於 JanusGraph 搭建如上圖所示架構的知識圖譜工具包。之所以叫做工具包，是因為系統架構比較簡單，儲存後端選用 HBase，索引後端選用 Elasticsearch。基於這種後端上層搭建 JanusGraph，再基於 JanusGraph 封裝應用服務。這個工具包主要支撐圖資料的寫入，圖資料的定時、定量更新，查詢和視覺化以及演算法執行需求。
工具包包含各類節點，一個節點是一個基礎操作的封裝。比如說，你要建立一個知識圖譜。首先是要宣告圖譜的結構，也就是 Schema，而諾亞平臺封裝 Schema 宣告運算元、節點寫入運算元、邊寫入運算元（對應上圖從左至右三張截圖）；在查詢方面，諾亞封裝了 JanusGraph 查詢語言 Gremlin 運算元；此外，網易遊戲還開發自定義查詢運算元，比如你可以傳入節點 ID 然後輸出它的屬性值。整個工具包的流程是使用者在諾亞平臺匯入資料，連線（呼叫）各類運算元後運算元給出對應執行結果或者執行操作，某種程度上工具包滿足了當時諾亞平臺使用者的需求。但，工具包其實是存在使用門檻：
- 瞭解 Schema：未接觸知識圖譜的使用者對 Schema 不瞭解，不明白“什麼是圖譜的結構？”、“我為什麼要設計圖譜的結構？”、“我怎麼去設計 Schema？”
- 資料正確寫入：原始資料可能是資料表或者文字，如何組織資料才能順利地寫入到圖裡面；
- 圖譜使用經驗：使用者可能沒有圖譜的使用經驗，更不會用圖資料庫，這種情況下他可能不瞭解 Gremlin、查詢語句也不會寫，那麼他就查不了資料；
以上都是知識圖譜工具包的使用門檻問題。
此外，這個這個知識圖譜工具包所用的視覺化的元件為 GitHub 上開源的 janusgraph-visualization 。部署到伺服器之後，如上圖所示，頂部輸入框中輸入 Gremlin 查詢語句，再填上伺服器資訊，系統會返回查詢結果（上圖左下角為返回資料）和查詢結果示意圖（上圖藍色球狀圖）。和之前說到的工具包基礎操作封裝類似，其實視覺化組建這塊也有使用門檻問題：第一個問題和節點使用類似，使用者可能不會寫 Gremlin。第二個問題，仔細檢視上圖左下角的結果返回資料，它詩歌結構化資料，給使用者的資訊啟示性不足。最後一個問題，瀏覽器崩潰問題。所以，這套視覺化系統的執行效率其實並不高。
此外，這個知識圖譜工具包封裝了個性化運算元，比如我們封裝了用知識圖譜實現推薦業務的常用邏輯，使用者可以直接呼叫運算元來實現推薦。但因為工具包底層依賴 JanusGraph，用過 JanusGraph 的小夥伴可能也有體會，它的執行速度會非常的慢。如上圖所示，在 4,000 個節點和 100 萬條邊的圖中去執行 100 條略複雜的查詢，就要花費 6 個小時的時間，這種執行效率是不可接受的。
基於上述原因，經過一輪探索實踐，JanusGraph 支撐的知識圖譜工具包難以滿足上層業務需求。簡單來說：能用但門檻高，而且有硬傷，加上網易遊戲圖資料規模又越來越大，這種情況下難以支撐業務。又經過一段時間的調研探索，遇到了 Nebula Graph。基於 Nebula Graph 的特性，網易遊戲對知識圖譜基礎設施和底層架構進行了重構。
上圖所示，儲存後端選用 Nebula Graph 預設的 RocksDB，基於 Nebula Graph 上層封裝知識圖譜平臺 Athena，Athena 中的後設資料會在下層資料層的 MySQL 進行管理。在平臺服務層 Athena 上面進一步抽象封裝應用層，將之前知識圖譜工具中的 Schema、點邊寫入、查詢等等操作封裝成應用形式，對應到上圖的本體管理、圖譜管理、圖譜服務。為了方便業務擴充、快速落地，上層應用層還封裝了 SDK。得益於 Nebula Graph 的高效能和新架構，網易遊戲目前有了更強的圖管理能力，目前圖規模在 10^8 級別的點和 10^10 級別邊。
Nebula Graph 物理部署
Nebula Graph 的部署結構如上圖所示，網易遊戲這邊僅用了 3 臺物理機器部署，便能管理上述的級別的圖規模。除了常規的服務部署之外，還增加了定製化服務狀態監控和程式管理模組。之所以新增這兩個服務的原因是網易遊戲搭建這套系統時，Nebula Graph 版本為 v2.0.1，該版本不具備記憶體水位管理（這個功能在 v2.5.0 開始支援），所以當機不能自動恢復。加入狀態監控和程式監控之後，當機可以自動恢復。此外，網易遊戲這邊還進一步封裝了 Nebula Java 客戶端變成高可用客戶端池，裡面內建自動重連、衝突檢測等等功能。這裡客戶端池只起到隔離作用，上層才是前面提到的知識圖譜平臺服務，以及其他的業務應用。
基於這樣的部署結構，網易遊戲的知識圖譜業務也有了較穩定的執行狀態。
效能對比：Nebula Graph v.s. JanusGraph
經過底層的儲存後端重構（用 Nebula Graph 代替 JanusGraph）之後，我們最直觀的體驗便是快、非常快。像上面的效能對比，100 萬條邊資料的寫入效能在原來基於 JanusGraph 架構下，大概需要 6 個小時。切換到 Nebula Graph 架構後，縮短到 10 分鐘左右，效能提高 33~40 倍。
而複雜鏈狀路徑查詢，即一個點連另一個點，再連另一個點這樣一條鏈的查詢。這種查詢 JanusGraph 架構大概需要 4 秒，而 Nebula Graph 縮短到 200 毫秒，效能提升 20 倍的樣子。
而複雜形狀路徑查詢，就是一個點出去，經過另一個點，然後再回到這個點，再從另一個方向出去經過另一個點，這樣路徑查詢。使用 Nebula Graph 之後也有了明顯的效能提升，從 5 秒降低到 3 秒，效能提升大約 2 倍左右。
效能提升比較明顯的點是在路徑生成上，兩跳 2-hop 路徑生成經查詢測試，JanusGraph 架構在 6 分鐘左右，而 Nebula Graph 只用 60 毫秒，效能提升 6,000 倍。三跳 3-hop 的路徑生成，JanusGraph 是超時 + OOM（這裡我們設定了超時閾值為半個小時），Nebula Graph 的話在 12 秒內跑出結果，這也是比較大的效能提升。
低門檻使用知識圖譜
單純圖資料庫效能快的話，其實對我們而言用處並不大，前面提到過怎麼簡單地建立圖、使用圖資料，才是使用者最常面對的門檻。
本體管理模組
基於先前知識圖譜工具包積累的探索經驗，我們在諾亞平臺開發了知識圖譜服務平臺，目前有本體管理、圖譜管理、圖譜服務三大功能，極大地降低了知識圖譜的使用門檻，提高了使用體驗。得益於 Nebula Graph 的高效能，知識圖譜服務平臺能以較高效能穩定執行，以服務封裝的產品。首先，看下本體管理，主要用於解決 Schema 設計問題。使用者可能並不清楚怎麼去設計 Schema，更甚者他不知道什麼是 Schema。即便使用者知曉何為 Schema，他怎麼去執行設計思路也是一個問題，難道讓他直接去編輯建立語句嗎？
因此，我們對 Schema 設計進行封裝抽象成本體構建模組。這個模組採用了互動式，通過簡單地拖拽（把概念拖進來，把關係拖進來）來實現使用者的本體設計，即所見即所得，他怎麼拖拽元件就得到怎麼樣的本體。根據使用者設計的圖結構將當中 Schema 進行解析，寫入到 Nebula Graph 中，至此，本體構建完成。構建完成的本體會儲存在本體庫，因為圖結構具備一定通用型可作為複用資源。所以，在本體管理模組將本體資源放到本體庫中，供所有的使用者共享使用建立自己的知識圖譜庫。
圖譜管理
設計好的圖譜結構，如何寫入資料、定時地維護圖譜裡面的資料，這裡我們抽象出了圖譜管理模組。
首先，使用者要在圖譜管理模組選擇所用本體，選擇完成後進入知識對映環節。知識對映簡單來說，就是 Schema 和資料的對映。使用者完成本體選擇（概念選擇、關係選擇）後，可以從各個資料來源，比如 MySQL、Hive 中選擇所需資料並配置過濾條件，這樣使用者就為剛才設計的本體（概念屬性或者是關係屬性）指定屬性值來自哪張表的哪個欄位。舉個例子，使用者他選擇電影標題屬性值來自 t3 資料表的 name 欄位，點選上圖藍色框的【執行】按鈕，這時候 t3 的 names 值將會直接寫入電影概念下節點的參考屬性。這個網易知識圖譜團隊稱之為流水線，即自動資料維護。自動資料維護服務還支援配置定時執行任務，假如使用者的資料是 T+1 更新就可以配置每天執行，這樣每天更新的資料會自動刷到圖譜中。
視覺化查詢
上面講完了 Schema 構建和資料寫入，那使用者怎麼查詢圖資料呢？答案是我們針對這個問題自研了一個高效能的視覺化工具。
上圖右上角為“關鍵詞的關鍵詞”選擇框，示意使用者可以去搜尋關鍵詞。這裡的關鍵詞對應 Nebula Graph 中某個節點的 tag 屬性，比如：電影的名字。在畫布中選擇關鍵詞之後，填入“十面埋伏”點選【搜尋】，系統會將使用者的搜尋意圖轉化為 Nebula Graph 中的查詢語句並執行，找到匹配的中心節點，再獲取該節點的一跳子圖，將其結果返回給知識圖譜平臺。最後，把子圖的資料同本體庫中的本體結構進行對映，最終刷到視覺化畫布上，呈現搜尋結果的示意圖 。此外，這個視覺化系統還支援點選子圖中的其他節點，展示其一跳子圖，也支援規則過濾資料、高亮視覺化結果。
說完功能性，為什麼說這套系統是高效能呢？這套視覺化工具在符合網易遊戲內部的資料形式之餘，也具備高效能：無論是點選搜尋還是檢視一跳子圖，都能在較短時間重新整理畫面呈現結果，多節點的情況下也不會造成卡頓。
可配置服務
配置式推薦理由服務
上面說的內容大多為知識圖譜維護，基於資料即服務的理念，網易遊戲封裝了知識圖譜服務，使用者可直接配置用上知識圖譜提供的能力。
這裡講下何為推薦理由？推薦理由就是使用者可在知識圖譜本體結構中配置路線，比如上圖的綠色部分，觀影使用者 v1 看過電影 v2，v2 的題材是 v3，而 v3 同樣是電影 v4 的題材，這個路徑便可變成配置的理由規則：推薦電影 v4 的理由是它的題材同你之前看過的電影 v2。對應到 Nebula Graph 中的查詢便是看 v1 和 v4 之間是否存在該條路徑，滿足的話就像其題材屬性值填充到理由規則中，比如十面埋伏和英雄都是中國題材電影這種理由。當然不同的節點可能滿足多種理由規則，比如上圖下方所示的 v1（這裡用十面埋伏來代指）的票房已經攀升到 xx 億這樣的理由規則，而這個理由對應到 Nebula Graph 中到查詢操作便是查詢票房屬性值。
推薦理由服務的好處是什麼呢？一，使用者不需要寫查詢實現以及維護 meta path 查詢通過簡單的配置形式即可獲得推薦理由；二，支援任意來源的線上請求，舉個例子：使用者可使用邏輯黑箱、演算法黑箱生成推薦結果同步給理由服務，理由服務依據指定的圖譜返回具體的推薦理由，將黑箱推薦白箱化。
配置式社交網路服務
這個部分講下社交網路服務，上文提到遊戲記憶體在社交網路。分析具體的業務場景時，發現需要基於知識圖譜進行圖計算，比如社群發現，因此這裡將社交網路進行了服務化封裝。
使用者在本體結構上選擇社交網路子圖，所謂的社交網路子圖就是社交網路中核心的成員是誰，比如說這個圖裡選擇的人物。此外，你還可以選若干個社交關係，上圖右側所示的自環關係“緋聞”，這樣便是一個社交子圖結構。再選擇社交演算法（上圖下方功能區域）填入演算法引數，點選【執行】。這樣社交網路的分析或者說計算流程，會被解析成諾亞平臺上的一個實驗，進行執行，執行完成後，使用者在 Web 介面可看到社群發現、社群潛力、社交推薦的結果。
配置式知識表示服務
知識表示服務可將圖譜中的點邊通過圖結構關係對映成向量。熟悉演算法同學工作的人可能知道，他們需要編寫 PyTorch / TensorFlow 等等程式碼，用到一個知識表示就需要寫一套程式碼，而且程式碼行數也不少。其實這當中存在通用性需求，諾亞知識圖譜平臺將通用型需求進行抽象封裝成配置式知識表示服務便能大大地節省時間，提高效率。
如上圖所示，首先還是選子圖結構，確定知識圖譜中哪些概念節點、哪些關係邊即將被系統對映成向量。再選擇知識除錯演算法，上圖便是選擇了 TransH，再選擇演算法引數：向量長度、迭代次數等等。接著配置執行結果存放在什麼地方（輸出型別），比如存放在 Redis、Hive、Milvus 中，選擇輸出型別後配置輸出源對應引數。最後，點選【釋出】執行即可。同上面的服務一樣，這個知識表示配置會被轉化成知識學習實驗去讀取 Nebula Graph 中的圖資料，再放到諾亞上面去計算知識表示演算法，最終根據使用者的配置輸出到 Redis / Hive / Milvus 中，這樣演算法工程師就可以非常方便地在離線實驗或者線上業務中呼叫知識表示向量了。
配置式推薦服務
同上文的推薦理由類似，也是 meta path 思路，使用者在知識圖譜結構上面配置多個 meta path，比如看過什麼電影、電影導演是誰、影片型別是國產片還是美國片，以及電影主演在不在行業黑名單，關聯上述 meta path，點選【釋出】執行。同上面的其他服務類似，系統到 Nebula Graph 中讀取圖資料，檢視結果中有哪些電影滿足上面的複合查詢。
知識圖譜在遊戲中的應用
在這個章節，簡單分享下網易遊戲基於諾亞平臺封裝的知識圖譜服務落地了哪些圖譜業務形式和知識圖譜應用。
做演算法的同學可能對 RippleNet 比較熟悉，網易遊戲的 RippleNet 實踐是基於商品資料構造知識圖譜，在其上層開發 RippleNet 實驗給使用者進行個性化推薦，比如：感興趣的商品、獨享折扣等等。此外，因為用到了知識圖譜，之前提到的配置式推薦理由可以給出一些推薦理由。這樣，業務落地之後，遊戲的購買率和單位流量代幣回收較之前都有了提升。
第二個例子，基於 meta path 的商品套裝推薦。這裡的套裝什麼概念？比如，麥當勞點單的套餐，便是個典型的套裝。它之所以是一個套裝，是因為你吃漢堡可能會渴，就需要喝可樂，所以漢堡和可樂會是一個套裝。套用這個思路到遊戲中，遊戲裡給玩家推薦皮膚套裝，當中的商品應當是搭配的，比如頭飾、上衣、光環的顏色搭配。想象下，綠色的頭飾搭配紅色的頭髮再加一個紅色光環，或者其他奇奇怪怪的色彩搭配，是很影響遊戲體驗的。在沒有諾亞知識圖譜服務平臺之前，想做出一個搭配的套裝需要藉助運營同學或者設計同學的人力資源，手工依賴人的經驗和審美進行設計，這相當低效。
有了知識圖譜服務平臺之後，將套裝設計專家知識抽象成 meta path 模板，比如：頭飾和上衣，再用 meta path 進行計算返回套裝，設計出來的套裝搭配度非常高。此外，在提升人效的同時也提高了購買率。
第三個是社交網路，網易遊戲用知識表示 TransH 演算法來向量化社交網路裡面的玩家。向量化之後，我們可以對資料進行下一步操作。舉個例子，用相似度做相似玩家的召回或者集合，這裡的集合可能是工會或者說組織，可在召回成功後推薦給其他相似玩家。在社交推薦系統的幫助下，遊戲中申請率和成功率有了提高。
上面配置式推薦理由服務中講到過黑箱白箱化，基於 metapath 的白盒推薦理由。像上圖所示的好友匹配，初期好友推薦會給出一個匹配度，這裡的數值可能是 81%。但是作為玩家或許會很困惑，為什麼是 81%，這個數值和這個使用者推薦結果是怎麼來的？系統為什麼把這個人推給我？而基於 metapath 的白盒推薦理由則能很好地解決這個問題。將黑箱推薦理由輸入到諾亞知識圖譜服務平臺上，利用知識圖譜匹配推薦理由。以上面的例子為例，系統可以給出女玩家和男玩家之前都去過多貝雪山、常去重返希望谷副本…等等理由，這樣被推薦的使用者接受推薦結果的可能性便大大提升了。
還是一個社交場景，有了社交網路資料，系統便可基於資料進行社群發現演算法計算，像上面便是直接把同社群內召回的玩家經過簡單的過濾後推薦給其他玩家，這裡好友申請率和申請成功概率也有一定的提高。
再來看看基於 meta path 的社交推薦，有了知識圖譜難以避免會涉及專家知識。專家知識在很多場景下，是非常硬核的東西因為它可以取得非常好的效果。像社交推薦業務，就直接將先前積累的社交推薦經驗，比如同時段遊玩、標籤分值類似的玩家放在一起抽象成知識圖譜上的 meta path 模板。利用這樣 meta path 模板，線上請求傳入玩家資料後，在 Nebula Graph 中線上實時計算結果並返回對應推薦玩家。這樣，社交好友申請率和申請成功率也會有很大提升。
展望
- 更加完備的知識圖譜平臺能力：簡單高效地支撐更多複雜圖資料管理和服務需求；
- 更加豐富的知識圖譜業務形式：探索更多有意思、有價值的知識圖譜業務；
- 更加深入的 Nebula Graph 社群參與程度。
交流圖資料庫技術？加入 Nebula 交流群請先填寫下你的 Nebula 名片，Nebula 小助手會拉你進群~~