Idéer og møder om, hvilke andre processer der kan automatiseres, opstår i virksomheder af forskellig størrelse hver dag. Men udover at der kan bruges meget tid på at lave en model, skal du bruge den på at evaluere den og kontrollere at det opnåede resultat ikke er tilfældigt. Efter implementering skal enhver model overvåges og periodisk kontrolleres.
Og det er alle de etaper, der skal gennemføres i enhver virksomhed, uanset dens størrelse. Hvis vi taler om omfanget og arven fra Sberbank, stiger antallet af finjusteringer betydeligt. Ved udgangen af 2019 havde Sber allerede brugt mere end 2000 modeller. Det er ikke nok blot at udvikle en model, det er nødvendigt at integrere med industrielle systemer, udvikle datamarts til at bygge modeller og sikre kontrol med dens drift på klyngen.
Vores team er ved at udvikle Sber.DS platformen. Det giver dig mulighed for at løse maskinlæringsproblemer, fremskynder processen med at teste hypoteser, forenkler i princippet processen med at udvikle og validere modeller og styrer også resultatet af modellen i PROM.
For ikke at snyde dine forventninger, vil jeg på forhånd sige, at dette indlæg er et indledende indlæg, og under snittet, for det første, taler vi om, hvad der i princippet er under hætten på Sber.DS-platformen. Vi vil fortælle historien om modellens livscyklus fra oprettelse til implementering separat.
Sber.DS består af flere komponenter, de vigtigste er biblioteket, udviklingssystemet og modeludførelsessystemet.
Biblioteket styrer modellens livscyklus fra det øjeblik ideen om at udvikle den dukker op, til dens implementering i PROM, overvågning og dekommissionering. Mange biblioteksfunktioner er dikteret af regulatorens regler, for eksempel rapportering og opbevaring af trænings- og valideringsprøver. Faktisk er dette et register over alle vores modeller.
Udviklingssystemet er designet til visuel udvikling af modeller og valideringsteknikker. De udviklede modeller gennemgår indledende validering og leveres til eksekveringssystemet for at udføre deres forretningsfunktioner. Også i runtime-systemet kan modellen placeres på en monitor med det formål at periodisk lancere valideringsteknikker for at overvåge dens drift.
Der er flere typer knudepunkter i systemet. Nogle er designet til at forbinde til forskellige datakilder, andre er designet til at transformere kildedata og berige dem (markup). Der er mange noder til at bygge forskellige modeller og noder til at validere dem. Udvikleren kan indlæse data fra enhver kilde, transformere, filtrere, visualisere mellemliggende data og opdele dem i dele.
Platformen indeholder også færdige moduler, der kan trækkes og slippes på designområdet. Alle handlinger udføres ved hjælp af en visualiseret grænseflade. Faktisk kan du løse problemet uden en enkelt linje kode.
Hvis de indbyggede muligheder ikke er nok, giver systemet mulighed for hurtigt at oprette dine egne moduler. Vi lavede en integreret udviklingstilstand baseret på for dem, der opretter nye moduler fra bunden.
Arkitekturen i Sber.DS er bygget på mikrotjenester. Der er mange meninger om, hvad mikrotjenester er. Nogle mennesker tror, at det er nok at opdele den monolitiske kode i dele, men samtidig går de stadig til den samme database. Vores mikroservice må kun kommunikere med en anden mikroservice via REST API. Ingen løsninger for at få direkte adgang til databasen.
Vi forsøger at sikre, at tjenester ikke bliver meget store og klodsede: Én instans bør ikke forbruge mere end 4-8 gigabyte RAM og skal give mulighed for at skalere anmodninger horisontalt ved at lancere nye instanser. Hver tjeneste kommunikerer kun med andre via REST API (). Det team, der er ansvarligt for tjenesten, skal holde API'en bagudkompatibel indtil den sidste klient, der bruger den.
Kernen i applikationen er skrevet i Java ved hjælp af Spring Framework. Løsningen blev oprindeligt designet til hurtig implementering i cloud-infrastrukturen, så applikationen blev bygget ved hjælp af et containeriseringssystem (). Platformen udvikler sig konstant, både i forhold til at øge forretningsfunktionaliteten (nye connectors, AutoML kommer til) og i forhold til teknologisk effektivitet.
En af funktionerne ved vores platform er, at vi kan køre kode udviklet i en visuel grænseflade på ethvert Sberbank-modeludførelsessystem. Nu er der allerede to af dem: en på Hadoop, den anden på OpenShift (Docker). Vi stopper ikke der og skaber integrationsmoduler til at køre kode på enhver infrastruktur, inklusive on-premise og i skyen. Med hensyn til mulighederne for effektiv integration i Sberbank-økosystemet planlægger vi også at understøtte arbejdet med eksisterende eksekveringsmiljøer. I fremtiden kan løsningen integreres fleksibelt "ud af boksen" i ethvert landskab i enhver organisation.
Dem, der nogensinde har forsøgt at understøtte en løsning, der kører Python på Hadoop i PROM, ved, at det ikke er nok at forberede og levere et Python-brugermiljø til hver datanode. Det enorme antal C/C++-biblioteker til maskinlæring, der bruger Python-moduler, vil ikke tillade dig at slappe af. Vi skal huske at opdatere pakker, når vi tilføjer nye biblioteker eller servere, samtidig med at vi bibeholder bagudkompatibilitet med allerede implementeret modelkode.
Der er flere tilgange til, hvordan man gør dette. Forbered for eksempel flere ofte brugte biblioteker på forhånd og implementer dem i PROM. I Clouderas Hadoop-distribution bruger de normalt . Også nu i Hadoop er det muligt at løbe -containere. I nogle simple tilfælde er det muligt at levere koden sammen med pakken .
Banken tager sikkerheden ved at køre tredjepartskode meget alvorligt, så vi får mest muligt ud af de nye funktioner i Linux-kernen, hvor en proces kører i et isoleret miljø , kan du begrænse, for eksempel, adgang til netværket og den lokale disk, hvilket reducerer mulighederne for ondsindet kode markant. Dataområderne i hver afdeling er beskyttet og kun tilgængelige for ejerne af disse data. Platformen sikrer, at data fra et område kun kan nå et andet område gennem en datapubliceringsproces med kontrol på alle stadier fra adgang til kilder til landing af data i målbutiksfronten.
I år planlægger vi at færdiggøre MVP'en for lancering af modeller skrevet i Python/R/Java på Hadoop. Vi har sat os selv den ambitiøse opgave at lære at køre ethvert brugerdefineret miljø på Hadoop, for ikke at begrænse brugerne af vores platform på nogen måde.
Derudover, som det viste sig, er mange DS-specialister fremragende til matematik og statistik, laver seje modeller, men er ikke særligt velbevandrede i big data-transformationer, og de har brug for hjælp fra vores dataingeniører til at udarbejde træningsprøver. Vi besluttede at hjælpe vores kolleger og skabe praktiske moduler til standardtransformation og forberedelse af funktioner til modeller på Spark-motoren. Dette vil give dig mulighed for at bruge mere tid på at udvikle modeller og ikke vente på, at dataingeniører forbereder et nyt datasæt.
Vi ansætter folk med viden inden for forskellige områder: Linux og DevOps, Hadoop og Spark, Java og Spring, Scala og Akka, OpenShift og Kubernetes. Næste gang vil vi tale om modelbiblioteket, hvordan modellen går gennem livscyklussen i virksomheden, hvordan validering og implementering foregår.
Kilde: www.habr.com