Paper Digest｜OpenSPG 超大规模知识仓储 KGFabric 论文解读

概述

2024年8月26日，数据管理与数据库领域的顶级国际会议VLDB 2024在广州举办。蚂蚁集团知识引擎团队的一篇论文被收录为Industry track的现场展示论文（Oral Paper），题目是《KGFabric: A Scalable Knowledge Graph Warehouse for Enterprise Data Interconnection》。

简单来说，KGFabric是一套基于分布式文件系统（DFS）的、全量知识仓储的解决方案。它采用SPG作为数据模型，能够更好地表达真实世界，同时在存储和计算效率上做了深度优化。最关键的能力是它支持Graph Fabric——在保护用户隐私的前提下实现多域图谱的融合，直接击中了知识图谱“数据孤岛”的痛点。与主流的关系型DBMS和图数据库相比，KGFabric在语义关系的存储空间上减少了90%以上；在实际工作负载中，图融合的性能提升了21倍；在多跳语义图分析任务中，性能甚至提高了100倍。

01 概述

在蚂蚁集团内部的实践中，团队构建了蚂蚁知识图谱平台。这个平台上涵盖了商户、公司、账户、产品等多个领域的特定知识图谱，管理着数万亿的结构化知识图谱，为搜索、推荐、风险控制等业务提供支撑。平台提供基于跨领域知识复用的多种企业级知识管理能力，支持多样化图谱业务的自助接入，并支撑了多种下游服务和图推理、图分析应用，线性扩展能力已经超过千亿量级。

随着平台不断迭代，跨域图谱融合、图匹配和图表示学习等任务对系统能力的要求越来越高，传统的数仓系统（比如ODPS）和图数据库逐渐力不从心。于是，我们提出了超大规模知识仓储的解决方案——KGFabric。它采用SPG（Semantic-enhanced Programmable Graph，语义增强可编程框架）作为数据模型，基于分布式文件系统提供了原生知识图谱存储和多域知识图谱融合能力。底层文件存储设计了一套混合存储格式，设计之初就兼容了多种图模型和超级点的存储与处理，分别为属性图和语义图实现了CSR索引和三元组索引。更妙的是，底层完全使用POSIX API实现文件I/O操作，这使得跨多云环境的部署成本很低。

02 基于SPG的建模

KGFabric采用SPG作为数据模型，它的语义与属性图兼容。SPG源自蚂蚁知识图谱平台多年支撑金融业务的沉淀，是一种基于属性图的语义框架。它创造性地融合了属性图的结构性和RDF的语义性——既克服了RDF/OWL语义复杂、难以工业落地的障碍，又充分继承了属性图结构简单、与大数据体系兼容的优势。

为了增强属性图中节点类型的语义表达，SPG在属性图的节点类型和边类型之上，引入了更多主体分类模型来扩充节点类型，以兼容更多元的知识表示。在SPG中，主体分类模型大致可以这样理解：

• 实体：
  业务相关性较强的客观实例，通过属性、关系刻画个体画像，比如用户、企业、商户。下图中的User就包含若干属性且与Shop相连。

• 概念：
  实体从具体到一般的抽象，表达一组实体集合或一种分类体系。相对静态，复用性很强，比如人群标签、领域标准类型。下图中的Concept.Prefer就是一个例子。

• 事件：
  加入时间、空间、标的等约束的实体类型，比如通过NLP、CV等抽取出来的行业事件、企业事件、诊疗事件。下图中的TransactionEvent就是事件类型。

03 核心能力

3.1 基于LSM-tree的存储架构

KGFabric的存储架构基于LSM-Tree，数据层分为Base和Delta两层。其中Delta层进一步划分为Level-0和Level-1：Level-0专为流式导入（mini-batch）优化，比如从消息队列导入；Level-1主要针对批量导入场景，比如从Hive或ODPS导入。为了平衡读放大，后台运行Tiering Compaction，定期重整并压实数据。在蚂蚁集团内部，每天有超过1000个数据导入任务，这套Compaction策略将随机读和顺序读的读放大分别控制在5倍和1.6倍以下。

KGFabric的目录层级主要包含：

1. Namespace：
   业务数据管理的基本单位，用于实现不同领域图谱的数据隔离。

2. RelationGroup：
   管理图谱数据分组，通常基于实体、关系或事件时间切片来分组。

3. Base：
   管理周期性快照数据。

4. Delta：
   管理流/批更新的增量数据。

版本管理依赖文件系统的put-if-not-exists语义，通过VersionPointer机制解决读写冲突。导入任务成功后，KGFabric自动创建新版本文件，通过时间戳映射相应版本文件，实现任意快照访问。current文件始终记录最新数据版本。

3.2 为语义图优化的File Format

