保障安全交易的背后：探究eBay风控数据实时监控平台

在风控领域，大数据在决策过程中扮演着至关重要的角色。这些数据涵盖了各个方面，包括用户行为、交易记录、基本信息和商品相关信息等。数据的来源多种多样，包括来自内部数据库和流媒体传输的用户商品信息，以及通过页面JS捕捉的数据等。这些数据作为重要变量参与到机器学习模型和风控规则中，直接影响着风控决策的成败。

想象一下，如果关键变量存在严重错误，可能导致正常用户的交易被错误封杀，从而对公司的GMV造成严重损害；又或者，本应被识别并阻止的欺诈行为竟然在问题修复之前逃过监测，从而引发大规模欺诈，对公司声誉和资金造成双重打击。

风控决策的准确性直接依赖于数据的稳定性和质量。为了及时发现线上数据问题，监控显得至关紧迫。风控数据的监控面临着海量数据、异常检测报警时效性不足、准确性不够、监控需求多变繁杂、维护工作量庞大等一系列挑战。在本文中，我们将揭开eBay风控数据实时监控平台的运作机制，分享在解决这些挑战时的监控策略，同时深入探讨一些高级监控技巧。欢迎加入我们的数据监控之旅，共同前行，确保您的风控决策始终位于科技的最前沿！

风控决策有上百个接入点。每个接入点的流量，执行的规则，规则中使用的模型和数据都不同。而需要监控的变量大约有12K，数据Cardinality（或称”基数“，是指接入点-变量的组合个数，一个组合代表一个时间序列，需要对不同的时间序列进行独立监控）数量约十万级别，并且随着变量和模型的增加还在不断增加，将来可能到达百万级别，每天的数据量高达3000亿。对于数据的监控和告警，ebay内部打造了统一的平台Sherlock来管理，并且提供报警规则（Alert Rule）的自主配置功能。面对如此巨大的数据量，对于每一个时间序列来埋点，设置对应的告警规则，那么其中的配置、管理、维护的工作量工作量仍然庞大，难以想象。

之前，各个业务团队仅对自身的单个接入点（Checkpoint）整体结果或少量特定关键风控规则（Risk Rule）进行粗粒度监控。报警规则的效果受设定人经验影响，需要大量调优工作。监控的时效性也较低，且存在数据监控的盲区，需人工维护来创建和修改报警条件。对于特定的Risk Rule监控时，需要进行进一步的人工调查，以定位问题，距离实现全平台、全数据7x24小时自动监控的目标相距甚远。

还有一种监控方式，是利用DW(数据仓库)中的历史数据来进行监控。但是这种方式要求数据已经落盘到DW中，需要一定的成本，所以也覆盖面不是很广，只覆盖了少量重要的业务数据。其次落盘会有小时甚至到天级别的延迟，并且这个数据常常没有设置及时的自动监控，有些分析师可能几天才对这些数据做一次人工审查。之前线上出问题，常有几天之后才被分析师做分析的时候发现的情况，对于业务造成不小的影响。

在该中心模块中，对于不同的数据来源，用不同的Flink job来消费各个平台产生的日志kafka消息。这些消息体包含该次请求中计算出来的变量/特征/模型返回结果，以及相关的一些错误，执行时间等信息。

下面的图展示了一个典型的消息体示例：

根据监控要求，需要对这个变量variable1在checkpoint(upstreamApp): app1和flow: flowA下进行监控。首先把一分钟内的数据进行预聚合，把聚合结果保存在eBay内部监控平台Sherlock的Event数据库以供后面的监控使用。根据监控目标，定义指标的Schema如下：

系统利用Flink job进行数据预聚合。值得关注的一个点是确保实时监控数据的实时性。为了满足这一要求，特别重要的是在尽可能短的时间内完成对当前时间段内数据的处理。鉴于庞大的数据量，我们需要设计一个高效的Flink任务以满足这一需求。

对于每个Kafka消息，我们在反序列化后提取相关维度信息（如Checkpoint+Flow+Platform+VariableName），以便对数据流进行分组。通过累加器，我们对定义的各项指标进行计算。一旦完成统计，结果将以Kafka消息的形式发送出去。我们采用以下设计确保数据的高效处理。

各接入点的流量差异大，日均流量有的上亿，有的上万。足够的数据点能通过降采样减小数据规模，保持代表性的同时，降低计算成本，提高聚合效率。使用metadata配置checkpoint的采样率，实现即时、灵活地调整。

