关于nebula:百亿级图数据在快手安全情报的应用与挑战

本文首发于 Nebula Graph 公众号 NebulaGraphCommunity，Follow 看大厂图数据库技术实际。

【作者介绍】

• 戚名钰：快手平安 - 挪动平安组，次要负责快手平安情报平台的建设
• 倪雯：快手数据平台 - 分布式存储组，次要负责快手图数据库的建设
• 姚靖怡：快手数据平台 - 分布式存储组，次要负责快手图数据库的建设

【公司简介】

快手是一家寰球当先的内容社区和社交平台，旨在通过短视频的形式帮忙人们发现所需、发挥所长，继续晋升每个人独特的幸福感。

一. 为什么须要图数据库

传统的关系型数据库，在解决简单数据关系运算上体现很差，随着数据量和深度的减少，关系型数据库无奈在无效的工夫内计算出后果。

所以，为了更好的体现数据间的连贯，企业须要一种将关系信息存储为实体、灵便拓展数据模型的数据库技术，这项技术就是图数据库（Graph Database）。

相比于传统关系型数据库，图数据库具备以下两个长处：

第一点，图数据库能很好地 体现 数据之间的关联关系

从下面的图模型能够看出，图数据库的指标就是基于图模型以一种直观的形式来展现这些关系，其基于事物关系的模型表白，使图数据库人造具备可解释性。

第二点，图数据库能很好地 解决 数据之间的关联关系：

• 高性能：传统关系型数据库在解决关联关系数据时次要靠 JOIN 操作，而随着数据量的增多和关联深度的减少，受制于多表连贯与外键束缚，传统关系型数据库会导致较大的额定开销，产生重大的性能问题。而图数据库从底层适配了图模型的数据结构，使得它的数据查问与剖析速度更快。
• 灵便：图数据库有非常灵活的数据模型，使用者能够依据业务变动随时调整图数据结构模型，能够任意增加或删除顶点、边，裁减或者放大图模型等，这种频繁的数据 schema 更改在图数据库上能到很好的反对。
• 麻利：图数据库的图模型十分直观，反对测试驱动开发模式，每次构建时可进行功能测试和性能测试，合乎当今最风行的麻利开发需要，对于进步生产和交付效率也有肯定帮忙。

基于以上两个长处，图数据库在金融反欺诈、公安刑侦、社交网络、常识图谱、数据血统、IT 资产及运维、威逼情报等畛域有微小需要。

而快手平安情报则是通过整合挪动端、PC Web 端、云端、联盟及小程序等全链条的平安数据，最终造成对立的根底平安能力赋能公司业务。

因为平安情报自身具备数据实体多样性、关联关系复杂性、数据标签丰富性等特点，因而采纳图数据库来做是最为适合的。

二. 为什么抉择 Nebula Graph

通过收集需要及后期调研，快手平安情报在图数据库上最终抉择了 Nebula Graph 作为生产环境的图数据库。

2.1 需要收集

对于图数据库的选型来说，其次要需要是在 数据写入 与数据查问 两个方面：

1. 数据写入形式：离线 + 在线

   • 须要反对天级的离线数据批量导入，每天新增写入数据量在百亿级别，要求当天产生的关联关系数据，小时级能写完
   • 须要反对数据的实时写入，Flink 从 Kafka 中生产数据，并在做完逻辑解决之后，间接对接图数据库，进行数据的实时写入，须要反对的 QPS 在 10W 量级

2. 数据查问形式：毫秒级的在线实时查问，须要反对的 QPS 在 5W 量级

   • 点及边的属性过滤及查问
   • 多度关联关系的查问

3. 局部根本图数据分析能力

   • 图最短门路算法等

综上所述，此次选型的实用于大数据架构的图数据库次要须要提供 3 种根本能力：实时和离线数据写入 、 在线图数据根本查问 、 基于图数据库的简略 OLAP 剖析 ，其对应定位是： 在线、高并发、低时延 OLTP 类图查问服务及简略 OLAP 类图查问能力。

2.2 选型

基于以上的确定性需要，在进行图数据库的选型上，咱们次要思考了以下几点：

• 图数据库所能反对的数据量必须要足够大，因为企业级的图数据常常会达到百亿甚至千亿级别
• 集群可线性拓展，因为须要可能在生产环境不停服的状况下在线扩大机器
• 查问性能要达到毫秒级，因为须要满足在线服务的性能要求，且随着图数据量的增多，查问性能不受影响
• 可能较不便的与 HDFS、Spark 等大数据平台买通，前期可能在此基础上搭建图计算平台

2.3 Nebula Graph 的特点

