作者：范志东

TuGraph Analytics（内部项目名 GeaFlow）是蚂蚁集团开源的分布式实时图计算引擎，即流式图计算。通过 SQL+GQL 融合分析语言对表模型和图模型进行统一处理，实现了流、批、图一体化计算，并支持了 Exactly Once 语义、高可用以及一站式图研发平台等生产化能力。

开源项目代码目前托管在 GitHub，欢迎业界同仁、大数据/图计算技术爱好者关注我们的项目并参与共建。

项目地址：https://github.com/TuGraph-family/tugraph-analytics

GeaFlow 论文【SIGMOD 2023】：GeaFlow: A Graph Extended and Accelerated Dataflow System

概览

本文希望通过一张图描述清楚 TuGraph Analytics 的整体架构脉络和关键设计思路，以帮助大家快速对 TuGraph Analytics 项目的轮廓有个整体的认识。闲言少叙，直接上图。

TuGraph Analytics 开源技术架构一共分为五个部分：

• DSL 层：即语言层。TuGraph Analytics 设计了 SQL+GQL 的融合分析语言，支持对表模型和图模型统一处理。

• Framework 层：即框架层。TuGraph Analytics 设计了面向 Graph 和 Stream 的两套 API 支持流、批、图融合计算，并实现了基于 Cycle 的统一分布式调度模型。

• State 层：即存储层。TuGraph Analytics 设计了面向 Graph 和 KV 的两套 API 支持表数据和图数据的混合存储，整体采用了 Sharing Nothing 的设计，并支持将数据持久化到远程存储。

• Console 平台：TuGraph Analytics 提供了一站式图研发平台，实现了图数据的建模、加工、分析能力，并提供了图作业的运维管控支持。

• 执行环境：TuGraph Analytics 可以运行在多种异构执行环境，如 K8S、Ray 以及本地模式。

DSL 层

DSL 层是一个典型的编译器技术架构，即语法分析、语义分析、中间代码生成(IR)、代码优化、目标代码生成（OBJ）的流程。

• 语言设计：TuGraph Analytics 设计了 SQL+GQL 的融合语法，解决了图+表一体化分析的诉求。具体语法设计可以参考文章：DSL语法文档
  

• 语法分析：通过扩展 Calcite 的 SqlNode 和 SqlOperator，实现 SQL+GQL 的语法解析器，生成统一的语法树信息。

• 语义分析：通过扩展 Calcite 的 Scope 和 Namespace，实现自定义 Validator，对语法树进行约束语义检查。

• 中间代码生成：通过扩展 Calcite 的 RelNode，实现图上的 Logical RelNode，用于 GQL 语法的中间表示。

• 代码优化：优化器实现了大量的优化规则（RBO）用于提升执行性能，未来也会引入 CBO。

• 目标代码生成：代码生成器 Converter 负责将 Logical RelNode 转换为 Physical RelNode，即目标代码。Physical RelNode 可以直接翻译为 Graph/Table 上的 API 调用。

• 自定义函数: TuGraph Analytics 提供了大量的内置系统函数，用户也可以根据需要注册自定义函数。

• 自定义插件: TuGraph Analytics 允许用户扩展自己的 Connector 类型，以支持不同的数据源和数据格式。

Framework 层

Framework 层设计与 Flink/Spark 等同类大数据计算引擎有一定的相似性，即提供了类 FlumeJava（FlumeJava: Easy, Efficient Data-Parallel Pipelines）的统一高阶 API（简称 HLA），用户调用高阶 API 的过程会被转换为逻辑执行计划，逻辑执行计划执行一定的优化（如 ChainCombine、UnionPushUp 等）后，被转换为物理执行计划，物理执行计划会被调度器分发到分布式 Worker 上执行，最终 Worker 会回调用户传递的高阶 API 函数逻辑，实现整个分布式计算链路的执行。