尽管进行了降采样，计算百分比等数据仍需高计算量。为降低计算成本，系统采用了TDigest算法，其核心思想是通过合并和压缩大规模数据的一组分位数，实现高效的分布近似和统计分析。

由于不同checkpoint的流量和变量使用不同，一些变量被多个checkpoint或同一checkpoint多次使用，可能导致热数据组的产生。这种情况下，计算节点负担沉重，内存资源短缺，计算速度明显下降，甚至可能引起系统崩溃。为解决数据倾斜问题，采用两阶段聚合方案。第一阶段对分组的key进行加盐以实现数据均匀分布和预聚合，第二阶段再将打散的key还原并进行再次聚合，得到最终的聚合结果。

图9:  Flink 二阶段聚合流样例

聚合时间窗口为1分钟，晚到的数据需以下处理：1）采用Watermark机制，允许数据最多延迟2分钟；2）对于超过2分钟的数据，鉴于实时监控需求，过长的延迟失去意义。因此，放弃预聚合计算，采用侧输出搜集这些数据，并进行metrics监控和告警。例如，若连续10分钟丢弃率超过5%，触发告警，需人工干预。

Kafka消息发送后，consumer应用接收数据，根据配置写入对应的Sherlock平台Events DB（ClickHouse）。采用Publish-Subscriber模式，通过消息解耦数据计算与写入，提升系统灵活性和可维护性。

我们将处理逻辑封装成通用组件，接入新数据源只需创建新Flink Job来处理不同的数据源消息，通过调用通用组件方法，显著降低新数据接入工作量。

Sherlock拥有强大监控功能，支持Events和Metrics数据。Metrics存储于基于Prometheus的TSDB数据库，Events存储于基于Clickhouse的列数据库。通过基于Grafana的Sherlock配置中心，我们可以定制Recording Rule对Metrics或Events数据进行聚合，生成新的Metrics指标数据。此外，我们还可以借助定制的Alerting Rule，让Sherlock定期检查Metrics或Events数据。一旦达到特定状态或条件，Sherlock就会迅速触发邮件、Page Duty、Web Hook API等通知手段，满足了数据异常检测的需求。

之前提到了数据预聚合，将每分钟的指标数据存储至Sherlock Events数据表。通过深入数据分析，我们发现绝大部分指标数据都呈现标准正态分布。

图10:  正态分布介绍

标准正态分布的Z值（表示一个数值距离平均值有多少个标准差）如上图所示，当Z值为3时，对应的置信度约为99.87%。这意味着该数值距离平均值相差3个标准差，大约有99.87%的数据在这个数值之下。当Z值为4时，对应的置信度为99.997%。为避免误报，异常检测标准被定为Z值为4。当Z值大于4时，可认定为异常。

基于这些假设，alerting rule可以采用7天均值加减4个标准差（Sigma）作为判断是否异常的标准。具体处理如下：

图11: Recording/Alerting Rule处理示意图

在前文提到的策略之外，为了更进一步降低误报，我们引入了一系列精巧的关键条件。这些条件并非凭空产生，而是建立在我们长期积累的监控经验基础上，每一个都经过了深思熟虑和反复验证。正是这种慎密的设计，使得我们在降低误报的道路上走得更加从容和坚实！

流量阈值策略：对于流量过小的时间序列，不会立即触发报警，以避免因不规律性而产生的误报。在特殊情况下（例如错误率过高），此条件可以有所放宽。

重复触发规避策略：通过与offset的历史数据进行比较，判断异常是否为新增情况，从而避免因重复触发而造成的不必要干扰。

稳定数据阈值策略：针对异常稳定的数据，即使出现微小波动也可能导致报警，因此可以设定一定的最小差异阈值（固定或比例）来判断是否需要触发报警。

分布异常处理策略：在数据分布类型发生变化时，例如聚集型或离散型数据的切换，应当触发相应的报警机制，以保障异常的及时发现和处理。

持续时间设置策略：对于容易出现波动的指标，短期内的波动可以忽略不计，适合设定较长的持续时间。例如，针对返回值百分位线（percentile）指标，若异常持续时间超过2小时，则触发报警；而对于较为明确的指标（如错误率），则在30分钟内触发相应的报警机制。