实际的图谱数据承载在RelationGroup目录中，包括若干数据文件和对应的元数据。数据文件分为PGFile和SGFile，分别存储属性图数据和语义图数据。布局上，PGFile和SGFile都由Footer和文件内的BlockIndex组成，内部则分别存储PGBlock和SGBlock——它们是基本的写入和压缩单位。

PGBlock主要存储属性图。内部包含点表（VertexTable）、边表（EdgeTable，含出边和入边）和属性表（PropertyTable），采用CSR索引格式进一步压缩子图数据。属性表支持行或列存储格式，并使用位图矩阵标识NULL值属性。在PGBlock内，通过点切分方式将超级点（度数很高的边，通常超过10万）的稠密边分配到若干个PGBlock中分别存储。下图中的vid2在block#1和block#95分别触发了两次切分逻辑。这解决了超级点在加载和计算时的内存瓶颈，提升了按关系类型加载边时分组limit的I/O效率。

在KGFabric中，语义图的存储包含三个组件：

• 概念词典：
  提供ConceptName和ConceptID之间的双向映射。

• 语义属性：
  在PGBlock中，不再用边表存储语义实体到概念的边，而是用属性表存储ConceptID来记录实体与概念实例的链接，优化存储空间。

• TripleIndex：
  表示概念到语义实体的边。由于这些边通常比较稠密，采用RoaringBitmap来优化存储空间和计算性能。基于TripleIndex实现了概念的多维索引，支持AND/OR/NOT等bitwise算子，并支持基于分桶的并发计算。

3.3 Graph Fabric

传统Data Fabric大多基于数据冗余实现，意味着跨集群之间的数据拷贝。而KGFabric中的Graph Fabric框架在避免冗余拷贝的同时实现了多域图谱融合。只需选取待融合的实体类型，再指定链指或融合算子，Graph Merge Tree（GMT）就能自动构造出虚拟类型FuseType。用户透明地使用该虚拟类型，实现基于Fuse-On-Write（FOW）或Fuse-On-Read（FOR）的图谱融合。GMT是Graph Fabric的核心数据结构，逻辑上是一棵多叉树。FOR的过程可以抽象为对树的后序遍历。在后序遍历中，还集成了AntPrivacy API，在Graph Fabric执行之前对数据进行属性粒度的加密，有效保障图谱融合过程中的用户数据安全。

3.4 图分析系统集成

为了优化金融场景下的负载性能，KGFabric可以作为图分析系统的存储后端，提供原生图检索和图加载能力，避免分布式构图场景下shuffle的额外开销。具体优化包括：

• 分区图加载：
  实现分布式图谱数据加载，支持多种图切分方式（按VertexID切分、按存储BlockSize切分等）。相比ODPS或Hive省去了数据shuffle环节，大幅提升读取性能。

• Backend Cache：
  包含meta cache和data cache。meta cache缓存RelationGroup的meta和BlockIndex，为常驻任务优化；data cache包含两级缓存——常驻磁盘的全量缓存和内存中的Block缓存，为延迟敏感的任务优化。

• 算子下推：
  支持filter/aggregate/window等图算子的下推。filter算子支持实体/关系/属性类型的下推，可下推到GMT的叶子结点（即RelationGroup的读取）；aggregate支持sum/max/min/count等统计下推；window算子支持基于时间切片的事件和索引的filter算子下推。

• 零拷贝序列化/反序列化：
  实现内存数据结构和磁盘数据结构的同构，降低序列化和反序列化的开销。

04 实验评测

为了评估系统性能，团队进行了存储空间、图分析效率和Graph Fabric扩展性实验。

4.1 数据集

主要选用LDBC-Finbench作为属性图（LPG）数据集，并通过为LDBC-Finbench添加语义关系，扩展出新的数据集LDBC-Finbench-X作为语义图（SPG）数据集。另外从生产场景选取了用户图谱、商户图谱和资金图谱作为真实数据集。各数据集的度数分布如下：

（注：原文中此处应有度数分布图，保留原图描述）

4.2 存储空间

对属性图数据集，KGFabric的存储空间占用仅为Neo4j的43.7%，为RocksDB的91.7%。对语义图数据集，KGFabric得益于强Schema建模，大幅优化了语义关系的存储开销，空间占用仅为RocksDB的7%，Neo4j的1.9%。

4.3 图分析效率

主要选用了pairwise path和cycle pattern两种典型的图分析任务，对比对象是ODPS、Neo4j和RocksDB。在pairwise path实验中，随着分析任务跳数增多，KGFabric提供的backend能大幅度提升图计算的扩展性。在cycle pattern实验中，受益于低构图成本，KGFabric最多可将3跳环路分析的耗时降低67.8%。

4.4 Graph Fabric扩展性

对于默认链指策略（IDE），随着数据源增多，相比ODPS，KGFabric表现出良好的扩展性。为了优化用户自定义链指策略（UDL）的性能，实现了rindex对数据进行预排序，进一步降低延迟。