共计 5249 个字符，预计需要花费 14 分钟才能阅读完成。
作者：范志东
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。【网络不畅能够尝试应用 VPN 拜访】
如果您对该项目标倒退有好的倡议和意见，欢送大家提交 Issue 到开源社区，或者通过邮箱 / 钉钉群与咱们间接分割。
邮箱：tugraph@service.alipay.com
钉钉群：TuGraph Analytics 探讨群