1. 高性能：提供毫秒级读写
2. 可扩大：可程度扩容，反对超大规模图存储
3. 引擎架构：存储与计算拆散
4. 图数据模型：点（vertex）、边（edge），并且反对点或边的属性（properties）建模
5. 查询语言：nGQL，类 SQL 的查询语言，易学易用，满足简单业务需要
6. 提供了较为丰盛和欠缺的数据导入导出工具
7. Nebula Graph 作为开源图数据库产品，在开源社区具备良好的活跃度
8. 相较于 JanusGraph 和 HugeGraph，Nebula Graph 查问性能有极大的晋升

正是基于 Nebula Graph 的以上特点以及对咱们应用场景和需要的恰好满足，因而最终抉择 Nebula Graph 作为咱们生产环境的图数据库来应用。

三. 平安情报的图数据建模

如下图所示，从情报的角度来看，平安的分层反抗与防守，从下到上，其反抗难度是逐步减少的：

每一个立体上，之前攻打方与防守方都是独自的反抗，当初利用图数据库之后，能够将每一个档次的实体 ID 通过关联关系串联起来，造成一张平面档次的网，通过这张平面档次的网可能使企业疾速把握攻击者的攻击方式、舞弊工具、团伙特色等较全貌的信息。

因而基于平安数据的图构造数据建模，能够将原来的立体辨认档次变成平面网状辨认档次，能帮忙企业更清晰精确的辨认攻打与危险。

3.1 根本图构造

平安情报的图建模次要目标是心愿判断任何一个维度危险的时候，不单单局限于该维度自身的状态与属性去看它的危险，而是将维度从个体扩大为网络层面，通过图构造的数据关系，通过 高低档次 （异构图）及 同级档次（同构图）平面去察看该维度的危险。

以设施危险举例：对一个设施而言，整体分为网络层、设施层、账号层和用户层这四个层面，每个层面都由其代表性的实体 ID 来表白。通过图数据库，能够做到对一个设施进行平面的三维档次的危险认知，这对于危险的辨认会十分有帮忙。

如上图所示，这是平安情报的根本图构造建模，以上形成了一个基于平安情报的常识图谱。

3.2 动态图构造

在根本图构造之上，还须要思考的是，每一种关联关系的存在都是有时效性的，A 时间段内关联关系存在，B 时间段内该关联关系则未必存在，因而咱们心愿平安情报能在图数据库上实在反映客观现实的这种不同时间段内的关联关系。

这意味着须要随着查问工夫区间的不同，而呈现出不同的图构造模型的数据，咱们称之为 动态图构造。

在动态图构造的设计上，波及到的一个问题是：在被查问的区间上，什么样的边关系应该被返回？

如上图所示，当查问工夫区间为 B、C、D 时，这条边应该要被返回，当查问工夫区间为 A、E 时，这条边不应该被返回。

3.3 权重图构造

在面对黑灰产或者真人作恶时，往往会呈现这种状况：就是一个设施下面会对应十分多的账号，有些账号是不法好人本人的罕用账号，而有些账号则是他们买来做特定不法直播的账号。为配合公安或法务的打击，咱们须要从这批账号外面 精准辨别出哪些账号是实在好人本人的罕用账号，而哪些账号只是他们买来用于作恶的账号。

因而这外面会波及到账号与设施关联关系边的权重问题：如果是该设施罕用的账号，那么表明这个账号与这个设施的关系是较强的关系，则这条边的权重就会高；如果仅仅是作恶 / 开直播的时候才会应用的账号，那么账号与设施的关系则会比拟弱，相应权重就会低一些。

因而咱们在边的属性上，除了有工夫维度外，还减少了权重维度。

综上所述，最终在平安情报上所建设的图模型是：带权重的动静时区图构造。

四. 基于图数据库的平安情报服务架构与优化

整体平安情报服务架构图如下所示：

平安情报服务整体架构图

其中，基于图数据库的情报综合查问平台，软件架构如下图所示：

情报综合查问平台软件架构图

注：AccessProxy 反对办公网到 IDC 的拜访，kngx 反对 IDC 内的间接调用

4.1 离线数据写入优化

针对所构建的关联关系数据，每天更新的量在数十亿级别，如何保障这数十亿级别的数据能在小时级内写入、感知数据异样且不失落数据，这也是一项十分有挑战性的工作。

对这部分的优化次要是：失败重试、脏数据发现及导入失败报警策略。

数据导入过程中会因为脏数据、服务端抖动、数据库过程挂掉、写入太快等各种因素导致写 batch 数据失败，咱们通过用同步 client API、多层级的重试机制及失败退出策略，解决了因为服务端抖动重启等状况造成的写失败或写 batch 不齐全胜利等问题。

