A partir de l'any passat, la nostra empresa va començar a organitzar hackatons. El primer concurs d'aquest tipus va ser molt reeixit, vam escriure sobre això a . El segon hackathon va tenir lloc el febrer de 2019 i no va tenir menys èxit. Sobre els objectius de mantenir aquest últim no fa gaire organitzador.
Els participants van rebre una tasca força interessant amb total llibertat per triar una pila de tecnologia per a la seva implementació. Va ser necessari implementar una plataforma de presa de decisions per al desplegament còmode de funcions de puntuació dels clients que poguessin funcionar amb un flux ràpid d'aplicacions, suportar càrregues pesades i el sistema en si fos fàcilment escalable.
La tasca no és trivial i es pot resoldre de moltes maneres, tal com estàvem convençuts durant la demostració de les presentacions finals dels projectes dels participants. A la hackathon hi havia 6 equips de 5 persones, tots els participants tenien bons projectes, però la nostra plataforma va resultar ser la més competitiva. Tenim un projecte molt interessant, del qual m'agradaria parlar en aquest article.
La nostra solució és una plataforma basada en l'arquitectura Serverless dins de Kubernetes, que redueix el temps que es necessita per portar noves funcions a la producció. Permet als analistes escriure codi en un entorn convenient per a ells i desplegar-lo en producció sense la participació d'enginyers i desenvolupadors.
Què és puntuar
Tinkoff.ru, com moltes empreses modernes, té puntuació de clients. La puntuació és un sistema d'avaluació de clients basat en mètodes estadístics d'anàlisi de dades.
Per exemple, un client recorre a nosaltres per demanar-li un préstec o obrir un compte d'empresari individual amb nosaltres. Si tenim previst concedir-li un préstec, hem d'avaluar la seva solvència i, si el compte és un empresari individual, hem d'assegurar-nos que el client no realitzarà transaccions fraudulentes.
La base per prendre aquestes decisions són models matemàtics que analitzen tant les dades de la pròpia aplicació com les dades del nostre emmagatzematge. A més de la puntuació, també es poden utilitzar mètodes estadístics similars al servei de generar recomanacions individuals de nous productes per als nostres clients.
El mètode d'aquesta avaluació pot acceptar una varietat de dades d'entrada. I en algun moment podem afegir un nou paràmetre a l'entrada que, a partir dels resultats de l'anàlisi de dades històriques, augmentarà la taxa de conversió d'utilitzar el servei.
Tenim una gran quantitat de dades sobre les relacions amb els clients, i el volum d'aquesta informació està en constant creixement. Perquè la puntuació funcioni, el processament de dades també requereix regles (o models matemàtics) que permetin decidir ràpidament qui aprovar una sol·licitud, qui rebutjar i qui oferir un parell de productes més, avaluant el seu interès potencial.
Per a la tasca que ens ocupa, ja utilitzem un sistema especialitzat de presa de decisions , que, a partir de les regles establertes per analistes, tecnòlegs i desenvolupadors, decideix si aprova o rebutja un determinat producte bancari al client.
Hi ha moltes solucions ja fetes al mercat, tant models de puntuació com sistemes de presa de decisions. Utilitzem un d'aquests sistemes a la nostra empresa. Però el negoci creix, es diversifica, augmenta tant el nombre de clients com el de productes que s'ofereixen i, juntament amb això, van sorgint idees sobre com millorar el procés de presa de decisions existent. Segurament la gent que treballa amb el sistema existent té moltes idees sobre com fer-lo més senzill, millor, més còmode, però de vegades les idees de fora són útils. El New Hackathon es va organitzar amb l'objectiu de recollir idees sòlides.
Tasca
La hackató es va celebrar el 23 de febrer. Als participants se'ls va oferir una tasca de combat: desenvolupar un sistema de presa de decisions que hagués de complir una sèrie de condicions.
Ens van explicar com funciona el sistema existent i quines dificultats sorgeixen durant el seu funcionament, així com quins objectius empresarials hauria de perseguir la plataforma desenvolupada. El sistema ha de tenir un temps de llançament al mercat ràpid per desenvolupar regles perquè el codi de treball dels analistes entri en producció el més ràpidament possible. I per al flux entrant d'aplicacions, el temps de presa de decisions hauria de tendir al mínim. Així mateix, el sistema que s'està desenvolupant ha de tenir capacitats de venda creuada per tal de donar l'oportunitat al client d'adquirir altres productes de l'empresa si són aprovats per nosaltres i tenen un interès potencial per part del client.
Està clar que és impossible escriure un projecte llest per al llançament d'un dia per l'altre que, sens dubte, entrarà en producció, i és bastant difícil cobrir tot el sistema, per la qual cosa se'ns va demanar que en implementéssim almenys una part. Es van establir una sèrie de requisits que ha de complir el prototip. Es va poder provar tant de cobrir tots els requisits en la seva totalitat, com de treballar en detall les seccions individuals de la plataforma que s'està desenvolupant.
Pel que fa a la tecnologia, tots els participants van tenir total llibertat d'elecció. Va ser possible utilitzar qualsevol concepte i tecnologia: streaming de dades, aprenentatge automàtic, aprovisionament d'esdeveniments, big data i altres.
La nostra solució
Després d'una mica de pluja d'idees, vam decidir que una solució FaaS seria ideal per completar la tasca.
Per a aquesta solució, va ser necessari trobar un marc sense servidor adequat per implementar les regles del sistema de presa de decisions que s'està desenvolupant. Com que Tinkoff utilitza activament Kubernetes per a la gestió d'infraestructures, vam analitzar diverses solucions ja fetes basades en això, us explicaré més sobre això.
Per trobar la solució més eficaç, vam mirar el producte que s'està desenvolupant a través dels ulls dels seus usuaris. Els principals usuaris del nostre sistema són analistes implicats en el desenvolupament de regles. Les regles s'han de desplegar al servidor, o, com en el nostre cas, desplegades al núvol, per a la presa de decisions posterior. Des de la perspectiva d'un analista, el flux de treball és el següent:
- L'analista escriu un script, una regla o un model de ML basat en les dades del magatzem. Com a part del hackathon, vam decidir utilitzar Mongodb, però l'elecció del sistema d'emmagatzematge de dades no és important aquí.
- Després de provar les regles desenvolupades sobre dades històriques, l'analista penja el seu codi al tauler d'administració.
- Per garantir el control de versions, tot el codi anirà als repositoris de Git.
- A través del tauler d'administració serà possible desplegar el codi al núvol com un mòdul sense servidor funcional independent.
Les dades inicials dels clients han de passar per un servei especialitzat d'Enriquiment dissenyat per enriquir la sol·licitud inicial amb dades del magatzem. Era important implementar aquest servei de tal manera que funcionés amb un únic repositori (del qual l'analista agafa les dades quan desenvolupa regles) per mantenir una estructura de dades unificada.
Fins i tot abans del hackathon, vam decidir el marc Serverless que faríem servir. Avui dia hi ha moltes tecnologies al mercat que implementen aquest enfocament. Les solucions més populars dins de l'arquitectura Kubernetes són Fission, Open FaaS i Kubeless. Fins i tot n'hi ha .
Després de sospesar tots els pros i contres, vam triar . Aquest marc sense servidor és bastant fàcil de gestionar i compleix els requisits de la tasca.
Per treballar amb Fissió, cal entendre dos conceptes bàsics: funció i entorn. Una funció és un fragment de codi escrit en un dels llenguatges per als quals hi ha un entorn de fissió. inclou Python, JS, Go, JVM i molts altres llenguatges i tecnologies populars.
Fission també és capaç de realitzar funcions dividides en diversos fitxers, preempaquetats en un arxiu. El funcionament de Fission en un clúster de Kubernetes està garantit per pods especialitzats, que són gestionats pel propi framework. Per interactuar amb els pods de clúster, a cada funció s'ha d'assignar la seva pròpia ruta ia la qual podeu passar paràmetres GET o el cos de la sol·licitud en el cas d'una sol·licitud POST.
Com a resultat, teníem previst obtenir una solució que permetés als analistes desplegar scripts de regles desenvolupats sense la participació d'enginyers i desenvolupadors. L'enfocament descrit també elimina la necessitat que els desenvolupadors reescriguin el codi de l'analista en un altre llenguatge. Per exemple, per al sistema actual de presa de decisions que utilitzem, hem d'escriure regles en tecnologies i idiomes de perfil reduït, l'abast dels quals és extremadament limitat, i també hi ha una forta dependència del servidor d'aplicacions, ja que tots les regles es despleguen en un sol entorn. Com a resultat, per desplegar noves regles és necessari alliberar tot el sistema.
A la nostra solució proposada, no hi ha necessitat d'alliberar regles, el codi es pot desplegar fàcilment amb un clic. A més, la gestió d'infraestructura a Kubernetes us permet no pensar en la càrrega i l'escalat es resolen de manera immediata. I l'ús d'un únic magatzem de dades elimina la necessitat de comparar dades en temps real amb dades històriques, la qual cosa simplifica el treball de l'analista.
El que tenim
Com que vam arribar al hackathon amb una solució ja feta (en les nostres fantasies), tot el que havíem de fer era convertir tots els nostres pensaments en línies de codi.
La clau de l'èxit en qualsevol hackathon és la preparació i un pla ben escrit. Per tant, el primer que vam fer va ser decidir en quins mòduls consistiria la nostra arquitectura del sistema i quines tecnologies faríem servir.
L'arquitectura del nostre projecte va ser la següent:
Aquest diagrama mostra dos punts d'entrada, l'analista (l'usuari principal del nostre sistema) i el client.
El procés de treball s'estructura així. L'analista desenvolupa una funció de regla i una funció d'enriquiment de dades per al seu model, emmagatzema el seu codi en un repositori Git i desplega el seu model al núvol mitjançant l'aplicació d'administrador. Considerem com es cridarà la funció desplegada i prenem decisions sobre les sol·licituds entrants dels clients:
- El client omple un formulari al lloc web i envia la seva sol·licitud al responsable del tractament. Una aplicació sobre la qual cal prendre una decisió arriba a l'entrada del sistema i es registra a la base de dades en la seva forma original.
- A continuació, s'envia la sol·licitud en brut per a l'enriquiment, si cal. Podeu complementar la sol·licitud inicial amb dades tant de serveis externs com de l'emmagatzematge. La consulta enriquida resultant també s'emmagatzema a la base de dades.
- Es llança la funció d'analista, que pren com a entrada una consulta enriquida i produeix una solució, que també s'escriu a l'emmagatzematge.
Vam decidir utilitzar MongoDB com a emmagatzematge al nostre sistema a causa de l'emmagatzematge de dades orientat a documents en forma de documents JSON, ja que els serveis d'enriquiment, inclosa la sol·licitud original, agregaven totes les dades mitjançant controladors REST.
Per tant, teníem 24 hores per implementar la plataforma. Vam distribuir els rols amb força èxit cada membre de l'equip tenia la seva pròpia àrea de responsabilitat en el nostre projecte:
- Taulers d'administració de front-end per al treball de l'analista, a través dels quals podia descarregar regles del sistema de control de versions dels scripts escrits, seleccionar opcions per enriquir les dades d'entrada i editar scripts de regles en línia.
- Administrador de backend, inclosa l'API REST per a la part frontal i integració amb VCS.
- Configuració d'infraestructura a Google Cloud i desenvolupament d'un servei per enriquir les dades font.
- Un mòdul per integrar l'aplicació d'administració amb el framework Serverless per al posterior desplegament de regles.
- Scripts de regles per provar el rendiment de tot el sistema i agregació d'analítica en aplicacions entrants (decisions preses) per a la demostració final.
Comencem en ordre.
La nostra interfície es va escriure a Angular 7 mitjançant el kit d'interfície d'usuari bancària. La versió final del tauler d'administració tenia aquest aspecte:
Com que hi havia poc temps, vam intentar implementar només la funcionalitat clau. Per desplegar una funció al clúster de Kubernetes, calia seleccionar un esdeveniment (un servei per al qual cal desplegar una regla al núvol) i el codi de la funció que implementa la lògica de presa de decisions. Per a cada desplegament d'una regla per al servei seleccionat, vam escriure un registre d'aquest esdeveniment. Al tauler d'administració podríeu veure els registres de tots els esdeveniments.
Tot el codi de funció es va emmagatzemar en un dipòsit Git remot, que també s'havia de configurar al tauler d'administració. Per versionar el codi, totes les funcions es van emmagatzemar en diferents branques del repositori. El tauler d'administració també ofereix la possibilitat de fer ajustos als scripts escrits, de manera que abans de desplegar una funció a la producció, no només podeu comprovar el codi escrit, sinó també fer els canvis necessaris.
A més de les funcions de regles, també vam implementar la capacitat d'enriquir gradualment les dades d'origen mitjançant funcions d'enriquiment, el codi de les quals també eren scripts en què era possible anar al magatzem de dades, trucar a serveis de tercers i realitzar càlculs preliminars. . Per demostrar la nostra solució, vam calcular el signe del zodíac del client que va deixar la sol·licitud i vam determinar el seu operador mòbil mitjançant un servei REST de tercers.
El backend de la plataforma es va escriure en Java i es va implementar com una aplicació Spring Boot. Inicialment teníem previst utilitzar Postgres per emmagatzemar dades d'administrador, però, com a part del hackathon, vam decidir limitar-nos a un simple H2 per estalviar temps. Al backend, es va implementar la integració amb Bitbucket per versionar les funcions d'enriquiment de consultes i els scripts de regles. Per a la integració amb repositoris Git remots, hem utilitzat , que és una mena d'embolcall sobre ordres CLI, que us permet executar qualsevol instrucció git mitjançant una interfície de programari convenient. Així doncs, teníem dos dipòsits separats per a funcions i regles d'enriquiment, i tots els scripts estaven dividits en directoris. A través de la interfície d'usuari era possible seleccionar l'últim commit d'un script d'una branca arbitrària del dipòsit. Quan es feien canvis al codi a través del tauler d'administració, es van crear commits del codi modificat en repositoris remots.
Per implementar la nostra idea, necessitàvem una infraestructura adequada. Vam decidir desplegar el nostre clúster Kubernetes al núvol. La nostra elecció va ser Google Cloud Platform. El marc sense servidor Fission es va instal·lar en un clúster de Kubernetes, que vam implementar a Gcloud. Inicialment, el servei d'enriquiment de dades d'origen es va implementar com una aplicació Java independent embolicada en un pod dins del clúster k8s. Però després d'una demostració preliminar del nostre projecte enmig del hackathon, se'ns va recomanar que el servei d'enriquiment fos més flexible per oferir l'oportunitat d'escollir com enriquir les dades en brut de les aplicacions entrants. I no vam tenir més remei que fer que el servei d'enriquiment també fos Serverless.
Per treballar amb Fission, hem utilitzat la CLI de Fission, que s'ha d'instal·lar a la part superior de la CLI de Kubernetes. El desplegament de funcions en un clúster k8s és bastant senzill, només cal assignar una ruta interna i l'entrada a la funció per permetre el trànsit entrant si es necessita l'accés fora del clúster. El desplegament d'una funció normalment no triga més de 10 segons.
Presentació final del projecte i resum
Per demostrar com funciona el nostre sistema, hem col·locat un formulari senzill en un servidor remot on podeu presentar una sol·licitud per a un dels productes del banc. Per sol·licitar, calia introduir les seves inicials, data de naixement i número de telèfon.
Les dades del formulari del client van anar al controlador, que simultàniament va enviar sol·licituds per a totes les regles disponibles, prèviament enriquint les dades d'acord amb les condicions especificades, i les va guardar en un emmagatzematge comú. En total, hem desplegat tres funcions que prenen decisions sobre les aplicacions entrants i 4 serveis d'enriquiment de dades. Després d'enviar la sol·licitud, el client va rebre la nostra decisió:
A més de la negativa o l'aprovació, el client també va rebre una llista d'altres productes, sol·licituds per als quals vam enviar en paral·lel. Així és com vam demostrar la possibilitat de venda creuada a la nostra plataforma.
Hi havia un total de 3 productes bancaris ficticis disponibles:
- Crèdit.
- joguina
- Hipoteca.
Durant la demostració, vam desplegar funcions preparades i scripts d'enriquiment per a cada servei.
Cada regla requeria el seu propi conjunt de dades d'entrada. Així, per aprovar una hipoteca, vam calcular el signe del zodíac del client i vam connectar-ho amb la lògica del calendari lunar. Per aprovar una joguina, vam comprovar que el client havia complert la majoria d'edat i, per emetre un préstec, vam enviar una sol·licitud a un servei obert extern per determinar l'operador mòbil i es va prendre una decisió al respecte.
Vam intentar que la nostra demostració fos interessant i interactiva, tots els presents podien anar al nostre formulari i comprovar la disponibilitat dels nostres serveis ficticis per a ells. I al final de la presentació, vam demostrar l'anàlisi de les sol·licituds rebudes, que mostraven quantes persones feien servir el nostre servei, el nombre d'aprovacions i les denegacions.
Per recopilar analítiques en línia, també hem implementat una eina de BI de codi obert i el va cargolar a la nostra unitat d'emmagatzematge. Metabase permet construir pantalles amb analítiques sobre les dades que ens interessen només cal registrar una connexió a la base de dades, seleccionar taules (en el nostre cas, recopilacions de dades, ja que hem utilitzat MongoDB), i especificar els camps que ens interessen; .
Com a resultat, vam aconseguir un bon prototip de plataforma de presa de decisions, i durant la demostració, cada oient va poder comprovar personalment el seu rendiment. Una solució interessant, un prototip acabat i una demostració reeixida ens van permetre guanyar, malgrat la forta competència d'altres equips. Estic segur que també es pot escriure un article interessant sobre el projecte de cada equip.
Font: www.habr.com