Viime vuodesta alkaen yrityksemme aloitti hackathonien järjestämisen. Ensimmäinen tällainen kilpailu oli erittäin onnistunut, kirjoitimme siitä vuonna . Toinen hackathon järjestettiin helmikuussa 2019, ja se oli yhtä onnistunut. Jälkimmäisen pitämisen tavoitteista ei niin kauan sitten järjestäjä.
Osallistujat saivat varsin mielenkiintoisen tehtävän täysin vapaasti valita teknologiapino sen toteuttamista varten. Asiakkaiden pisteytystoimintojen kätevää käyttöönottoa varten oli tarpeen ottaa käyttöön päätöksentekoalusta, joka voisi toimia nopean sovellusvirran kanssa, kestää raskaita kuormia ja itse järjestelmä oli helposti skaalautuva.
Tehtävä on ei-triviaali ja se voidaan ratkaista monella tapaa, kuten vakuuttuimme osallistujien projektien loppuesitysten esittelyssä. Hackathonissa oli 6 5 hengen joukkuetta, kaikilla osallistujilla oli hyviä projekteja, mutta meidän alustamme osoittautui kilpailukykyisimmäksi. Meillä on erittäin mielenkiintoinen projekti, josta haluaisin puhua tässä artikkelissa.
Ratkaisumme on Kubernetesin sisällä olevaan palvelimettomaan arkkitehtuuriin perustuva alusta, joka vähentää uusien ominaisuuksien tuomiseen kuluvaa aikaa. Sen avulla analyytikot voivat kirjoittaa koodia heille sopivassa ympäristössä ja ottaa sen käyttöön tuotantoon ilman insinöörien ja kehittäjien osallistumista.
Mikä on pisteytys
Tinkoff.ru:lla, kuten monilla nykyaikaisilla yrityksillä, on asiakaspisteytys. Scoring on tilastollisiin tiedon analysointimenetelmiin perustuva asiakasarviointijärjestelmä.
Esimerkiksi asiakas kääntyy puoleemme pyytämällä lainaa tai avaamaan meille yksityisyrittäjätilin. Jos aiomme myöntää hänelle lainaa, meidän on arvioitava hänen maksukykynsä, ja jos tili on yksittäinen yrittäjä, meidän on varmistettava, että asiakas ei tee vilpillisiä liiketoimia.
Tällaisten päätösten perustana ovat matemaattiset mallit, jotka analysoivat sekä itse sovelluksen että varastomme dataa. Pisteytymisen lisäksi vastaavia tilastollisia menetelmiä voidaan käyttää myös asiakaskohtaisten uusien tuotteiden suositusten tuottamisessa.
Tällaisen arvioinnin menetelmä voi hyväksyä erilaisia syöttötietoja. Ja jossain vaiheessa voimme lisätä syötteeseen uuden parametrin, joka historiallisen datan analyysin tulosten perusteella nostaa palvelun käytön konversioprosenttia.
Meillä on runsaasti tietoa asiakassuhteista, ja tämän tiedon määrä kasvaa jatkuvasti. Jotta pisteytys toimisi, tietojenkäsittely vaatii myös sääntöjä (tai matemaattisia malleja), joiden avulla voit nopeasti päättää, kenelle hakemus hyväksytään, keneltä hylätään ja kenelle tarjotaan vielä pari tuotetta, arvioiden mahdollisen kiinnostuksen.
Käsillä olevassa tehtävässä käytämme jo erikoistunutta päätöksentekojärjestelmää , joka päättää analyytikoiden, tekniikkojen ja kehittäjien asettamien sääntöjen perusteella hyväksyäkö vai evätäänkö asiakkaan tietyn pankkituotteen.
Markkinoilla on paljon valmiita ratkaisuja, sekä pisteytysmalleja että itse päätöksentekojärjestelmiä. Käytämme yhtä näistä järjestelmistä yrityksessämme. Mutta liiketoiminta kasvaa, monipuolistuu, sekä asiakasmäärät että tarjottavat tuotteet lisääntyvät, ja tämän myötä syntyy ideoita nykyisen päätöksentekoprosessin parantamiseksi. Varmasti olemassa olevan järjestelmän parissa työskentelevillä on monia ideoita, kuinka tehdä siitä yksinkertaisempi, parempi, kätevämpi, mutta joskus ulkopuolisista ideoista on hyötyä. New Hackathon järjestettiin tavoitteena kerätä järkeviä ideoita.
Tehtävä
Hackathon pidettiin 23. helmikuuta. Osallistujille tarjottiin taistelutehtävä: kehittää päätöksentekojärjestelmä, jonka oli täytettävä useita ehtoja.
Meille kerrottiin, miten olemassa oleva järjestelmä toimii ja mitä vaikeuksia sen toiminnassa ilmenee sekä mitä liiketoimintatavoitteita kehitetyn alustan tulisi pyrkiä. Järjestelmässä tulee olla nopea markkinoilletuloaika sääntöjen kehittämiseen, jotta analyytikoiden työkoodi pääsee tuotantoon mahdollisimman nopeasti. Ja saapuvan hakemusvirran osalta päätöksentekoajan tulisi olla mahdollisimman pieni. Kehitettävässä järjestelmässä tulee myös olla ristiinmyyntikykyä, jotta asiakkaalla on mahdollisuus ostaa muita yrityksen tuotteita, mikäli ne ovat hyväksymiämme ja asiakkaalta mahdollisesti kiinnostuneita.
On selvää, että on mahdotonta kirjoittaa yhdessä yössä julkaisuvalmis projektia, joka varmasti menee tuotantoon, ja koko järjestelmän kattaminen on melko vaikeaa, joten meitä pyydettiin toteuttamaan ainakin osa siitä. Esitettiin useita vaatimuksia, jotka prototyypin on täytettävä. Oli mahdollista yrittää sekä kattaa kaikki vaatimukset kokonaisuudessaan että työstää yksityiskohtaisesti kehitettävän alustan yksittäisiä osia.
Tekniikan osalta kaikille osallistujille annettiin täydellinen valinnanvapaus. Oli mahdollista käyttää mitä tahansa käsitteitä ja teknologioita: datan suoratoistoa, koneoppimista, tapahtuman hankintaa, big dataa ja muita.
Ratkaisumme
Pienen aivoriihen jälkeen päätimme, että FaaS-ratkaisu olisi ihanteellinen tehtävän suorittamiseen.
Tätä ratkaisua varten oli tarpeen löytää sopiva Serverless viitekehys toteuttamaan kehitettävän päätöksentekojärjestelmän sääntöjä. Koska Tinkoff käyttää aktiivisesti Kubernetesia infrastruktuurin hallintaan, katselimme useita siihen perustuvia valmiita ratkaisuja, joista kerron lisää myöhemmin.
Tehokkaimman ratkaisun löytämiseksi tarkastelimme kehitettävää tuotetta sen käyttäjien silmin. Järjestelmämme pääkäyttäjät ovat sääntökehitykseen osallistuvat analyytikot. Säännöt on otettava käyttöön palvelimella tai, kuten meidän tapauksessamme, otettava käyttöön pilvessä myöhempää päätöksentekoa varten. Analyytikon näkökulmasta työnkulku näyttää tältä:
- Analyytikko kirjoittaa skriptin, säännön tai ML-mallin varastosta saatujen tietojen perusteella. Osana hackathonia päätimme käyttää Mongodbia, mutta tallennusjärjestelmän valinnalla ei ole tässä merkitystä.
- Testattuaan kehitettyjä historiatiedon sääntöjä analyytikko lataa koodinsa hallintapaneeliin.
- Versioinnin varmistamiseksi kaikki koodi siirtyy Git-tietovarastoihin.
- Hallintapaneelin kautta on mahdollista ottaa koodi käyttöön pilvessä erillisenä toimivana Serverless-moduulina.
Asiakkaiden alkuperäisten tietojen tulee kulkea erikoistuneen Enrichment-palvelun kautta, joka on suunniteltu rikastamaan alkuperäistä pyyntöä varaston tiedoilla. Oli tärkeää toteuttaa tämä palvelu siten, että se toimisi yhden arkiston kanssa (josta analyytikko ottaa tiedot sääntöjä kehittäessään) yhtenäisen tietorakenteen ylläpitämiseksi.
Jo ennen hackatonia päätimme käyttää Serverless-kehystä. Nykyään markkinoilla on melko paljon tekniikoita, jotka toteuttavat tämän lähestymistavan. Kubernetes-arkkitehtuurin suosituimmat ratkaisut ovat Fission, Open FaaS ja Kubeless. Niitä on jopa .
Punnittuamme kaikki edut ja haitat, valitsimme . Tämä palvelinton kehys on melko helppo hallita ja täyttää tehtävän vaatimukset.
Jotta voit työskennellä Fissionin kanssa, sinun on ymmärrettävä kaksi peruskäsitettä: toiminta ja ympäristö. Funktio on koodinpätkä, joka on kirjoitettu jollakin niistä kielistä, joille on olemassa Fission-ympäristö. sisältää Pythonin, JS:n, Gon, JVM:n ja monia muita suosittuja kieliä ja teknologioita.
Fission pystyy myös suorittamaan toimintoja, jotka on jaettu useisiin tiedostoihin, jotka on valmiiksi pakattu arkistoon. Fissionin toiminta Kubernetes-klusterissa varmistetaan erikoistuneilla podilla, joita kehys itse hallinnoi. Jotta voit olla vuorovaikutuksessa klusteriryhmien kanssa, jokaiselle toiminnolle on määritettävä oma reittinsä, jolle voit välittää GET-parametreja tai pyynnön rungon POST-pyynnön tapauksessa.
Tämän seurauksena suunnittelimme saavamme ratkaisun, jonka avulla analyytikot voisivat ottaa käyttöön kehitettyjä sääntöskriptejä ilman insinöörien ja kehittäjien osallistumista. Kuvattu lähestymistapa poistaa myös kehittäjien tarpeen kirjoittaa analyytikkokoodi uudelleen toiselle kielelle. Esimerkiksi nykyisessä käyttämämme päätöksentekojärjestelmässä meidän on kirjoitettava säännöt pitkälle erikoistuneilla teknologioilla ja kielillä, joiden laajuus on erittäin rajallinen, ja on myös vahva riippuvuus sovelluspalvelimesta, koska kaikki pankin sääntöluonnokset otetaan käyttöön yhdessä ympäristössä. Tämän seurauksena uusien sääntöjen käyttöönotto edellyttää koko järjestelmän vapauttamista.
Ehdotetussa ratkaisussamme ei tarvitse vapauttaa sääntöjä, vaan koodi on helppo ottaa käyttöön napin painalluksella. Myös Kubernetesin infrastruktuurin hallinta antaa sinun olla ajattelematta kuormitusta ja skaalausta; tällaiset ongelmat ratkaistaan heti. Ja yhden tietovaraston käyttö poistaa tarpeen verrata reaaliaikaisia tietoja historiallisiin tietoihin, mikä yksinkertaistaa analyytikon työtä.
Mitä saimme
Koska tulimme hackathonille valmiin ratkaisun kanssa (fantasioitamme), meidän ei tarvinnut tehdä muuta kuin muuntaa kaikki ajatuksemme koodiriveiksi.
Avain menestykseen missä tahansa hackathonissa on valmistautuminen ja hyvin kirjoitettu suunnitelma. Siksi ensimmäinen asia, jonka teimme, oli päättää, mistä moduuleista järjestelmäarkkitehtuurimme koostuu ja mitä tekniikoita käytämme.
Projektimme arkkitehtuuri oli seuraava:
Tämä kaavio näyttää kaksi sisääntulopistettä, analyytikko (järjestelmämme pääkäyttäjä) ja asiakas.
Työprosessi on rakentunut näin. Analyytikko kehittää mallilleen sääntöfunktion ja tietojen rikastusfunktion, tallentaa koodinsa Git-tietovarastoon ja ottaa mallinsa käyttöön pilvessä järjestelmänvalvojasovelluksen kautta. Pohditaan, kuinka käyttöön otettua toimintoa kutsutaan, ja tehdään päätöksiä asiakkaiden saapuvista pyynnöistä:
- Asiakas täyttää verkkosivulla olevan lomakkeen ja lähettää pyyntönsä rekisterinpitäjälle. Hakemus, josta on tehtävä päätös, tulee järjestelmän syötteeseen ja tallennetaan tietokantaan alkuperäisessä muodossaan.
- Seuraavaksi raakapyyntö lähetetään tarvittaessa rikastamista varten. Voit täydentää alkuperäistä pyyntöä tiedoilla sekä ulkoisista palveluista että tallennustilasta. Tuloksena oleva rikastettu kysely tallennetaan myös tietokantaan.
- Käynnistyy analyytikkotoiminto, joka ottaa syötteeksi rikastetun kyselyn ja tuottaa ratkaisun, joka myös kirjoitetaan muistiin.
Päätimme käyttää MongoDB:tä järjestelmämme tallennustilana dokumenttisuuntautuneen tietojen tallennuksen JSON-dokumenttien muodossa, koska rikastuspalvelut, mukaan lukien alkuperäinen pyyntö, kokosivat kaikki tiedot REST-ohjainten kautta.
Meillä oli siis XNUMX tuntia aikaa ottaa alusta käyttöön. Jaoimme roolit melko onnistuneesti, jokaisella tiimin jäsenellä oli projektissamme oma vastuualue:
- Analyytikon työn käyttöliittymät, joiden kautta hän saattoi ladata sääntöjä kirjoitettujen komentosarjojen versionhallintajärjestelmästä, valita syötetietojen rikastamisvaihtoehtoja ja muokata sääntöskriptejä verkossa.
- Taustajärjestelmän järjestelmänvalvoja, mukaan lukien REST API etupuolelle ja integrointi VCS:n kanssa.
- Infrastruktuurin luominen Google Cloudiin ja palvelun kehittäminen lähdetietojen rikastamiseen.
- Moduuli järjestelmänvalvojasovelluksen integroimiseksi Serverless-kehykseen sääntöjen myöhempää käyttöönottoa varten.
- Sääntöskriptit koko järjestelmän suorituskyvyn testaamiseksi ja analytiikan yhdistäminen saapuville sovelluksille (tehdyt päätökset) lopullista esittelyä varten.
Aloitetaan järjestyksessä.
Käyttöliittymämme on kirjoitettu Angular 7:llä käyttämällä pankkikäyttöliittymäpakettia. Hallintapaneelin lopullinen versio näytti tältä:
Koska aikaa oli vähän, yritimme ottaa käyttöön vain avaintoiminnot. Toiminnon käyttöönottoa varten Kubernetes-klusterissa oli tarpeen valita tapahtuma (palvelu, jolle sääntö on otettava käyttöön pilvessä) ja päätöksentekologiikkaa toteuttavan toiminnon koodi. Kirjoitimme tästä tapahtumasta lokin jokaista valitun palvelun säännön käyttöönottoa varten. Hallintapaneelissa voit nähdä kaikkien tapahtumien lokit.
Kaikki toimintokoodi tallennettiin Git-etävarastoon, joka oli myös asetettava hallintapaneelissa. Koodin versiota varten kaikki toiminnot tallennettiin arkiston eri haaroihin. Hallintapaneeli tarjoaa myös mahdollisuuden tehdä muutoksia kirjoitettuihin komentosarjoihin, jotta voit ennen toiminnon käyttöönottoa tuotantoon tarkistaa kirjoitetun koodin, mutta myös tehdä tarvittavat muutokset.
Sääntötoimintojen lisäksi toteutimme myös mahdollisuuden rikastaa lähdetietoa asteittain Enrichment-funktioilla, joiden koodina oli myös komentosarjat, joissa oli mahdollista mennä tietovarastoon, soittaa kolmansien osapuolten palveluihin ja tehdä alustavia laskelmia. . Ratkaisumme esittelyä varten laskimme pyynnön jättäneen asiakkaan horoskooppimerkin ja määritimme hänen matkapuhelinoperaattorinsa käyttämällä kolmannen osapuolen REST-palvelua.
Alustan taustaosa on kirjoitettu Java-kielellä ja toteutettu Spring Boot -sovelluksena. Alun perin suunnittelimme Postgresin tallentamiseen järjestelmänvalvojan tietoja, mutta osana hackathonia päätimme rajoittua yksinkertaiseen H2:een ajan säästämiseksi. Taustalla integrointi Bitbucketin kanssa toteutettiin kyselyn rikastustoimintojen ja sääntökomentosarjojen versioimiseksi. Käytimme integrointiin Git-etävarastoihin , joka on eräänlainen CLI-komentojen kääre, jonka avulla voit suorittaa mitä tahansa git-käskyä kätevän ohjelmistoliittymän avulla. Joten meillä oli kaksi erillistä arkistoa rikastustoiminnoille ja säännöille, ja kaikki skriptit oli jaettu hakemistoihin. Käyttöliittymän kautta oli mahdollista valita arkiston mielivaltaisen haaran komentosarjan viimeisin toimitus. Kun teet muutoksia koodiin hallintapaneelin kautta, muuttuneesta koodista luotiin commits etävarastoihin.
Ideamme toteuttamiseksi tarvitsimme sopivan infrastruktuurin. Päätimme ottaa Kubernetes-klusterimme käyttöön pilvessä. Valintamme oli Google Cloud Platform. Palvelimeton Fission-kehys asennettiin Kubernetes-klusteriin, jonka otimme käyttöön Gcloudissa. Aluksi lähdetietojen rikastuspalvelu toteutettiin erillisenä Java-sovelluksena k8s-klusterin sisällä olevaan Podiin käärittynä. Mutta sen jälkeen, kun projektimme esiteltiin alustavasti kesken hackathonin, meille suositeltiin Enrichment-palvelun joustavuutta, jotta voimme valita, kuinka rikastaa saapuvien sovellusten raakadataa. Eikä meillä ollut muuta vaihtoehtoa kuin tehdä rikastuspalvelusta myös palvelinton.
Työskenteleksemme Fissionin kanssa käytimme Fission CLI:tä, joka on asennettava Kubernetes CLI:n päälle. Toimintojen käyttöönotto k8s-klusteriin on melko yksinkertaista; sinun tarvitsee vain määrittää toiminnolle sisäinen reitti ja sisääntulo, jotta saapuva liikenne sallitaan, jos tarvitaan pääsy klusterin ulkopuolelle. Yhden toiminnon käyttöönotto kestää yleensä enintään 10 sekuntia.
Hankkeen loppuesitys ja yhteenveto
Havainnollistaaksemme järjestelmämme toimintaa olemme sijoittaneet etäpalvelimelle yksinkertaisen lomakkeen, jonne voit lähettää hakemuksen johonkin pankin tuotteista. Pyydäksesi sinun oli syötettävä nimikirjaimesi, syntymäaikasi ja puhelinnumerosi.
Asiakaslomakkeen tiedot menivät rekisterinpitäjälle, joka lähetti samanaikaisesti pyynnöt kaikista saatavilla olevista säännöistä, rikastettuaan tietoja aiemmin määritettyjen ehtojen mukaisesti ja tallentaen ne yhteiseen varastoon. Otimme käyttöön yhteensä kolme toimintoa, jotka tekevät päätöksiä saapuvista sovelluksista, ja 4 tiedonrikastuspalvelua. Hakemuksen jättämisen jälkeen asiakas sai päätöksemme:
Kieltäytymisen tai hyväksynnän lisäksi asiakas sai myös listan muista tuotteista, joista lähetimme rinnakkain pyynnöt. Näin osoitimme ristiinmyynnin mahdollisuuden alustallamme.
Saatavilla oli yhteensä 3 fiktiivistä pankkituotetta:
- Luotto.
- lelu
- Kiinnitys.
Esittelyn aikana otimme käyttöön valmiit toiminnot ja rikastusskriptit jokaiselle palvelulle.
Jokainen sääntö vaati oman syöttötietosarjansa. Joten asuntolainan hyväksymiseksi laskemme asiakkaan horoskooppimerkin ja liitimme tämän kuukalenterin logiikkaan. Lelun hyväksymiseksi tarkistimme asiakkaan olevan täysi-ikäinen ja lainan myöntämiseksi lähetimme ulkopuoliselle avoimelle palvelulle matkapuhelinoperaattorin selvittämispyynnön, josta tehtiin päätös.
Pyrimme tekemään esittelystämme mielenkiintoisen ja vuorovaikutteisen, kaikki läsnäolijat pääsivät käymään lomakkeellamme ja tarkistamaan kuvitteellisten palveluidemme saatavuuden. Ja aivan esityksen lopussa esitimme vastaanotettujen hakemusten analytiikkaa, joka osoitti kuinka moni palveluamme käytti, kuinka monta hyväksyntää ja kieltäytymistä.
Lisäksi otimme käyttöön avoimen lähdekoodin BI-työkalun kerätäksemme analytiikkaa verkossa ja ruuvattiin se varastoyksikköömme. Metabase antaa sinun rakentaa analyyttisiä näyttöjä meitä kiinnostavista tiedoista; sinun tarvitsee vain rekisteröidä yhteys tietokantaan, valita taulukot (meidän tapauksessamme tietokokoelmat, koska käytimme MongoDB:tä) ja määrittää meitä kiinnostavat kentät .
Tuloksena saimme hyvän päätöksentekoalustan prototyypin ja demonstraation aikana jokainen kuuntelija sai itse tarkistaa sen suorituskyvyn. Mielenkiintoinen ratkaisu, valmis prototyyppi ja onnistunut esittely antoivat meille mahdollisuuden voittaa muiden joukkueiden kovasta kilpailusta huolimatta. Olen varma, että jokaisen tiimin projektista voidaan kirjoittaa myös mielenkiintoinen artikkeli.
Lähde: will.com