本文源码:GitHub·点这里 || GitEE·点这里java
在编程体系中有不少复杂的业务是很难理解的,可是又须要作一个量化分析,给业务人员或者运营,或者用户一个参考标准,例如常见指数,芝麻分数,店铺等级,这类业务评定标准很是复杂,由于影响结果的因素不少。git
在多个维度的业务考量模型中,有一个核心概念叫作权重,指某一因素或指标相对于某一事物的重要程度,其不一样于通常的比重,体现的不只仅是某一因素或指标所占的百分比,强调的是因素或指标的相对重要程度,倾向于贡献度或重要性。一般状况下每一个维度的权重在0-1之间,全部维度的权重之和为1。github
能够从一个实际案例来分析权重的概念,好比判断一个客户是不是重点运营的对象,一般会从每周登陆次数,在线时长,交易量等维度考虑,若是客户A常常登陆,可是没有核心业务交易,客户B不多登陆,可是业务交易高,因此这里登陆次数的权重就应该低于交易量这个维度。算法
如何肯定权重占比,一般有两个思路,一借鉴专业业务人员的提供的经验,放到业务中不断尝试调优;二根据产品的分析数据,计算各个维度权重,也是须要在业务中不断尝试优化。spring
实际上复杂业务场景的量化过程是复杂且漫长的,须要对多个维度的数据作收集,有时候不但须要作周期性量化,例如几家大厂的信用分,也可能存在实时分析的场景,金融业务中的欺诈风控等,也有两种场景综合的实时推荐体系,都会用到量化流程。编程
对用户、店铺、产品等多种场景作综合评估,把一个复杂的事物经过多个维度抽象分析,生成简单容易理解的评估结果,例如店铺等级、产品评分、用户综合指数等,进而对各个使用场景产生参考的依据。从结果来看多是很容易理解,可是获取结果的分析过程是相对复杂的,有的场景可能须要周期性执行评估模型,有的场景可能须要实时计算,还有多是两种状况结合即依赖周期评估,也须要参考实时计算。设计模式
这个场景相对复杂度较高,例如用户进行搜索,可是又勾选一系列排除或者必要条件,这在搜索类的功能中很常见,在处理时不但要对用户的搜索条件作最高的匹配度分析,还要基于搜索结果作最优排序,这种就存在两个阶段评估,第一个阶段匹配最优搜索条件,第二阶段对匹配结果作最优选排序,最大可能的给出用户想要的搜索结果。数据结构
在金融领域内,这是很常见的一种风控模型,即对用户多个维度统计,作维度评分而后累加到一块儿,风控分越高,说明该用户风险越大,进而阻止高风险交易。架构
这个场景很常见,在金融理财类的APP中,使用以前必须通过一个测评体系,来判断用户的风险承受能力:例如保守型、积极型等,当用户购买的产品属于高风险时,会提示和用户的风险承受能力不匹配,提示用户从新测评。并发
维护一份维度的评估规则表,classify_sign理解为同一业务场景下的划分标识,weight则标识该维度在评估中的比重。
CREATE TABLE `evaluate_rule` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `classify_sign` varchar(50) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '归类标识', `rule_value` varchar(300) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '规则描述', `rule_type` int(1) DEFAULT NULL COMMENT '规则类型:1精准匹配,2范围,3模糊', `weight` decimal(10,2) DEFAULT '0.00' COMMENT '权重分布', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='评估项规则';
对于规则的具体描述,核心就是两个字段,规则值以及匹配到该规则获取的结果。
public class RuleValue { /** * 规则值描述 */ private Object ruleValue ; /** * 规则匹配结果 */ private Object ruleResult ; // 基础构造 public RuleValue(Object ruleValue, Object ruleResult) { this.ruleValue = ruleValue; this.ruleResult = ruleResult; } // 省略 Get 和 Set }
为了简化参数在模型中传递的复杂度,统一封装匹配因素的数据在一个数据模型中,这里以城市和标签两个因素作流程测试。
public class MatchItem { // 城市 private String city ; // 标签 private String tag ; // 基础构造 public MatchItem(String city, String tag) { this.city = city; this.tag = tag; } // 省略 Get 和 Set }
这里只是对两种状况作简单的实现描述,在实际的开发场景中,数据和匹配规格都是十分复杂的,在整个评估模型实现流程须要不断优化。
@Service public class AssessBizService { private static Logger LOG = LoggerFactory.getLogger(AssessBizService.class); @Resource private EvaluateRuleDao evaluateRuleDao ; /** * 业务评估流程 */ public void assessBiz (MatchItem matchItem){ // 精准匹配城市 EvaluateRuleEntity evaluateRule01 = evaluateRuleDao.getBySign("assess-biz",1); List<RuleValue> cityRuleList = JSONArray.parseArray(evaluateRule01.getRuleValue(), RuleValue.class); for (RuleValue cityRule:cityRuleList){ if (cityRule.getRuleValue().equals(matchItem.getCity())){ int result = Integer.parseInt(String.valueOf(cityRule.getRuleResult())); LOG.info("匹配项:{},匹配结果:{}",matchItem.getCity(),result*evaluateRule01.getWeight()); break ; } } // 模糊匹配标签 EvaluateRuleEntity evaluateRule02 = evaluateRuleDao.getBySign("assess-biz",3); List<RuleValue> tagRuleList = JSONArray.parseArray(evaluateRule02.getRuleValue(), RuleValue.class); for (RuleValue tagRule:tagRuleList){ if (String.valueOf(tagRule.getRuleValue()).contains(matchItem.getTag())){ int result = Integer.parseInt(String.valueOf(tagRule.getRuleResult())); LOG.info("匹配项:{},匹配结果:{}",matchItem.getTag(),result*evaluateRule02.getWeight()); break ; } } } }
GitHub·地址 https://github.com/cicadasmile/data-manage-parent GitEE·地址 https://gitee.com/cicadasmile/data-manage-parent
推荐阅读:编程体系整理
序号 | 项目名称 | GitHub地址 | GitEE地址 | 推荐指数 |
---|---|---|---|---|
01 | Java描述设计模式,算法,数据结构 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
02 | Java基础、并发、面向对象、Web开发 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆ |
03 | SpringCloud微服务基础组件案例详解 | GitHub·点这里 | GitEE·点这里 | ☆☆☆ |
04 | SpringCloud微服务架构实战综合案例 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
05 | SpringBoot框架基础应用入门到进阶 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆ |
06 | SpringBoot框架整合开发经常使用中间件 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
07 | 数据管理、分布式、架构设计基础案例 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
08 | 大数据系列、存储、组件、计算等框架 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |