关系图谱在太阿系统中的应用

原创武文佳贝壳产品技术

前言

关系图谱是描述两个元素直观关系的一种数据可视化方式。通过两点一线来描述一段关系，多段关系组成一张关系网，如人物关系图。

关系图谱在太阿业务系统中进行了落地实践。太阿平台是监察办案的一站式作业平台，主要包括对新房或二手房经纪人违规行为的调查闭环线上化、调查过程中的溯源工具合集以及一些可能涉及风险的流程审核等。其中溯源工具中的事实图谱和亲密度图谱就采用了关系图谱。

事实图谱用来还原经纪人作业中的一切事实关系，如经纪人A使用过的电话号、设备、小程序、身份证，联系过的客户、经纪人，分享或浏览过的房源，到访过的门店等等，每个相关元素（房源等）依然存在自己的事实关系网。

亲密度图谱是基于相同底层数据抽象而成的亲密度图谱，可以查询经纪人/客户-经纪人/客户的直接关系，以及该直接关系是通过设备、电话、WIFI组成的哪些链路产生的连接。

以上两种图谱需要满足一些基本的交互：点的拖拽、删除、筛选、扩散，和基本的布局：扩散、链路对称等。下面我们从以下几个方面来进行详细的讲述，通过阅读本文，我们在遇到与关系图相关需求时，能够快速选型，并对整个实现过程有基本的了解：

常见数据可视化工具
关系图谱选型实践
优化
总结

一、常见数据可视化工具

工作中我们常常遇到的图表主要有：折线图、柱状图、饼图、仪表盘、漏斗图、雷达图等，在某些特殊需求场景下，我们可能会用到关系图、流程图，那么哪些框架可以实现这些图表呢？

1.1

ECharts

简介：

基于 js 的开源可视化库，支持 30+ 种常见图表类型
底层使用 zrender 渲染引擎，支持 canvas 和 svg 渲染
使用上可全量/按需加载

优点：

使用流传度广泛
配置多，功能丰富
社区活跃（Star47.8k，持续维护）

缺点（作为关系图）：

初始化后布局不受控制
复杂交互不方便更新视图，只能通过重新 setOption，比较深的数组配置项不方便

1.2

简介：

基于数据驱动操作 DOM的一款 JavaScript 函数库，被很多图表当作底层库
不需要某个特定的框架，重点在于对现代主流浏览器的兼容

优点：

更底层，自由度高，基于 svg 绘制，可通过 dom 直接操作svg
丰富的 api，只有想不到，没有画不出
社区非常活跃（Star98k）
便于数据处理、数据分析

缺点（作为关系图）：

上手学习成本高、相关分析组件都需要自己去添加，过于灵活
数据量很大时响应比较慢

1.3

简介：

蚂蚁集团开发的简单、易用、完备的图可视化引擎
提供了图的绘制、布局、分析、交互、动画等基础能力。旨在让关系变得透明，简单

优点：

优秀的性能：支持大规模图数据的交互与探索
丰富的元素：内置丰富的节点与边元素，自由配置，支持自定义
可控的交互：内置 10+ 交互行为，支持自定义交互
强大的布局：内置了 10+ 常用的图布局，支持自定义布局
便捷的组件：优化内置组件功能及性能

缺点（作为关系图）：

布局过渡动画时间长
除力导布局外，现有顶点无法固定

当然，除以上工具外，还有 G2/F2、Higncharts 等图表库，这里我们不过多介绍。通过对比在实现关系图谱时的优缺点，并结合复杂的业务交互要求，下面选择 D3 和 G6 来进一步实践，看看在太阿系统中是如何实现的以及过程中的一些问题。

二、关系图谱选型实践

2.1

事实图谱-D3

首先明确我们的产品目标：

展示：边、点、箭头、文本等
交互：点拖拽、删除、筛选、扩展
布局：同心圆
状态：选中、hover

基于 D3 的页面渲染过程如下所示，其中大部分展示和基本的交互，D3 都提供了内置功能。

对于个性化部分，支持自定义，如当选中节点时，展示自定义操作环，相关代码如下，通过新建 svg 的节点，一步步实现：

从流程图中可以看出，D3 的写法类似 jQuery，支持链式调用；任意内容均需要手动添加/绘制（代码量大）；可自定义绘制内容、样式，添加事件灵活、可扩展性强；api 丰富，需具备一定绘图知识。

最后我们实现了如下所示效果：

但是当数据量很大时，如下图所示，事实图谱遇到的产品痛点主要有：

不支持批量操作（将无关元素删除或批量拖拽）
页面响应慢，操作不流畅

对于痛点一，D3 只是没有提供现成的分析组件供我们使用，但是可以通过brush 绘制框选区域，并拿到区域中的元素，进行下一步操作，这里不做具体演示。

对于痛点二，主要有两个原因引起：

