在大数据领域中，流式图计算（Streaming Graph Processing）作为一种用于处理实时数据流的计算模型和技术，结合了图计算和流式数据处理的概念，旨在处理数据流中的节点（vertices）和边（edges）之间的关系，以实时分析、处理和理解不断涌现的数据。蚂蚁集团对于流式图计算在实时数据处理与分析领域有较成熟的体系。今天主要介绍蚂蚁集团实时数据体系和关键技术、基于流式图计算的实时流量归因场景应用，以及基于流式图计算在支付宝营销场景实时 OLAP 和数金场景实时用户行为意图分析的探索。
首先介绍的是蚂蚁集团实时大数据能力框架图。
总体分基础技术、实时核心能力、业务三个层次。基础技术包含计算、存储、消息队列等，今天重点分享的流式图计算引擎就在这里。实时核心能力自下向上依次是技术架构&研发范式、数据资产、数据解决方案。技术架构&研发范式包括“流批一体”、“湖仓一体”等架构，也包括针对不同业务情景的研发范式和架构约束。技术架构之上是资产层，类似离线数仓我们为实时也构建了一套资产管理和治理体系。最上面是领域解决方案，面向类似业务场景提供一套通用的实时领域解决方案，比如营销活动、实时风控等场景。基于这个能力大图，逐渐实现以需求驱动为主向数据驱动业务发展的整体战略目标转化。
这里简要介绍实时能力大图中的“流批一体”。流批一体能力的应用指的是一种应用程序能够同时处理实时数据流和批量数据的能力。换句话说，该应用能够灵活地在实时情境下处理连续的数据流，也可以在一段时间内处理累积的数据批次。Apache Flink 和 Apache Spark 是两个流行的分布式计算框架。这两个框架都具有处理实时数据流和批处理数据的能力。
对于流批一体可以有两个层面的理解：
蚂蚁的解决方案是在数据研发平台层实现开发一套逻辑代码实现流批一体，并在此基础上做了大量优化。比如代码里可以根据“__source_type__“这些系统级别的关键词（值为“bounded”和“unbounded”）进行不同位点和分区的流式和批式处理。
蚂蚁流式图计算系统的整体框架包含了容器资源、流图引擎与 API、数据应用，及计算控制后台几个层面，为实现高效的数据处理和分析提供了完整的架构。在该框架中，底层为强大的容器基础设施，涵盖了 Kube.NETes（k8s）和Ray，为上层提供了可扩展性和资源管理。在此基础上构建了流图引擎，为数据流处理和分析提供核心支持，其中包括 GraphView API、Unified Graph Engine 和 Graph State。最上层则是流图数据应用，涵盖了转化归因、实时 OLAP、行为意图等多个领域，同时展望未来的发展，计划在广告场景中引入链路诊断，以进一步提升系统的功能和价值。整个框架在数据处理的各个层面提供了一体化的解决方案，为实时数据处理和分析应用提供了强有力的支持。
左边是一个流量转化漏斗，指在数字营销和业务运营中，通过不同阶段的处理和转化，将大量的潜在用户或访问者逐步引导、筛选，最终实现特定目标的过程。包括了公域到商家私域/行业阵地的流量分发、私域交易转化、流量商业化变现几个环节。从平台视角，通过为商家进行流量引导、提升交易转化，最终实现流量的商业化价值。
以用户在支付宝的访问为例，可以详细介绍如何通过流量漏斗实现从公域流量到商家私域，再到交易转化，最终实现商业化：
右边是一个对应的广告商业化的漏斗。从曝光到点击再到转化，可以通过广告中不同的 CPM（千次曝光）、CPC（点击）、CPA（动作）计费模式来实现流量的实时跟踪与变现。
流量转化归因模型在数字营销等场景中具有关键作用，它可以帮助分析和理解用户在不同阶段的行为对最终转化（例如购买、注册等）的贡献，从而优化营销策略和资源分配。这有助于了解用户决策路径、优化转化率，以及对不同营销渠道和策略进行评估和优化。
用户路径建模：客户端上报的埋点数据将被用于构建用户路径模型，即用户在整个流程中的行为路径。这可以通过分析用户在页面之间的转换关系来实现，整个过程会形成一个动态的路径图。
该模型包含以下节点：
经过裁剪的最终转化链路：A(1)->B(6)->F(7)->G(8)->H(9)
这是实时流量转化归因的整体技术架构，其中数据部分比较核心的是基于业务中间层的转化事件定义（如交易支付、权益核销等）和转化数据模型的 Schema 归一化。通过对不同转化事件类型的 Schema 归一化可以屏蔽不同业务的差异，便于下游消费使用。在此基础上，通过逻辑视图可以实现对不同业务场景分类消费的支持，大大提升了数据消费的效率。最后是基于流图的转化归因计算，输入是流量和转化事件，输出是转化的归因结果。
目前，用户行为日志主要以“访问”和“点击”为主，“曝光”由于数据量大、上传延迟高暂没有使用。根据实时的用户访问行为日志和用户点击行为日志通过流式图计算引擎进行实时构图，当转化事件到达时进行归因路径计算，即根据流量转化归因模型从橙色节点（路径起点）到绿色节点（路径终点）的链路计算，最后将其结果输出到下游的 MQ 和 OLAP。
该系统从用户端到后端的数据采集时效已经达到五分钟90%以上，十分钟接近100%，已可以满足绝大多数业务需求。
以上是实时生产过程中的实时转化链路，上游主要有两种数据源，一种是客户端埋点采集，一种是服务端数据采集（如服务端日志、数据库 binlog）。一般而言服务端数据采集实效性比较快，除了中间件的抖动，其上报速度在秒级。整个链路的主要延迟集中在流量上报环节和流图计算环节，其中流量上报环节由于客户端、网络等多种因素变量较大，而流图计算环节则是可控的人为设定的等待时间窗口，因为实际的流量、转化事件上传不是严格有序及时上传的，这个等待窗口大小的设定也要结合归因的时效性和准确性综合考虑权衡。最终这些数据会加工处理成 DWD 中间层供下游营销等应用场景使用。
后置计算是流计算的一种研发模式。当前蚂蚁实时计算以“前置计算”为主，正逐步发展成为包括“后置计算”在内的支持不同业务场景的“多模式计算”研发模式。
以实时特征研发为例，基于后置计算模式后，新增特征只需要在特征平台进行特征视图配置，无需为不同特征加工建设不同的 Flink 实时任务，实时特征研发效率得到极大提升。
接下来介绍支付宝营销场景后置计算的一个案例，即流式图计算在实时 OLAP 场景的探索。采用流图进行后置计算后，在数据模型和研发模式上都发生了比较大的变化。
数据模型方面，过去在我们完成基础的 ODS、DWD 建设后，随着时间和复杂度的增加，ADM 应用层的数量会急剧上升（各种维度的指标报表），这给开发和运维工作都带来了极大压力。采用流图后，基于用户去做图建模，将权益和玩法等业务层面与用户本身建立关系，形成一个图关系网，再进行后置分析。
研发模式方面，经典的研发模式是指标需求驱动研发，先采集上游数据，形成维度等中间表，再根据不同的场景去计算对应需求的指标。这个模型的缺点是对于内部运营非常态化需求的指标数据而言，浪费了前置计算量。基于流图的后置计算可以有效的避免这个浪费，只有业务有需求需要查看数据时，才进行计算，即保证了数据时效性也避免了计算浪费。除此之外，模型的灵活性比较高，对于临时增加计算节点和指标等行为的代价比较小。总而言之，后置流图计算更符合如今高复杂度，高灵活性需求的应用场景。
流式计算引擎与传统基于 OLAP 的引擎内测对比发现，对于单表场景，流式计算引擎性能稍显逊色，但是多表关联场景，其性能明显优于基于 OLAP 的引擎。
另一个我们基于流式图计算的探索是在数字金融领域，在财富场景进行的用户行为意图分析。以前，我们对用户行为意图的分析主要是使用一维的用户行为特征或者二维的用户行为序列。类似上面提到的流量转化归因的例子，用户实际的行为是复杂多变的、噪音较多，传统的数据模型在意图识别准确度，尤其是大规模数据的精准意图识别上还存在比较大的挑战。
上图通过对用户行为意图的实时构图及对不同节点意图分的计算，得到用户最有可能感兴趣的产品。比如用户在进入支付宝理财 tab 页，可能在不同的页面（如引导、承接、交易）访问了不同的基金产品，这其中结合基金产品的 spm 和访问次数会计算一个意图分，并综合整个路径中不同意图分的情况得到一个用户最可能交易的意图节点。另一方面，基于这些用户偏好的产品节点，可以进一步推演出用户感兴趣的产品类目，基于这些数据可以实现更丰富的推广营销。
基于流图可以实现更加快速精准识别用户行为意图，与传统的推荐算法不同，作为一个实时数据方案，它具备高时效性、过程白盒化、可人工干预扩展节点、消除噪音意图识别更精准、后置计算效率更高等特点。
展望未来主要包括以下这些：
京公网安备 11010802035086号