我们可不是设定单一规则，我们的Alerting Rule可是针对不同指标量身定制的！但问题是，对于同一个指标，这个Alerting Rule得覆盖所有的Dimension。比如说，对于变量指标，我们要在Alerting Rule的PromQL查询中加点魔法，比如 sum by(variable_name, upstream_flow)，这样一来，无论哪个Dimension触发条件，我们的报警系统就会亮起来。这样一来，一个监控指标就能搞定，就算有几万个dimension的时间序列也能轻松hold住，省心省力，降低了维护成本。

通过启用 Web Hook，我们成功实现了一键处理报警的功能，直接连接到通知中心。不过，问题来了，在同一时间，多个Checkpoint下可能有好几个变量在狂发相同的报警。咱们一一发邮件告诉用户，那邮件不就得泛滥成灾吗？别急，我们可是拿出了高招，把Sherlock发的报警在通知中心做了个整合，减少了这种重复报警对用户的“骚扰”。

另外，想象一下，成千上万的变量和Checkpoints散落在不同团队手中，有业务工程师、平台工程师、数据科学家，还有风控运营大军等等。每个团队都对自己关心的数据情有独钟。这可不能乱发，得精准送达！所以，我们在平台上设定了Notifier Config，搞了个超高级的分发规则，让每个团队都能收到自己感兴趣的数据。就是这么贴心！

图12: 监控平台-Notifier配置图

比如说，某个数据平台上的所有变量的alert，我们都送给了这个数据平台的团队。而对于某个checkpoint的所有变量的alert，我们差不多把它们一网打尽，送给了该checkpoint的工程团队和相关的业务团队。有些团队可能只对某种类型的alert感兴趣，或者干脆就只对某种变量心心念念。别慌，这都能通过配置轻松搞定！说白了，就是让报警送到该去的地方，不多不少，精准到位！

图13: 监控平台-通知中心架构图

具体的设计如上图所示。

报警触发与服务筛选

Sherlock的alert通过Webhook触发服务，这个服务根据配置筛选出对应的通知接收方，通常包括多个团队或个体。

信息丰富与补充

对alert进行信息的丰富和补充是关键一步。通过查询Risk变量的metadata服务，获取该变量相关的Risk Rule信息，调用ES的服务查找该Rule的触发情况，以及调用Sherlock Service查询指标变化前后的值。这些信息被组合成一个enriched alert。

Kafka队列传输与分区

Enriched Alert被发送到Kafka队列中，根据Checkpoint + Flow + Platform + VariableName + 收件人进行分区，确保有序传输。

消费与去重

Consumer消费Kafka队列数据，查询该消息是否在24小时内已发送过。如果是，则无需再次发送；否则，放入本地内存中的通知队列。

定时调度与排序

每10分钟执行一个调度任务，根据每个收件人来组合数据，并对数据按照严重程度进行排序。

告警通知

以邮件方式发送通知到相应的接收方，并将通知的结果记录到Sherlock Events中。如果存在额外的通知需求，比如需要触发PagerDuty，可以在Sherlock中自定义条件来触发报警，实现更灵活的通知方式。

通过一系列精心设计的处理步骤，我们成功将过去10分钟内的所有报警信息整合成一份超级邮件，直接送到用户手中。这份邮件不仅包含了用户感兴趣的所有报警，还融合了严重级别的指标变化数据、与Risk Rule相关的使用数据，以及Risk Rule触发情况的变化数据。这一切精华都在这封邮件里！看一眼邮件，用户就能秒懂，判断是否要迅速采取相应行动。搞得轻松愉快，就像吃个零食一样，简直是报警世界的大杀器！

刚刚的介绍让你感受到了吧？我们的系统真的是灵活得就像个魔术师一样！这可全靠着一个强大而灵巧的数据中心。在这神奇的数据中心里，充满了各种各样的配置数据，包罗万象，绝对不限于以下这些：

通知配置：什么样的alert，需要发给谁？这在第三节通知中心中已经有详细的介绍。

报警配置：哪些alert，需要disable。比如某些变量/checkpoint不适合该alert时，可以在这里配置忽略该报警。

数据丰富(Enrich)配置：在邮件中需要补充的信息，可以通过指定PromQL查询，offset等参数来实现对于数据丰富逻辑的控制。

Email的模版配置：通过定义邮件模版来指定数据来源对应的邮件内容来控制邮件的生成。

别以为配置这些就结束了，其实还有一大堆其他的系统配置！这些配置和三个模块的完美结合，让我们轻松实现了动态控制数据预聚合、异常检测、通知等功能。对于监控系统来说，运维工作可真是不少。别担心，我们通过调整这些配置就能轻松接入用户的需求，而不用一味地涉及到代码。

