A partir do ano pasado, a nosa empresa comezou a organizar hackathons. O primeiro concurso deste tipo tivo moito éxito, escribimos sobre el . O segundo hackathon tivo lugar en febreiro de 2019 e non foi menos exitoso. Sobre os obxectivos de manter este último non hai moito tempo organizador.
Os participantes recibiron unha tarefa bastante interesante con total liberdade para elixir unha pila de tecnoloxía para a súa implementación. Era necesario implementar unha plataforma de toma de decisións para o despregamento cómodo de funcións de puntuación dos clientes que puidesen funcionar cun fluxo rápido de aplicacións, soportar cargas pesadas e o propio sistema era facilmente escalable.
A tarefa non é trivial e pódese resolver de moitas maneiras, como estabamos convencidos durante a demostración das presentacións finais dos proxectos dos participantes. No hackathon estiveron 6 equipos de 5 persoas, todos os participantes tiñan bos proxectos, pero a nosa plataforma resultou ser a máis competitiva. Temos un proxecto moi interesante, do que me gustaría falar neste artigo.
A nosa solución é unha plataforma baseada na arquitectura sen servidor dentro de Kubernetes, o que reduce o tempo que leva incorporar novas funcións á produción. Permite aos analistas escribir código nun ambiente conveniente para eles e implantalo na produción sen a participación de enxeñeiros e desenvolvedores.
Que é puntuar
Tinkoff.ru, como moitas empresas modernas, ten puntuación de clientes. A puntuación é un sistema de avaliación de clientes baseado en métodos estatísticos de análise de datos.
Por exemplo, un cliente recorre a nós para solicitarlle un préstamo ou abrir unha conta individual de empresario connosco. Se pensamos concederlle un préstamo, entón debemos avaliar a súa solvencia e, se a conta é un empresario individual, debemos asegurarnos de que o cliente non realizará transaccións fraudulentas.
A base para tomar este tipo de decisións son modelos matemáticos que analizan tanto os datos da propia aplicación como os datos do noso almacenamento. Ademais da puntuación, tamén se poden utilizar métodos estatísticos similares no servizo de xeración de recomendacións individuais de novos produtos para os nosos clientes.
O método de tal avaliación pode aceptar unha variedade de datos de entrada. E nalgún momento podemos engadir un novo parámetro á entrada, que, en función dos resultados da análise dos datos históricos, aumentará a taxa de conversión de uso do servizo.
Temos unha gran cantidade de datos sobre as relacións cos clientes, e o volume desta información está en constante crecemento. Para que a puntuación funcione, o tratamento de datos tamén require regras (ou modelos matemáticos) que che permitan decidir rapidamente quen aprobar unha solicitude, quen rexeitar e quen ofrecer un par de produtos máis, avaliando o seu interese potencial.
Para a tarefa que nos ocupa xa utilizamos un sistema de decisión especializado , que, en base ás regras establecidas por analistas, tecnólogos e desenvolvedores, decide se aprobar ou rexeitar un determinado produto bancario ao cliente.
No mercado hai moitas solucións preparadas, tanto modelos de puntuación como sistemas de toma de decisións. Usamos un destes sistemas na nosa empresa. Pero o negocio crece, diversifícase, aumenta tanto o número de clientes como o de produtos ofrecidos e, xunto con isto, van xurdindo ideas sobre como mellorar o proceso de toma de decisións existente. Seguramente a xente que traballa co sistema existente ten moitas ideas sobre como facelo máis sinxelo, mellor, máis cómodo, pero ás veces son útiles ideas de fóra. O Novo Hackathon organizouse co obxectivo de recoller ideas sonoras.
Tarefa
O hackathon celebrouse o 23 de febreiro. Propúxoselles aos participantes unha tarefa de combate: desenvolver un sistema de toma de decisións que debía cumprir unha serie de condicións.
Explicáronnos como funciona o sistema existente e que dificultades xorden durante o seu funcionamento, así como que obxectivos comerciais debería perseguir a plataforma desenvolvida. O sistema debe ter un tempo de comercialización rápido para desenvolver regras para que o código de traballo dos analistas entre en produción o máis rápido posible. E para o fluxo de solicitudes entrantes, o tempo de toma de decisións debería tender ao mínimo. Ademais, o sistema que se está a desenvolver debe ter capacidades de venda cruzada para darlle ao cliente a oportunidade de adquirir outros produtos da empresa se son aprobados por nós e teñen interese potencial por parte do cliente.
Está claro que é imposible escribir un proxecto listo para lanzar dun día para outro que seguramente entrará en produción, e é bastante difícil cubrir todo o sistema, polo que pedimos que implementáramos polo menos parte del. Establecéronse unha serie de requisitos que debe cumprir o prototipo. Foi posible tentar tanto cubrir todos os requisitos na súa totalidade, como traballar en detalle en seccións individuais da plataforma que se está a desenvolver.
En canto á tecnoloxía, todos os participantes tiveron total liberdade de elección. Foi posible utilizar calquera concepto e tecnoloxía: transmisión de datos, aprendizaxe automática, aprovisionamento de eventos, big data e outros.
A nosa solución
Despois dunha pequena chuvia de ideas, decidimos que unha solución FaaS sería ideal para completar a tarefa.
Para esta solución, foi necesario atopar un marco sen servidor axeitado para implementar as regras do sistema de toma de decisións que se está a desenvolver. Dado que Tinkoff usa activamente Kubernetes para a xestión de infraestruturas, analizamos varias solucións preparadas baseadas nel; falarei máis sobre iso máis tarde.
Para atopar a solución máis eficaz, observamos o produto que se está a desenvolver a través dos ollos dos seus usuarios. Os principais usuarios do noso sistema son os analistas implicados no desenvolvemento de regras. As regras deben ser despregadas no servidor, ou, como no noso caso, despregadas na nube, para a posterior toma de decisións. Desde a perspectiva dun analista, o fluxo de traballo é así:
- O analista escribe un script, unha regra ou un modelo de ML baseado nos datos do almacén. Como parte do hackathon, decidimos usar Mongodb, pero a elección do sistema de almacenamento de datos non é importante aquí.
- Despois de probar as regras desenvolvidas sobre datos históricos, o analista carga o seu código no panel de administración.
- Para garantir a versión, todo o código irá aos repositorios de Git.
- A través do panel de administración será posible implementar o código na nube como un módulo funcional sen servidor.
Os datos iniciais dos clientes deben pasar por un servizo de Enriquecemento especializado deseñado para enriquecer a solicitude inicial con datos do almacén. Era importante implementar este servizo de tal forma que funcionase cun único repositorio (do que o analista toma datos ao desenvolver regras) para manter unha estrutura de datos unificada.
Mesmo antes do hackathon, decidimos o marco sen servidor que usaríamos. Hoxe hai unha gran cantidade de tecnoloxías no mercado que implementan este enfoque. As solucións máis populares dentro da arquitectura de Kubernetes son Fission, Open FaaS e Kubeless. Incluso hai .
Despois de sopesar todos os pros e contras, escollemos . Este marco sen servidor é bastante sinxelo de xestionar e cumpre os requisitos da tarefa.
Para traballar con Fisión, cómpre comprender dous conceptos básicos: función e ambiente. Unha función é un fragmento de código escrito nunha das linguaxes para as que existe un ambiente de Fisión. inclúe Python, JS, Go, JVM e moitas outras linguaxes e tecnoloxías populares.
Fission tamén é capaz de realizar funcións divididas en varios ficheiros, empaquetados previamente nun arquivo. O funcionamento de Fission nun clúster de Kubernetes está garantido por pods especializados, que son xestionados polo propio framework. Para interactuar cos módulos de clúster, cada función debe ter asignada a súa propia ruta, á que pode pasar os parámetros GET ou o corpo da solicitude no caso dunha solicitude POST.
Como resultado, planeamos obter unha solución que permitise aos analistas implementar scripts de regras desenvolvidos sen a participación de enxeñeiros e desenvolvedores. O enfoque descrito tamén elimina a necesidade de que os desenvolvedores reescriban o código do analista noutro idioma. Por exemplo, para o actual sistema de toma de decisións que utilizamos, temos que escribir regras en tecnoloxías e linguaxes altamente especializados, cuxo alcance é extremadamente limitado, e tamén existe unha forte dependencia do servidor de aplicacións, xa que todos os proxectos de regras bancarias desenvólvense nun único ambiente. Como resultado, para implementar novas regras é necesario liberar todo o sistema.
Na nosa solución proposta, non hai necesidade de liberar regras; o código pódese implementar facilmente con só facer clic nun botón. Ademais, a xestión da infraestrutura en Kubernetes permítelle non pensar na carga e na escala; tales problemas resólvense de forma inmediata. E o uso dun único almacén de datos elimina a necesidade de comparar datos en tempo real con datos históricos, o que simplifica o traballo do analista.
O que temos
Xa que chegamos ao hackathon cunha solución preparada (nas nosas fantasías), o único que tiñamos que facer era converter todos os nosos pensamentos en liñas de código.
A clave do éxito en calquera hackathon é a preparación e un plan ben escrito. Polo tanto, o primeiro que fixemos foi decidir en que módulos constaría a nosa arquitectura do sistema e que tecnoloxías utilizaríamos.
A arquitectura do noso proxecto foi a seguinte:
Este diagrama mostra dous puntos de entrada, o analista (o usuario principal do noso sistema) e o cliente.
O proceso de traballo estrutúrase así. O analista desenvolve unha función de regra e unha función de enriquecemento de datos para o seu modelo, almacena o seu código nun repositorio de Git e desprega o seu modelo na nube a través da aplicación de administrador. Consideremos como se chamará a función despregada e tomemos decisións sobre as solicitudes entrantes dos clientes:
- O cliente enche un formulario no sitio web e envía a súa solicitude ao controlador. Unha aplicación sobre a que se debe tomar unha decisión chega á entrada do sistema e rexístrase na base de datos na súa forma orixinal.
- A continuación, envíase a solicitude en bruto para o enriquecemento, se é necesario. Pode complementar a solicitude inicial con datos tanto de servizos externos como de almacenamento. A consulta enriquecida resultante tamén se almacena na base de datos.
- Lanzase a función de analista, que toma unha consulta enriquecida como entrada e produce unha solución, que tamén se escribe no almacenamento.
Decidimos usar MongoDB como almacenamento no noso sistema debido ao almacenamento de datos orientado a documentos en forma de documentos JSON, xa que os servizos de enriquecemento, incluída a solicitude orixinal, agregaron todos os datos a través de controladores REST.
Entón, tiñamos XNUMX horas para implementar a plataforma. Distribuímos os roles con bastante éxito; cada membro do equipo tiña a súa propia área de responsabilidade no noso proxecto:
- Paneis de administración front-end para o traballo do analista, a través dos cales podía descargar regras do sistema de control de versións de guións escritos, seleccionar opcións para enriquecer os datos de entrada e editar guións de regras en liña.
- Administrador de backend, incluída a API REST para a parte frontal e integración con VCS.
- Configurar infraestrutura en Google Cloud e desenvolver un servizo para enriquecer os datos fonte.
- Un módulo para integrar a aplicación de administración co marco sen servidor para o posterior despregue de regras.
- Scripts de regras para probar o rendemento de todo o sistema e agregación de analíticas nas aplicacións entrantes (decisións tomadas) para a demostración final.
Comecemos en orde.
O noso frontend foi escrito en Angular 7 usando o kit de interface de usuario bancario. A versión final do panel de administración tiña este aspecto:
Como había pouco tempo, tentamos implementar só a funcionalidade clave. Para implantar unha función no clúster de Kubernetes, foi necesario seleccionar un evento (un servizo para o que hai que despregar unha regra na nube) e o código da función que implementa a lóxica de toma de decisións. Para cada implantación dunha regra para o servizo seleccionado, escribimos un rexistro deste evento. No panel de administración podes ver os rexistros de todos os eventos.
Todo o código de función foi almacenado nun repositorio Git remoto, que tamén tiña que ser configurado no panel de administración. Para versiónr o código, todas as funcións foron almacenadas en diferentes ramas do repositorio. O panel de administración tamén ofrece a posibilidade de facer axustes nos scripts escritos, de xeito que antes de implementar unha función na produción, non só pode comprobar o código escrito, senón tamén facer os cambios necesarios.
Ademais das funcións de regras, tamén implementamos a capacidade de enriquecer gradualmente os datos de orixe mediante funcións de enriquecemento, cuxo código tamén eran scripts nos que era posible ir ao almacén de datos, chamar a servizos de terceiros e realizar cálculos preliminares. . Para demostrar a nosa solución, calculamos o signo do zodíaco do cliente que deixou a solicitude e determinamos o seu operador móbil mediante un servizo REST de terceiros.
O backend da plataforma foi escrito en Java e implementado como unha aplicación Spring Boot. Inicialmente planeamos usar Postgres para almacenar datos de administración, pero, como parte do hackathon, decidimos limitarnos a un simple H2 para aforrar tempo. No backend, implementouse a integración con Bitbucket para versionar as funcións de enriquecemento de consultas e os scripts de regras. Para a integración con repositorios Git remotos, usamos , que é unha especie de envoltorio sobre comandos da CLI, que lle permite executar calquera instrución git mediante unha interface de software conveniente. Así que tiñamos dous repositorios separados para funcións e regras de enriquecemento, e todos os scripts estaban divididos en directorios. A través da IU foi posible seleccionar a última confirmación dun script dunha rama arbitraria do repositorio. Ao facer cambios no código a través do panel de administración, creáronse confirmacións do código modificado en repositorios remotos.
Para implementar a nosa idea, necesitabamos unha infraestrutura adecuada. Decidimos implantar o noso clúster de Kubernetes na nube. A nosa elección foi Google Cloud Platform. O marco sen servidor Fission instalouse nun clúster de Kubernetes, que implementamos en Gcloud. Inicialmente, o servizo de enriquecemento de datos de orixe implementouse como unha aplicación Java separada envolta nun Pod dentro do clúster k8s. Pero despois dunha demostración preliminar do noso proxecto no medio do hackathon, recomendáronnos flexibilizar o servizo de Enriquecemento para ofrecer a oportunidade de escoller como enriquecer os datos brutos das aplicacións entrantes. E non nos quedou máis remedio que facer que o servizo de enriquecemento sexa tamén sen servidor.
Para traballar con Fission, usamos a CLI de Fission, que debe instalarse encima da CLI de Kubernetes. Implementar funcións nun clúster k8s é bastante sinxelo; só precisa asignar unha ruta interna e un ingreso á función para permitir o tráfico entrante se é necesario acceder fóra do clúster. A implantación dunha función normalmente non leva máis de 10 segundos.
Presentación final do proxecto e resumo
Para demostrar como funciona o noso sistema, colocamos un formulario sinxelo nun servidor remoto onde podes enviar unha solicitude para un dos produtos do banco. Para solicitalo, tiñas que introducir as túas iniciais, data de nacemento e número de teléfono.
Os datos do formulario do cliente foron ao controlador, que enviou simultaneamente solicitudes para todas as regras dispoñibles, enriquecendo previamente os datos segundo as condicións especificadas e gardándoos nun almacenamento común. En total, implantamos tres funcións que toman decisións sobre as aplicacións entrantes e 4 servizos de enriquecemento de datos. Despois de enviar a solicitude, o cliente recibiu a nosa decisión:
Ademais da negativa ou aprobación, o cliente tamén recibiu unha lista doutros produtos, solicitudes para as que enviamos paralelamente. Así demostramos a posibilidade de venda cruzada na nosa plataforma.
Había un total de 3 produtos bancarios ficticios dispoñibles:
- Crédito.
- Toy
- Hipoteca.
Durante a demostración, despregamos funcións preparadas e scripts de enriquecemento para cada servizo.
Cada regra requiría o seu propio conxunto de datos de entrada. Entón, para aprobar unha hipoteca, calculamos o signo do zodíaco do cliente e conectamos isto coa lóxica do calendario lunar. Para aprobar un xoguete, comprobamos que o cliente cumpriu a maioría de idade e, para emitir un préstamo, enviamos unha solicitude a un servizo aberto externo para determinar o operador de telefonía móbil e tomouse unha decisión respecto diso.
Tentamos que a nosa demostración fose interesante e interactiva, todos os presentes puideron acudir ao noso formulario e comprobar a dispoñibilidade dos nosos servizos ficticios para eles. E ao final da presentación, demostramos as análises das solicitudes recibidas, que mostraban cantas persoas utilizaron o noso servizo, o número de aprobacións e as negativas.
Para recoller análises en liña, implementamos ademais unha ferramenta de BI de código aberto e enroscouno á nosa unidade de almacenamento. Metabase permíteche construír pantallas con analíticas sobre os datos que nos interesan; só tes que rexistrar unha conexión á base de datos, seleccionar táboas (no noso caso, coleccións de datos, xa que utilizamos MongoDB) e especificar os campos que nos interesan. .
Como resultado, conseguimos un bo prototipo de plataforma de toma de decisións e durante a demostración cada oínte puido comprobar persoalmente o seu rendemento. Unha solución interesante, un prototipo acabado e unha demostración exitosa permitíronnos gañar, a pesar da forte competencia doutros equipos. Estou seguro de que tamén se pode escribir un artigo interesante sobre o proxecto de cada equipo.
Fonte: www.habr.com