FinBench：金融场景下的图系统选型

畅谈Fintech 2023-05-05

351

导读 FinBench，全称 Financial Benchmark，是蚂蚁集团基于业务实践总结出来并在 LDBC 组织下多厂商共同建设的金融图场景系统基准评测，本次分享题目为《FinBench：金融场景下的图系统选型》，该文章内容基于 TuGraph 社区 MeetUp 演讲实录整理。

全文目录如下：

1. FinBench Background

2. FinBench Scenarios

3. FinBench Design

4. FinBench Chokepoints

5. Progress and Plans

FinBench Background

首先来介绍一下 FinBench 的背景。

1. Why Benchmark?

不同的数据库具有不同的特性表现，例如查询语言有 Cypher，Gremlin 等，图模型有语义的 RDF 和属性图，计算场景上分为 TP、AP、HTAP，数据库的场景和功能都是多种多样的。用户选择使用哪一个数据库与怎样构建整体的业务解决方案，这两个问题相生相成，业务方和用户很难严谨地对比这些数据库。

Benchmark 提供了一个真实的场景，有一些特殊的数据 pattern，或者计算测试 case 的 pattern，帮助去测试系统，来验证这些系统的功能的正确性、性能、稳定性等。比如 TPC-C 是在关系型数据库（RDBMS）领域中比较经典的一个 Benchmark，它描绘了一个供应链/零售场景去对系统进行测试。

2. Benchmarks by TPC for RDBMS

发展比较早的 TPC 是关系型数据库领域的 Benchmark 组织，其下的 Benchmark 有 TPC-C、TPC-H 和 TPCx-AI 等。比如 TPCx-AI 是专门面向端到端的以 AI/ 数据分析为核心的一个 Benchmark。TPC 通过定义各种各样的 Benchmark，同时对外提供 audit 服务，能够从功能、性能、开销、性价比等多方面对各个数据库进行对比。

3. Linked Data Benchmarks by LDBC

新兴的图领域，有一个类似 TPC 的组织叫做 LDBC，全称为关联数据委员会。在之前，LDBC 已经定义了比较多的 Benchmark，比如 SPB 是用于 RDF 数据库的 Benchmark。还有 Graphalytics 包含了一些标准的图算法，主要是面向 AP 系统作图计算分析系统的 Benchmark。大家了解最多的可能是 SNB，它用社交网络的场景来对基于属性图的 GDBMS 进行测试的 Benchmark。在与蚂蚁集团内部的金融场景进行总结对比之后，我们认为金融场景和 SNB 的社交场景有一定的差别，所以在去年向 LDBC 提出提案，现在与多家厂商一块共同建设这个 Financial Benchmark，能够模拟金融场景对 GDBMS 进行测试。

4. Data Processing Pipeline

在数据处理流程中，往往会有一个偏 TP 的、在线的系统，有实时的数据写入，处理偏 TP 的查询/数据写入。对于相对复杂的图分析，通过某种方式把数据从 TP 系统 ETL 到另外的 AP 系统中，跑一些分析迭代类的算法。还有一些情况下的较复杂的查询，相比于全图分析计算复杂度没有那么高，但由于某些原因不能在 TP 系统中进行查询，那么就会构建第二个 AP 系统去处理。此系统处理的查询往往比 TP 复杂，但又没有到全图迭代级别的计算，这就是 SNB 中 BI 和 Interactive workload 的区别。在 FinBench 中，我们也分别总结出了两个 FinBench workload，一个 Transaction workload 是今年着力建设的 workload，另一个 analytics workload 是计划未来建设的工作。

FinBench Scenarios

1. Risk Control Scenario: Transfer Cycle

这部分从几个比较典型的场景切入来介绍 FinBench 的设计理念。

第一个场景是风控场景。为了做交易风控，我们往往会构建一个图，其中点是账户，比如有个人账户或者公司账户等等，账户往往会有账户信息、状态信息等等。边是账户到账户之间的转账关系，转账关系上会有常见的业务属性，比如这笔转账是什么时候发生的，转账金额是多少。有这么一个建模的图之后，业务人员就可以在这个图上进行风控策略的设计，比如可以通过转账行为或者关联账户的情况判断一笔交易是否存在一定的风险。这是在风控场景下的图建模。

上图中右侧是一个转账环的例子，这个转账环就是一个业务层面的风控策略对应在图上的特征。

