目前存在各种各样的图数据类型，如上图所示：网页链接图、生物结构图、社交网络图等。
现实中的图计算任务是非常复杂的工作流程，不是仅仅靠一个简单的算法就能实现的。如上图示例：第一，欺诈检测的工作流首先要通过ETL抽取数据，建模以后储存管理，并进行格式转换；第二，开展图挖掘获取有效信息；第三，利用图学习，即机器算法寻找共性特征；第四，展开图分析，通过标签扩散；最后，交互式分析与结果可视化。
但是，在真实的应用场景中问题复杂，计算模式多样，解决方案碎片化；同时用户的门槛很高，学习难度也很大；海量数据的计算复杂度高且效率低。因此，解决图计算大规模应用的挑战是我们GraphScope系统开发的重要目标。
GraphScope的构建，始于2020年底。两年的时间里，我们结合了阿里的海量数据场景以及以达摩院团队和业界专家学者的合作成果，将各个团队的图计算工作整合在一起，最终形成了GraphScope系统。
具体来说， GraphScope的基本架构如上图所示。底层现在是Vineyard分布式内部存储，同时支持其他类型的存储。中间层为一系列高性能图计算引擎，并且用Python语言把各种各样的图计算的负载串联在一起，提供了一个统一的图模型和算法库。同时本系统可以和上下游的其他生态环节打通，使用户可以在使用系统的时候，能以很低的成本同时拷贝上下游的数据。
团队目标是希望GraphScope成为用户开发图计算应用的第一站，通过开源努力打造一个业界图计算的标准。第一，为用户建立简单、通用、灵活的编程模型，拓展Gremlin和Python；第二，支持丰富的图计算任务的类型，比如说图分析、图交互式查询、图模式匹配、图学习等；第三，达到业界领先的性能；第四，有一个开放、易用的Notebook的环境；最后，与上下游的业务做深度结合，形成一个全生命周期的一个设计。
12月开源以来，GraphScope入库了中国科协“科创中国”平台，在今年的OSCAR开源产业大会上得到了“尖峰开源社区和开源项目”奖。两年时间里系统积攒了2000+ Github stars，上百个各种各样的图分析和学习算法库，在阿里每天大概完成近5万的日常任务支持。同时，系统支持复杂的图模型，单个图的规模大小在阿里内部也超过了50 TB。总体开发效率对于工程师来说也是从几周加速到几个小时的时间。
关于GraphScope平台，用户有很多问题，如下图所示：支不支持JAVA？是否可以把算法放进来？支持Spark吗？数据怎么更新？如何支持在线推理？怎么直观管理生命周期？如何编辑交互式的图查询？不用Python可以吗？等等。
因为我们要打造的是一个人人可用的图计算系统，如果大家还有新的问题与建议，也欢迎大家多给我们一些反馈。
一、实时离线一体图计算引擎
首先，讲一讲GraphScope如何实现离线一体图计算引擎。关于GraphScope究竟是不是图数据库，这是一个常见的问题。杭州有很多关于图数据库的创业公司，大家也很容易联系到我们是否也是图数据库。但我们不是一个图数据库，GraphScope其实是一个图计算引擎。
在真实的用户场景中，用户首先有一个实时的数据源会被处理，比如说互联网的用户日志，或者说银行的用户交易。这个数据会沉淀到一个主数据库，即OLTP的主数据库。
举个例子，用户从银行ATM机取款，这笔操作一定是一个transaction，就是存在事务的一个数据库里。随后这个数据库里会定期周期性地同步到一个数据仓或数据库里。这些数据包括一些实时的数据，例如日志等行为：在某应用中点了一个商品、点了一个链接、看了某个帖子。日志同样会被沉淀到数据库里。那么这些分析与查询，在传统意义上都叫OLAP请求。
那么图处理在现实中是什么呢？一些模式learning的计算，数据从这个端口到那个端口可能要很长时间，比如在阿里最典型的场景里可能要一天或者两天的时间。但是这样会让freshness下降，fresh是新鲜度数据，意思是数据传递从这里到那里经过两天的时间，数据可能就不这么新鲜了。
目前解决这个问题最好的办法是做图数据库。换言之，数据都存在数据仓库里和数据库里，如果不想经过很长的链路加载，这时候就需要图数据库，即graph database。但是，如果数据一旦涉及双写的问题，跨系统的ACID即数据的一致性很难保证。
因此，GraphScope是一个图计算引擎，可以从关系数据库中实时地把一个关系数据库的表投影成一张图，而用户的增删改查还是在关系数据库里来实现。GraphScope系统本身不处理数据的增删改查，但是它可以通过LOG同步的方式永远和外部数据源的图保持一致；同时支持服务化能力、交互式查询、图分析、图学习。
未来，我们希望GraphScope的capability，即处理计算的类型可以更加丰富，这个是我们的下一部分的工作，预计2023年的第一个季度可以完成正式开源，大家敬请期待。
二、全新的图交互查询/模式匹配IR与引擎
很多用户关心，GraphScope支持图模式匹配吗？为什么查询这么慢？怎么调优？在偏数据图查询的场景里，我希望做一些解答，这也是我们下一步的工作。
我们第一个想解决的问题是，如何更好的支持更多的图查询语言。我们的目标是解决用户的需要，用户增加一种图查询语言，需要一百多种不同的算子。那么如果引擎把这一百多种算子各自实现一遍，基本上是无法正常运行的。
第二，是否能支持图模式匹配？第三，如何支持更好的系统的自动查询优化，即系统自动匹配一条最优路线？最后，如何支持更多类型的图查询，是采用高查询吞吐还是并行加速？
那么如何在一个系统里让交互式查询引擎支持这么多能力呢？首先，我们在关系数据库的查询算子上做了一些和图相关的扩展，发现绝大多数现有的图查询语言的语义，其实都可以用非常有限的算子来实现。因此算子的空间从几百个甚至大几百个优化精简到几十个。并且这几十个的表达能力足够强到，把所有现在最常见的查询全都覆盖掉。
第二，我们需要做一层更通用的查询优化器，预计是明年的第三季度。我们认为在这层查询只有算子的组合，可以自动基于图上的特征来做查询优化。优化之后我们分为两个路径，第一个叫High QPS，目标是让这个系统在单位时间内能处理更多的图查询。另一条链路是data parallel的plan，目标是单个查询的延时尽量小。
第三，我们会构建一个通用的存储，预计明年的年终完成。它可以支持动态图、静态图、内存、外存。
三、图分析引擎的全新升级
那么还有一些问题怎么解决呢？
如图所示，如何高效地开发并让用户能执行更多种多样的复杂图分析的问题，以及如何适配已经有的JAVA等图算法；还有如何更好的融入像Spark为代表的大数据的这种处理生态。这个就是我们要解决的问题。
对于这些问题，我们提供FLASH框架。真正的图计算系统中面临的分析问题非常多样化，不一定所有都是固定点计算，一些有非常复杂的控制流。那么我们的目标其实不仅仅是要达到一个很好的性能，同时我们还要让这个开发变得简单。
所以我们提出了FLASH，它不仅是让开发简单，使得大家的代码行数可以都减少了，最多的情况下减少了92%。大概只有不到10%的代码行数，可以最高加速两个数量级。同时，基于FLASH我们提供了72个常见的各种全新的图算法，可以直接在GraphScope里使用。
我们现在有很多的图引擎，尤其计算引擎。除了GraphScope以外，很多的生产中用的引擎是在大数据套件中使用的，但是往往性能会比较差。是否能把Sprak上的一些应用运行在GraphScope上，并充分发挥GraphScope的性能，将这个生态打通呢？
要解决这个问题，首先要解决如图所示的一些问题。即如何在GraphScope上通过各种JAR来实现Java的高效运行。
如果不考虑性能，那么JAVA对C++、c语言、原生代码的调用都翻译成了一次跨语言的调用，但这中间就会有数倍的性能的磨损。那我们能不能解决这个问题呢？
其实是可以的，我们和阿里云的编译器团队做了一套开源的Fast FFI的解决方案。自动地把JAVA和C++之间的数据类型和方法对接，生成胶水代码。可以让JAVA代码很容易地去调用C++里边的代码，保证它的安全性和易用性。同时，把C++中的代码通过LLVM可以直接翻译到JVM上的byte code，打通了native code和JAVA code之间的屏障。通过这一系列的工作，我们的性能基本上达到C++在JAVA实现的性能与JAVA和C++类似的能力。
目前的支持主要是通过两条路径，一条是GraphScope Java SDK 实现了性能提高；另一条是GraphScope for Giraph降低图计算任务的运行时间。
同时我们也做了Spark支持，核心的一点是Spark是现在最广泛使用的大数据处理套件。它本身自带的图计算GraphX非常低效，基于GraphScope的跨语言能力赋能GraphX加速。同时更好的一点是内部的存储是直接作为RDD被Spark的下游任务直接使用，而不需要把这个数据载入到一个中间文件中。所以通过整体的方案实现了和Spark的对接。流程图如下所示：
达到效果Spark的性能提升大概是4.8倍，端到端的性能提升大概是两倍。其中，端到端的意思是一个数据的转换、转码和重新加载的速度。就用户体验来说，和基本的Spark没有区别。
四、图学习引擎的全新升级
GNN的训练框架其实越来越多，各种类型的学术界和工业界都已经开发出来了。那么它没有一个很好的支持工业界的在线推理的方式，而我们能不能利用各种各样的像GPU这样的新兴的硬件呢？
这些答案都是肯定的。首先我们做了一个升级，增加了高吞吐的采样引擎，这部分已经进入了主分支。同时，我们也已经完成了一个动态图推理的采样服务。使得我们在GraphScope上开发的模型可以很容易地服务客户。
工业级分布式GNN训练中的挑战主要是计算与资源利用需求不对等。模型训练是在稠密的数据集上做计算，图采样是在很稀疏的图上做计算，对内存的要求会比较高。两边的不对等使得我们GPU要么内存带宽，要么GPU的计算能力使用效率不高。通信、存储等也是同样道理。
为了解决这些问题，我们使用采样训练解耦、异构硬件加速和兼容PyG生态。
采样训练解耦在逻辑上把图的采样过程和图的训练过程分为两个角色来分别执行，中间用一个渠道可以让他们通信，这个渠道可以是共享内存，比如说共享显卡的内存和共享主机的内存；也可以通过网络，也可以通过高速互联网络。通过这样一个解耦的方法实现它能灵活部署、独立伸缩，同时又能利用各种部署模式，使得高并发采样和采样训练异步的能力得以实现。
我们也实现了异构硬件加速。比如说GPU上采样的支持，通过把特征做缓存，把图结构做切分等，充分利用GPU间的互联的特征，加速采样过程。
兼容PyG生态是指，用户可以在没有任何修改的情况下，可以直接使用PyG上的现有的模型。
五、图可视化解决方案
这部分工作是我们和来自蚂蚁集团的AntV团队一起来合作完成的。
比如有一张图，图数据很大，怎么把它展示出来？如何进行探索？怎么让用户能交互式地把查询给表达出来，直观地把图的整个生命周期管理起来？
比如可以管理图，建一个图的模型，导入图，进而分析图的数据。那么想做到这样，用户需要有一个类似于整个图的bi工具。在整个站点中实现一个zero code的对接到GraphScope上，然后让用户来实现上述功能。然后它也支持Gremlin的查询，pattern的绘制，对pattern进行查询，点边条件过滤，扩展节点，在这个结果上进行探查。
六、用户友好性与易用性提升
最后我们希望能实现对用户的友好性和易用性的提升，关键不在于我们的技术怎么样，而在于我们怎么样才能服务好用户。
