本文将分享货拉拉基于 tugraph-analytics 的实时业务数据异常归因诊断技术。
Tugraph-analytics 是蚂蚁开源的一个高性能流图计算引擎，支持万亿级数据的存储，具备图表混合处理、实时图计算，以及 OLAP 等核心能力。
本次分享主要包括以下五大部分：
1. 背景介绍
2. 方案演进
3. 收益
4. 未来规划
5. 问答环节

01 背景介绍

1. 业务背景

首先来介绍一下业务背景。货拉拉是一家物流公司，涵盖货运、搬家、跑腿、冷运等业务。这些业务会受到很多因素的影响。比如天气、交通状况等外部因素，以及链路变更、业务变更等内部因素。

以往由于数据量比较大，处理非常耗时，并且影响因素分散在各个地方，比较离散，导致业务异常告警不及时。为解决这些问题，我们采用大数据技术来统一进行采集计算，期望实现业务异常的及时告警和快速归因。

02 方案演进

1. 早期方案

我们的早期方案采用流批结合的方式。采用流式引擎对数据进行清洗和统计，最终把数据输出到 Doris 数据库中，再采用批作业的方式去查询 Doris 数据库里面的数据，进行异常检测，如果有告警，会关联天气、交通等外部因素进行告警。

这一流+批的方式存在诸多问题。第一个问题是引擎不统一，批作业天然就有时效性不足的问题；第二个问题是批作业不利于流量回放，实时业务告警如果涉及到告警策略的修改，需要通过流量回放来进行效果验证，批作业无法支持这种验证；第三个问题是关联外因数据信息是通过 join 的方式去做的，不易表达各个实体间的复杂关系，可能会导致归因效果不佳。

2. 技术选型

明确问题之后，开始进行技术选型。针对批引擎存在的问题，希望通过一个流式引擎来代替，但这个引擎最好能支持流批一体。同时，新的引擎还要能跟公司现有平台以及外部的一些开源组件很好地、快速地集成。经过对比，我们选择了 Flink，它是目前国内主流的流式处理引擎。

针对前面提到的关联的问题，我们需要选择一个能够支持多实体复杂关系表达和快速计算的组件。图就能够很好地表达复杂的网络关系。而我们的是一个实时的场景，要求能对数据做实时增量计算，并把结果输出到表供下游使用。再加上货拉拉业务数据的维度是比较大的，所以我们要求它能支持超大维度的计算。同时，考虑到未来业务会一直增长，所以要能够支持弹性扩容以及存算分离的架构。综上所述，我们选择了 tugarph-analytics 这一组件。

3. 图 vs 表

图相对表而言有哪些优势呢？首先，图的关系运算成本更低，它不像 join 操作在分布式系统中涉及大量的 shuffle 和计算开销；第二是无数据冗余，在表场景下，我们为了做一个场景加速，往往都需要将多张表提前物化成一个大的宽表，这样就会造成很大的数据冗余；第三是图支持更复杂的关系查询，表要做关系查询只能通过 join 去操作，对于一些复杂查询很难通过索引去表达，比如要查询一个人 4 度以内的好友，通过索引去做，可能需要很多个 SQL，去做 Join 再做 union，而使用图则会简单很多。

上图中展示了图 match 和表 join 的性能对比，可以看到 match 在构图时的耗时数会比表的耗时数更多一些，但换来的是复杂场景下多跳查询的性能提升。

4. 架构演进

上图展示了我们新的架构，采用了全部流式的做法。前面的数据处理还是基于原来的链路，用 Flink 消费业务数据，然后做清洗统计，再把数据打到数仓的 Topic 里面去，而告警部分与之前不同，现在是用流来做的。主要包括三个部分，即异常检测、图归因和异常通知。接下来详细介绍每部分具体的工作。

5. 异常检测/通知

异常检测包括两个模块，一个是动态阈值的计算，会有一个模块去消费数仓的数据，然后基于历史数据进行动态阈值的计算，再把动态阈值打到 MySQL 去；另一个模块会消费数仓的数据，结合 MySQL 里面的动态阈值去进行异常的判断，当判断到数据有异常时，把异常数据打到 Kafka 里面去，用于 tugraph-analytics 的构图。

再来看异常通知部分，这里主要是通过 Flink SQL 做聚合和变频，实现降噪的效果。新的流程具有三大优势，一个是流式引擎的时效性更强，而且目前作业都是通过 SQL 或者 GQL 的方式来实现，也从一定程度上提高了开发效率；第二个优势是引入了动态阈值算法，基于历史数据计算告警阈值，比静态阈值的方式更准确；第三是实现了变频告警，通过窗口去做聚合变频，业务高峰期或者一些核心场景的指标的告警敏感度要求更高，低峰期或非核心场景的告警敏感度要求则相对较低，我们通过 Flink 实现了灵活的窗口进行变频的通知，已达到降噪的效果。

6. 异常归因

