Nebula Graph 在网易游戏业务中的实践

当游戏遇上知识图谱，网易游戏是如何应对大规模图数据的管理问题，Nebula Graph 又是如何帮助网易游戏落地游戏内复杂的图的业务呢？在本文，我们来一探究竟。

目前网易游戏大部分的产品都是在线游戏，作为国际领先的头部游戏厂商，网易所吸引的在线玩家数量也是相当庞大的，而数量庞大的玩家登录我们的游戏势必产生海量的操作性数据。

如上图中间显示的交易数据——玩家可以购买商城里的物品，或者直接购买其他玩家的物品；社交数据——加好友、点赞、刷礼物等等，有些游戏中还会存在婚姻系统。此外，还有常见的对战系统、发言系统——玩家在频道内发表自己的见解，或者是整理自己的游戏经验变成游戏攻略。

对游戏设计和开发人员而言，各个游戏内的系统都需要保证资源可以在系统内部正常的循环和流转，以保证游戏生态的平稳运行，我们称之为系统循环。系统设计会产生系统循环图，交易会产生交易网络，社交会产生社交网络，对战会产生对战关系网络，发言会产生 UGC 知识库，产出攻略则会形成攻略知识库。

这些丰富多样的图数据就是游戏中无处不在的图。

简单来感受下网易游戏玩家在游戏中感受到的图：

游戏的商品系统

上图是某款游戏的商品系统，不知道 Nebula 的小伙伴有没有喜欢收集皮肤的，可能你玩的游戏中会推送一些皮肤礼包，礼包里会有若干件皮肤，但你想过礼包里的皮肤是否随机选取这个问题吗？肯定不是，游戏制作方自然希望把好看的皮肤进行搭配，将不同玩家喜欢的皮肤放在一起推送给玩家。这时候，各个皮肤之间、皮肤与玩家之间便会产生联系。像上图右边的例子，玩家可能表达过对某件皮肤的喜欢，而它又和另一件皮肤比较搭，此时搭配第三件皮肤，从第三件皮肤的销售情况中了解到，它与先前的两件皮肤有比较高的同时购买率。那么，这个时候通过图结构就可将这三件皮肤进行关联，形成礼包推送给玩家，此时玩家对礼包的接受度和可能喜爱程度会更高。

以上都是知识图谱工具包的使用门槛问题。

此外，这个知识图谱工具包所用的可视化组件为 GitHub 上开源的 janusgraph-visualization（https://github.com/fenglex/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 的部署结构如上图所示，网易游戏这边仅用了 3 台物理机器部署，便能管理上述的级别的图规模。除了常规的服务部署之外，还增加了定制化服务状态监控和进程管理模块。之所以新增这两个服务的原因是网易游戏搭建这套系统时，Nebula Graph 版本为 v2.0.1，该版本不具备内存水位管理（这个功能在 v2.5.0 开始支持），所以宕机不能自动恢复。加入状态监控和进程监控之后，宕机可以自动恢复。此外，网易游戏这边还进一步封装了 Nebula Java 客户端变成高可用客户端池，里面内置自动重连、冲突检测等等功能。这里客户端池只起到隔离作用，上层才是前面提到的知识图谱平台服务，以及其他的业务应用。

经过底层的存储后端重构（用 Nebula Graph 代替 JanusGraph）之后，我们最直观的体验便是快、非常快。像上面的性能对比，100 万条边数据的写入性能在原来基于 JanusGraph 架构下，大概需要 6 个小时。切换到 Nebula Graph 架构后，缩短到 10 分钟左右，性能提高 33~40 倍。

而复杂链状路径查询，即一个点连另一个点，再连另一个点这样一条链的查询。这种查询 JanusGraph 架构大概需要 4 秒，而 Nebula Graph 缩短到 200 毫秒，性能提升 20 倍的样子。

而复杂形状路径查询，就是一个点出去，经过另一个点，然后再回到这个点，再从另一个方向出去经过另一个点，这样路径查询。使用 Nebula Graph 之后也有了明显的性能提升，从 5 秒降低到 3 秒，性能提升大约 2 倍左右。

本体管理模块

基于先前知识图谱工具包积累的探索经验，我们在诺亚平台开发了知识图谱服务平台，目前有本体管理、图谱管理、图谱服务三大功能，极大地降低了知识图谱的使用门槛，提高了使用体验。得益于 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 中到查询操作便是查找票房属性值。

