在数字化转型的浪潮中，尤其是当我们进入到大数据的高级阶段，也就是深数据时代以后，图数据库以其在处理复杂数据关系方面的独特优势，正逐渐成为金融等行业的重要底层技术工具。银行业作为数据要素密集型行业，很多银行很早开始了对图数据库的尝试、探索和实践。
据我们调研交流，多数银行对图数据库的学习和认知基本都是最老牌的Neo4j社区版开始，像招行、平安这样的数字化转型在同业领先的少数银行，甚至采购了商用版Neo4j，个别国有大行这两年还采购了2017年开始商业化的TigerGraph，其他进入业务管理应用实践的银行，有的采购的是互联网大厂科技输出的自用产品，有的采用的是国内其他的一些不甚知名的独立品牌，但多数的银行尤其是中小银行基本还停留在知识图谱项目+社区免费或开源套壳图数据库底座的阶段。总体看，市场情况比较复杂，各家银行认知情况和实践程度差异比较大。
就像2023年ChatGPT刚出来国内就开始上演百模大战，在国内图数据库和图计算技术（本文合称为“图技术”）研发及运用领域，这种类似情况早在十年前就开始了，只是应用领域主要是2B，尤其是2大B，很多人不甚清楚而已。自从Neo4j于2011年推出免费社区版（注：社区版并非开源版本，Neo4j 从来没有把核心层代码开源，而社区版所谓的开源内容仅限于服务层、接口层代码），特别是2012年google提出知识图谱概念，图技术在互联网领域快速运用，并逐渐向金融、政府、产业等大型用户场景快速扩散。在大模型技术突破和基础大模型产品问世之前，知识图谱一直是一枝独秀，代表着人工智能技术运用的主流路径。到现在，多数人还把图技术混同于知识图谱，其实知识图谱只是图技术的应用场景之一，更多的应用场景正在逐渐被挖掘出来。Gartner2021年的一份报告表示，图技术在数据分析领域会被广泛运用，在 2025 年将有 80%的创新型智能分析场景中运用到图技术。
目前图技术产业链生态总体看不太健康，市场比较混乱，不少金融用户走了弯路甚至踩了坑。无论是上游的图技术厂商，还是下游的图技术应用企业，基本都缺乏底层技术自研能力，图存储和图计算引擎要么是非原生的、多模式的，要么是基于Neo4j社区版或开源的 Janusgraph、ArangoDB 进行套壳改造而来的。就是看似无所不能、四处出击的互联网大厂们，基本也是自身场景特征和自主可控的需要，基于传统关系型数据库或Apache Spark等大数据框架搭建的技术架构（知乎上有不少文章可供阅考）。放眼过去，真正从第一行代码开始进行内核开发、架构创新并且实现工程化的，寥寥无几，而拥有高密度、高并发硬件加速性能的更是凤毛麟角，嬴图XAI就是在大量真实而复杂的金融场景中得到技术性能验证，并且拥有众多首创性解决方案能力的，金融级高性能图技术引擎产品。关于这一点，我们都能通过过去几年的产品研发实践、用户测试场景、技术创新运用中一一证明，而不是自话自说、自吹自擂。
01 | 为什么Neo4j在金融场景中基本沦为入门级的玩具
必须承认，Neo4j作为最早的、开创性的原生图数据库产品，对于带动图技术认知和应用起到了先驱者的作用，其知名度是最高的，当然这和最早发布免费社区版有很大关系（不少人的认知还停留在根据Github社区中的热度排名来评判产品好不好的阶段），另外其工具链条和技术文档也非常的成熟和完善。其真正的问题和面临的挑战在于，随着数据规模的量级增长和数据关系探索的需求深化，技术架构老化及其导致的性能瓶颈制约问题变得日益突出，难以满足金融级别的大规模数据在深度查询、复杂计算、实时交互等方面的数据处理需求。据我们的观察和银行同业技术交流反馈，在金融领域，Neo4j基本沦为了科技、研发人员学习图数据库技术的入门、实验室级别的玩具，难以堪当金融机构IT基础设施大任。
很多人都知道，Neo4j免费提供的社区版只能单机部署，而且只提供几种基础算法，只有采购商用版才提供集群化部署和算法库。银行用户利用社区版只能做一些小规模数据的探索和离线分析。出于业务稳定运行等方面的现实考虑，即便是中小银行，也无法真正以此为技术底座去开发搭建生产级上层应用系统。即便采购的是集群部署的分布式商用版，计算性能也基本相当拉跨，甚至因为其架构设计问题迟迟无法解决，很多情况下查询时效性还不如单机版，对此，我们曾在一家银行项目实践过程中亲身感受过。究其原因，从能观察到的情况看：
其一、从底层内核看，Neo4j的开发语言难以实现高并发。Neo4j中j就是指Java。顾名思义，其产品内核是用Java语言开发的。从底层内核的角度来看，Neo4j的设计和实现在一定程度上受限于其采用的Java语言。Java虽然是一种强大的通用编程语言，适用于构建可移植和面向对象的应用程序，但它在处理性能密集型任务时可能不如更接近硬件的语言高效。在编程语言的选择上，汇编语言提供了对硬件的直接控制，C和C++则因其更低的抽象级别和更高的性能而常用于系统级编程。相比之下，Java虚拟机（JVM）在运行时特性虽然优化了跨平台兼容性，但在性能和内存管理等维度上必然会有所折衷。因此，Neo4j使用Java作为内核开发语言，虽然确保了良好的可维护性和广泛的开发者基础，但也意味着其性能潜力存在一定的上限。随着数据量的增长和应用场景的复杂化，这一选择必然导致系统在高并发和大规模、复杂、深度数据处理方面的性能瓶颈。
其二、从数据结构看，Neo4j的设计存在缺陷。Neo4j的底层数据结构从来没有完整的对外公开过（这也是不少国内厂商和用户把其社区版作为开源版本来使用的不求甚解之处！）。但是，其创始人和研发团队曾经在各种采访、博客及书籍中透露过其采用 IFA（近邻无索引）类型数据结构。但是，我们知道图数据库需要解决的一个最大的技术挑战是面向热点数据，特别是超级节点时的穿透性能问题。而 Neo4j 处理超级节点时采用的是链表类型数据结构（具体表现为具有 50 个以上邻居的顶点的数据存储结构为链表）。这种数据结构的查询效率非常低，非常难以实现并发加速等优化，尤其是很难在高并发的环境下提升系统的响应速度和处理能力。
其三、从算法工程来看，Neo4j图算法架构设计存在不足，且普遍未实现高并发。Neo4j拥有大概50种图算法，这在图数据库阵营中算是非常丰富的，但其算法的工程化实践存在两大问题。第一，每次算法运行需要从持久化的磁盘层向内存进行映射，导致时效长、效率低；第二，算法实现并未充分考虑到并行处理的需求。大多数算法仍旧沿用了学术论文中介绍的串行计算方法，这在理论上虽然经过了验证，但在实际应用中，尤其是在数据量迅速增长的现实场景下，这种映射后再（非高并行）处理方式可能会形成显著的性能瓶颈。在图数据库的研究与应用中，图算法和图论占据着核心地位。学术界对算法的研究往往侧重于理论的证明和验证，而算法在实际应用中的效率和可扩展性则需要通过工程化的并行改造来提升。随着数据规模的不断扩大和应用场景的日益复杂，对算法进行并行化处理变得尤为重要。通过并行化，图数据库能够更有效地利用计算资源，处理更大规模的数据集，从而显著提高查询响应速度和系统整体性能。
其四、Neo4j的分布式技术架构已落后老化。以我们之前在一家银行看到的Neo4j分布式集群计算性能不佳的情况为例，问题主要出在集群配置和数据一致性处理机制上。其集群由三台服务器组成，采用hot-standby模式，即热备份。在这种模式下，所有读写操作集中在一台主服务器上，而另外两台服务器仅承担数据备份的任务，不参与负载均衡。这导致了一个单点瓶颈，因为所有的数据处理压力都落在了主服务器上。如果主服务器发生故障，系统需要从备份服务器中选出一台来接管，这个过程可能会导致服务中断。此外，这种三服务器拷贝的模式在资源利用上显得原始且浪费，因为多台服务器的计算能力并未得到充分利用。很显然，在 Neo4j v4.0 的早期版本中，其集群架构的设计显得颇为幼稚，对于分布式共识 RAFT 协议的实现还停留在了学术层面，在实际应用中已经远远不够先进。另，在 v5.0中 Neo4j 的水平分布式设计，也被诟病其 Sharding 的实现存在缺陷——图数据被切片后，任何深度2层以上查询的效率都可能会因为网络开销的介入而较单机版本更为低效，而对于 Neo4j 这种本身单机效率就不高的情况，分片后的效率落差更加雪上加霜。很显然，Neo4j针对现代的高并发和大规模分布式数据处理需求的优化还有很长的路要走。
其五、Neo4j缺乏应对大规模复杂数据场景的其他关键技术。以最为复杂的金融场景为例，金融交易活动是一个典型的多方参与、多环节交互的复杂网络，其网络结构中存在着大量的超级节点。这些超级节点，如金融同业、支付机构、大型企业、交易平台等等，由于其广泛的业务往来和市场影响力，成为了交易网络中的关键枢纽。它们的存在极大地增加了网络的互联性和复杂度，同时也对图数据库的查询、计算和分析能力提出了更高的要求。图数据库必须具备高效的处理技术，特别是在超级节点的穿透和动态剪枝方面，使得图数据库能够快速识别并追踪这些关键节点的交易路径，确保金融监管的全面性和深入性并及时发现潜在的风险点，也为金融机构提供精细化的风险管理和决策支持。
02 | 从实际场景对标看嬴图XAI的计算高性能
近几年来，我们在若干个性能测试和项目实践中，能够证明嬴图XAI在计算性能方面的强劲实力，是全球最新一代的图数据库产品，甚至被有的银行用户评价为汽车中的法拉利。这里举几个真实的，能够多方对标的例子及其性能数据表现。
这是一个来自某证券交易所项目性能测试的真实案例，当时国内外主要图数据库厂商都参与了其中，除了嬴图，国外的有Tigergraph 、Neo4j，国内有创邻、Nebula及其他几家，从而颇具行业代表性。本文以两个典型的计算性能测试任务为例。
这项计算任务颇具挑战性：对约4,000家上市公司和6,000家待发行企业共计约10,000家公司，以及交易所关注的约8,000位自然人（包括实际控制人、重要股东等），进行两两之间的全部最短关联路径查询，即在全量工商图谱数据集中，执行80,000,000次查询，全量计算这8,000名自然人与指定的10,000家公司之间的最短关联路径。据统计，平均每个最短路径查询返回了约上百条最短路径。这意味着，整个查询过程将返回百亿条路径。交易所要求将每一条路径以点边点的格式打包，并存储在硬盘上，最终的数据存储结果高达500GB（实际计算出的路径数据量接近100亿条）。
该项任务不仅是对系统的严酷压力测试，也是对极端复杂计算能力的挑战。我们部署了三台服务器构成的HTAP集群，总共耗时四十几分钟，而其他厂商没有一家能在一天之内顺利完成这一计算任务。从用户的角度来看，平均每一条最短路径查询的计算时间仅为0.46毫秒（460微秒），这展示了高并发环境下的效率优势。在这次性能测试中，Neo4j处理每一条最短路径查询的平均时间为0.5秒，但是查询运行时长高达数周！相比而言，嬴图系统速度提升了1,000余倍，这证明了嬴图XAI在高并发处理能力上具有显著的优势。
这项任务要求从特定企业出发，全面描绘出整个集团的股权结构。这一过程涉及对十亿级点、边规模的整个工商图谱数据集进行全量计算，以确保查询结果的完整性和准确性。尽管查询起点是单一企业，但在如此庞大的图谱中，存在众多超级节点，这对图数据库的性能提出了严峻挑战。传统的图数据库在处理此类查询时，往往会遇到性能瓶颈，导致查询进程卡顿。为了应对这一问题，其他厂商通常需要采用分步查询、采样缓存等策略（同理，大家可能用过“两查一宝”中的企业集团谱系查询功能，其层层点开的底层背后，要么是根据非最新数据预计算好的，要么只能根据最新数据分步计算）。
交易所之前使用的Neo4j，在执行超深度查询时，无法一次性穿透数十层股权结构，只能通过Cypher查询语句逐层穿透，并在每层之间缓存数据。这一过程耗时漫长，通常需要两到三个小时才能完成。以某大型房地产集团穿透分析为例，从第一层的一级子公司开始，到第四、五层时，子公司数量已达数千家。若进行全量穿透，整个投资持股路径将涉及数十万条数据记录。在不进行任何过滤（例如，只计算持股5%以上的路径）的情况下，穿透至第30层仍有62家企业，最深层可达32层。使用Neo4j进行此类查询，由于内存限制，很难观察到查询的收敛结果。
相比之下，我们的嬴图XAI引擎能够在0.2秒内完成全量计算，并生成相关统计数据。这些数据可以导出至文件供后续分析，或返回至客户端。虽然浏览器可能无法承受如此庞大的数据量，但我们的系统提供了将数据回写至数据库的选项，以支持进一步的分析和应用。对于达到30层股权的超深度穿透查询，我们的系统能够在28毫秒内返回结果，显著提升了查询效率和用户体验。
（二）软件加速弥补国产硬件性能差距
我们基于国产xinchuang服务器（我们已完成适配龙芯、飞腾等国产主流芯片），和国外典型图数据库产品基于X86服务器，在Twitter数据集上进行了性能对比测试。这里有两个要交代：
其一、数据集具有挑战性。这是国际上进行图数据库性能评测普遍采用的基准数据集，这张15亿点边的图有两大特点：一是高密度，虽然仅有4,200万个顶点，却拥有15亿条边，这意味着平均每个顶点连接着约70条边；二是顶点分布极不均匀，数据集中存在大量的超级节点，这些节点的连接邻居数超过100万。
其二、国产芯片在性能上存在一定差距。在xinchuang实践中，我们发现基于ARM架构的国产芯片在相同主频和核心数下，性能大约比Intel X86慢30%甚至 3倍。该项性能测试表明，运行在国产芯片上的嬴图系统依然在性能指标方面能够指数级超越其它国外产品。
（注：在非xinchuang条件下，国内有一些厂家也会拿他们在LDBC 的测试数据集上“屡破世界纪录”来作为谈资。但是需要注意的是，LDBC 的测试结果因为被这些厂家大量注水而导致不具有太多意义——具体表现为，LDBC 只记录 API 接口调用的返回时间，因此绝大多数的查询，国内厂家都是采用接口封装的模式，并不通过图查询语言来实现。这里面存在两个“陷阱”，1. 接口封装后面如何实现的完全是黑盒化的，可以理解为完全是 hard-coding，结果是预置缓存的，根本不是实时查询与计算的；2. 无论多复杂的查询，接口调用时间恒定为 3 毫秒，显然没有进行真正的实时计算——因为国内厂家的注水搅浑了这个领域，导致国外厂商已经不再参与 LDBC 的性能评测，并且，这个“作假”非常低级，缓存数据与采用接口调用返回结果这种所谓的“优化手段”，根本不具有普适性，采用这种方法来进行测试的厂家，可以推断，其底座必非自研。）
这是最基本的图查询操作。一开始查询效率相差不大，但是随着查询深度增加，消耗时长的差距开始迅速放大；直到6度往后出现更大的分化，只有嬴图XAI和TigerGraph才没有出现超时的情况；而到了超深度的23层，只有嬴图才能实现秒级查询。下图数据清晰可见，在查询1度邻居时，Neo4j需要大约200毫秒（0.2秒），嬴图仅需0.8毫秒（800微秒），速度提升了400倍。当查询3度邻居时，Neo4j需要大约290秒，嬴图仅需6秒。（BTW，在X86架构的机器上，我们可以在0.6秒内完成。）
这是最基本的图算法之一。在嬴图的系统上，使用X86服务器处理15亿条边的数据集，只需不到20 秒即可完成计算，几乎能够实现实时处理。相比之下，TigerGraph需要200秒，而Neo4j则需要10分钟（600秒）。
其计算复杂度大约是PageRank的四五倍。在处理数十亿级别的数据量时，Neo4j的性能受限，无法返回。只有Tigergraph和嬴图系统能够处理。使用X86机器，嬴图查询可以在80秒以内完成，较 Tigergraph（900 秒） 高效 10 倍以上。
该算法的复杂度比标签传播算法还要高出数倍。在处理15亿条边的数据集时，嬴图的系统大约需要20分钟来完成计算与数据回写，而Tigergraph甚至无法在合理时间内完成。这是因为Louvain算法需要对数据进行多次迭代直至收敛，计算复杂度极高。在这种情况下，我们的系统几乎是唯一能够以 T+0 模式完成计算与回写（落盘或落库）的。
需要指出的是，Neo4j在处理大型图时存在一个显著的问题，即其内存映射过程。在运行大型图查询之前，Neo4j需要将数据从硬盘导入到内存中，这一过程可能颇为耗时，上亿的数据量级需要以小时计，甚至会出现 OOM（内存溢出）等无法完成映射的问题。而且，一旦数据更新，还需要重新进行内存映射。我们称这种处理方式为静态图算法。这是Neo4j被广泛批评的一个问题。
在很多时候，效率与质量难以兼得，这个两难问题在高度数字化的零售业务场景中尤为突出。一方面，随着同业竞争的加剧，银行都在想方设法地改进用户体验和降低等待时长，另一方面，提升风控质量和保障交易合规需要跑批更多更复杂的模型，导致可能会消耗更多的决策时间。为了确保交易的安全性，每一笔业务申请和大额转账都必须通过反欺诈风控系统的审查。对于万亿级别的银行，上午交易高峰期，每秒可能有数千笔业务申请或转账交易同时发生。这种业务场景的挑战不仅是高TPS（每秒事务处理量）和高计算复杂度，更大的挑战在于它是典型的TP（事务处理）加AP（分析处理）的结合。
算力提升和架构变革是解决这一两难问题的唯一出路。以某股份制银行为例，其技术架构就经历了从VoltDB（一种分布式内存关系型数据库），到Apache Spark+GraphX，到Neo4j再到嬴图XAI高性能图技术的技术迭代过程。早期尝试的关系型的VoltDB和Apache Spark+GraphX的传统大数据架构，交易高峰期业务处理时耗大约需要四五百毫秒（且无法处理超级节点，并且只能存储 7 天的历史数据，远远无法满足业务的 90 天历史数据在线查询、30 毫秒时延的诉求），后来改用 Neo4j图技术以后，业务处理时耗降低一半，亦即两三百毫秒。而且，当遇到超级节点时，无论是Neo4j还是Spark都会出现等待过长甚至卡死的情况。行方提出的需求是能否降低到30毫秒以内。该需求的技术挑战在于，必须实时处理新增的交易数据，动态更新图数据库的拓扑结构，包括节点、边以及它们的属性，并且在毫秒级的时耗内计算过去90天内交易双方的上下游两层交易关系，以便及时发现并拦截可疑交易。
事实证明，仅使用了三台服务器的嬴图XAI最小规模集群，能够在高并发和负载均衡的模式下，能够在5毫秒内完成全部的反欺诈检查和实时决策模型的运算，并且能够并发处理多笔交易并稳定运行。具体来说，数据入图的过程大约需要300微秒（0.3毫秒），紧接着进行过去90天的用户行为分析，判断是否有与黑名单或灰名单账户的交易往来等特征。这一分析过程涉及多个模型，在并发模式下，仅需要3到4毫秒的时间来完成。整个反欺诈流程在全量实时计算的情况下，在5毫秒内完成。其中，嬴图XAI的超级节点穿透技术和动态图算法技术发挥了关键作用，而 Neo4j不能高效处理超级节点，加上需要进行内存映射的静态图算法，自然无法实现这一目标。
在信用卡申请等更偏重AP的实时决策场景中，嬴图XAI高性能图技术引擎的优势更为显著。以一个具有4亿节点和边规模的单边图为例，我们要在图中完成模式匹配，找出在一定时间内被5个以上信用卡申请使用过的电话号码。这种查询，我们使用25%的集群规模，就能比Spark快得多，仅需1.7秒就能完成全量数据的模型运算；而Spark完成ETL后，至少还需要13分钟（780秒）。另一个更复杂的全图查询在我们的系统中大约需要40多秒（不到一分钟），而Spark系统则需要至少一个小时，这还不包括数据ETL的时间，因为ETL本身还需要额外的时耗 （小时级）。这些对比清楚地展示了算力提升和架构变革在处理速度和效率上的巨大优势。
03 | 嬴图XAI：通往高性能图技术之路
对于计算优先的图数据库而言，能否在底层内核、数据结构、超级节点穿透、算法工程化等方面全方位实现高密度并发，从而通过硬件算力释放和软件全面加速，是决定一个图数据库是否具备高性能，能否胜任金融场景复杂计算任务的四大核心要素。没有计算高性能，用图是没有多大实际意义的。
从第一天开始，嬴图XAI产品的目标就是“极致性能、极致体验”，瞄准要求最高的金融场景，以极致性能、创新方案以及落地交付，赋能用户数智化转型，在享受极致体验的同时，真正实现降本增效。为了实现这一目标，整个图技术引擎的研发经历了一个极其庞大而复杂的工程化实现过程，体现在从数据存储、计算引擎、算法工程、可视化等方方面面。除了计算效率之外，准确性也是我们在金融场景中特别关注的方面。全量计算对于确保数据分析的准确性至关重要，而采样方法可能会导致错误的结果。
我们深刻意识到，尽管架构的优化是提升性能的关键，但真正的突破在于对图数据库内核的深度定制和创新。我们的团队从一开始就决定不依赖于现有的图数据库产品，而是从零开始构建我们自己的技术体系。这一决策最终证明是我们成功的关键。当然，我们的技术创新不仅限于技术内核的原创设计。例如2023年10月份，我们获得了中国首个关于超级节点穿透的专利，这是我们的产品能够实现实时或近实时的深度下钻和复杂计算的关键技术之一，还有我们在业内唯一实现的“即写即算”的动态图算法技术、同时满足负载均衡和数据一致性的HTAP架构等等，这些是满足和胜任大型银行等金融机构复杂数据处理需求的底层技术保障。近年来，我们已经成功处理了一些最复杂的金融数据场景，开创了图技术应用的先河，包括但不限于资债经营分析、流动性风险、智慧审计、实时交易拦截、实时资金流向等等。
嬴图XAI的技术创新，不仅解决了传统图数据库的性能瓶颈问题，也为各行各业提供了强大的数据分析工具，高性能图数据库将在未来的数据处理领域发挥更加重要的作用。展望未来，我们将继续致力于图数据库技术的研发和创新，以满足不断增长的数据处理需求和提升用户体验。我们相信，随着技术的不断发展，图数据库将在更多领域展现其独特的价值，成为企业数据管理和分析的重要工具。我们期待与更多的合作伙伴一起，共同推动数据技术发展和人工智能融合运用，探索图数据库的无限可能。文/ 孙宇熙 张天赫
_1.png)