接下来介绍异常归因，上图是异常归因的数据流图，图中有一些指标、告警、任务/服务变更记录，以及天气、交通等信息。其中指标和告警是从数仓的 topic 中加载数据，经过一定的加工计算，最后把数据打到图里面去。而对于任务变更信息，是通过 Webhook 的形式去接收变更平台的变更信息，然后进行一些关系的计算，再把数据打到图里面去。对于天气、交通等外部因素，就需要从互联网上面去抓取。增量更新的数据流到图里面之后，会去跟全量数据一起做一个图的计算，然后将计算结果输出成表，同时增量的这一份数据也会被更新到全量的图里面去。

接下来看一下图里面的数据具体是什么样的？上图展示了其中的一个缩影。可以看到告警和指标之间有关系，同级指标和价值指标之间也同样存在关系。这里画出的只是一跳，实际场景中可能会有更多跳的关系。指标和因素之间，因素和因素之间，也都存在着关系。在实时归因告警场景下，我们需要考虑两个问题，一个是最新实体之间时间的对齐以及数据的延迟问题，以保证计算结果的准确性；另一个问题是，我们的因素数据大多是离散的，比如天气，一般的表达形式可能是多云、晴或者大雨、小雨，这种在图里面如果是文本的形式，我们是没办法拿来做计算的，所以这里就需要有一套规划的逻辑。

针对于数据对齐以及延迟的问题，我们是以 5 分钟一个切片提前建立好这些实体之间的关系，数据来了之后会更新这些实体的一些属性，并把它们标记为更新，这样就能保证时间的对齐，同时因为我们引入了标志位，可以识别到数据的延迟问题，会将这些延迟的情况返回到我们的归因逻辑中去作为一个变量，使得我们的计算结果更加准确可行。

对于数据离散的问题，我们制定了一个异常分等级，以天气为例，基于历史数据统计每一类数据对于业务的影响，然后对他们做一个异常等级的划分，用数字表达，就可以加入到归因逻辑计算中去了。

完成构图之后，来看一下具体的异常归因计算逻辑，包括下钻和归因两部分。下钻部分，告警进来之后会先去查找它关联的同级指标以及下级指标，然后对查找到的这些指标计算贡献率，加入归因的路径中。

首先我们会找到这些指标管理的因素，然后判断这些因素的异常分是否大于异常系数，如果大于异常系数，会去找到这个因素关联的指标数以及它关联的告警数有多少。然后结合上面的贡献率计算出现在这个因素的置信度，当置信度大于这个系数的时候，我们就认为现在告警会受到这一因素的影响，最终输出有影响的 top k 因素。

整体采用成本模型的思路，先下钻到贡献率高的城市，再对异常因素的告警分进行计算，并判断是否跟告警有关。在使用的过程中我们也遇到了一些问题，进行了修复，并把相关代码提交到了 Git。

完成了图数据的构建和计算之后，再来看一下这块数据的应用。包括两种场景，第一种是实时计算，针对于核心场景我们会通过 ETL 的方式计算好，然后把数据打到外表去进行后续的相关告警逻辑。对于一些非核心的场景，数据不需要往外发，否则会导致很多告警噪音，这种情况下就可以通过 OLAP 的方式进行查询。同时我们在对计算逻辑进行改动的时候，也是通过 OLAP 来做一些验证的，包括归因结果的反查。

03 收益前面介绍了异常检测和归因的实现方式，下面来看一下这一做法带来的收益，主要分为两个方向，一个是时效提升，另外一个是能力拓展。

时效提升方面，首先告警时效实现了从批到流的优化，告警时效从原来的 1 小时缩短到了 5 分钟。另外，从原来的代码开发到现在的 SQL 和 GQL 的开发，也使得开发效率有了大幅提升。计算性能方面，从原来的表 join 到现在的图 match，使得计算性能也得到了进一步提升。

能力拓展方面，借助于图，我们能够去表达多实体之间更复杂的关系，也使得我们的归因效果更加准确。除此之外，因为我们告警场景最终对于告警逻辑的修改一定是要基于流量回放去做效果验证的，现在新的架构是完全基于时序的，因此为我们后续的全局流量回报打下了基础。

04 未来规划

关于未来规划，首先还是流量回放，因为我们认为这是整个告警逻辑里面至关重要的一点，所以接下来会做一个全局的流量回放。第二个方面是拓展图 OLAP 的场景，我们计划是把任务诊断场景接到图里面来，也会去寻求接入更多的图数仓场景。第三个方面是自然语言到 GQL，因为大部分人对 GQL 的还是比较陌生的，未来会通过大模型生成 GQL 来降低使用门槛。

以上就是本次分享的内容，谢谢大家。

05 问答环节

Q：图主要就是用到存储和查询吗？

A：我们主要是要用到增量计算、实时计算，因为我们现在的告警逻辑是实时的场景。除了告警的发现，还要去做告警的归因，而归因因素之间存在一些很复杂的关系。原来通过多表 join 去做，代码逻辑比较复杂，所以我们引入了图来做复杂关系的查询。采用 ETL 方式，把数据读到图里，计算完再向外表去输出。

以上就是本次分享的内容，谢谢大家。

本文来自公众号：DataFunSummit

原文阅读