4.2 双集群 HA 保障与切换机制

在图数据库局部，快手部署了在线与离线两套图数据库集群，两个集群的数据采纳同步双写，在线集群承当在线 RPC 类的服务，离线集群承当 CASE 剖析及 WEB 查问的服务，这两个集群互不影响。

同时集群的状态监控与动静配置下发模块是买通的，当某一个集群呈现慢查问或产生故障时，通过动静配置下发模块来进行主动切换，做到下层业务无感知。

4.3 集群稳定性建设

数据架构团队对开源版本的 Nebula Graph 进行了整体的调研、保护与改良。

Nebula 的集群采纳计算存储拆散的模式，从整体架构看，分为 Meta，Graph，Storage 三个角色，别离负责元数据管理，计算和存储：

Nebula 整体架构图

Nebula 的存储层作为图数据库引擎的底座，反对多种存储类型，咱们应用 Nebula 时抉择了 经典模式，即用经典的 C++ 实现的 RocksdDB 作为底层 KV 存储，并利用 Raft 算法解决一致性的问题，使整个集群反对程度动静扩容。

存储层架构图

咱们对存储层进行了充沛的测试、代码改良与参数优化。其中包含：优化 Raft 心跳逻辑、改良 leader 选举和 log offset 的逻辑以及对 Raft 参数进行调优等，来晋升单集群的故障复原工夫；再联合客户端重试机制的优化，使得 Nebula 引擎在用户体验上从最后的故障间接掉线改善为故障毫秒级复原。

在监控报警体系上，咱们构建了对集群多个层面的监控，其整体监控架构如下图所示：

集群监控架构图

包含如下几个方面：

1. 机器硬件层面 cpu busy、磁盘 util、内存、网络等
2. 集群每个角色 meta、storage、graph 服务接口监控、partition leader 上线状态及散布的监控
3. 从用户角度对集群整体可用性的评估监控
4. 集群各角色 meta、storage、rocksdb、graph 的 metric 采集监控
5. 慢查问监控

4.4 对超级节点查问的优化

因为事实图网络结构中点的出度往往合乎 幂律散布 特色，图遍历遇到超级点（出度百万 / 千万）将导致数据库层面显著的 慢查问，如何保障在线服务查问耗时的平稳性，防止极其耗时的产生是咱们须要解决的问题。

图遍历超级点问题 在工程上的解决思路是：在业务可承受的前提下放大查问规模。具体方法有：

1. 查问中做符合条件的 limit 截断
2. 查问按肯定比例进行边采样

上面别离形容具体的优化策略：

4.4.1 limit 截断优化

【前提条件】

业务层面可承受每一跳做 limit 截断，例如如下两个查问：

# 最终做 limit 截断
go from hash('x.x.x.x') over GID_IP REVERSELY where (GID_IP.update_time >= xxx and GID_IP.create_time <= xxx) yield GID_IP.create_time as create_time, GID_IP.update_time as update_time, $^.IP.ip as ip, $$.GID.gid | limit 100
# 在两头查问后果曾经做了截断，而后再进行下一步
go from hash('x.x.x.x') over GID_IP REVERSELY where (GID_IP.update_time >= xxx and GID_IP.create_time <= xxx) yield GID_IP._dst as dst | limit 100 | go from $-.dst ..... | limit 100

【优化前】

对第二个查问语句，在优化前，storage 会遍历点的所有出度，graph 层在最终返回 client 前才做 limit n 的截断，这种无奈防止大量耗时的操作。

另外 Nebula 尽管反对 storage 配置集群（过程）级别参数 max_edge_returned_per_vertex（每个 vertex 扫描最大出度），但无奈满足查问语句级别灵便指定 limit 并且对于 多跳多点出度查问 也无奈做到语句级别准确限度。

【优化思路】

一跳 go 遍历查问分两步：

• step1：扫描 srcVertex 所有出度 destVertex（同时获取边的属性）
• step2：获取所有 destVertex 的属性 value

那么 go 多跳遍历中每跳的执行分两种状况：

• case 1：只执行 step1 扫边出度
• case 2：执行 step1 + step2

而 step2 是耗时大头（查每个 destVertex 属性即一次 rocksdb iterator，不命中 cache 状况下耗时 500us），对于出度大的点将「limit 截断」提前到 step2 之前是要害，另外 limit 能下推到 step1 storage 扫边出度阶段对于超级点也有较大的收益。

