项目简介
本案例是一个专注于flink动态规则计算的项目，核心技术组件涉及flink、hbase、clickhouse、drools等
项目可根据各类个性化需求进行二次开发后，直接用于实时运营，实时风控、交通监控等场景的线上生产
1.1背景介绍
本项目案例，本质上是一个基于flink和drools实现的动态规则系统；
只是，为了更好地带领读者理解和推进系统的开发，这里假设项目的业务背景是一个电商企业的实时市场运营系统；
易牛鹰眼FLINK动态规则实时智能运营系统，是基于用户行为洞察的一站式智能运营平台；
集活动创建、执行、管理、反馈、迭代为一体，能够通过用户行为、属性、标签等数据筛选受众，实现目标人群的精准触达，提升关键指标和运营效率。
1.2系统功能
精细化营销闭环方案
- 活动策略制定
每天都想策划行之有效的运营活动？
在易牛实时智能运营上您可以灵活创建活动计划，制定活动目标、触发时间、计划类型，快速落地活动策略，释放运营想象力！ - 用户精准筛选
还在提需求等待数据部门的漫长排期？
通过用户属性和行为数据洞察，还有丰富的分群和标签随需随取，您可以快速筛选符合活动设想的精准人群，让精细化成为习惯！ - 受众精细化触达
用户触达手段单一？
易牛实时智能运营为您打通了短信、微信、弹窗、App 推送等多种用户触达通道！
1.3适用场景（实时运营）
- 订单催付
- 信息推送
- 产品上线通知
- 新品发布
1.4适用场景（实时风控）
风控是业务场景的产物，风控系统直接服务于业务系统，与之相关的还有惩罚系统和分析系统，各系统关系与角色如下：
- 业务系统，通常是APP+后台 或者 web，是互联网业务的载体，风险从业务系统触发；
- 风控系统，为业务系统提供支持，根据业务系统传来的数据或埋点信息来判断当前用户或事件有无风险；
- 惩罚系统，业务系统根据风控系统的结果来调用，对有风险的用户或事件进行控制或惩罚，比如增加验证码、限制登陆、禁止下单等等；
- 分析系统，该系统用以支持风控系统，根据数据来衡量风控系统的表现，比如某策略拦截率突然降低，那可能意味着该策略已经失效，又比如活动商品被强光的时间突然变短，这表面总体活动策略可能有问题等等，该系统也应支持运营/分析人员发现新策略；
其中风控系统和分析系统是本文讨论的重点，为了方便讨论，我们假设业务场景如下：
- 业务场景：互联网电商行业；
- 风控范围包括：
- 注册，虚假注册；
- 登陆，盗号登陆；
- 交易，盗刷客户余额；
- 活动，优惠活动薅羊毛；
- 风控实现方案：事中风控，目标为拦截异常事件；
风控系统有规则和模型两种技术路线，规则的优点是简单直观、可解释性强、灵活，所以长期活跃在风控系统之中，但缺点是容易被攻破，一但被黑产猜到里面就会失效，于是在实际的风控系统中，往往再结合上基于模型的风控环节来增加健壮性。但限于篇幅，本文中我们只重点讨论一种基于规则的风控系统架构，当然如果有模型风控的诉求，该架构也完全支持。
规则就是针对事物的条件判断，我们针对注册、登陆、交易、活动分别假设几条规则，比如：
- 用户名与身份证姓名不一致；
- 某IP最近1小时注册账号数超过10个；
- 某账号最近3分钟登陆次数大于5次；
- 某账号群体最近1小时购买优惠商品超过100件；
- 某账号最近3分钟领券超过3张；
规则可以组合成规则组，为了简单起见，我们这里只讨论规则。
该系统有三条数据流向：
- 实时风控数据流，由红线标识，同步调用，为风控调用的核心链路；
- 准实时指标数据流，由蓝线标识，异步写入，为实时风控部分准备指标数据；
- 准实时/离线分析数据流，由绿线标识，异步写入，为风控系统的表现分析提供数据；
前面提到规则往往由人编写并且需要动态调整，所以我们会把风控判断部分与规则管理部分拆开。规则管理后台为运营服务，由运营人员去进行相关操作：
- 场景管理，决定某个场景是否实施风控，比如活动场景，在活动结束后可以关闭该场景；
- 黑白名单，人工/程序找到系统的黑白名单，直接过滤；
- 规则管理，管理规则，包括增删或修改，比如登陆新增IP地址判断，比如下单新增频率校验等；
- 阈值管理，管理指标的阈值，比如规则为某IP最近1小时注册账号数不能超过10个，那1和10都属于阈值；
1.5适用场景（实时推荐）
推荐系统本身是一个复合系统，可能涉及到用户画像，推荐算法，事件行为统计，商品属性管理，商品查询等；
而推荐系统中的推荐策略，大体来说，可以分为“按规则推荐”，“按热门榜推荐”，“按推荐算法推荐”，“按用户画像属性推荐”；
其中，本实时动态规则系统完全可以适用于“按规则推荐”的策略场景
1.6运营需求示例
公司最近有一个商务休闲服装品牌的商家&平台联合促销活动，在3.25-4.25期间，只要购买该品牌的服装，则都可以使用一个50元的代金券；
市场运营人员不想把优惠券无差别地发放给平台所有用户，而是想把优惠券尽可能发给有可能产生购买行为的用户；因此，市场部定义了一个发放优惠券的促销规则：
受众画像属性条件：
- 用户年龄：28-40岁之间
- 用户性别：男性
- 月累计消费金额：>=2000
受众行为属性条件：
- 用户在最近1个月内，有过10次男装浏览行为
- 用户在最近1个月内，有过5次“商务休闲”关键词搜索行为
- 用户在最近1天内，依次做过“浏览服装栏目”、“收藏服装商品”，“查看购物车”行为
规则触发条件：
- 用户浏览男装
此处只是众多需求中的一个例子，而这类需求是灵活多变的，且最好能够对在线运行的规则进行动态管理（新增，修改，暂停，启用，删除等）
1.7系统需求概述
1.7.1规则动态发布管理
1.7.2规则运行状态监控
1.7.3规则运行效果分析
如果从动态的角度来看一个运营（或风控等）系统的话，我们至少还需要两部分，一是衡量系统的整体效果，一是为系统提供规则/逻辑升级的依据。
在衡量整体效果方面，我们需要：
- 判断规则是否失效，比如拦截率的突然降低；
- 判断规则是否多余，比如某规则从来没拦截过任何事件；
- 判断规则是否有漏洞，比如在举办某个促销活动或发放代金券后，福利被领完了，但没有达到预期效果；
在为系统提供规则/逻辑升级依据方面，我们需要：
- 发现全局规则，比如某人在电子产品的花费突然增长了100倍，单独来看是有问题的，但整体来看，可能很多人都出现了这个现象，原来是苹果发新品了……
- 识别某种行为的组合，单次行为是正常的，但组合是异常的，比如用户买菜刀是正常的，买车票是正常的，买绳子也是正常的，去加油站加油也是正常的，但短时间内同时做这些事情就不是正常的。
- 群体识别，比如通过图分析技术，发现某个群体，然后给给这个群体的所有账号都打上群体标签，防止出现那种每个账号表现都正常，但整个群体却在集中薅羊毛的情况。
这便是分析系统的角色定位，在他的工作中有部分是确定性的，也有部分是探索性的，为了完成这种工作，该系统需要尽可能多的数据支持，如：
- 业务系统的数据，业务的埋点数据，记录详细的用户、交易或活动数据；
- 风控拦截数据，风控系统的埋点数据，比如某个用户在具有某些特征的状态下因为某条规则而被拦截，这条拦截本身就是一个事件数据；
下面是一个典型的大数据分析场景，架构也比较灵活，此处仅仅给出一种建议的方式。
相对来说这个系统是最开放的，既有固定的指标分析，也可以使用机器学习/数据分析技术发现更多新的规则或模式；
