Código-fonte deste artigo: GitHub · clique aqui || GitEE · clique aqui
1. Pensamento quantitativo
Existem muitos negócios complexos no sistema de programação que são difíceis de entender, mas uma análise quantitativa é necessária para dar ao pessoal de negócios ou operações ou usuários um padrão de referência, como índice comum, pontuação de gergelim, nível de loja, tais padrões de avaliação de negócios. Muito complicado , porque existem muitos fatores que afetam os resultados.
No modelo de consideração de negócios multidimensional, existe um conceito central chamado peso, que se refere à importância de um determinado fator ou indicador em relação a uma determinada coisa. É diferente da proporção geral e reflete não apenas a importância de um determinado fator ou indicador: a porcentagem que enfatiza a importância relativa de fatores ou indicadores e tende a contribuir para a importância ou importância. Em circunstâncias normais, o peso de cada dimensão está entre 0-1 e a soma dos pesos de todas as dimensões é 1.
O conceito de peso pode ser analisado a partir de um caso prático. Por exemplo, para determinar se um cliente é um objeto de operação chave, ele é geralmente considerado em termos de número de logins por semana, duração online, volume de transações, etc. A efetua login com frequência, mas não tem transações de negócios principais, o Cliente B raramente efetua login, mas as transações de negócios são altas, então o peso do número de logins aqui deve ser menor do que a dimensão do volume de transação.
Como determinar a proporção de pesos geralmente tem duas ideias. Uma é aprender com a experiência fornecida por profissionais de negócios e colocá-la no negócio para tentar otimizar continuamente; em segundo lugar, calcular o peso de cada dimensão com base nos dados de análise do produto, ele também precisa ser constantemente experimentado no negócio.
Na verdade, o processo de quantificação de cenários de negócios complexos é complicado e demorado. É necessário coletar dados em várias dimensões. Às vezes, não apenas a quantificação periódica é necessária, como a pontuação de crédito de várias grandes fábricas, mas também pode haver Cenários de análise de tempo. Para controle de risco de fraude em negócios financeiros, há também dois cenários de sistemas abrangentes de recomendação em tempo real, ambos usando processos quantitativos.
Dois, caso de cena
1. Avaliação abrangente
Avaliação abrangente de vários cenários, como usuários, lojas, produtos e análise abstrata de uma coisa complexa por meio de várias dimensões para gerar resultados de avaliação simples e fáceis de entender, como nível de loja, classificação de produto, índice abrangente do usuário, etc., e, em seguida, use cada referência de geração de A base da cena. Pode ser fácil de entender a partir dos resultados, mas o processo de análise para obter os resultados é relativamente complicado. Alguns cenários podem exigir a execução periódica do modelo de avaliação, alguns cenários podem exigir cálculos em tempo real ou uma combinação das duas situações que é dependente. A avaliação periódica também precisa se referir a cálculos em tempo real.
2. Recomendação de cena
Este cenário é relativamente complexo. Por exemplo, o usuário realiza uma pesquisa, mas uma série de exclusões ou condições necessárias são verificadas. Isso é muito comum em funções de pesquisa. Durante o processamento, não é necessário apenas realizar a análise de correspondência mais alta no condições de pesquisa do usuário., E executa a classificação ideal com base nos resultados da pesquisa. Existem duas fases de avaliação. A primeira fase corresponde às condições de pesquisa ideais e a segunda fase realiza a classificação mais ideal dos resultados correspondentes para dar ao usuário o que o usuário deseja. resultados da pesquisa.
3. Pontuação de controle de risco
No campo financeiro, este é um modelo de controle de risco muito comum que conta usuários em várias dimensões, pontua as dimensões e, em seguida, adiciona-os. Quanto maior a pontuação de controle de risco, maior o risco do usuário, evitando assim o alto risco transações.
4. Índice Financeiro
Este cenário é muito comum. Em aplicativos financeiros e de gestão de patrimônio, um sistema de avaliação deve ser passado antes do uso para determinar a tolerância ao risco do usuário: como conservador, ativo, etc., quando o usuário compra um produto de alto risco, irá solicitar e A tolerância de risco do usuário não corresponde, e o usuário é solicitado a reavaliar.
Três, realização de ideias
1. Tabela de regras de dimensão
Manter uma tabela de regras de avaliação dimensional, classify_sign é entendido como um identificador de divisão no mesmo cenário de negócios e o peso identifica a proporção da dimensão na avaliação.
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='评估项规则';
2. Descreva as regras
Para a descrição específica da regra, o núcleo é dois campos, o valor da regra e o resultado obtido pela correspondência da regra.
public class RuleValue {
/**
* 规则值描述
*/
private Object ruleValue ;
/**
* 规则匹配结果
*/
private Object ruleResult ;
// 基础构造
public RuleValue(Object ruleValue, Object ruleResult) {
this.ruleValue = ruleValue;
this.ruleResult = ruleResult;
}
// 省略 Get 和 Set
}
3. Valor de correspondência do pacote
A fim de simplificar a complexidade da transmissão dos parâmetros no modelo, os dados dos fatores de casamento são uniformemente encapsulados em um modelo de dados, onde os dois fatores cidade e rótulo são usados para o teste do processo.
public class MatchItem {
// 城市
private String city ;
// 标签
private String tag ;
// 基础构造
public MatchItem(String city, String tag) {
this.city = city;
this.tag = tag;
}
// 省略 Get 和 Set
}
4. Implementação da lógica de avaliação
Aqui está apenas uma descrição de implementação simples para as duas situações: No cenário de desenvolvimento real, os dados e as especificações correspondentes são muito complexos e todo o processo de implementação do modelo de avaliação precisa ser continuamente otimizado.
@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 ;
}
}
}
}
Quarto, o endereço do código-fonte
GitHub·地址
https://github.com/cicadasmile/data-manage-parent
GitEE·地址
https://gitee.com/cicadasmile/data-manage-parent
Leitura recomendada: sistema de programação de acabamento
| Número de série | Nome do Projeto | Endereço GitHub | Endereço GitEE | Recomendado |
|---|---|---|---|---|
| 01 | Java descreve padrões de design, algoritmos e estruturas de dados | GitHub · clique aqui | GitEE · Clique aqui | ☆☆☆☆☆ |
| 02 | Fundação Java, simultaneidade, orientado a objetos, desenvolvimento web | GitHub · clique aqui | GitEE · Clique aqui | ☆☆☆☆ |
| 03 | Explicação detalhada do caso do componente básico do microsserviço SpringCloud | GitHub · clique aqui | GitEE · Clique aqui | ☆☆☆ |
| 04 | Caso abrangente de combate real da arquitetura de microsserviço SpringCloud | GitHub · clique aqui | GitEE · Clique aqui | ☆☆☆☆☆ |
| 05 | Introdução ao aplicativo básico do framework SpringBoot para avançado | GitHub · clique aqui | GitEE · Clique aqui | ☆☆☆☆ |
| 06 | O framework SpringBoot integra e desenvolve middleware comum | GitHub · clique aqui | GitEE · Clique aqui | ☆☆☆☆☆ |
| 07 | Caso básico de gerenciamento de dados, distribuição, design de arquitetura | GitHub · clique aqui | GitEE · Clique aqui | ☆☆☆☆☆ |
| 08 | Série de Big Data, armazenamento, componentes, computação e outras estruturas | GitHub · clique aqui | GitEE · Clique aqui | ☆☆☆☆☆ |