这里咱们总结下什么条件下能执行「limit 截断优化」及其收益：

表正文: N 示意 vertex 出度，n 示意 limit n，scan 示意扫边出度耗费，get 示意获取 vertex 属性的耗费

【测试成果】

对于以上 case1 和 case2 可执行「limit 截断优化」且收益显著，其中平安业务查问属于 case2，以下是在 3 台机器集群，单机单盘 900 GB 数据存储量上针对 case2 limit 100 做的测试后果（不命中 rocksdb cache 的条件）：

以上测试结果表明，通过咱们的优化后，在图超级点查问耗时上，获得了十分优异的体现。

4.4.2 边采样优化

针对不能简略做「limit 截断优化」的场景，咱们能够采取「边采样优化」的形式来解决。在 Nebula 社区原生反对的“storage 过程级别可配置每个 vertex 最大返回出度边和开启边采样性能”根底上，咱们优化后，能够进一步反对如下性能：

1. storage 开启采样性能后，可反对配置扫 max_iter_edge_for_sample 数量的边而非扫所有边（默认）
2. graph 反对 go 每跳出度采样性能
3. storage 和 graph 的“采样是否开启 enable_reservoir_sampling”和“每个 vertex 最大返回出度 max_edge_returned_per_vertex”都反对 session 级别参数可配

通过以上性能的反对，业务能够更灵便地调整查问采样比例，管制遍历查问规模，以达到在线服务的平滑性。

4.5 查问客户端的革新与优化

开源的 Nebula Graph 有本人的一套客户端，而如何将这套客户端与快手的工程相结合，这里咱们也做了一些相应的革新与优化。次要解决了上面两个问题：

• 连接池化：Nebula Graph 官网客户端提供的底层接口，每次查问都须要建设连贯初始化、执行查问、敞开连贯这些步骤，在高频查问场景中频繁创立、敞开连贯极大地影响着零碎的性能与稳定性。在实践中，通过连接池化技术对官网客户端进行二次封装，并对连贯生命周期的各个阶段进行监控，实现了连贯的复用和共享，晋升了业务稳定性。
• 主动故障切换：通过对连贯建设、初始化、查问、销毁各个阶段的异样监控和定期探活，实现了数据库集群中的故障节点的实时发现和主动剔除，如果整个集群不可用，则能秒级迁徙至备用集群，升高了集群故障对在线业务可用性造成的潜在影响。

4.6 查问后果的可视化及下载

针对固定关系的查问（写死 nGQL），前端依据返回后果，进行定制化的图形界面展现，如下图所示：

这里前端采纳 ECharts 的关系图，在前端的图构造数据加载及展现这里也做了一些优化。

问题一：关系图须要能展现每个节点的详情信息，而 ECharts 提供的图里只能做简略的 value 值的展现。

解决方案：在原代码上进行革新，每个节点增加点击事件，弹出模态框展现更多的详情信息。

问题二：关系图在点击事件触发后，图会有较长时间的转动，无奈识别点击了哪个节点。

解决方案：获取首次渲染图形时每个节点的窗口地位，在点击事件触发后，给每个节点地位固定下来。

问题三：当图的节点泛滥时候，关系图展现的比拟拥挤。

解决方案：开启鼠标缩放和评议漫游性能。

针对灵便关系的查问（灵便 nGQL），依据部署的 Nebula Graph Studio 进行可视化的出现，如下图所示：

五. 图数据库在平安情报上的实际

基于以上图数据库的构造与优化，咱们提供了 Web 查问和 RPC 查问两种接入形式，次要反对了快手的如下业务：

• 反对快手平安的溯源、线下打击与黑灰产剖析
• 反对业务平安的风控与反作弊

例如，群控设施与失常设施在图数据上的体现存在显著区别：

对于群控设施的辨认：

六. 总结与瞻望

• 稳定性建设：集群 HA 能力实现跨 AZ 集群的实时同步、拜访主动切换，以保障 99.99 的 SLA
• 性能晋升：思考革新 RPC、AEP 新硬件的存储计划、优化查问执行打算
• 图计算 平台 与图查问买通：建设图计算 / 图学习 / 图查问的一体化平台
• 实时断定：实时关系的写入及实时危险的综合断定

七. 致谢

感激开源社区 Nebula Graph 对快手的反对。

交换图数据库技术？退出 Nebula 交换群请先填写下你的 Nebulae 名片，Nebula 小助手会拉你进群~~

举荐浏览

• 【美团图数据库平台建设及业务实际】
• 【Nebula Graph 在微众银行数据治理的实际】
• 【图数据库选型 | 360 数科的图数据库迁徙史】