• 高阶 API：TuGraph Analytics 通过 Environment 接口适配异构的分布式执行环境（K8S、Ray、Local），使用 Pipeline 封装了用户的数据处理流程，使用 Window 抽象统一了流处理（无界 Window）和批处理（有界 Window）。Graph 接口提供了静态图和动态图（流图）上的计算 API，如 append/snapshot/compute/traversal 等，Stream 接口提供了统一流批处理 API，如 map/reduce/join/keyBy 等。

• 逻辑执行计划：逻辑执行计划信息统一封装在 PipelineGraph 对象内，将高阶 API 对应的算子（Operator）组织在 DAG 中，算子一共分为 5 大类：SourceOperator 对应数据源加载、OneInputOperator/TwoInputOperator 对应传统的数据处理、IteratorOperator 对应静态/动态图计算。DAG 中的点（PipelineVertex）记录了算子（Operator）的关键信息，如类型、并发度、算子函数等信息，边（PipelineEdge）则记录了数据 shuffle 的关键信息，如 Partition 规则（forward/broadcast/key 等）、编解码器等。

• 物理执行计划：物理执行计划信息统一封装在 ExecutionGraph 对象内，并支持二级嵌套结构，以尽可能将可以流水线执行的子图（ExecutionVertexGroup）结构统一调度。图中示例的物理执行计划 DAG 被划分为三部分子图结构分别执行。

• 调度器：TuGraph Analytics 设计了基于 Cycle 的调度器（CycleScheduler）实现对流、批、图的统一调度，调度过程通过事件驱动模型触发。物理执行计划中的每部分子图都会被转换为一个 ExecutionCycle 对象，调度器会向 Cycle 的头结点（Head）发送 Event，并接收 Cycle 尾结点（Tail）的发回的 Event，形成一个完整的调度闭环。对于流处理，每一轮 Cycle 调度会完成一个 Window 的数据的处理，并会一直不停地执行下去。对于批处理，整个 Cycle 调度仅执行一轮。对于图处理，每一轮 Cycle 调度会完成一次图计算迭代。

• 运行时组件：TuGraph Analytics 运行时会拉起 Client、Master、Driver、Container 组件。当 Client 提交 Pipeline 给 Driver 后，会触发执行计划构建、分配 Task（ResourceManagement 提供资源）和调度。每个 Container 内可以运行多个 Worker 组件，不同 Worker 组件之间通过 Shuffle 模块交换数据，所有的 Worker 都需要定期向 Master 上报心跳（HeartbeatManagement），并向时序数据库上报运行时指标信息。另外 TuGraph Analytics 运行时也提供了故障容忍机制（FailOver），以便在异常/中断后能继续执行。

State 层

State 层设计相比于传统的大数据计算引擎，除了提供面向表数据的 KV 存储抽象，也支持了面向图数据的 Graph 存储抽象，以更好地支持面向图模型的 IO 性能优化。

• State API：提供了面向 KV 存储 API，如 get/put/delete 等。以及面向图存储的 API，如 V/E/VE，以及点/边的 add/update/delete 等。

• State 执行层：通过 KeyGroup 的设计实现数据的 Sharding 和扩缩容能力，Accessor 提供了面向不同读写策略和数据模型的 IO 抽象，StateOperator 抽象了存储层 SPI，如 finish（刷盘）、archive（Checkpoint）、compact（压缩）、recover（恢复）等。另外，State 提供了多种 PushDown 优化以加速 IO 访问效率。通过自定义内存管理和面向属性的二级索引也会提供大量的存储访问优化手段。

• Store 层：TuGraph Analytics 支持了多种存储系统类型，并通过 StoreContext 封装了 Schema、序列化器，以及数据版本信息。

• 持久化层：State 的数据支持持久化到远程存储系统，如 HDFS、OSS、S3 等。

Console 平台

Console 平台提供了一站式图研发、运维的平台能力，同时为引擎运行时提供元数据（Catalog）服务。

• 标准化 API：平台提供了标准化的 RESTful API 和认证机制，同时支持了页面端和应用端的统一 API 服务能力。

