导读：本文介绍的主题是开源的图计算引擎GraphScope，其目标是做一个人人可用的图计算。
今天的介绍会围绕下面三点展开：
01
大规模的图计算和GraphScope
1. 大规模的图计算
图是大数据的一种重要数据来源，在互联网产品中会遇到很多图，比如网页链接图、生物结构图、社交网络图，还有知识图谱、在线用户行为等。在图数据的多样性基础上，图的计算类型也是多样性的。我们来看一个例子。
这是现实中一个用户购买行为中检测购买欺诈行为的工作流，主要环节包括：
整个流程中，会涉及到多种多样的图计算，比如图挖掘、图学习、图分析，还有交互式查询等。现有图计算系统，仅侧重于某一种类型的图计算，用户要完成这样一个工作流，需要构建多个系统，这些系统在开发、运维都会有一些不同的地方，给用户构建工作流带来了困难。图计算大规模应用充满了挑战，主要体现以下几个方面：
2. GraphScope
为应对这些挑战，我们依托阿里巴巴的海量数据和丰富场景，以及达摩院智能计算实验室这些年在图计算领域做的一些研究和沉淀，研发并开源了一站式大规模图计算系统GraphScope。
GraphScope是一个开源、易用的图计算平台，我们希望把它打造成用户开发图计算应用的第一站。它支持丰富和灵活的编程模型，支持丰富的计算类型任务，比如前面提到的图分析、图交互查询、模式匹配和图学习，都能一站式支持。它还提供易用的用户界面，有业界领先的性能，也支持Kubernetes云原生的环境。
下图是GraphScope的整体系统架构，可以看到它的应用层，面向用户提供一个统一的图编程模型，有一些内建的算法库，用户可以直接使用。在引擎层，有一个高性能的图计算引擎。在存储层有一个Vineyard的分布式存储。下面逐层介绍它们的特点和一些核心技术。
① 应用层
GraphScope是完全拥抱PyData的生态，在图遍历和图操作方面又兼容了Gremlin和NetworkX现实标准。
GraphScope提供了Python的Interface，用户如果要写一个图分析的任务，通过graphscope.session( )就可以打开或链接一个集群，之后都是Python中单机写如下图的Python代码。这一段代码，看起来像是一段单机的代码，但是因为GraphScope的存在，它的背后是有一个集群，在做分布式的计算的。
在图遍历上，GraphScope支持Gremlin查询语言。Gremlin这种语言在图查询中使用得比较多，下图例子是通过在交易图中进行环检测，查找出可能存在的洗钱交易。
在图算法的层面，GraphScope的API完全兼容NetworkX。NetworkX是Python上的一个图分析库的事实标准。NetworkxX的用户可以直接使用之前的业务逻辑，代码稍做修改，就可以在GraphScope运行图计算代码，从而降低分布式图计算的门槛。
GraphScope的高性能引擎支持对Gremlin查询的并行化。Gremlin查询可表达任意嵌套遍历和动态控制流，但是它存在细粒度动态数据依赖与可扩展性的矛盾，我们提出了新的数据流模型抽象，很好地解决了正确性问题，且与性能优化解耦，以支持复杂策略优化。
在图分析上，我们着重解决用户很难写出一个正确的图分析算法的问题。现有的一些模型有各种各样的问题，导致用户只能在点中心的编程模型下开发，又给用户带来一些额外的困难。
GraphScope高性能引擎对图分析算法的自动并行化机制，基于子图的PIE编程模型，用户只需要提供三个函数就可以采用即插即用的方式，单机算法自动并行化，用户不用关心并行环境的细节。
在这个模型下，对于用户想做分布式的算法，只需要提供三个函数：一个是PEval，用于局部计算的单机顺序算法；另一个是IncEval，用于后续迭代计算的单机顺序增量算法；最后一个是Assemble，用于结果聚合的函数。
通过这种即插即用的算法，可以在GraphScope里面运行，从而实现单机算法的自动并行化，用户也不需要关心这里面并行环境的细节。这个系统核心技术获得了学术界和工业界的普遍认可，获得了SIGMOD2017最佳论文奖，VLDB2017最佳演示奖和SIGMOD2018研究热点奖。
② 存储层
在存储层，我们提出了Vineyard分布式内存管理框架。提出这种框架的初衷是我们观察到各种大数据系统中，在内存构建和管理上有很多复用的部分，工作流里面跨越各个系统的数据流动需要借助一些低效的外部文件系统，同时也缺少可变数据的高效同步机制。Vineyard提供了跨系统的内存数据统一管理，它基于共享内存，零拷贝开箱，提供高层数据抽象，现在已经开源，被收录为CNCF Sandbox项目。
基于Vineyard提供流水线集成能力，比如一个工作流，刚开始要用到科学计算、图计算，之后下一轮要用到机器学习，没有Vineyard，就需要把图计算完成之后将数据落盘，在下一个环节里面重新载入。如果有了Vineyard，因为Vineyard是内存数据管理，这个GraphScope的计算结果可以直接放入Vineyard，直接零拷贝、零开销的给下一个环节继续使用，从而实现了跨系统的数据共享。
再来看一看GraphScope的性能，在交互式查询方面，GraphScope在LDBC数据集和只读查询中领先JanusGraph 1-2个数量级。GraphScope是一个纯内存的计算引擎，是在静态数据集上做的一个只读查询，跟前面LDBC的应用场景还是有一些差别。
在图分析的性能验证上，GraphScope跑了LDBC的图分析基准测试，在这个测试中领先了PowerGraph， GeminGraph， Plato分别是34.7倍/1.9倍/5.1倍。并且，GraphScope在生产环境中整体端到端性能有着显著提升。
--
02
GraphScope Demo
下面是我们的演示环节，这些代码可以在我们的GitHub上看到，欢迎大家提取和试用。
如果想在线体验的话，我们提供了一个在线的Jupyter notebook环境。另外，我们也提供了一个单机的部署模式，在不依赖于集群的情况下，也可以使用GraphScope。进入系统之后，因为GraphScope和Python是完全兼容的，如果要做一些Python的图的分析任务、图的操作任务时，会用到NetworkX。
--
03
GraphScope的未来规划
接下来介绍GraphScope的未来规划，分成以下几个部分。
1. GPU在图计算上的支持
图算法天然的有高并发的属性，而且随着数据逐年增加，对内存和高并发的需求越来越迫切。这些年GPU的发展迅猛，相比于CPU而言，它有100多倍或更高的读写带宽，更多的核，可能会达到数千的计算核。
这是GraphScope里对GPU图处理框架的设计，图进来之后，经过分区，每个GPU都拿到一个分块，我们可以看到一个核心的模块Kernel Arbiter（优化器），有几个负载均衡的策略，这是因为GPU相比于CPU有更多的核，但是每个核的计算性能更弱，而且GPU采用的是单指令多线程的方式执行，所以在每一个核的负载均衡是非常影响它的性能的。这里有四个负载均衡的策略。
第一个负载均衡的策略叫TWC，分别是Thread（线程），Wrap（线程束）和CTA（线程组）。在这种策略下，会把所有的点按它们的粗细程度分类，如果是粗度最小的点，可能只有一个Thread去处理，如果比较大，可能会用CTA方式来处理，从而尽可能达到每个核之间的负载均衡。
再看一下上图右边的STRICT模式，我们要严格保证每个CTA里面处理的点数和边数差不多一致，所以有可能会需要一个预处理，会引入一些额外的开销，所以右边这个Overhead最大的。
关于这些内部的负载均衡，我们在GraphScope公众号上有一篇文章写了相关内容，关注这个问题的同学可以去看一下。
上面是GPU内部的负载均衡，在GPU之间，我们借用了NVLINK。
NVLINK是NVIDIA提出的GPU之间的调速链接，最大的带宽能够达到300GB/s。如果有了这种高带宽低时延时的链接，我们就可以做GPU之间的Work Stealing。上图例子中GPU处理的点比较多，可以在工作过程中把这些工作转移到另外一个负载均衡的GPU上去。下图是初步实验的结果：
GPU图处理框架的性能在一些算法上从秒级降到了毫秒级，扩展性也很好，我们用8卡的机器能够达到7倍的加速比。这一部分已经开源了，里面的自动调优、动态负责均衡等功能计划于2022年第二季度发布，但是对GPU的加速功能我们已经开源在阿里巴巴libgrape-lite这个库里面，性能报告在这里面也能找到。
2. 业界性能领先的Java图计算支持
我们想做业界性能领先的Java图计算支持，现在业界一些常见的图计算应用系统，包括以下几种：Giraph, GraphX还有Gelly，这些都是Java写的系统，相比之下GraphScope这种C++写的系统性能更优，可能会差两个数量级左右。但是Java写的系统的优点是对用户来讲实现比较简单，比如Giraph这种系统存在很多年了，存量用户比较大，存量应用也比较多。
如何让GraphScope支持这些Java的应用？我们的设想如下：
如何让使用Java开发的应用无缝运行在GraphScope上？一是通过Java Virtual Machine实现。使用这种方式在运行上会有一些问题。
首先是Java和C++之间的性能差距，另外如果Java通过JNI的方式调用库的话，可能还有一些额外的问题，比如无法内联，这是一个边的迭代器，如果是纯用Java写的代码，是可以内联的。如果涉及到JNI去调用与它相关的代码逻辑的话，则没有办法内联。还有一些其它的性能问题。
针对这些问题，我们提出的解决方案是FastFFI。这是我们与阿里的编译器团队合作提出的，这个组件已经单独开源了。FastFFI提供了两个组件，一个是FastFFI SDK，通过这个可以封装C++Library，生成一些胶水代码，对于用户来讲，可以直接在这上面写Java Code，然后完成C++库的调用。第二部分是LLVM4JNI SDK，有了这部分，可以将C++ Code通过LLVM的帮助，直接转成原生的Java Code，从而解决Java Code调用C++Library的内联问题。
通过这两种方式，有了一些初步尝试，我们已经提供了GraphScope上面的Java SDK，能够让用户直接在这上面写PIE模型的Java SDK，对于相同的应用，使用Java SDK实现的性能最好的已经能够达到C++的78.6%。另外一种是我们针对Giraph提供的解决方案，实现了对Pregel模型的适配，Giraph上的应用能无缝运行在GraphScope上，使用相同计算资源的情况下，Giraph图计算任务在GraphScope上的运行时间下降，性能提升37%—72%。接下来我们还会做GraphX的适配，计划在2022年下半年发布。
3. 动态图神经网络（GNN）训练与服务
图神经网络在很多场景都有应用，比如淘宝搜索、淘宝推荐和搜索反作弊等。
现在基于静态图的端到端GNN训练有比较成熟的解决方案，就是阿里巴巴开源的Graph-learn库，上面支持端到端的GNN训练，也有很好的可扩展性，现在GraphScope中的关于图学习的任务也是由Graph-learn来完成的。
我们期望在未来推出一个动态图GNN训练推理服务，有一个动态图存储，支持动态图更新，也支持高吞吐的训练采样，能够支持批量、流式的采样训练，还支持极低延迟的在线采样查询，能够在单机上支持推理请求，并支持10毫秒级的P99延迟。这计划在2022年第二季度发布。
4. 其它新特性
下面我们再介绍一些“黑科技”。
一个是高效图存储。我们虽然不是一个图数据库，但是用户生成的一些图数据，我们也不想丢掉，还可能需要处理一些更新。所以我们在GraphScope有一个框架，用来存储图数据。这部分内容今年会在产品上做更多的整合。
二是增量化的流式图计算。例如，在图计算的场景中，今天将过去30天的数据构建在一张图上，想算一个pagerank，或者做一个边的计算等。依次类推，明天、后天都要做30天的，每天都是删掉最老的一天，增加新的一天。这里会有很多重复的、冗余的计算。我们希望用户写了一个图的算法，可以增量化地执行，并且在增量化地执行过程中，用最小的代价去保存计算中间结果，只要能保存最终的结果就可以了。那么这个过程能不能自动化呢？我们去年发表了一篇论文，已经把系统化的工作完成了。虽然我们是一个图计算，未来有可能让它去支持各种模式的增量化图计算。
三是HTAP图计算。我们发现图数据库有非常多场景，但是现实中很多的数据请求还是在一个关系型数据库中的。我们的图数据库或者是图计算的工作是要高效地、低延时地从大型的关系型数据库中抽取需要的数据到内存，或者一个新的数据库中，能够支持计算。HTAP是我们希望把这个数据抽取的过程低时延，虽然我们没有一个自己的持久化的存储，只有一个内存计算的副本，这个副本以低时延的方式与一个关系型数据库保持同步，这样我们不用考虑数据的一致性的问题，用户也不需要从零点批量导入一批数据等等。这样，我们就可以在一个接近准实时的图上做各种各样的图的计算、交互式分析和图机器学习等。这个功能也将在今年逐渐落地。
四是提供非常丰富的上下游对接。图计算不是一个完整的“烟囱”，必定会是在Python等场景中应用，应该是在单机的环境下做一些图计算的工作。这也是我们GraphScope所要追求的一个目标。
GraphScope开源及其社区发展，这张图上的数据要更新了（数据统计截止至2022.3.10，最新star数量 1650+）。
如果大家对GraphScope感兴趣，欢迎使用和贡献代码。
今天的分享就到这里，谢谢大家。
阅读更多技术干货文章、下载讲师PPT，请关注微信公众号“DataFunTalk”。
合作分享：于文渊博士 阿里巴巴 资深技术专家
合作分享：徐静波博士 阿里巴巴 高级技术专家
编辑整理：罗刚 国家开放大学出版社
出品平台：DataFunTalk
分享嘉宾：
活动推荐：
关于我们：
DataFun：专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章700+，百万+阅读，14万+精准粉丝。
欢迎转载分享评论，转载请私信。
| 留言与评论（共有 0 条评论） “” |
