Ideer og møter om hvilke andre prosesser som kan automatiseres oppstår i virksomheter av ulike størrelser hver dag. Men i tillegg til at det kan brukes mye tid på å lage en modell, må du bruke den på å evaluere den og sjekke at resultatet ikke er tilfeldig. Etter implementering må enhver modell overvåkes og kontrolleres med jevne mellomrom.
Og dette er alle stadiene du må gjennom i ethvert selskap, uansett størrelse. Hvis vi snakker om omfanget og arven til Sberbank, øker antallet finjusteringer eksponentielt. Ved utgangen av 2019 var mer enn 2000 modeller allerede brukt i Sberbank. Det er ikke nok bare å utvikle en modell, det er nødvendig å integrere med industrielle systemer, utvikle datamarts for å bygge modeller og sikre kontroll over driften på en klynge.
Teamet vårt utvikler Sber.DS-plattformen. Det lar deg løse maskinlæringsproblemer, fremskynder prosessen med å teste hypoteser, forenkler i prinsippet prosessen med å utvikle og validere modeller, og kontrollerer også resultatet av modellen i PROM.
For ikke å lure forventningene dine, vil jeg si på forhånd at dette innlegget er en introduksjon, og under snittet, for en start, blir det fortalt om hva som i utgangspunktet er under panseret på Sber.DS-plattformen. Vi vil fortelle historien om livssyklusen til en modell fra opprettelse til implementering separat.
Sber.DS består av flere komponenter, de viktigste er biblioteket, utviklingssystemet og modellutførelsessystemet.
Biblioteket kontrollerer livssyklusen til modellen fra det øyeblikk ideen om å utvikle den dukker opp til dens implementering i PROM, overvåking og dekommisjonering. Mange funksjoner i biblioteket er diktert av regulatorens regler, for eksempel rapportering og lagring av opplærings- og valideringsprøver. Faktisk er dette et register over alle våre modeller.
Utviklingssystemet er beregnet for visuell utvikling av modeller og valideringsmetoder. De utviklede modellene gjennomgår primær validering og leveres til utførelsessystemet for å utføre sine forretningsfunksjoner. I utførelsessystemet kan modellen også settes på skjermen for å periodisk lansere valideringsmetoder for å kontrollere driften.
Det er flere typer noder i systemet. Noen er designet for å koble til ulike datakilder, andre - for å transformere kildedataene og berike dem (markup). Det er mange noder for å bygge ulike modeller og noder for deres validering. Utvikleren kan laste data fra alle kilder, transformere, filtrere, visualisere mellomliggende data, dele dem opp i deler.
Plattformen inneholder også ferdige moduler som kan dras inn på prosjektområdet. Alle handlinger utføres ved hjelp av et visualisert grensesnitt. Faktisk kan du løse problemet uten en eneste linje med kode.
Hvis de innebygde egenskapene ikke er nok, gir systemet muligheten til raskt å lage dine egne moduler. Vi har laget en integrert utviklingsmodus basert på for de som lager nye moduler fra bunnen av.
Sber.DS-arkitekturen er bygget på mikrotjenester. Det er mange meninger om hva mikrotjenester er. Noen tror at det er nok å dele den monolittiske koden i deler, men de går fortsatt til den samme databasen. Vår mikrotjeneste må kun kommunisere med en annen mikrotjeneste via REST API. Ingen løsninger for å få direkte tilgang til databasen.
Vi prøver å forhindre at tjenester blir veldig store og trege: en enkelt forekomst skal ikke forbruke mer enn 4-8 gigabyte RAM og skal kunne skalere forespørsler horisontalt ved å lansere nye forekomster. Hver tjeneste kommuniserer kun med andre via REST API (). Teamet som er ansvarlig for tjenesten er pålagt å holde API-en bakoverkompatibel frem til siste klient som bruker den.
Kjernen i applikasjonen er skrevet i Java ved hjelp av Spring Framework. Løsningen ble opprinnelig designet for rask distribusjon i skyinfrastrukturen, så applikasjonen bygges ved hjelp av et containeriseringssystem (). Plattformen er i stadig utvikling, både når det gjelder å øke forretningsfunksjonaliteten (nye koblinger, AutoML kommer til), og når det gjelder teknologisk effektivitet.
En av "brikkene" til plattformen vår er at vi kan kjøre koden utviklet i det visuelle grensesnittet på et hvilket som helst Sberbank-modellutførelsessystem. Nå er det allerede to av dem: en på Hadoop, den andre på OpenShift (Docker). Vi stopper ikke der og lager integrasjonsmoduler for å kjøre kode på hvilken som helst infrastruktur, inkludert på stedet og i skyen. Når det gjelder mulighetene for effektiv integrering i Sberbank-økosystemet, planlegger vi også å støtte arbeid med eksisterende kjøretidsmiljøer. I fremtiden kan løsningen integreres fleksibelt "ut av boksen" i ethvert landskap i enhver organisasjon.
De som noen gang har prøvd å vedlikeholde en løsning som kjører Python på Hadoop i PROM vet at det ikke er nok å forberede og levere et tilpasset pythonmiljø til hver dataanode. Et stort antall C / C ++-biblioteker for maskinlæring som bruker Python-moduler vil ikke la deg hvile i fred. Vi må ikke glemme å oppdatere pakker når vi legger til nye biblioteker eller servere, samtidig som vi opprettholder bakoverkompatibilitet med allerede implementert modellkode.
Det er flere måter å gjøre dette på. Klargjør for eksempel flere ofte brukte biblioteker på forhånd og implementer dem i PROM. Clouderas Hadoop-distribusjon bruker vanligvis . Også nå i Hadoop er det mulighet for å løpe - containere. I noen enkle tilfeller er det mulig å levere koden sammen med pakken .
Banken tar sikkerheten ved å kjøre tredjepartskode svært alvorlig, så vi får mest mulig ut av de nye funksjonene i Linux-kjernen, der en prosess kjører i et isolert miljø , kan du begrense, for eksempel, tilgang til nettverket og den lokale disken, noe som i stor grad reduserer muligheten for ondsinnet kode. Hver avdelings dataområder er beskyttet og kun tilgjengelig for eierne av disse dataene. Plattformen sikrer at data fra ett domene kun kan komme inn i et annet domene gjennom en datapubliseringsprosess med kontroll på alle stadier fra tilgang til kilder til landing av data i målmarkedet.
I år planlegger vi å fullføre MVP for løpende modeller skrevet i Python/R/Java på Hadoop. Vi satte oss den ambisiøse oppgaven å lære å kjøre et hvilket som helst brukermiljø på Hadoop, for ikke å begrense brukerne av plattformen vår på noen måte.
I tillegg, som det viste seg, er mange DS-spesialister gode på matematikk og statistikk, lager kule modeller, men er ikke så godt kjent med big data-transformasjoner, og de trenger hjelp fra våre dataingeniører for å utarbeide treningsprøver. Vi bestemte oss for å hjelpe kollegene våre og lage praktiske moduler for typisk transformasjon og klargjøring av funksjoner for modeller på Spark-motoren. Dette vil gi mer tid til å bli viet til å utvikle modeller og ikke vente på at dataingeniører skal utarbeide et nytt datasett.
Vi har folk med kunnskap innen ulike områder: Linux og DevOps, Hadoop og Spark, Java og Spring, Scala og Akka, OpenShift og Kubernetes. Neste gang skal vi snakke om modellbiblioteket, hvordan modellen går gjennom livssyklusen innad i bedriften, hvordan validering og implementering foregår.
Kilde: www.habr.com