这里在业务流程上，业务人员会遇到一个问题：有一个转账边要写入的时候，业务人员首先检测是否存在一个转账环，当转账环构成（这笔交易可能会涉及到一些危险场景）时，希望终止这笔交易，同时把相关的账户状态标记为一个异常的状态，给业务的下一个流程进行反馈。直接处理这类查询的结果是，即使检测到风控策略命中了，转账也已经写入到 db 里面了，我们不希望这样的事情发生。如果不把转账关系直接写入到 db 里面，就需要把风控策略对应的图上的特征做翻译，比如先假设当前的交易不存在来检测这笔交易发生之后是否形成一个转账环，业务人员需要在这里对风控策略做“翻译”后再去检测这个图上特征，以满足风控需求。

2. Read-Write Query: Transaction-Wrapped Strategy

针对上述场景，我们提出了 Read-Write Query，从业务层面来解释就是用 Transaction（事务）包裹的风控策略。这类 Query 把风控策略、转账边的写入都放在一个 Transaction 中。具体例子比如，在 Transaction 内先检测涉及到的相关账户是否状态异常，如果状态异常，那这笔交易肯定是有问题的，就把这个 Transaction 直接退出，对应的交易就被驳回了。如果涉及到的账户状态都没有问题，则进行下一步，在这个 Transaction 中把转账边写入，再去分析是否命中业务 pattern，如果命中 pattern，那么交易有问题，就把这笔 Transaction 退出，随着 Transaction 的退出，这笔交易自然也不会写到 db。同时会开启一个新的 Transaction，把相关账户的状态标记为有问题。如果转账关系写入后发现业务 pattern 并没有命中，那么就提交 Transaction，交易边可以顺利的写入到 db。这就是为了方便业务人员写风控策略而做的 Read-Write Query 设计。

3. Risk Control Scenario: Fund tracing from Loan

上图展示的是一个模拟资金追踪溯源的场景。图上特征是贷款发放后，把一定时间范围内的资金去向相关的交易边过滤出来，比如示例中红色边就是相应时间窗口之外的交易边，在分析过程中就要过滤掉。示例中，将黑色的交易边过滤出来之后，根据各级账户各条边上的交易金额，与上一级账户的资金流输入金额进行比例计算。

这类图上的计算有两个重要的特征，第一个点在遍历时的过滤上，我们称之为 recursive filtering。它是在筛选一条路径的时做一个递归的判断，假设存在一条路径，这个路径上的时间顺序是 e₁<e₂<e₃<...<e_i，在金额上的顺序是 e₁>e₂>e₃>..>e_i，另外时间窗口上，上一跳跟下一跳的时间要落在一个时间窗口之内（如时间差不超过一天）。第二个点是在计算上，在计算上明显的特征是在路径上基于当前边回溯计算到上一跳（上游边）资金浓度的特征。这是贷后追踪贷后资金浓度计算的典型场景在图上特征的总结。

FinBench Design

接下来，介绍 FinBench 的主体设计。

1. A Glance of FinBench

在 data 特性上，数据模型仍是关联数据建模（点由边去进行连接），点边都具有一些属性。边上有一个特性叫做 Edge Multiplicity，指的是在相同的起点和终点之间可能会存在多条重复边，数据分布上有大点。在测试集上的特性有图上遍历、Read-Write Query，基于时间的数据管理等。在负载上，模拟真实世界的负载来对系统进行测试，同时提供不同规模的负载。

在 Benchmark Suite 建设上，主要有四个组件分别是 DataGen，Driver，Reference Implementation 以及 ACID Suite。DataGen 的主要功能是生成测试数据，包括存量数据和增量数据，存量数据由测试系统进行批量载入，增量数据会交给 Driver，由 Driver 分析后以 Query 的形式发到测试系统，由测试系统接收这些数据进行写入。ACID 测试是相对比较独立的对测试系统进行测试。

2. Data Schema Design

图模型建模上目前主要是有五类点，虚线边代表的是 Edge Multiplicity。

3. Data Distribution Design

数据分布上，我们对一些真实的线上系统存储的数据做了一个侧写，从侧写的结果来看，有如下共性结论，average degree 即平均的度数大概是分布在 1 到 3 之间，平均是2。大点的度数基本上是在百万级别，也就是有百万条边。整体图上度数的分布符合 PowerLaw 幂律回归的特征。同时我们也对有时间戳的边的时间分布做了分析，可以看到这些边在时间上的分布是符合现实生活中的预期的，基本上分布在早中晚高峰。

4. Transaction Workload