• 任务研发：平台支持“关系-实体-属性”的图数据建模。基于字段映射配置，可以定义图数据传输任务，包括数据集成（Import）和数据分发（Export）。基于图表模型的图数据加工任务支持多样化的计算场景，如 Traversal、Compute、Mining 等。基于数据加速器的图数据服务，提供了多协议的实时分析能力，支持 BI、可视化分析工具的接入集成。

• 构建提交：平台通过任务和作业的独立抽象，实现研发态与运维态的分离。任务开发完成后执行发布动作，会自动触发构建流水线（Release Builder），生成发布版本。任务提交器（Task Submitter）负责将发布版本的内容提交到执行环境，生成计算作业。

• 作业运维：作业属于任务的运行态，平台提供了作业的操纵（启停、重置）、监控（指标、告警、审计）、调优（诊断、伸缩、调参）、调度等运维能力。作业的运行时资源会由资源池统一分配和管理。

• 元数据服务：平台同时承载了引擎运行时的元数据服务能力，以实现研发与运维的自动化。元数据以实例维度进行隔离，实例内的研发资源可以根据名字直接访问，如点、边、图、表、视图、函数等。

• 系统管理：平台提供了多租户隔离机制、细粒度用户权限控制，以及系统资源的管理能力。

执行环境

TuGraph Analytics 支持多种异构环境执行，以常见的 K8S 部署环境为例，其物理部署架构如下：

在 TuGraph Analytics 作业的全生命周期过程中，涉及的关键数据流程有：

• 研发阶段：Console 平台提供了实例下所有的研发资源的管理，用户可以在创建任务前，提前准备所需的研发资源信息，并存储在 Catalog。

• 构建阶段：任务创建完成后，通过发布动作触发构建流水线，用户的 JAR 包、任务的 ZIP 包等会上传到 RemoteFileStore。

• 提交阶段：作业提交时，Console 会根据作业的参数配置、运行时环境信息，以及远程文件地址等创建 KubernetesJobClient，既而会拉起 Client Pod，Client 会拉起 Master Pod，Master 会拉起 Container Pods 和 Driver Pod。所有的 Pod 拉起后，Client 会把作业的 Pipeline 发送给 Driver 执行，Driver 最终通过 Cycle 调度的 Events 与 Containers 交互。所有的 Pod 启动时都会从 RemoteFileStore 下载版本 JAR 包、用户 JAR 包、作业 ZIP 包等信息。Driver 对 DSL 代码编译时，也需要通过 Console 提供的 Catalog API 操作 Schema 信息。

• 运行阶段：作业运行时，各个组件会上报不同的数据和信息。Master 会上报作业的心跳汇总信息，Driver 会上报作业的 Pipeline/Cycle 指标以及错误信息，Container 会上报作业的 Offset、指标定义以及错误信息等。RuntimeMetaStore 存储作业的 Pipeline/Cycle 指标、Offset、心跳汇总、错误等信息。HAMetaStore 存储各个运行组件的地址信息。DataStore 存储 State 数据和作业 FailOver 时所需的元数据信息。MetricStore 存储运行时指标信息。

• 监控阶段：Console 会主要查询 RuntimeMetaStore 和 MetricStore 存储的信息用于作业的运行时监控。

• 清理阶段：作业重置/删除时，Console 会对作业的 RuntimeMeta、HAMeta 以及部分 Data 做清理操作。

总结

希望通过以上的介绍，可以让大家对 TuGraph Analytics 开源技术架构有个比较清晰的了解，我们非常欢迎开源社区的技术爱好者参与到项目的建设中来。

如果您对 TuGraph Analytics 项目比较感兴趣，欢迎动动手指扫码直达 GitHub 仓库，为我们的项目加一颗 Star。

如果您对该项目的发展有好的建议和意见，欢迎大家提交 Issue 到开源社区，或者通过邮箱/钉钉群与我们直接联系。

邮箱：tugraph@service.alipay.com

钉钉群：TuGraph Analytics 讨论群