这个部分讲下社交网络服务，上文提到游戏内存在社交网络。分析具体的业务场景时，发现需要基于知识图谱进行图计算，比如社区发现，因此这里将社交网络进行了服务化封装。

知识表示服务可将图谱中的点边通过图结构关系映射成向量。熟悉算法工作内容的人可能知道，他们需要编写 PyTorch TensorFlow 等等代码，用到一个知识就表示需要写一套代码，而且代码行数也不少。其实这当中存在通用性需求，诺亚知识图谱平台将通用型需求进行抽象封装成配置式知识表示服务便能大大地节省时间，提高效率。

同上文的推荐理由类似，也是 metapath 思路，用户在知识图谱结构上面配置多个 metapath，比如看过什么电影、电影导演是谁、影片类型是国产片还是美国片，以及电影主演在不在行业黑名单，关联上述 metapath，点击【发布】运行。同上面的其他服务类似，系统到 Nebula Graph 中读取图数据，查看结果中有哪些电影满足上面的复合查询。

做算法的同学可能对 RippleNet 比较熟悉，网易游戏的 RippleNet 实践是基于商品数据构造知识图谱，在其上层开发 RippleNet 实验给用户进行个性化推荐，比如：感兴趣的商品、独享折扣等等。此外，因为用到了知识图谱，之前提到的配置式推荐理由可以给出一些推荐理由。这样，业务落地之后，游戏的购买率和单位流量代币回收较之前都有了提升。

第二个例子，基于 metapath 的商品套装推荐。这里的套装什么概念？比如，麦当劳点单的套餐，便是个典型的套装。它之所以是一个套装，是因为你吃汉堡可能会渴，就需要喝可乐，所以汉堡和可乐会是一个套装。套用这个思路到游戏中，游戏里给玩家推荐皮肤套装，当中的商品应当是搭配的，比如头饰、上衣、光环的颜色搭配。想象下，绿色的头饰搭配红色的头发再加一个红色光环，或者其他奇奇怪怪的色彩搭配，是很影响游戏体验的。在没有诺亚知识图谱服务平台之前，想做出一个搭配的套装需要借助运营同学或者设计同学的人力资源，手工依赖人的经验和审美进行设计，这相当低效。

有了知识图谱服务平台之后，将套装设计专家知识抽象成 metapath 模板，比如：头饰和上衣，再用 metapath 进行计算返回套装，设计出来的套装搭配度非常高。此外，在提升人效的同时也提高了购买率。

第三个是社交网络，网易游戏用知识表示 TransH 算法来向量化社交网络里面的玩家。向量化之后，我们可以对数据进行下一步操作。举个例子，用相似度做相似玩家的召回或者集合，这里的集合可能是工会或者说组织，可在召回成功后推荐给其他相似玩家。在社交推荐系统的帮助下，游戏中申请率和成功率有了提高。

上面配置式推荐理由服务中讲到过黑箱白箱化，基于 metapath 的白盒推荐理由。像上图所示的好友匹配，初期好友推荐会给出一个匹配度，这里的数值可能是 81%。但是作为玩家或许会很困惑，为什么是 81%，这个数值和这个用户推荐结果是怎么来的？系统为什么把这个人推给我？而基于 metapath 的白盒推荐理由则能很好地解决这个问题。将黑箱推荐理由输入到诺亚知识图谱服务平台上，利用知识图谱匹配推荐理由。以上面的例子为例，系统可以给出女玩家和男玩家之前都去过多贝雪山、常去重返希望谷副本…等等理由，这样被推荐的用户接受推荐结果的可能性便大大提升了。

还是一个社交场景，有了社交网络数据，系统便可基于数据进行社区发现算法计算，像上面便是直接把同社区内召回的玩家经过简单的过滤后推荐给其他玩家，这里好友申请率和申请成功率也有一定的提高。

再来看看基于 metapath 的社交推荐，有了知识图谱难以避免会涉及专家知识。专家知识在很多场景下，是非常硬核的东西因为它可以取得非常好的效果。像社交推荐业务，就直接将先前积累的社交推荐经验，比如同时段游玩、标签分值类似的玩家放在一起抽象成知识图谱上的 metapath 模板。利用这种 metapath 模板，在线请求传入玩家数据后，在 Nebula Graph 中在线实时计算结果并返回对应推荐玩家。这样，社交好友申请率和申请成功率也会有很大提升。