还有一种运维工作是不断对异常检测进行监控与调优。为了降低误报，我们得根据线上报警的反馈一直不停地调整Sherlock recording rule或者alerting rule，以期实现更出色的效果。异常检测这东西有点复杂，虽说Sherlock自带的PromQL查询工具能满足基本需求，但要说使用便利程度，总还是有点限制。所以，在配置中心，我们还特意提供了进阶版的工具，帮你高效运维，从此告别繁琐！

图14: Promql tool 优化显示

瞧一瞧左边那幅图，是不是觉得Sherlock配置工具就像个天书？再看右边那个，同样的PromQL查询在配置工具里展示得多么清晰！我们可不是凭空来的，通过打造PromQL AST解析器，专门用来剖析PromQL查询，呈现出漂亮的抽象语法树。而且，我们还能自动分析所有的Recoding Rule和Alerting Rule的关系。看看这个页面，直接链接过去，审查和问题排查都变得异常高效！

除了基本指标的监控外，系统还支持一些复杂指标的监控。

比如对于模型来讲，feature和model score的PSI(Population Stability Index)指数是一个非常重要的特征。PSI比较了在评分数据中预测概率的分布与训练数据中预测概率的分布。其思想是检查“当前评分数据与训练数据相比有多不同”。

以上是PSI的计算公式。首先需要对于数据分桶，然后对于每个分桶计算预期占比与实际占比，再用以上公式来计算PSI。如果PSI过高，则很可能是训练数据已经出现飘移，有可能是线上出了什么问题，或者需要重新训练模型了。

线上模型运行时，Feature数据和模型得分都存储在离线数据表中。确认数据稳定后，可用历史数据进行分桶，并在配置中心维护分桶信息。分桶方法为：数值类型按照p1、p5、p10、p30、p50、p70、p90、p95、p99计算7天内的占比，类别型数据按Top19分为19个桶，其余数据归为“其他”桶。

Flink Job在预聚合时读取分桶配置，对分桶进行聚合，将聚合数据保存至Sherlock Events。定时任务每隔10分钟，对于每个分桶，查询7天前的一小时和当前1小时的数据，来计算预期和实际占比，用于计算1小时的PSI。同样，也可计算1天的PSI。需注意，当期望占比为0时，按业界经验处理为较小的数，如0.0001。

图15: PSI架构图

根据PSI数据，可以制定相应的警报规则，例如当PSI大于0.25时触发报警。为减少误报，可添加额外条件，如使用7天平均加减4个标准差作为上下界，考虑流量稳定性等因素。

不仅仅基础类型，有些数据返回类型可是复杂得很。比如，有些模型的输出居然是Map或List，你能想象吗？从这些数据结构中提取分数得费一番功夫。更另人头疼的是，每个模型的开发者都有自己的一套规则，数据结构千奇百怪，缺乏统一规范。为了解决这个头疼的问题，我们引入了Derived Value Parser的神技。这玩意儿能让你定义提取逻辑，Flink在预聚合时就会乖乖地执行这个逻辑，提取出你想监控的数值。拿JsonPath执行expression中定义的逻辑，提取分数就是轻而易举的事。

有时用户希望监控特定数值（例如某变量的0值率）或特定区间的比例（例如模型分数在0～100的比例）是否发生变化。采用类似的方法，可以处理这些需求。例如，通过定义"categorical": [0.0]，指定需要监控的特定数值；定义"bands": ["[1,100]", "(100,500]"]，指定需要监控的数值区间。在Flink聚合时，根据这些配置进行分桶，得到特定返回值的个数和比例等监控数据。通过这种灵活的配置，满足了用户对于特定数值监控的个性化需求。

eBay风控数据实时监控平台，可谓是对风控领域数据监控的一场革命。面对海量数据、异常检测报警时效性不足、准确性不够、监控需求多变繁杂、维护工作量庞大等一系列挑战，这个解决方案脱颖而出。在经过生产环境中长时间的锤炼后，它变成了一个高效且用户友好的监控方式，满足了风控部门对实时监控的各种需求。这不仅仅是一个解决方案，更是一种通用的工具，可以为其他领域的监控工作提供参考和借鉴的宝贵经验。别再为监控而烦心，eBay风控数据实时监控平台来拯救你！