数据计算平台的反模式：从一个净损失100万美金的事故说起 作者 | 张彭善整理 | 邓艳琴本文整理自 PayPal 大数据研发架构师、资深数据科学家张彭善老师在 QCon 上海 2020 的演讲，他跟我们分享的是PayPal 风控团队从四个事故和五个反模式中总结出的经验。今天，我和大家分享的内容是 PayPal 风险管理数据计算平台。 从一个生产事故说起我们首先从一个生产事故说起。这个生产事故带来的直接的经济损失是 100 万美金，而这个 100 万美金它还是一个净损失。净损失是一个什么样的含义？就是指它还不仅仅包括我们 PayPal 的营业额所受到的损失，还包括 PayPal 把钱赔偿给了用户所带来的损失。 那么这样的一个生产事故是由什么样的原因造成的呢？其实是我们风险管理的一个产品上面的策略出了问题。在某一时刻，它对交易的拒绝率从 1% 上涨到了 4%，对欺诈交易的识别率从 70% 下降到了 40%。那我们这里所说的策略到底是什么呢？ 我们可以看一下这样一个最简单的策略——如果机器学习的风险模型判定分值大于 600 分，我们就可以拒绝这样的一笔交易。当然最终造成生产事故的问题，是因为某一个上游数据的不可用，造成了一些特征的不可用，进而造成了整个模型分布的一个变化。 带着这样一个问题，我们来看一下今天的主要的内容。 首先我会和大家去介绍一下整个 PayPal 的风险管理系统以及解决方案。在第二部分，我们会展开讲解如何构建这样一个数据和计算的平台来解决风险管理这样的业务问题。其实大数据发展了这么多年，大家对于这种数据和计算都有一些经验，所以在第三和第四部分，我们更多的是从一些事故出发，看一看能不能在这些事故中学习到更深层次的知识和经验。通过这些事故，我们会总结一下对于数据和计算系统的一些反模式，以及我们如何去避免这样的一些反模式。当然，这些反模式和传统的软件的反模式还有一些不一样，具体不一样在哪里？看到后面你就知道了。 PayPal 风险管理平台PayPal 目前在全球 200 多个国家和地区都可以使用，支持几十种货币的交易。那么对于这样一个全球化的支付平台，最重要的有两个能力，一个是合规，就是说我要对这 200 多个国家和地区有准入的市场机制。另外一个是风险管理，这是在说我们要如何在这样一个全球化的支付产品中去管理风险。当然，风险的管理不仅仅是指我们要给公司挽回一些损失，也是指我们还要帮客户挽回损失。 因此，我们的最终目的就是要让用户更放心地在我们平台进行支付，对用户来说，他做任何的支付，都不需要担心有任何的风险和欺诈的问题，即使有任何的问题，其实最终可能也是由我们 PayPal 来进行赔偿。 那么怎么做到这一点呢？大家都知道，主要的解决方案肯定是基于数据的解决方案。没有数据，整个风险管理几乎都无从做起。 我们会在数据之上构建一些机器学习和深度学习的模型。当然，它们并不直接进行判定。基于这些模型，我们有一些决策去进行风险模型的判定，它们会对最终的业务产生影响，这一点我在开头分享的事故中也提到过。但这并不是说所有的欺诈问题都能百分之百被这些模型解决，因为有很多新型的欺诈。第一，它不能被反映到训练数据里面，第二，我们知道，即使在训练数据里，模型也有欠拟合和过拟合的问题，它不一定能学习到这样的一些欺诈的类型，所以我们需要灵活的规则系统去做补充，以防欺诈风险。 无论是模型、决策或者是规则，最终其实都是以数据为支撑。 我把我们使用的数据大概分为三类，当然，我们主要使用的是一些行为性的数据。 第一类就是基于历史的行为数据。比如说一个用户他在一年内所做的交易的笔数，属于欺诈的交易的笔数，这个维度还可以扩展很多。那么从用户的角度，从 Cookie 的角度，从 IP 的角度，从 Email 的角度，各个维度，我们都可以去利用这样的统计数据。 第二个维度是基于流式的统计。其实我们的系统有很多职业玩家，他们每时每刻都在试探我们的系统。当我们的系统有任何的不可用问题，损失马上就来了。所以对于流式的统计其实也非常关键，比如说最近 1 分钟或者 5 分钟里用户的登录情况和交易情况。我们整个的时间窗口也可以扩展得非常大，最多可以扩展到一个月甚至是 90 天去评估。 第三个维度是基于图的连接关系的行为数据分析。欺诈分子之间总有一些内在的关联，可能是账户之间，也可能是账户和设备之间。这些关联我都可以利用起来，比如说，本来评估的可能是单一维度的信息，但是我现在可以把这个账户连接到的其他账户的行为也纳入评估。 这里有一个统计，是我在 2019 年 7 月份在内部做的一个分享。大概在一年半的时间内，我们整个计算平台的特征数目从 6000 增长到了 14000，模型的数目从 80 增长到了 250。 这个数据是 2019 年 7 月的，而现在这个数据又翻了一番。我们可以看到，随着计算规模的扩大，特征或者模型的复杂性也在随之变化，变得更加复杂。 到今天为止，很多模型可能都是基于深度学习，基于 Embedding、基于多任务学习这样一些模型去部署，那么对于特征也是一样，有很多的特征，可能本身它就是一个小的模型。还有我们刚刚介绍的这种基于图的连接关系的非常复杂的特征，如果我们去查询多跳，有的时候它的计算会有一个爆炸式的增长。那我们如何构建一个数据和计算平台来满足这样的一个日益增长的业务的需求呢？如果我们看整个的数据和计算平台，在今天来讲，用一个词来形容的话，就是端到端。对于业务来讲，一个端到端的数据计算平台，可以更快地帮助他部署，用于业务支撑的模型或者是数据计算。 从功能的角度，我们大概将这个计算平台分为了三个子平台。 第一个平台是关于数据和特征的平台，第二个平台是关于模型训练的平台，这样一来有了数据我就可以去训练模型。而在有了模型之后，我还要让它起作用，我要把模型部署上线，所以第三个部分就是说关于模型上线和线上管理的平台。但第三部分也包括特征的一些管理，因为很多时候我们可能大部分的工作都在数据和特征上面，基于这样的一个平台，底层可能包括很多内容，一方面我们要构建统一的 Portal 来满足这样的一个端到端的产品的需求。另一方面是对所有数据的统一存储和建模，如何保证线上线下的数据的一致性，这个也非常关键。还有我们线上的统一的计算服务，能够帮助用户随时随地快速部署上线。 数据和特征平台 我先给大家讲第一个平台，数据和特征的计算平台。如果大家有一些经验的话，可能会发现，我们虽然是在做机器学习，但其实大部分时候都在做数据，大概有 60% 以上的时间可能都是和数据相关的。还有一个更加让人崩溃的实际情况，你可能花了几个月好不容易做出一个模型，上线之后却发现一些数据不可用，你可能还要往复这样的一个数据和特征的过程。 所以数据和特征的计算平台更多的是构建了一个统一的地方。对于用户来讲，他拿到的数据都可以信任，它和线上的数据是一致的。基于这些数据，用户可以开发一些特征的计算逻辑，这些特征的计算逻辑可以被同步到线上，你不会遇到因为线上线下不一致的逻辑而导致的种种问题。目前来说，整个数据和特征的计算平台其实是最难构建的，因为有各种各样的数据质量问题和数据不一致的问题。 端到端的训练平台 相对来讲，训练平台更加容易一些，因为我们在准备好训练数据和特征逻辑之后，接下来就变成了一个稍微定量的问题。 那我们怎么训练出一个模型呢？我们在训练平台有一个自动化的管道化的构建，你无论是做特征统计、特征选择，还是做模型的选择，都可以进入管道化，甚至最后我们也可以给你推荐一些还不错的模型。当然在每一个步骤用户都可以去介入，可以去调整里面的参数，调整里面的数据处理方式，获取最终他想要的一个模型。 自动模型和特征部署平台 那么对于用户来讲，整个后端的计算资源 CPU 也好，GPU 也好，甚至是 Framework 也好，都是做了一个很好的抽象，用户不需要关心，也不需要去维护这样的一些平台级别的功能。有了这样的一个模型和特征，最终我们需要将它们部署上线，我们希望它们能够真正的带来收益。其实我们的功能无论是对于特征还是模型，我们都支持一键上线。当然，一键上线从功能角度上讲是没有问题的，但是从安全的角度来讲，其实还是需要有一个审核的机制，确保你不会对线上的交易有灾难性的影响。 但是所有的这些离线的模型和特征，我们都可以把功能一键推到线上，然后自动设置一些流量的策略。通过他们分配到的流量，这些模型和特征都可以运算起来，最终我们有相应的报表生成，然后你就可以去和线下结果去做对比。甚至今天，根据每个业务的数据分布，我们还实现了一个自动化的策略的上线，就是说你对业务的判定大于多少分，要做什么样的操作，在多少分到多少分之间，再做一个什么样的操作，这些都是自动进行的。最终我们所做的一切都是为了更快更高效地支持业务方的需求。 基于 Gremlin 的实时图计算平台在前面，我提到过我们大概有三种不同的数据计算维度，如果从数据计算的角度来讲，大概在 2018 年底到现在，其实我主要发力的是图的实时计算。大家如果听过我在 QCon 上海 2019 的演讲就会知道，当时我分享的是大规模的实时图计算的平台的建设经验，在这个平台中我们选用了 Gremlin 这样的开源的框架。 其实大家可以看一下简单的 Gremlin 语言，它最大的优势是它的表达性，基本上，你写下表达语言，就把整个的计算逻辑算下来了。它从一个 IP 到它关联的账户，再到它关联的 Cookie 的运算，整个计算非常直观，这是 Gremlin 一个非常大的优势。当然还有很重要的一点，我们为什么会选用 Gremlin 呢？因为作为一个开源的软件，它后面的编译层、优化层和存储层，我们都是做了定制，我们的存储层是根据我们主要支持的 Aerospike，这是我们公司的 NoSQL 解决方案，已经内置了一些高可用和灾备的功能。我们主要的一个优化是改善了 Gremlin 原来序列化的查询，加强了并行化的查询来解决整个实时计算延迟的问题。 大规模仿真平台我们的业务方经常会有这样的一些需求，比如说他说我有一个很棒的想法，我新设计了一个很好的特征，我新做了一个很好的模型，我想去试验一下它的效果。在之前我们只能在线上给业务方去做这些实验。 但从 5 年前开始，我们就构建了一个仿真计算平台，以满足用户的实验性需求，这一块我在后面的反模式的部分会继续去讲。那么通过这样的一个仿真计算平台，我们可以允许我们的用户以容器化的形式去部署整个计算服务，然后它可以把它最新开发的特征和模型一键部署到这样的一些计算服务中去。 其实对于仿真计算平台，它最大的难点是对于当时的数据快照的获取，比如说我们的流量是过去的流量，我们的交易可能是几天前，甚至几个月前的一个交易，所以想要知道当时他依赖的数据的情况，我们需要有版本，或者说快照的能力。 那么对于一些事件来讲，比如说登录交易，我们是基于事件的建模，本身它们就有基于数据的版本的能力，对于一些 Key Value 数据，包括一些离线数据，一些流式数据，我们是基于 HBase 去建模，去构建这样的一个多版本的快照的模式。 数据规模的压力也是我们选用 HBase 的一个很大的原因。大家可以想象一下，实际数据的规模其实是线上系统的规模的放大，因为我需要记住这个数据的历史变化的所有的版本。因此，对于图的实时计算的仿真来说，它面临的挑战会更大。这个主要是基于我们对于图的快照和 Journal 的方式，去实现图计算仿真的能力。 有了这样一个仿真计算平台的能力，我们就不担心我们的用户做任何的实验性的逻辑，因为所有实验性的逻辑都可以在这样一个平台去实现。在反模式部分，我后面也会讲到为什么我们要做这个平台。 这样一个平台，我在过去几年处理了很多的生产事故，这些生产事故导致了金钱的损失，给我们带来了非常多的压力，但是更重要的是我们从这些事故中学习到的东西，我们通过举一反三来反思整个系统存在的问题。 发生在 PayPal 的四个事故整个系统存在的问题其实对于所有的数据计算系统都是通用的，所以我们通过回顾一些事故来了解一下整个数据系统所独有的一些特点或者问题。 事故一：上游空值表示加戏，大批交易惨被拒绝第一个事故，这个事故和开篇的事故比较类似，也是在某一个时刻，我们产品的某一个策略，它对交易的拒绝率从 1% 上升到了 10%，也就是说大概有 10% 的交易都被我们的策略给拒绝掉了。 这是一个很大的生产事故。这个生产事故的直接的原因和开篇提到的问题类似，也是模型分布的下降导致了整个策略的变化。而最根本性的原因是我们上游的一个数据字段，它对一个空值的表示由一个空字符串转换成了一个 #。所以这里的计算逻辑是对于字段的不等于空的一个表示发生了问题。 当我们找到这个问题，要去修复它就非常容易，我可以把不等于空改成不等于空或者是不等于 #，但是这有没有真正解决问题？其实并没有，因为我们以后可能还会面临其他问题，比如它可能会改成问号，可能会改成别的各种各样的不同的空的表示，这是我们不能预测的。 这里其实有一个技巧，如果对于不确定性的判定的逻辑更弱一点，那我们就更加倾向于对确定性的判定。比如说它不等于空是一个不确定性的判定，它等于 1 或者等于 2 的时候是一些确定性的业务，而这些确定性的业务的变化的可能性是很小的。所以，我们应该倾向于在它等于 1 或者等于 2 的时候做一个什么样的计算，然后把不等于空放到 else 里面去做计算。有了这样一个技巧，我们可以把这个问题举一反三，应用到所有的特征的检查上面，确保这样的问题不会再犯第二次。 为了最终的安全，我们要在上线之前检查最终所有的数据的分布。如果任何的分布发生了变化，可能我们上线的增量数据会带来系统的业务影响。如果我们提前检测的话，就可以把问题规避掉。 对于这个问题，我还将在后面的反模式那一块内容继续深入探讨。 事故二：Full GC JVM 暂停，永生代撑满苦难言第二个事故其实也比较典型。 对于整个模型和规则系统来讲，实际上我们的计算服务的上游是我们的决策服务和规则服务，他们通过一个微服务调用我们的计算服务。但是某一天我们发现这两个服务之间的差距非常大，可能在几百毫秒的规模。但是我们知道作为微服务来讲，作为 HTTP Gap 来讲，可能 10 毫秒就已经非常高了。那么，到底是什么样的异常导致了这么大的一个差距？ 其实问题发生在我们计算服务的上游，整个部署规则，部署策略的系统，正在发生 Full GC 的 JVM 暂停。为什么 Full GC 会发生？实际上，对于业务策略和规则系统，我们要求要动态部署，动态部署就会利用到 Java 的动态加载功能，所以在每一次规则和决策去部署的时候，我们都会发现这样的现象。 这里出现了两个问题。第一个问题是永久代（Perm Gen）被撑满了，撑满了之后再去回收，其实还是回收不掉，所以始终会处于一个一直在回收的状态。第二个问题是由于动态加载的一些新的对象导致 CMS GC 的 Concurrent Mode Failure。 最后其实我们统一用 G1 GC 去代替 CMS GC 的办法，解决了这两个问题。 我为什么说这个问题比较典型呢？因为我相信可能大部分的这样的系统都要支持业务，我们需要灵活地部署，不用每一次都要重新构建我们的服务，重新发布版本。那么随着规则和策略的慢慢增长，总有一天它会超越一个界限。到了这个界限之后，系统行为是否还如预期？是否会发生类似的问题？大家可以关注一下。 事故三：热点查询做无用功，严重拉低系统可用性第三个事故也比较有趣。某一天，我们整个计算服务的可用性降到了一个非常低的数字。我们查看整个系统发现后端使用的 NoSQL DB 有了一个热点的查询。那这个热点的查询是从哪里来的？ 其实，我们系统里大概 60% 的交易是有 IP 值的，百分之三十几是没有 IP 值的。对于业务方来讲，它就设计了一个 Key，代表一个不存在的 IP 值，而它的统计其实是基于全量的一个统计。这样一个 -9999 的 Key 导致了 30% 的流量都会查询同一个 Key，进而导致了整个 NoSQL DB 的吞吐量和性能下降，直接把整个计算服务的可用性都拉下来了。 这里其实有一个比较典型的跟业务相关的 Fallback 策略。如果数据不存在，我应该去查什么？这很多时候都是造成热点的隐患。 当然不仅仅这种 Fallback 是有这样的问题，后面我也会讲到，不合适的特征设计有时候也会造成热点的问题。 事故四：Schema 数据没有同步，计算请求全线延时第四个事故是这样的，我们某一个数据的 Schema 发生了变化，但是当时这个数据生产方只发送了新的 Schema，没有发送新的数据，进而触发了我们计算服务的一个 Bug，导致所有的计算请求都会延时两秒结束。 大家也知道，无论是离线数据还是流式的数据，可能它的 Schema 都在变化。比如说我们基于一个账户，我们统计 4 个值，那么今天是统计 4 个值，可能明天要统计另外 7 个值，我新加了一些数据，那么这个就会涉及到 Schema 的变化。但通常来说，我们的系统都是动态支持和加载这些最新的 Schema，然后去处理这些最新的数据。 后来我们回想起这个事故，发现我们大概有 4 个地方可以挽回这样的损失。 第一个地方就是数据生产方，生产这个数据的用户其实最应该负责这个数据和 Schema 的一致性，这是产生事故的一个最根本性的原因。 第二个地方是我们的 ETL，导入数据的一个组件。在它拿到 Schema 的时候，它可以尝试去把 Schema 解一下，如果失败了，这样的一个 Schema 其实不应该被上线。 第三个地方，我们线上的系统在收到这条数据，在写入 DB 之前，我们也可以去施加一个这样的限制。 第四个地方就是触发了我们整个系统的一个 Bug，这个 Bug 其实我也把它列到这了。中国有一个成语，叫一字千金。我跟你说，一字千金算什么？大家看看这一段代码，它们可是做到了一行代码就值 100 万美金。 在这段代码里面，整个的数据请求是一个线程调度的形式。我发起了一个线程去调度，然后用到了 countDownLatch，Java 里面的倒计数锁存器。但是这个地方有一个问题，在解析数据出问题的时候，countDown 这个方法并没有被调用到，导致另外一个线程等待超时。所以这里有个最简单的改这个代码的方式，就是把 countDown 放到 finally，确保它一定会被执行到。这样一来，我们可以解决生产环境的问题，还有对于所有异常的处理。 当然最后我们发现了这个问题，我们从各个角度都要举一反三，去尝试弥补整个系统的漏洞，对所有涉及到线程调用的地方，notify 也好，wait 也好，或者是 countDown 也好，一定要确保你的通知都是受保护的。 还有对于所有超时的时间参数，有没有设计一个当时的合理的值？我们最重要的是要举一反三，把系统里所有的这样的超时行为都找出来，避免类似的问题再次在线上再发生。 数据平台的五个反模式当然，我今天不是来和大家分享我们为什么有这么多事故的。很多的时候，发生了这些事故，公司都在赔钱，甚至有的事故对公司来讲还是公关危机。无论是钱还是公关危机，可能都是我们个人所很难承担的。 那我们能够从这些事故中学到什么东西，来避免以后更多的事故的发生，这个对我们来说才是最关键的。接下来， 我们来看一下数据平台的反模式。 反模式一：坏 & 可变数据源第一个反模式，可变的或者是坏的数据源。对于整个数据平台，如果大家去仔细思考一下，其实它和传统的软件平台有一点不一样，它的依赖从软件的编译型依赖变成了数据的运行时依赖，我们不大可能控制上游每一个数据的可用性，但是上游任何一个数据的可用性又可能会导致模型的变化。 其实模型是一个非常脆弱的系统，它又非常复杂，依赖了几百个特征，甚至几千个特征，任何一个特征有问题，这个模型就会有问题。而这些特征又依赖了很多的输入，任何一个输入有问题都有可能导致模型最终的问题，带来的都是生产事故。 所以对于这种坏的数据源，更多的可能是来自于上游发布造成的 Bug，比如在发布的时候，某一个字段不小心被去掉了。对于可变的数据源，有可能你在做某一个模型的时候，你依赖的流量是基于现在的产品，然后会有新的产品发布，这也会导致你的特征统计分布的变化，所以你也可以预期你的模型分布也变化了。那么我们到底要如何才能避免这样的反模式带来的问题？ 第一个，你要做监控，对于你所有的业务指标，所有的模型，特征的变化，你要能第一时间知道，所以我们需要有这样的一个流式的监控，去监测到我们的数据的变化。 第二个，我们要非常清楚地知道我们的模型和数据最终依赖的数据是什么，所以我们需要去构建整个的 Data Lineage 系统，我们要知道这一个输入可能会引起后面几个模型的变化，我们也要知道这样的模型可能依赖了前面哪些输入。但有了这些能力，只能说我们能够看到这些影响，那最终我们怎么去避免这些影响？ 有了这些 Data Lineage 系统，我们需要做一些回归的功能，对于任何的数据的变化，可能会影响我们模型或者决策的，我们在发布之前都要做回归测试，看看它对于真实系统的影响。 反模式二：未声明的数据依赖 & 消费者第二个问题是未声明的数据依赖和未声明的消费者。 什么是未声明的数据依赖？比如，一个模型有 n 个特征， n 个特征又依赖了 m 个输入。输入 1、2、3，我们和上游沟通过了，说这个数据我用了，你不要给我随便地不可用或者出什么问题。但是输入 4 在某一个 Corner Case 不小心被某一个特征引用，有可能上下游都不知道它被使用了，这就造成了一个问题，某一天上游把输入 4 去掉了，去掉了就意味着事故。这是一个未声明的数据依赖的例子。 那未声明的消费者又是什么呢？我们很多时候为了做一个风险管理的业务，上线模型的时候，策略也上线了。过了两天，另外一个业务方的同事看到了这个模型，他觉得不错，然后他就在他的策略里用了。那么在下一次模型升级的时候就很有可能发生意外。然后那个人就跳出来说，你为什么要修改这个模型的分布？你为什么要重新发布而不通知我？所有的这些都是因为未声明和未注册导致的，所以要避免这样的一个反模式。 我们当然有一个可以商量的方法，就是我把所有的数据依赖，所有的模型和策略都要做一个注册系统，你需要到我这来注册，我给你 approve，我才能让你去用。但是这样一个系统可能会比较昂贵。 那么回到第一个反模式，我们可能还是要优先去构建整个系统的数据依赖关系，我们要能知道整个数据的影响，即使你不声明，我也知道你用了输入 4，即使你偷偷用我的模型，我也能知道是你在用这个模型。当我知道了这些应用，我在后面做任何操作的时候，通过一定的回归，通过对于分布的每次上线前的自动化的检查，我就可以知道我的每次修改对线上业务的影响情况，进而避免类似业务事故的发生。 但我们回过来看，产生这种事故的根源，更多还是因为整个数据系统变成了运行时依赖，和传统的软件比，它其实是非常难以管理的。 反模式三：坏的级联模型的依赖性第三个反模式，级联模型，这个反模式也比较臭名昭著。 我相信大家可能也和我们一样，有很多业务方要做模型，做业务，大家都会有 KPI 的压力。有的时候我们要做一个性能比以前更好的模型，这里有一个最简单的方法，我可以教给大家。你可以用以前的模型做特征，加上一些新的特征，然后去开发出一个新的模型，通过这个方法，基本上我们都能做出一个更好的模型。如果这个时候你的模型做得还比老的模型要差，那就是你的建模技术实在太差了。 但这样的模型依赖给维护带来了噩梦。以后只要有相关的升级，这两个模型就要一起升级，所以这种级联的依赖在一开始就应该被终止掉。当然我们现在有这样的一个数据平台，有模型的发布平台，对于所有的这些依赖，我都可以识别出你依赖的特征是什么，我能够在第一时间去找到你是否依赖了一个已知的被业务用到的模型，如果你用到了，你就要去解释。 但是并不是所有的这种级联模型，我们都不允许上线，有几种可能还能再商量一下。 比如说上图右边的这种方式，它是基于中间的两个模型，这两个模型可能是一个中间的状态，我最后做一个 bagging 也好，做一个 ensemble 也好，然后到了最后的一个模型。如果业务方能够保证他只用模型三，或者我们从系统的角度来保证只有模型三会被业务用到，模型一和二只是一个中间的结果，这种状态还是可以被允许上线的。 反模式四：热点的聚合第四个反模式是对于热点，对于 Hot Key 或者是 Default Key，我们在前面讲到的产品事故中，已经看到业务方会去设计一些不存在的值的 Fallback 策略来弥补，即使在数据不可用的时候，我也可以给他一个缺省值，这会导致热点的发生。 还有一种情况也会导致热点发生，比如说我们的业务方设计了一个特征，这个特征是基于 Country 的，对于我们整个平台来讲，我们可能大部分的 Country 都是 US，当然对于国内的支付平台来说，大部分可能都是 China，这本身就是一个热点。 反过来我们再看一下这样的一个 Country 有没有意义。其实对于模型，对于整个业务的收益来讲，它没有任何的意义。一个交易属于美国还是属于中国，对于整个交易的风险没有任何的区分度。所以在这种情况下，业务在设计这种特征的时候，应该做一个更详细的刻画。比如说我可以做 City，我可以做 Country 加上产品，再加上时间，这样更细粒度的刻画其实更能够帮助到你，甚至能帮助你提高性能。 对于平台的角度来讲，我们不可能假设我们的业务方能给我们把这样的问题都处理掉，总有这样那样的一些异常，那么平台就需要能够自动检测这种热点。 检测出热点之后，我们可以利用一些简单的缓存机制，避免对 NoSQL DB 产生极端压力。其实到目前为止，大部分的 NoSQL DB 在这种热点的情况下应该都是很脆弱的。而一个特征，在数据计算平台，又很容易设计出热点来，这里还是需要多加注意。 反模式五：实验性的计算逻辑聊聊最后一个反模式。我们的业务方，他们总是有很多实验性的想法。 我们线上本来也维护了很多的实验逻辑，这个逻辑可能一辈子也不会被业务使用，没有任何的业务价值。但是业务方总有很多很新奇的想法，很新奇的模型。还有一些最新的模型，他都希望到这个系统来试一下。我们费了很大的劲把它部署到线上，这个东西到线上之后可能再也不会被删掉了，以后没有人敢维护这样的一个系统。甚至可能由于这样的一些实验代码，还会导致生产事故的发生。 那要怎么才能避免这样的实验性的计算逻辑带来的影响呢？第一个，我们要解耦，我们不应该把实验的计算逻辑和产品的计算逻辑耦合到一起。我们有一个简单的方案，大家可以把实验计算的服务和产品服务划分为两个独立的服务，然后把流量复制过去。但这个时候大家可能要小心一点，因为流量的复制意味着对数据库的双倍的压力。所以对于实验计算的流量，可能需要大家去做一定的流量的采样。但这个并不能真正改变这样一个因为实验性的计算逻辑带来的问题，有可能我还会把 DB 搞挂掉。 最终的解决方案就是我在前面介绍的线下的仿真系统。在这样的一个仿真系统上，用户可以随意做实验，我有整个历史流量给你去做实验，你要评估自己的特征也好，你要评估模型带来的收益也好，随便你造。同时，我也不用担心你会影响我整个线上平台的稳定性。 所以真正的完全的解耦就是去构建一个仿真计算的平台，但是它带来的开销就是你可能还需要去维护另外一个平台。我觉得业务发展到一定程度的时候，其实是可以考虑对这样一个仿真计算平台做投入。 混沌工程 & 故障注入 前面讲了这么多的反模式，其实它们都是整个数据计算平台的系统性的一些问题。那么有没有什么方式可以让我们真的能够预知到系统的缺陷？我们就借鉴混沌工程的思想，既然我怕我出问题，我就提前注入一些错误，看我系统到底有没有问题。这个思想被我们借鉴到了整个数据平台，我们可以把我们的数据，比如说一个关键的字段，置为不可用，我们也可以把我们的一些数据置为不可用，比如说某一个离线数据，某一个流式的数据，然后再来看我们整个的计算行为，比如说模型计算的分布变化，策略的变化。通过预先注入错误，我们能够发现系统中的缺陷，这样一来就可以提高整个系统的健壮性。 总结最后和大家总结一下我们今天的主要内容。 首先我给大家介绍了 PayPal 的风险管理的业务，以及我们如何构建基于数据的数据分析型的计算平台去支持业务。紧接着，我们大概过了一下我们整个端到端的数据和计算平台。而在第三和第四部分，更多的是分享我们从事故中总结出来的一些属于数据和计算系统的反模式，这些反模式确实是整个数据平台所独有的。 其实很多时候，业务方辛辛苦苦做几个月，好不容易做出一个模型上线，一年带来的收益是 100 万美金，一个事故可能就会把这样的一个收益给拉回来，所以大家还是要足够重视整个数据和计算平台的健壮性，尤其是以后业务越来越复杂，计算越来越重，我们不可能最终维护一个灾难性的系统。 作者简介张彭善，PayPal 大数据研发架构师、资深数据科学家。2008 年硕士毕业于上海交通大学，2012 年加入 PayPal 风险管理平台部门至今。在 PayPal 主要负责实施和构建了大数据计算平台、离线机器学习平台以及实时机器学习平台用以支撑 PayPal 全球风险管理业务。目前除负责机器学习平台外，正带领团队构建 PayPal 实时图计算平台用以加强风控数据维度。在大数据计算、分布式系统实现和优化、大规模机器学习和深度学习系统优化以及高可用可扩展计算平台等领域有着丰富的实战经验。 会议推荐2021 年 4 月 22-24 日，QCon 全球软件开发大会（北京站）将继续为广大技术人带来一场前沿技术学习和优秀案例品鉴的“视听盛宴”。大会现已确认 70 + 演讲嘉宾， 包含人工智能、智能金融、业务架构、Java 生态、大前端等 25 个热门技术专题，内容持续更新中。扫描下图二维码或点击【阅读原文】可直达大会官网，大会门票 7 折抢购中，购票立减 2640 元，团购享更多优惠！如有问题可咨询客户经理 ring：17310043226（同微信） ??点击阅读原文了解大会详情 阅读原文