关于阿里风控
- 阿里风控大脑是“大中台小前台”战略，由于阿里风控管的风险业务很多，领域非常杂，所以允许不同的领域、不同的风控场景可以有自己独特的交互，有自己的console，但是用到的底层引擎必须是中心化的，由风控引擎做统一计算和处理。
- 阿里风控大脑代表高智能，后续会有深度学习和无监督学习模型大量上线，防控策略及防控方式都会更加智能化。目前阿里风控覆盖的主要业务和防控的风控场景包括黑客攻击、消费者保护、商家保护等。数据表示，阿里风控2019年双11保护了约388亿消费者的操作行为，同时挡住了约22亿次恶意攻击。
阿里风控典型防控链路
用户通过阿里的APP或网站访问阿里的业务会产生大量操作。这些操作进来之后会经过防控环节。首先会是端上防控，主要在应用层，比如应用的加固，应用的代码混淆等。然后是端上安全策略。第二层是在网络层，在网络层做流量清洗和流量保护。
- 基础安全防控：
网络层之后会有人机判断。人机部分在风控领域占比非常大，网络层+人机的防控方式和下面几层差异比较大，主要针对基础流量做防控，不会加入具体的业务逻辑，所以称其为基础安全防控。
- 实时安全防控：
人机比较复杂，一部分与流量相关，另一部分偏业务。其中偏业务的部分与下面几层称为业务防控范围。人机之后，在业务防控侧做白/黑判断，主要是出于成本考虑。如果能先判定用户行为的白/黑，后面则不需要做太多进一步判定，可以节约大量成本。然后是比较复杂的灰的判定，需要从多个维度来识别风险。
- 准实时联合防控：
近线是一种准实时联合性防控，将多种流量或者多种行为放在一起监控。
- 离线回捞：
离线主要是一种离线回捞，针对历史数据做大量回捞。不是所有业务都会走近线或离线，业务按照自己需求自行选择。
业务安全（MTEE）架构
- 风险识别主要是风险行为的判定，当检测到用户的某些行为有风险，如果业务比较简单而且识别准确度很高，那么此行为可以直接流入风险处置做处置。
- 如果识别出的行为没法确定或识别准确率不太高，会将其放到风险审核通过机审或者人审做进一步判定，判定之后才进行处置。
- 还有一些业务非常复杂，可能需要进一步的综合判定，那么会将其放到风险决策。比如一些风险不论在一段时间内触犯多少次，只能对其进行一次处罚，但是它在不同环节或是不同行为可能会被识别多次，即会多次被认为有风险，需要在风险决策中对这种风险进行统一去重、收口。
近线引擎的痛点场景
阿里在做近线引擎之前内部讨论了很久，因为近线引擎的边界和实时引擎比较接近，有时很难区分。很多时候在近线引擎里面做的事情在实时引擎里也可以做。那么为什么要做近线引擎？阿里发现有很多场景虽然可以在实时引擎里做，但是需要很多定制化的开发，需要按照场景专门找开发人员去实现。模型大规模推广之后，发现这样的应用场景越来越多，所以希望有更好的方式解决这些问题。
比如在商品新发时，需要结合商品图片信息和商品其他信息做综合判断该商品是否涉黄，对于图片信息，大部分公司可能会使用图片识别引擎，但图片识别引擎本身处理能力时快时慢，所以返回时间不一定。这种情况通过实时引擎等待返回是不可能去做的，所以需要做很多个性化的开发去实现整个链路的异步化。还有一些场景比如一个帖子有很多回帖，某些回帖可能是垃圾回帖或带有欺诈行为，大部分情况下是无法通过单个消息或者回帖判断其是否有欺诈行为，而要综合从发帖到回帖各个环节来判断，所以需要把时间跨度很长的很多消息放在一起来处理。
这在实时引擎中也不好处理，因为实时引擎本身就是基于事件消息触发的。还有一些非常复杂的业务场景，比如拉新场景，需要结合注册+登录+交易等多种行为来判断是否有薅羊毛等黑灰产行为，需要将很多事件放到一起去综合判定，在实时引擎中也不太好做。所以阿里最终决定做近线引擎来对上述问题进行更好的抽象和处理，希望有一种更好的解法来解决这些问题。
- 时效性不能太差，即允许有延时，但不能太久，因为如果延时太久，没有返回风险结果，业务侧就会认为这种行为是正常的，容易造成漏防。
- 要支持多事件综合处理的能力，在流计算中称为支持多流的join处理。并且需要非常灵活的数据处理能力，大部分算法里面会有很多非常灵活的数据加工，需要算法同学自己实现。
- 希望近线引擎能和阿里现有的风控体系无缝融合，因为阿里本身原本的风控体系非常庞大，上下游环节非常多，如果近线引擎孤立在外，可能需要做很多重复造轮子的事情。
- 性能优越的流计算平台。实时计算是阿里内部定制版的Flink，在公司内部已经搭建了性能非常好的流计算平台。
- 完善的SQL语义支持。实时计算有一套完整的SQL语义支持，因为阿里希望业务方尽量使用SQL，SQL使用成本较低，上手速度也会非常快。
- 平台开放、拓展性强。平台开放性、扩展性非常不错，兼容成本也非常低。
- 生态良好、持续升级。实时计算团队会持续优化SQL性能，使用SQL也可以持续享受到这个福利。
近线引擎功能框架
近线引擎的主要功能是把风控逻辑转换成实时计算能够执行的任务。近线引擎会把自己需要的数据需求给到事件中心，事件中心通过统一数据服务做数据增强之后流到实时计算里面做计算。为什么要把数据补全放到前面去做？因为实时计算是按照任务分别计算，同一个事件或同一个流量可能会在不同的任务里面计算多次，如果把数据增强放到Blink里面做，可能会存在多次补全。另外数据补全体量非常大，成本消耗很大，如果放到实时计算里面做，会对实时计算造成非常大的压力，并且不好做性能优化。
- 业务组件：对风控元素进行封装。在近线风控链路中有很多风控元素，比如事件中心的数据源、对应的下游风控决策或过程中需要用到的模型、算法、策略等。对这些元素进行组件封装，从而使用户使用近线引擎时可以快速使用这些风控元素。
- Security-SQL：语法和实时计算SQL类似，实时计算SQL中会要求写具体的物理实现，阿里希望用户不需要关注这些实现细节，而只关注业务逻辑，所以设计了S-SQL。
- 语法转义：将S-SQL翻译成实时计算SQL。
- Bli实时计算任务管理：包括任务的上下限、安全生产相关的，做灰度、做测试等。
近线引擎工作模式
- 算法同学模式—开放式SQL：
算法同学模式是开放式SQL。因为算法同学具备较强的数据能力和开发能力，并且经常会针对一些业务场景写个性化很强的算法，如果将其限制的太死反而不方便，所以支持完全用S-SQL来写业务逻辑。下图所示案例是从数据源取出一个字段。左侧是对过程中需要用到的业务组件的封装，中间是S-SQL。可以看到S-SQL写法跟Blink SQL完全不一样，只需要写
event.odl_event_ugc。event是数据源的特殊名词，即一个系统保留关键字。用S-SQL来写根本不用关注event是怎么来的等影响研发效率的信息，因为在系统、业务组件里有一套约定告知event从哪里来。
- 运营同学模式—通用能力：
运营同学可能有一定的数据能力，但没法自己去研发算法，但运营同学也希望能用上不同的算法来实现自己的业务需求。算法同学会按照不同业务场景开发一些通用能力，比如音频类、视频类、图片类、或文本类的，有基本的，也有具体业务的。每一个通用能力会转换成一个实时计算任务。业务同学可以通过交互式的方式配置自己的策略，其中可以引用通用能力用来做风险识别。当业务流量进来，首先进行数据预处理，然后按照引用的通用功能把流量转发到各通用能力对应的任务作相应计算，然后将原始数据和通用数据进行合并，之后再执行自己的策略，并最终将数据分发给下游，比如风险决策系统。整个处理过程拆分的比较细，主要是因为在同一个实时计算任务里面，如果代码量特别大或者是任务特别长，性能和运维会是非常大的问题。将任务拆的比较细便于管理运维，性能也会更好。
另外，任务之间基本通过两种方式进行数据传递。第一种是MetaQ，上游任务会通过MetaQ分发到下游。第二种是通过HBase，因为HBase的多列加上HLog可以很方便地把多条消息整合到一条消息里面，所以数据合并基本是用HBase来做。
目前近线引擎用了约2000CU资源，日均处理事件量约300亿，主要覆盖的场景有商品、内容、直播、拉新等多个领域，风险识别在风控领域占比约10%。相信随着模型和算法的进一步发展，产品的进一步完善，比重也会大幅上升。
离线引擎
- 新业务的接入需要快速提高安全水位。阿里集团规模最近几年发展越来越快，覆盖了非常多的业务领域。大部分新业务的安全水位很比较低，需要接入风控体系。原来会让新业务走实时引擎做对接，对接成本较高，对接速度比较慢。新业务方和安全小二都希望有一种更方便、更快速的对接方式。
- 新发现的风险，或在当前时间点漏过的变异风险，在发现之后需要对历史数据进行回捞，需求量很大。
- 业务同学在离线做大数据风险之后得到的一些结果，需要有渠道流入到审核或处置等后续环境。
- 业务同学会做策略变更，需要用历史数据来验证其实际影响，否则上线过程会变得非常慢。
离线引擎功能框架
- 语义转译SQL：
离线引擎底层主要依赖于MaxCompute，主要过程是将风险语义转换成MaxCompute任务去执行。离线引擎和近线引擎有些地方非常像，比如语义转换和任务管理部分，区别只是近线引擎基于Blink，离线引擎基于MaxCompute。
- 仿真模拟：
离线引擎的独特之处是需要对历史数据进行全面处理。一个很大的问题是新特征不能通过事件中心对历史数据进行补全，所以做了仿真模拟，即尽可能在离线上复现风控在实时引擎中用到的特征。按照如何去做将仿真分为三类：
- 业务原始数据：
业务原始数据即业务发过来的数据，按照目前策略，业务原始数据会通过事件中心全量写到MaxCompute中。事件中心使用DataHub 中间件，事件数据会通过DataHub写到MaxCompute。这类数据默认全部都有，不需再做过多操作。
- 不可模拟的增强数据：
第二类是不可模拟的增强数据。比如调用了一个第三方的服务，完全不清楚第三方服务的逻辑是什么，只知道第三方服务给出的数据。因为调用的第三方服务比较多，所以不可能逐一去看，这类数据基本暂时是不可模拟的。目前对于这种数据要预先配置在事件中心里面去做补全，其缺点是如果要在新的事件上做补全，已经属于事后的事情了，那么历史的那部分数据是没办法获取的。所以不可模拟的增强数据目前还有缺陷。
- 可模拟的增强数据：
第三类是可模拟的增强数据，按照模拟方式的不同又分为三种。第一种数据来自MaxCompute，因为很多数据，如离线指标、IP库原来就在MaxCompute上做计算，计算完成后同步到线上，给线上应用使用，对这种数据只需在做SQL翻译时直接采用数据源表即可。第二种是可归档数据。很多数据应用是在自己或周边团队建设的，如名单库、关键词库等等，非常清楚整个数据逻辑，可以按约定做好数据归档。归档方式多种多样，如直接回流到MaxCompute上，或将其转成文件，在MaxCompute上读取。归档数据体量不会特别大，数据量最多TB级。第三种基本指实时指标，线上几千个实时特征每时每秒产生的数据量都非常大，这些数据全量回流到MaxCompute的成本很高。但好的地方在于，实时计算用到的原始数据基本都是实时引擎流出的，而且这些数据事件中心都会接入，所以MaxCompute上也都有这些原始数据。而且实时指标的逻辑都维护在系统里面，是非常清楚的，所以可以基于原始数据及指标的计算逻辑，在MaxCompute上写一套模拟任务去模拟。阿里写了一套尽可能仿真的仿流式计算的任务模板，结果数据和流计算基本一致，最多会有一分钟或者更小时间窗口的误差。通过这一整套模板，就可以在离线引擎上提供很多与线上一致或接近一致的指标供用户使用。
- 业务原始数据：
- 任务调度
Blink无需太多任务调度，流量来了就处理，但离线批处理需要有任务调度。离线引擎的任务调度很大一部分是用DataWorks本身的调度，但也有一些场景没办法使用。
目前离线引擎的任务分为两种。- 周期性任务：
用户需要周期性的对一些增量或者全量的历史数据进行风险识别。周期性任务借助DataWorks的周期任务，因为它的周期任务管理已经做得很好，首先有完善的上下游依赖和调度，其次有丰富的调度参数配置，可以通过很多参数来控制调度。DataWorks周期性任务的缺点是任务结构不建议经常刷新，如果经常刷新任务的上下游结构，可能导致任务调度出问题。比如昨天的任务今天还未调度，如果把调度链路改了，任务就可能有问题甚至报错。但在离线引擎中，为了让一次风控计算任务性能更好，需要将一个任务拆成多个任务，即多个DataWorks周期性任务来处理。比如会先用一个任务做预处理，然后多个任务并行做各种数据增强，之后再进行合并，最后做策略执行，如此一来时效性会很好，执行速度会更快。但是周期任务中这种任务链会在策略变更时需要经常去刷新，为了避免刷新带来的问题，现在将增强数据固定分成了几类，比如无论这一次离线任务里是否使用名单，先将名单增强任务生成好，将任务节点永远保留在任务链中，那么无论怎么刷新，最多是刷新其中的逻辑，而不刷新任务结构，从而让离线引擎任务可以随时更新。
- 一次性任务：
需要对历史数据做一次性回捞，不需要跑多次。一次性任务是利用DataWorks中的触发式任务。触发式任务最大的问题是只支持单个任务做调度。因为一次性任务时效性很重要，用户做一次回捞不可能等几个小时，所以需要对任务进行更细致的分拆，分拆完成后在离线引擎里面自己实现调度，通过周期性轮询任务状态，自己完成任务依赖、任务调度等工作。
- 周期性任务：
经验总结
阿里目前有三个引擎，实时引擎、近线引擎和离线引擎，其好处是用户能做的事情变得更多，能力变得更强，坏处是引擎增多，概念增多，用户理解和使用成本会变得更高。所以阿里在引擎设计之初坚持的原则是用同一套元数据，即引擎的元数据都是一样的，可以在最大层面上避免用户对引擎理解的不一致。其次，在很长时间甚至到现在，一直在做的事情都是尽量让引擎用到的是同一套数据。未来希望所有引擎有同一套风控语言，例如S-SQL或比S-SQL更成熟、更抽象的一种语言。这种语言可用于解释风控场景中的各种语义。如果有这样一套风控语言，风控用户对风险的描述、风险场景的落地会更加直观清楚。
