Simula noong nakaraang taon, nagsimulang mag-organisa ang aming kumpanya ng mga hackathon. Ang unang kumpetisyon ay napaka-matagumpay, isinulat namin ang tungkol dito . Ang pangalawang hackathon ay naganap noong Pebrero 2019 at hindi gaanong matagumpay. Tungkol sa mga layunin ng paghawak sa huli hindi pa katagal organizer.
Ang mga kalahok ay binigyan ng isang medyo kawili-wiling gawain na may kumpletong kalayaan sa pagpili ng isang stack ng teknolohiya para sa pagpapatupad nito. Kinailangan na ipatupad ang isang platform sa paggawa ng desisyon para sa maginhawang pag-deploy ng mga function ng pagmamarka ng customer na maaaring gumana nang may mabilis na daloy ng mga application, makatiis ng mabibigat na load, at ang system mismo ay madaling scalable.
Ang gawain ay hindi mahalaga at maaaring malutas sa maraming paraan, tulad ng kinumbinsi namin sa panahon ng pagpapakita ng mga huling presentasyon ng mga proyekto ng mga kalahok. Mayroong 6 na koponan ng 5 tao sa hackathon, lahat ng mga kalahok ay may magagandang proyekto, ngunit ang aming platform ay naging pinaka mapagkumpitensya. Mayroon kaming isang napaka-kagiliw-giliw na proyekto, na nais kong pag-usapan sa artikulong ito.
Ang aming solusyon ay isang platform batay sa Serverless na arkitektura sa loob ng Kubernetes, na binabawasan ang oras na kinakailangan upang magdala ng mga bagong feature sa produksyon. Pinapayagan nito ang mga analyst na magsulat ng code sa isang kapaligiran na maginhawa para sa kanila at i-deploy ito sa produksyon nang walang paglahok ng mga inhinyero at developer.
Ano ang pagmamarka
Ang Tinkoff.ru, tulad ng maraming makabagong kumpanya, ay may pagmamarka ng customer. Ang pagmamarka ay isang sistema ng pagtatasa ng customer batay sa mga istatistikal na pamamaraan ng pagsusuri ng data.
Halimbawa, ang isang kliyente ay bumaling sa amin na may kahilingan na magbigay sa kanya ng pautang, o magbukas ng isang indibidwal na account ng negosyante sa amin. Kung plano nating mag-isyu sa kanya ng pautang, kailangan nating suriin ang kanyang solvency, at kung ang account ay isang indibidwal na negosyante, kailangan nating tiyakin na ang kliyente ay hindi magsasagawa ng mga mapanlinlang na transaksyon.
Ang batayan para sa paggawa ng mga naturang desisyon ay mga modelong matematikal na sinusuri ang parehong data mula sa mismong application at ang data mula sa aming imbakan. Bilang karagdagan sa pagmamarka, ang mga katulad na istatistikal na pamamaraan ay maaari ding gamitin sa serbisyo ng pagbuo ng mga indibidwal na rekomendasyon para sa mga bagong produkto para sa aming mga kliyente.
Ang paraan ng naturang pagtatasa ay maaaring tumanggap ng iba't ibang data ng pag-input. At sa ilang mga punto maaari kaming magdagdag ng isang bagong parameter sa input, na, batay sa mga resulta ng pagsusuri sa makasaysayang data, ay tataas ang rate ng conversion ng paggamit ng serbisyo.
Mayroon kaming maraming data tungkol sa mga relasyon sa customer, at ang dami ng impormasyong ito ay patuloy na lumalaki. Para gumana ang pagmamarka, nangangailangan din ang pagpoproseso ng data ng mga panuntunan (o mga modelo ng matematika) na nagbibigay-daan sa iyong mabilis na magpasya kung sino ang aaprubahan ng isang aplikasyon, kung sino ang tatanggihan, at kung sino ang mag-aalok ng ilang higit pang produkto, na tinatasa ang kanilang potensyal na interes.
Para sa gawaing nasa kamay, gumagamit na kami ng isang espesyal na sistema ng paggawa ng desisyon , na, batay sa mga panuntunang itinakda ng mga analyst, technologist at developer, ay nagpapasya kung aaprubahan o tatanggihan ang isang partikular na produkto ng pagbabangko sa kliyente.
Mayroong maraming mga handa na solusyon sa merkado, parehong mga modelo ng pagmamarka at mga sistema ng paggawa ng desisyon mismo. Ginagamit namin ang isa sa mga system na ito sa aming kumpanya. Ngunit ang negosyo ay lumalaki, nag-iiba-iba, parehong ang bilang ng mga kliyente at ang bilang ng mga produktong inaalok ay tumataas, at kasama nito, ang mga ideya ay umuusbong kung paano pagbutihin ang umiiral na proseso ng paggawa ng desisyon. Tiyak na ang mga taong nagtatrabaho sa umiiral na sistema ay may maraming mga ideya kung paano gawin itong mas simple, mas mahusay, mas maginhawa, ngunit kung minsan ang mga ideya mula sa labas ay kapaki-pakinabang. Ang Bagong Hackathon ay isinaayos na may layuning mangolekta ng mga ideyang matunog.
Gawain
Ang hackathon ay ginanap noong Pebrero 23. Ang mga kalahok ay inalok ng isang gawain sa labanan: upang bumuo ng isang sistema ng paggawa ng desisyon na kailangang matugunan ang isang bilang ng mga kundisyon.
Sinabi sa amin kung paano gumagana ang umiiral na system at kung anong mga paghihirap ang lumitaw sa panahon ng operasyon nito, pati na rin kung anong mga layunin sa negosyo ang dapat ituloy ng binuong platform. Ang sistema ay dapat magkaroon ng isang mabilis na time-to-market para sa pagbuo ng mga panuntunan upang ang gumaganang code ng mga analyst ay makapasok sa produksyon sa lalong madaling panahon. At para sa papasok na daloy ng mga aplikasyon, ang oras ng paggawa ng desisyon ay dapat na pinakamababa. Gayundin, ang system na binuo ay dapat magkaroon ng cross-sell na mga kakayahan upang mabigyan ang kliyente ng pagkakataong bumili ng iba pang mga produkto ng kumpanya kung sila ay naaprubahan namin at may potensyal na interes mula sa kliyente.
Malinaw na imposibleng magsulat ng isang ready-to-release na proyekto sa magdamag na tiyak na mapupunta sa produksyon, at medyo mahirap sakupin ang buong sistema, kaya hiniling sa amin na ipatupad ang hindi bababa sa bahagi nito. Ang ilang mga kinakailangan ay itinatag na ang prototype ay dapat matugunan. Posibleng subukan ang parehong upang masakop ang lahat ng mga kinakailangan sa kanilang kabuuan, at magtrabaho nang detalyado sa mga indibidwal na seksyon ng platform na binuo.
Tulad ng para sa teknolohiya, ang lahat ng mga kalahok ay binigyan ng kumpletong kalayaan sa pagpili. Posibleng gumamit ng anumang mga konsepto at teknolohiya: Data streaming, machine learning, event sourcing, big data at iba pa.
Ang aming solusyon
Pagkatapos ng kaunting brainstorming, napagpasyahan namin na ang solusyon ng FaaS ay magiging perpekto para sa pagkumpleto ng gawain.
Para sa solusyong ito, kinailangan na humanap ng angkop na balangkas na Walang Server upang maipatupad ang mga patakaran ng binuong sistema ng paggawa ng desisyon. Dahil aktibong ginagamit ni Tinkoff ang Kubernetes para sa pamamahala ng imprastraktura, tumingin kami sa ilang mga handa na solusyon batay dito; sasabihin ko sa iyo ang higit pa tungkol dito sa ibang pagkakataon.
Upang mahanap ang pinaka-epektibong solusyon, tiningnan namin ang produktong binuo sa pamamagitan ng mga mata ng mga gumagamit nito. Ang mga pangunahing gumagamit ng aming system ay mga analyst na kasangkot sa pagbuo ng panuntunan. Dapat i-deploy ang mga panuntunan sa server, o, tulad ng sa aming kaso, i-deploy sa cloud, para sa kasunod na paggawa ng desisyon. Mula sa pananaw ng isang analyst, ganito ang hitsura ng daloy ng trabaho:
- Nagsusulat ang analyst ng script, panuntunan, o modelo ng ML batay sa data mula sa warehouse. Bilang bahagi ng hackathon, nagpasya kaming gamitin ang Mongodb, ngunit ang pagpili ng sistema ng pag-iimbak ng data ay hindi mahalaga dito.
- Pagkatapos subukan ang mga binuo na panuntunan sa makasaysayang data, ina-upload ng analyst ang kanyang code sa admin panel.
- Upang matiyak ang pag-bersyon, mapupunta ang lahat ng code sa mga repositoryo ng Git.
- Sa pamamagitan ng admin panel magiging posible na i-deploy ang code sa cloud bilang isang hiwalay na functional na Serverless module.
Ang paunang data mula sa mga kliyente ay dapat dumaan sa isang espesyal na serbisyo ng Enrichment na idinisenyo upang pagyamanin ang paunang kahilingan gamit ang data mula sa warehouse. Mahalagang ipatupad ang serbisyong ito sa paraang gagana ito sa iisang repositoryo (kung saan kinukuha ng analyst ang data kapag bumubuo ng mga panuntunan) upang mapanatili ang isang pinag-isang istruktura ng data.
Bago pa man ang hackathon, nagpasya kami sa Serverless framework na aming gagamitin. Sa ngayon, napakaraming teknolohiya sa merkado na nagpapatupad ng pamamaraang ito. Ang pinakasikat na solusyon sa arkitektura ng Kubernetes ay Fission, Open FaaS at Kubeless. Mayroong kahit na .
Pagkatapos timbangin ang lahat ng mga kalamangan at kahinaan, pinili namin . Ang Serverless framework na ito ay medyo madaling pamahalaan at nakakatugon sa mga kinakailangan ng gawain.
Upang gumana sa Fission, kailangan mong maunawaan ang dalawang pangunahing konsepto: function at environment. Ang function ay isang piraso ng code na nakasulat sa isa sa mga wika kung saan mayroong Fission na kapaligiran. kasama ang Python, JS, Go, JVM at marami pang iba pang tanyag na wika at teknolohiya.
Ang Fission ay may kakayahang magsagawa ng mga function na nahahati sa ilang mga file, na paunang naka-package sa isang archive. Ang operasyon ng Fission sa isang Kubernetes cluster ay sinisiguro ng mga dalubhasang pod, na pinamamahalaan ng mismong framework. Upang makipag-ugnayan sa mga cluster pod, ang bawat function ay dapat magtalaga ng sarili nitong ruta, at kung saan maaari kang magpasa ng mga GET parameter o request body sa kaso ng isang POST request.
Bilang resulta, nagplano kaming kumuha ng solusyon na magbibigay-daan sa mga analyst na mag-deploy ng mga binuong script ng panuntunan nang walang paglahok ng mga inhinyero at developer. Tinatanggal din ng inilarawang diskarte ang pangangailangan para sa mga developer na muling isulat ang analyst code sa ibang wika. Halimbawa, para sa kasalukuyang sistema ng paggawa ng desisyon na ginagamit namin, kailangan naming magsulat ng mga panuntunan sa mga highly specialized na teknolohiya at wika, ang saklaw nito ay lubhang limitado, at mayroon ding isang malakas na pag-asa sa server ng aplikasyon, dahil ang lahat ng draft na mga patakaran ng bangko ay naka-deploy sa iisang kapaligiran. Bilang resulta, upang mag-deploy ng mga bagong panuntunan, kinakailangan na ilabas ang buong system.
Sa aming iminungkahing solusyon, hindi na kailangang maglabas ng mga panuntunan; ang code ay madaling i-deploy sa pag-click ng isang pindutan. Gayundin, ang pamamahala ng imprastraktura sa Kubernetes ay nagbibigay-daan sa iyo na huwag isipin ang tungkol sa pag-load at pag-scale; ang mga naturang problema ay nalutas sa labas ng kahon. At ang paggamit ng iisang data warehouse ay nag-aalis ng pangangailangang ihambing ang real-time na data sa makasaysayang data, na nagpapasimple sa gawain ng analyst.
Ang nakuha namin
Dahil dumating kami sa hackathon na may handa na solusyon (sa aming mga pantasya), ang kailangan lang naming gawin ay i-convert ang lahat ng aming mga iniisip sa mga linya ng code.
Ang susi sa tagumpay sa anumang hackathon ay paghahanda at isang mahusay na pagkakasulat na plano. Samakatuwid, ang unang bagay na ginawa namin ay magpasya kung anong mga module ang bubuo ng aming system architecture at kung anong mga teknolohiya ang aming gagamitin.
Ang arkitektura ng aming proyekto ay ang mga sumusunod:
Ang diagram na ito ay nagpapakita ng dalawang entry point, ang analyst (ang pangunahing gumagamit ng aming system) at ang kliyente.
Ang proseso ng trabaho ay nakabalangkas tulad nito. Ang analyst ay bubuo ng isang function ng panuntunan at isang function ng pagpapayaman ng data para sa kanyang modelo, iniimbak ang kanyang code sa isang repositoryo ng Git, at ini-deploy ang kanyang modelo sa cloud sa pamamagitan ng application ng administrator. Isaalang-alang natin kung paano tatawagin ang naka-deploy na function at gumawa ng mga desisyon sa mga papasok na kahilingan mula sa mga kliyente:
- Pinunan ng kliyente ang isang form sa website at ipinapadala ang kanyang kahilingan sa controller. Ang isang application kung saan kailangang gumawa ng desisyon ay dumating sa input ng system at naitala sa database sa orihinal nitong anyo.
- Susunod, ang hilaw na kahilingan ay ipinadala para sa pagpapayaman, kung kinakailangan. Maaari mong dagdagan ang paunang kahilingan ng data mula sa mga panlabas na serbisyo at mula sa imbakan. Ang resultang enriched query ay naka-imbak din sa database.
- Inilunsad ang function ng analyst, na kumukuha ng enriched na query bilang input at gumagawa ng solusyon, na isinulat din sa storage.
Nagpasya kaming gamitin ang MongoDB bilang storage sa aming system dahil sa document-oriented na storage ng data sa anyo ng mga dokumento ng JSON, dahil pinagsama-sama ng mga serbisyo sa pagpapayaman, kasama ang orihinal na kahilingan, ang lahat ng data sa pamamagitan ng REST controllers.
Kaya, mayroon kaming XNUMX na oras para ipatupad ang platform. Ibinahagi namin ang mga tungkulin nang matagumpay; ang bawat miyembro ng koponan ay may sariling lugar ng responsibilidad sa aming proyekto:
- Mga front-end na admin panel para sa trabaho ng analyst, kung saan maaari niyang i-download ang mga panuntunan mula sa version control system ng mga nakasulat na script, pumili ng mga opsyon para sa pagpapayaman ng data ng input at mag-edit ng mga script ng panuntunan online.
- Admin ng backend, kasama ang REST API para sa harap at pagsasama sa VCS.
- Pagse-set up ng imprastraktura sa Google Cloud at pagbuo ng isang serbisyo para sa pagpapayaman ng source data.
- Isang module para sa pagsasama ng admin application sa Serverless framework para sa kasunod na pag-deploy ng mga panuntunan.
- Mga script ng mga panuntunan para sa pagsubok sa pagganap ng buong system at pagsasama-sama ng analytics sa mga papasok na application (mga ginawang desisyon) para sa panghuling pagpapakita.
Magsimula tayo sa pagkakasunud-sunod.
Ang aming frontend ay isinulat sa Angular 7 gamit ang banking UI Kit. Ang huling bersyon ng admin panel ay ganito ang hitsura:
Dahil may kaunting oras, sinubukan naming ipatupad lamang ang pangunahing pag-andar. Upang mag-deploy ng function sa cluster ng Kubernetes, kinakailangang pumili ng event (isang serbisyo kung saan kailangang i-deploy ang isang panuntunan sa cloud) at ang code ng function na nagpapatupad ng logic sa paggawa ng desisyon. Para sa bawat deployment ng panuntunan para sa napiling serbisyo, nagsulat kami ng log ng kaganapang ito. Sa admin panel maaari mong makita ang mga log ng lahat ng mga kaganapan.
Ang lahat ng function code ay nakaimbak sa isang malayuang Git repository, na kailangan ding itakda sa admin panel. Upang i-version ang code, ang lahat ng mga function ay naka-imbak sa iba't ibang sangay ng repository. Ang admin panel ay nagbibigay din ng kakayahang gumawa ng mga pagsasaayos sa nakasulat na mga script, upang bago mag-deploy ng isang function sa produksyon, hindi mo lamang masuri ang nakasulat na code, ngunit gawin din ang mga kinakailangang pagbabago.
Bilang karagdagan sa mga function ng panuntunan, ipinatupad din namin ang kakayahang unti-unting pagyamanin ang source data gamit ang mga function ng Enrichment, ang code kung saan ay mga script din kung saan posible na pumunta sa data warehouse, tumawag sa mga serbisyo ng third-party at magsagawa ng mga paunang kalkulasyon . Upang ipakita ang aming solusyon, kinakalkula namin ang zodiac sign ng kliyente na umalis sa kahilingan at tinukoy ang kanyang mobile operator gamit ang isang third-party na REST na serbisyo.
Ang backend ng platform ay isinulat sa Java at ipinatupad bilang isang Spring Boot application. Una naming binalak na gamitin ang Postgres upang mag-imbak ng data ng admin, ngunit, bilang bahagi ng hackathon, nagpasya kaming limitahan ang aming sarili sa isang simpleng H2 upang makatipid ng oras. Sa backend, ipinatupad ang pagsasama sa Bitbucket upang i-version ang mga function ng pagpapayaman ng query at mga script ng panuntunan. Para sa pagsasama sa malalayong Git repository, ginamit namin , na isang uri ng pambalot sa mga utos ng CLI, na nagbibigay-daan sa iyong magsagawa ng anumang git na mga tagubilin gamit ang isang maginhawang interface ng software. Kaya nagkaroon kami ng dalawang magkahiwalay na repository para sa mga function at panuntunan sa pagpapayaman, at ang lahat ng mga script ay nahahati sa mga direktoryo. Sa pamamagitan ng UI, naging posible na piliin ang pinakabagong commit ng isang script ng isang arbitrary na sangay ng repositoryo. Kapag gumagawa ng mga pagbabago sa code sa pamamagitan ng admin panel, ginawa ang mga commit ng binagong code sa mga malalayong imbakan.
Upang maipatupad ang aming ideya, kailangan namin ng angkop na imprastraktura. Nagpasya kaming i-deploy ang aming Kubernetes cluster sa cloud. Ang aming napili ay Google Cloud Platform. Ang Fission serverless framework ay na-install sa isang Kubernetes cluster, na aming na-deploy sa Gcloud. Sa una, ang serbisyo sa pagpapayaman ng source data ay ipinatupad bilang isang hiwalay na Java application na nakabalot sa isang Pod sa loob ng k8s cluster. Ngunit pagkatapos ng paunang pagpapakita ng aming proyekto sa gitna ng hackathon, inirekomenda sa amin na gawing mas flexible ang Enrichment service para mabigyan ng pagkakataong pumili kung paano pagyamanin ang raw data ng mga papasok na application. At wala kaming pagpipilian kundi gawing Serverless din ang enrichment service.
Upang gumana sa Fission, ginamit namin ang Fission CLI, na dapat na naka-install sa ibabaw ng Kubernetes CLI. Ang pag-deploy ng mga function sa isang k8s cluster ay medyo simple; kailangan mo lang magtalaga ng panloob na ruta at pagpasok sa function upang payagan ang papasok na trapiko kung kailangan ang access sa labas ng cluster. Ang pag-deploy ng isang function ay karaniwang tumatagal ng hindi hihigit sa 10 segundo.
Pangwakas na pagtatanghal ng proyekto at pagbubuod
Upang ipakita kung paano gumagana ang aming system, naglagay kami ng simpleng form sa isang malayong server kung saan maaari kang magsumite ng aplikasyon para sa isa sa mga produkto ng bangko. Upang humiling, kailangan mong ilagay ang iyong mga inisyal, petsa ng kapanganakan at numero ng telepono.
Ang data mula sa form ng kliyente ay napunta sa controller, na sabay-sabay na nagpadala ng mga kahilingan para sa lahat ng magagamit na mga patakaran, na dati nang pinayaman ang data ayon sa tinukoy na mga kondisyon, at nai-save ang mga ito sa isang karaniwang imbakan. Sa kabuuan, nag-deploy kami ng tatlong function na gumagawa ng mga desisyon sa mga papasok na application at 4 na serbisyo sa pagpapayaman ng data. Pagkatapos isumite ang aplikasyon, natanggap ng kliyente ang aming desisyon:
Bilang karagdagan sa pagtanggi o pag-apruba, nakatanggap din ang kliyente ng isang listahan ng iba pang mga produkto, mga kahilingan kung saan ipinadala namin nang magkatulad. Ito ay kung paano namin ipinakita ang posibilidad ng cross-sale sa aming platform.
Mayroong kabuuang 3 gawa-gawang produkto ng bangko na magagamit:
- Credit.
- Laruang
- Mortgage.
Sa panahon ng demonstrasyon, nag-deploy kami ng mga inihandang function at enrichment script para sa bawat serbisyo.
Ang bawat panuntunan ay nangangailangan ng sarili nitong set ng input data. Kaya, upang aprubahan ang isang mortgage, kinakalkula namin ang zodiac sign ng kliyente at ikinonekta ito sa lohika ng lunar na kalendaryo. Upang aprubahan ang isang laruan, sinuri namin na ang kliyente ay umabot na sa edad ng mayorya, at upang mag-isyu ng pautang, nagpadala kami ng kahilingan sa isang panlabas na bukas na serbisyo para sa pagtukoy sa cellular operator, at isang desisyon ang ginawa tungkol dito.
Sinubukan naming gawing kawili-wili at interactive ang aming demonstrasyon, lahat ng naroroon ay maaaring pumunta sa aming form at suriin ang pagkakaroon ng aming mga kathang-isip na serbisyo sa kanila. At sa pinakadulo ng pagtatanghal, ipinakita namin ang analytics ng mga natanggap na aplikasyon, na nagpakita kung gaano karaming tao ang gumamit ng aming serbisyo, ang bilang ng mga pag-apruba, at pagtanggi.
Upang mangolekta ng analytics online, nag-deploy din kami ng open source na tool na BI at inilagay ito sa aming storage unit. Binibigyang-daan ka ng Metabase na bumuo ng mga screen na may analytics sa data na interesado sa amin; kailangan mo lang magrehistro ng koneksyon sa database, pumili ng mga talahanayan (sa aming kaso, mga koleksyon ng data, dahil ginamit namin ang MongoDB), at tukuyin ang mga larangan ng interes sa amin .
Bilang resulta, nakakuha kami ng magandang prototype ng platform sa paggawa ng desisyon, at sa panahon ng demonstrasyon, maaaring personal na suriin ng bawat tagapakinig ang pagganap nito. Ang isang kawili-wiling solusyon, isang tapos na prototype at isang matagumpay na demonstrasyon ay nagpapahintulot sa amin na manalo, sa kabila ng malakas na kumpetisyon mula sa ibang mga koponan. Sigurado ako na ang isang kawili-wiling artikulo ay maaari ding isulat sa proyekto ng bawat koponan.
Pinagmulan: www.habr.com