点击蓝字，关注我们在Apache 软件基金会（ASF）的官方全球系列大会 Community Over Code Asia 2025中，蚂蚁集团图计算开发工程师赵晴雯分享了「利用流式图计算加速多流连接」，以下为分享内容整理，亮点包含：
流计算的发展与挑战 流图计算引擎Apache GeaFlow（孵化中）的设计和核心功能。 Apache GeaFlow典型的应用场景， Apache GeaFlow的未来规划和演进方向。
流计算的发展与挑战
流计算的发展
过去十几年间，流处理技术经历了快速迭代与革新。早期我们接触的流计算引擎多以Apache Storm（由Twitter在2011年开源）为代表，开创了事件驱动型应用的开发范式，比如实时异常检测和日志分析场景。2013年技术生态开始多元化：LinkedIn推出的Samza（次年进入Apache）依托Kafka构建分布式流处理能力，而Spark同期开源的Streaming模块则采用微批处理模式，将流数据切分为小批次进行处理。
2014年Flink的横空出世成为重要转折点，其流原生架构实现了低延迟与高性能的突破。到2016年，技术栈进一步丰富：Kafka Streams让流处理能力深度嵌入消息系统，Apache Beam提出编程模型抽象层，而Heron作为Storm的继任者也在此时崭露头角。流计算处理引擎进入百花齐放阶段。
如今流计算技术持续进化，应用场景完成三级跳：从最初的事件驱动应用，演进到流批一体的ETL流水线，再到当前通过SQL实现的实时数据分析。当我们赞叹流处理引擎在实时计算场景的卓越性能时，不禁要问：在需要复杂关联分析的场景中，是否依然能保持同等高效的处理能力？
流计算的挑战
我们以Flink作业中的关联分析场景为例，来看流计算引擎在复杂计算中的挑战。当流数据以窗口形式切割进入执行链路时，每个算子都会即时处理并传递结果。但在所有算子中，Join操作往往成为性能瓶颈——它不仅需要处理实时数据流，还要维护左右两个流的状态存储。
以Flink的Join实现为例：当左流数据进入算子时，会先写入Left State View，随后查询Right State View寻找匹配数据。这种双向状态维护机制虽然保证了关联准确性，但带来了双重压力——每个Join算子都需要同时存储两个流的全量状态。当处理一度关联时，状态规模尚在可控范围，但随着关联深度增加，问题会急剧恶化，最终可能导致状态存储爆炸，作业运行缓慢甚至失败。
我们可以从另一个角度观察：现实中的关联数据往往具有复杂结构。例如项目、员工与公司之间的多维关系，传统表结构建模需要拆分为六张关联表，而采用图建模时，只需将实体抽象为顶点、关系转化为边，就能无损还原所有关联关系。通过对比可见，在表达复杂关联时，图模型具有天然优势——其拓扑结构能更直观、更精确地呈现实体间的关联网络，相较于关系表的离散存储方式，在可读性和完整性层面展现出显著优越性。
关联分析场景中图模型优势
关联表达直观性：通过"跳数"（Hop）机制实现多度关联分析，一跳即对应图结构的一次遍历，三跳关联仅需三次图遍历；而传统表结构需通过三次JOIN操作实现同等分析，计算逻辑复杂度随关联深度指数级增长。
模型扩展性对比：图模型通过顶点/边结构天然支持复杂关系扩展，新增关联仅需增加边结构即可；而关系表需持续新增关联表并重构JOIN逻辑，模型迭代成本随关系复杂度直线上升。
计算性能差异（通过K跳关联压测对比）：
在1-2跳浅层关联时，Flink的JOIN实现与GeaFlow流图计算性能接近
3跳关联时性能差距急剧放大：GeaFlow耗时200+秒 vs Flink 20,000+秒（慢100倍）
4跳关联时Flink在10万秒内未能完成计算，而GeaFlow仅需1万+秒
复杂分析场景，流图计算的模式 还是有很明显的优势，传统流计算在复杂关联场景中的根本性瓶颈——JOIN操作的组合爆炸问题，而流图计算通过图遍历的计算范式实现了性能突破。
Apache GeaFlow介绍
2018年，GeaFlow首次亮相，推出流图混合计算能力。 在当年双11的信贷业务黑产识别算法中，取得非常突出的业务效果。 2019年，基于流图混合计算能力研发了图仿真能力。 2020年，增量图计算能力，通过每日增量图实现按需计算，性能较全图计算大幅提升。
2021年，流批一体化的图计算体系
2022年，图 OLAP分析能力。
2023年，进行开源、打破了了 LDBC SNB-BI 的世界纪录
DSL：融合SQL和ISO/GQL混合表达语言。
API层：提供了流API和图API两种接口。流API 可以进行批/流数据处理，而图API 可以进行 离线/动态增量的图处理，满足不同场景下的图计算需求。
框架层：包含了任务调度、shuffle、流/图算子、执行pipeline、内存管理等模块。 存储层：KV存储和自研的图原生存储。KV存储做算子的临时数据保存。 集群管理：支持k8s和Ray两种。
Apache GeaFlow核心功能
图表一体化处理能力； 支持离线与实时图数据加载； 自主研发的原生图存储系统； 图OLAP（联机分析处理）查询能力； 离线与增量图计算支持。
图表一体化处理能力
图结构定义：通过脚本定义图结构（如点表/边表），支持数据源为离线表或Kafka流； 图加载执行：通过SQL-like语句（如SELECT）将数据源数据写入图存储，完成图加载； 图计算与遍历：加载后可进行图计算（如统计多跳关联节点总数），可通过两种GQL及Gremlin两种语法实现。
流批图一体
执行计划结构：
执行计划：由流批计算节点和迭代计算节点组成； 迭代计算节点分为两类：图计算节点（用于执行如PageRank、连通分量（CC）等复杂计算）和图遍历节点（如通过Grammari语句从起点出发进行多跳查询和操作，查询语言会在遍历节点中被翻译为内部执行DAG。）
多模态调度机制：
一个作业DAG中可能包含流计算、批计算、图计算等多种计算模态； 调度核心概念为“Cycle”和“Cycle调度”，通过将不同模态切分为不同的Cycle进行调度。
不同模态的调度方式：
流计算：作为一个整体Cycle，采用无限循环调度； 批计算：每个节点为一个Cycle，采用一次性调度； 图计算：混合计算，包含批计算节点和迭代节点，采用组合调度； 流图计算：在离线图计算基础上增加外层无限调度，实现持续处理。
统一调度框架：通过Cycle调度机制，将流、批、图三种计算模式有机整合，实现统一调度与高效协同。
增量图计算
数据处理方式：每天的新增数据被切分为多个批次，每一批数据构建为一个“增量图”（Delta图）。 计算过程：计算算法基于增量图进行迭代处理，经过多轮计算后输出结果。 图结构更新：完成计算后，更新后的增量图会合并到历史底图中，实现图结构的持续演进。 历史底图演变：历史底图随新增数据的不断加入，从初始状态（如T1）逐步演进到后续状态（如T2）。
图原生存储
无论是批量数据还是流式数据，都会被解析并建模为点和边的形式。 这些点和边在进入图计算引擎后，会经过二次编码，转化为KV结构进行存储。K（Key）部分包含点或边的元数据，V（Value）部分则是点或边的属性值。 整个存储架构遵循LSM（Log-Structured Merge-Tree）结构设计。在内存中，点和边以邻接链表的方式组织，边会按照源点ID（srcId）进行聚集，便于后续图遍历和查询操作。 刷入到磁盘时 Key 和 Value分开存储， Value 存入数据文件， Key 存储索引文件，每条索引包括ID/SRCID + Key + Value offset。我们在索引文件上维护了稀疏索引机制，将ID范围划分为多个索引块，从而加快定位速度。 存储按照不同需求分成3个等级， 从内存到磁盘再到DFS。
原生图存储的优势：
1、查询高效：查询一个点及其所有关联边，通常只需要一次 IO 操作。相比之下，如果点和边分离存储，则需要两次 IO。因此，在处理图结构中的关系查询时，GeaFlow表现非常出色。
2、性能提升：引入了多项优化手段，如key/value分离，异步压缩，计算下推，冷热分离等，进一步提升整体性能。
Graph OLAP架构
OLAP服务由coordinator， executionworker, 图存储三部分组成：
Coordinator：作用类似于图计算中的Driver。接收到一条查询语句之后，Coordinator会首先进行语法解析，然后将其转化为一个逻辑执行计划，再进一步翻译成物理执行计划。 Worker节点：负责执行具体的计算任务，例如完成多跳查询、多条件分析等操作，计算完成后，结果会沿着原来的路径逐级返回给客户端。 图数据主要存储在DFS（分布式文件系统）。但在大多数情况下，为了提升查询性能，会把DFS数据加载到本地磁盘上做数据加速。
图推理功能
图推理功能核心原理是图算子上 + GNN模型运行。在图计算算子初始化（open）阶段，构建推理环境，该环境主要基于Python实现。在创建推理环境的过程中，会完成一系列准备工作，包括：创建独立的Python进程；初始化Python运行环境；下载并加载基础模型文件；执行其他与推理相关的初始化操作。
在迭代计算阶段，GeaFlow负责从存储里捞数据及迭代消息交换， python进程负责推理计算，进程交互通过共享内存。
优势：缩短线上推理链路、近线模型推理时效性好。
Apache GeaFlow应用场景
流量归因分析
核心原理通过将用户行为数据转化为行为图结构，分析用户行为路径与转化节点的关联关系，从而确定不同渠道对最终转化的贡献度。
建模：将用户在一个APP上的行为数据转化为行为图。用户和买点（分为交易和非交易）作为节点，用户与买点之间的操作行为作为边。
路径匹配规则：终点——固定为交易买点（有效转化节点），起点——用户节点或初始行为节点。通过图搜索算法，定位从起点到终点的有效转化路径。
示例说明：在行为图中，路径 AA→B→F→G→E→AA→B→F→G→H 被判定为有效转化路径，表明用户从初始行为到最终交易的完整链路。
增量图计算：用户新增行为数据实时构建增量图，动态更新图结构。在增量图中执行路径匹配算法，提取所有可能的起始点到转化点的路径。
归因依据：所有匹配路径构成归因分析的基础，用于量化各渠道对最终转化的贡献权重。
技术特点：
图结构优势：通过节点与边的关联，直观呈现用户行为链路。 动态计算：基于增量图的实时更新，支持高效归因分析。 路径可解释性：明确路径规则（起点→终点），增强归因结果的可信度。
图数仓
传统数仓瓶颈：
高计算开销：基于Join的交易经济分析需处理大量关系计算（如Shuffle开销），导致性能低下。
宽表加速的局限性：数据冗余、模型灵活性差。
图数仓方案优势
高效分析：单次查询即可获取关联路径（如用户→行为→交易），减少多表Join开销。 灵活扩展：新增顶点或边无需重构全局结构，支持动态数据模型迭代。
图数仓架构设计——基于GeaFlow核心能力
模型管理：基于图模型定义（如顶点类型、边关系），实现数据到图结构的映射。 数据加载：将外部数据（如日志、交易记录）转换为图数据并 存储。 分析计算：支持OLAP分析（如路径挖掘、关联分析）及实时查询。 资产治理：模型Catalog管理（元数据、关系定义）；数据关联关系可视化，统一管理数据资产。
实际效果与应用场景
性能提升：在蚂蚁集团内部，图数仓作为数据分析平台的核心加速层，实测加速比达5~20倍（对比传统方案）。
总结展望
图表一体化处理能力； 支持离线与实时图数据加载； 自主研发的原生图存储系统； 图OLAP（联机分析处理）查询能力； 离线与增量图计算支持。
图模型管理：支持完整的图数据模型定义，涵盖顶点、边及其属性的灵活配置。 图数据加载：提供高效的数据导入机制，可将多种来源的数据转换为图结构并持久化存储。 图分析与计算：内置丰富的图算法和分析能力，支持复杂关系挖掘与大规模图计算。 图研发平台支持：在开源版本中，配套提供一体化的图研发平台——GeaFlow Console。
AI领域探索：逐步探索向量索引及RAG增强。 湖仓一体化：持续完善湖仓融合能力，当前重点推进与Paimon（数据湖项目）的集成工作。 图能力优化：优化图数据查询与分析语言支持和提升图计算框架的性能与易用性。 开源生态：GeaFlow核心代码已迁移至Apache GeaFlow开源仓库，当前处于孵化阶段。代码仓库：https://github.com/apache/geaflow
欢迎关注TuGraph代码仓库✨
https://github.com/tugraph-family/tugraph-db
