关于作者：郝鑫，Airwallex 空中云汇风控平台工程师，nebula-go Maintainer.自 2023 年底起，重点做图计算相关工作，业务场景侧重于风控。
![图片]()
本文首发于「NebulaGraph 技术社区」公众号，了解更多 NebulaGraph 产品信息，请访问官网
一、Airwallex 空中云汇
作为知名的全球支付及金融平台，Airwallex 空中云汇致力于为企业提供一站式跨境支付解决方案。
我们从实际业务场景入手，来让大家更了解 Airwallex 空中云汇。大家平时在购物、玩游戏、订阅视频网站平台，或者使用一些付费软件时，都会有不同产品下的跨境支付场景，包括刷卡支付或者定时订阅支付。这些支付服务的提供方包括游戏公司、电商平台，或者其他平台上的商户。
而 Airwallex 空中云汇，其实就站在这些企业的背后，为这些企业提供收单、收款以及资金管理相关的服务。
![图片]()
在跨境场景下，我们面临的客户形式和背景会非常多样化。
一方面其中有一些客户是游戏公司，面向不同国家的用户提供一个提供游戏内购款相关的产品；还有一些是电商平台，包括自营平台和类似于淘宝这种为不同商户提供服务的平台。
另一方面我们的客户不仅仅是这些平台本身，还包括平台上的商户。这些商户在法律上是一个独立的商业实体，所以我们需要对这些实体有非常清晰明确的认识。
![图片]()
以上展示的是一张从公司官网上摘录的 UI 界面，帮助大家感受 Airwallex 的业务场景。
二、NebulaGraph 的应用场景
我们把 NebulaGraph 的使用场景分为四个主要类目：
![图片]()
（一）客户关系洞察
刚才已经简单提到，在跨境场景下，不同国家的法律法规有其特殊性，商业实体是法律上的基本单位，我们需要对这些实体进行分类和关联。这有助于我们了解客户所在地的法律法规和业务范围，确保合规性。
1. 个人信息关联
2. 设备信息关联
涉及客户使用的设备，如 IP 地址、设备 ID 等。这些信息可以帮助我们识别异常登录行为，例如从不寻常的地理位置或设备进行的登录。
3. 网络信息关联
包括客户的网络行为和交易模式。通过分析客户的网络活动，我们可以识别异常的交易模式或潜在的风险交易。例如，频繁的大额交易或在短时间内从多个不同地点进行的交易都可能引发警报。
4. 人脸信息关联
这是生物识别技术的一部分，用于验证客户身份。
（二）实时交易关联
我们实时交易的时候，需要用 NebulaGraph 进行一些交易的关联。
设备信息关联，与 KYC 场景下的设备信息关联存在差异，这里的设备信息主要来源于集成了 Airwallex SDK 的支付组件。当用户进行支付操作时，会应用 Airwallex 不同平台的 SDK（移动端，网页端等），用户追踪设备 ID，设备型号，IP 地址等信息。
支付和收款信息的关联主要用于验证交易的合法性和安全性；在电商环境下，账单信息关联是识别异常购买模式和潜在欺诈行为的关键，而物流信息关联主要用于追踪商品流向和确保交易的完整性。
（三）模型特征提取
在模型特征提取方面，我们并不是直接使用原始数据，而是先对数据进行处理，生成特征。这些特征随后被用于不同模型的训练和实时推断。在线图服务运行时，会定期生成数据快照用于模型训练，同时在线服务也需要实时接口来计算特征，用于模型推断。
（四）可视化交互
我们目前的实现较为简单，主要面向内部运营人员。我们提供了一些 Web 页面，允许运营人员根据自身需求输入信息并进行操作，以实现按需查询和交互。
三、Why NebulaGraph？
（一）背景
上述提到的客户关系洞察（KYC，Know Your Customer）是风控领域确保客户身份真实性和评估其风险状况的重要流程。它不仅在新客户注册时进行，还贯穿于客户整个生命周期，以应对客户资料或交易行为的变化。
KYC 的核心在于验证客户身份、了解其财务状况和风险特征，从而防止欺诈和金融犯罪。
![图片]()
图关系是 KYC 的自然表征。通过图数据库，可以将客户、账户、设备、交易等信息以节点和边的形式进行建模，直观地展示客户之间的复杂关联。例如，法人与商业实体的关联、账户与设备的关联等。这种结构化表示不仅提升了数据的可读性，还使得异常行为的识别更加高效，比如通过关联分析发现潜在的欺诈链条。
因此，我们使用 NebulaGraph 其实是一种非常水到渠成的选择。
（二）面临的问题
在引入 NebulaGraph 之前，我们使用的是一个简单的 Python 图服务，主要用于处理一些基础的图关系应用。当时公司还处于早期阶段，数据量相对较小，因此我们从离线数仓中读取所有数据，通过传统的操作提取点和边的信息，并将其存储在内存中构图。
![图片]()
这种架构在数据量较小时表现尚可，但随着业务的发展，逐渐暴露出一些问题。
首先，稳定性不足，因为需要定时更新数据，每隔 10 分钟就需要重新读取和构图，这个过程容易出现故障。其次，内存效率较低，尤其是在数据量逐渐增加的情况下，内存占用成为一个瓶颈。此外，查询语言的表现力有限，无法满足复杂场景的需求，导致开发效率低下。这些问题促使我们考虑引入图数据库来解决业务中的挑战。
（三）NebulaGraph 选型
![图片]()
当时在选型时，我们对比测试了多个图数据库。我们淘汰了性能测试中表现不佳的一些图数据库，即使个别图数据库与 NebulaGraph 性能接近，但在功能全面性上有所欠缺。此外， NebulaGraph 拥有丰富的企业应用案例也是我们选择它的重要因素。
四、系统架构设计
（一）客户关系系统架构
客户关系的构图
![图片]()
如图所示，我们对账户节点进行了高度简化。实际上，我们内部的账户信息是一个层级结构，因为每个子账户实际上都是一个独立的公司。
我们构建的是一个异构图，这种结构有几个显著的优点：
1. 易于满足不同的查询场景
异构图能够灵活地适应多种查询需求。例如，我们可以轻松地查询某个账户的关联信息，或者分析账户之间的交易模式。
2. 易于引入新的关系类型
随着业务的发展，我们可能会遇到新的数据类型或关系。异构图的灵活性使得添加这些新的关系类型变得相对简单，只需要在图中添加相应的节点和边。
3. 易于结合 TTL 进行数据清理
TTL（Time to Live）机制可以帮助我们自动清理过期的数据，确保图数据库中的信息保持最新和相关。
在过去的几年中，我们不断引入新的关系类型，使得我们的图结构比上图上显示的更为丰富。这种灵活性不仅满足了我们当前的需求，还为未来可能的新发展提供了便利。我们可以在不同的边上配置不同的属性和权重，以便进行更精细的数据分析和清洗。
系统架构
![图片]()
- 数据写入
- Schema First
我们的图服务主要用于以下几个方面：
- 模型特征提取
我们需要实时进行客户分析，以及其他不同场景下的交易和用户行为分析。
- 规则引擎
这是我们内部的一个风控引擎，通过图的特征数据进行规则处理，最终做出不同的判断。
- 业务服务
内部的其他业务服务可以利用图数据库的数据进行相应的处理。
- 可视化
提供一些界面让运营人员进行查询和分析。
业务复杂性
![图片]()
- Schema复杂且易变
- 数据逻辑变更与清洗
- 数据清洗和逻辑变更需要一个易于操作的流程，以应对业务的快速变化。
应对策略
- 一处定义，动态生成
- TTL + 全量写入
- 使用 TTL 机制结合全量写入的方式，确保数据的时效性和完整性。
![图片]()
我们采用了一种 Declarative 的 Schema 管理方式。 当我们对一个字段进行命名、添加、属性信息进行修改的时候的时候，会在内部自动生成相应的变更语句。
![图片]()
在查询结果映射方面，我们采用了“声明即所得”的方式。
通过在代码中定义结构体，并使用注解直接映射查询结果中的字段，查询结果会自动填充到对应的结构体字段中，无需手动处理字段映射。此外，通过 SDK 或接口动态获取字段信息，确保每次查询都能正确映射到最新的 Schema，避免了因字段变化导致的查询错误，提高了系统的稳定性。
（二）交易关联系统架构
![图片]()
![图片]()
![图片]()
在交易关联系统中，与客户关系系统存在较大差异，在这里，我们对实时性要求更高，因此我们采用了分离计算、读时合并的架构。
历史数据（超过 4 小时）通过小时级批处理进行预计算，生成子图的点边信息，并存储在图数据库中。实时数据（4 小时以内）则通过 Kafka 实时获取上游交易的原始数据，在服务端进行拆分和构建后写入 NebulaGraph.
五、未来展望
![图片]()
目前，单一 Nebula 集群在计算资源隔离方面存在不足，导致不同应用间的查询峰值会相互干扰，且一套集群无法同时满足 TP（事务处理）和 AP（分析处理）的目标。此外，图算法的支持也存在一定的开放性不足和生态不够丰富的问题。
在未来，我们希望能够改善这些问题，通过更好的资源隔离技术和更丰富的图算法生态，来提升系统的性能和可用性。我们期待与社区和其他开发者一起合作，共同推动技术的发展和生态的建设。
「ps：本文整理自 Airwallex 在 NebulaGraph 社区 nMeetup 上的分享，Airwallex 目前已升级为 NebulaGraph 企业版」
✦
如果你觉得 NebulaGraph能帮到你，或者你只是单纯支持开源精神，可以在 GitHub 上为 NebulaGraph 点个 Star！每一个 Star 都是对我们的支持和鼓励✨
https://github.com/vesoft-inc/nebula
✦