第一、现状是，当鼠标 hover 到每个点元素和线元素，都会向后端发起请求，当数据量很大时，频繁的 setState 会引起页面卡顿；

第二、由于 D3 是基于 svg 实现的。

前面也提到过一些框架都支持 canvas 和 svg 两种渲染方式，那么具体两者有何差异呢？

Canvas VS SVG

HTML5 提供了 Canvas 和 SVG 两种绘图技术，也是多数 Web 图表库使用的渲染技术。

Canvas 是基于脚本的，通过 JavaScript 指令来动态绘图：页面先有一个指定大小的canvas标签；js像素级脚本绘制，绘制完成后，浏览器渲染节点，将不再追踪画布内元素，减少浏览器内存，若发生更新，全画布重新渲染。

SVG 则是使用 XML 文档来描述矢量图。抽象层次更高，声明描述式的接口功能更丰富，内置了大量的图形、滤镜和动画等，方便进行文档元素的维护，也能导出为文件脱离浏览器环境使用。

这里我们引用微软博客的对比图来看一下两者的渲染时间随画布大小和元素数量的性能差异。

从图中可以看出：

svg：受元素数量影响大；拖拽画布、缩放，高保真

canvas：受画布影响大，拖拽画布、缩放，可能会失真；适合大数据量场景

不少人觉得 svg 可以用 dom 直接操作，便于开发者使用，但针对交互性能，很多库在 canvas 上构建了一层 mvc，可以实现和 svg 类似的交互，性能有时候比原生的 svg 更好，如 zrender。

2.2

亲密度图谱-G6

太阿图谱的数据量都很大，节点元素动辄 200+，所以从性能和实现难易两方面考虑，亲密度图谱部分采用 G6 来实现。

首先我们来看一下 G6 的大致架构图：

G6 的底层使用的是自己开发的渲染引擎，支持 canvas、svg，后来为了能专注 canvas精品，从 v2 版本开始暂不支持 svg 渲染。

g-core：核心库中提供了 Shape（自定义绘制元素）、Item（内置元素事件）、Behavior（自定义交互）等核心方法或类。

g6-pc：上层库提供了大量内置的插件、交互、布局、元素，便于开发者直接使用。

整个过程通过 GPU、图算法等来加速数据的处理和渲染。最后面向用户输出的是一般关系图和树两种图表。

明确大致结构后，我们来看具体实现部分，需求目标与第二节事实图谱相同，此处不再赘述。

下图是 G6 绘制的流程图，从图中可以看出：G6 不用写很多 api，通过new G6.Graph(config)，传入配置即可初始化，内置的分析组件也是拿来即用。对于交互，G6不用重新更新整个配置，在实例添加事件修改目标元素属性即可。

Graphin 是基于 G6 封装的开箱即用的上层组件，具体业务中我们就是通过 Graphin 实现的。它更贴合 react 的使用（如同 echats 和 echarts-for-react 的关系）：

用法类似 slot，可拔插
相比 d3 能更快上手

如上是 Graphin 的框架中提供的工具或分析组件，其中：

Behaviors 中包含内置交互行为：相关高亮、框选、可点击、可 hover 等。
GraphinContext：提供了用 hooks 方式获取 graph 的上下文，即当前图谱实例，用于添加事件等。
graphin-components 中包含一些内置分析组件：如操作菜单。

最后我们通过如下的流程图来完成渲染和业务逻辑。

实现效果如下，点击左侧两点连线，可进入右侧详情链路图，其中图一采用graphin-force 力导布局，图二详情采用 radial 辐射布局。

至此，Graphin用少量的代码即可快速绘制出复杂的关系图，流畅度很好。

初版交付的产品有两大使用痛点：

左侧底图在进行点的扩散时，其他点会跟着一起移动，这对于用户来说非常不友好（把存有疑问的两者拖拽到一旁，扩散后，发生移位，在数据量大时很不方便）。
右侧的详情链路，当数据量很少，且每条链路上的点数量相同时，效果还可以（下图一），随着数据量的增多，并伴有节点数量不同的情况，就会交错在一起，需要用户手动梳理（下图二），但是用户是希望可以达到图三的效果，轴对称并且有序。

三、优化

3.1

移位问题

我们的期望是，在目标元素数据发生扩散的时候，现有的点保持不动。G6 的大部分个性化布局，数据结构是一体化的，当数据发生变化时，需要重新计算布局，未提供用户介入渲染过程的方法。所以在布局上，我们只能选择 force 力导布局（如同 D3）。

force 布局分两种元素坐标，一种是正常的 x/y，代表当下时刻的坐标，另一种是 fx/fy，代表固定的坐标。我们每次重新布局完成后，将所有元素的 x/y 坐标转换为 fx/fy 的固定坐标。恰好在组件的 layout 属性中提供了onLayoutEnd 回调函数，供我们在合适的时机进行坐标赋值。