Transaction Workload 有四种 query：Complex Read Query，Simple Read Query，Write Query，和 Read-Write Query。Complex Read Query 相比 Simple Read Query 的计算会稍微复杂一点，它是从典型的风控或者商业分析的场景中总结出来的。Simple Read Query 往往是一些比较简单的查询。Write Query 是数据的写入，包括插入、更新、删除。Read-Write Query 总结出来了三个 query，是 FinBench 的一个亮点。

① Transaction Workload：Read-Write Query

Read-Write Query 的设计如上图所示，前面已经通过业务上的例子详细介绍过了，这里就不再展开介绍。Read-Write Query 由不同的 Read Query 和 Write Query 组成，将这些 Complex Query 包裹在一个 transaction 中，来满足风控业务人员的需求。

② Transaction Workload：Temporal Window

第二个 FinBench transaction workload 的特性是 Temporal Window。在做数据分析或者过滤时，我们往往会关注更靠近当前时间的数据，这就是一个时序窗口。在图上的表现是，在做查询的时候对边上的时间做起始时间到结束时间的过滤约束。在具体的业务实践中，大家往往会选择做优化，比如存储分级把冷数据热数据做分开存储，或者做 TTL 把一些过期的数据做淘汰。

③ Transaction Workload：Special Patterns

这是 FinBench 总结出的一些比较特殊的 pattern，比如左上角是一个转账环，右上角是一级二级账户的呈树状结构转账关系。下面是一个担保链，比如对企业做担保关系的穿透。

④ Transaction Workload：Recursive Path Filtering

这是在贷后追踪场景中，有 Recursive Path Filtering 的特征，在上文也做了具体的介绍，不再赘述

5. Load Pattern in Real System

这里是对负载设计的总结。我们对一些业务系统做了持续长达一个月以上的监测，发现负载的波动遵循着以天为周期的变化。同时我们也对点边的负载做了分离的分析，可以看到点边的负载以及读写的负载也是存在差异的。

6. Load Pattern (Driver Design)

Driver 设计上，Driver 向测试系统发出查询请求，将有不同的 query 按照一个策略混合在一起发给测试系统，FinBench 中有 n+2 个 stream，一个 stream 用来单独地发 Complex Read Query，一个 stream 用来发 Read-Write Query，n 个 stream 用来发写的 Query，来保证读写的比例是平衡的。在负载规模的控制上，Driver 基于 TCR 参数保证系统能够在不同的负载下得到测试。

7. ACID Test Suite

ACID 测试在工业界或者学术界都是一个比较标准成熟的设计。原子性和隔离级别的测试都是基于 Fail Case 进行测试的。Durability 测试上，ACID Suite 分别对系统做 graceful（有缓冲时间/宕机）和 ungraceful（无缓冲时间/宕机）的情况来分别对系统进行测试。Consistency 上的测试和 Durability 结合在一起进行测试。

FinBench Chokepoints

1. Chokepoints in FinBench

Chokepoint 是 LDBC 在创立之后就一直在宣传的一个概念，指的是在 Benchmark 设计过程中，对问题场景总结出来的一些技术上的挑战，这也是数据库的开发人员需要去考虑进行优化的方向。这里列出了 FinBench 的一些 chokepoint。

2. Examples of Chokepoints in FinBench

接下来展开介绍其中两个 chokepoint。

比如贷后追踪的 Recursive Path Filtering 的过滤特征是这样的。现有的查询语言事实标准 Cypher 在表达这个过滤的 pattern 时没有很好的表达能力。我们希望的是，查询语言在这个场景下能够有好的表达能力。这里有一个例子，是某个实验室正在做的尝试去改善的 Cypher 的一个扩展，尝试从一些关键字上去解决表达的问题。

在存储上，我们在边上都是有时间戳属性的。为了保证在对时间进行过滤的时候数据访问有比较良好的局部性，我们可以做一些优化，比如在存边的时候把时间戳作为边上的一个 ID，对这个边进行排序存储，那么在数据访问的局部性就会比较好。

Read-Write Query，其表现是一个 Complex Query 并上一个比较短的 Write Query，在表现上来说，它大部分的时间可能是在读，小部分时间是在写，针对 Read-Write Query 的情况，可以做一些优化。比如把前一个 Read-Write Query 的读和下一个 Read-Write Query 的读并行起来，并行后可能会出现最终在写入数据的时候有一些竞争或者冲突的情况，这里也是有各种优化手段的。

Progress and Plans

1. FinBench Progress