Idéer och möten om vilka andra processer som kan automatiseras uppstÄr i företag av olika storlekar varje dag. Men förutom att mycket tid kan gÄ Ät till att skapa en modell, mÄste man ocksÄ investera tid i att utvÀrdera den och kontrollera att den erhÄllna resultaten inte Àr slumpmÀssiga. Efter implementeringen mÄste varje modell övervakas och kontrolleras periodiskt.
Och detta Àr alla steg som mÄste genomgÄs i vilket företag som helst, oavsett dess storlek. NÀr vi talar om storleken och legacy-systemen hos Sberbank ökar antalet finjusteringar mÄngfalt. I slutet av 2019 anvÀndes redan över 2000 modeller i Sber. Det rÀcker inte med att bara utveckla en modell; det Àr nödvÀndigt att integrera med industriella system, utveckla datavitriner för att bygga modeller, och sÀkerstÀlla kontroll över modellens prestanda i klustret.
VÄrt team utvecklar plattformen Sber.DS. Den gör det möjligt att lösa problem med maskininlÀrning, pÄskyndar processen för hypotesprövning, förenklar i allmÀnhet utvecklings- och valideringsprocessen för modeller samt kontrollerar resultatet av modellens arbete i PROB.
För att inte lura era förvÀntningar vill jag redan nu sÀga att detta inlÀgg Àr en introduktion, och nedan berÀttas först om vad som egentligen finns under huven av plattformen Sber.DS. BerÀttelsen om modellens livscykel frÄn skapelse till implementering kommer vi att berÀtta separat.
Sber.DS bestÄr av flera komponenter, dÀr nyckelelementen Àr bibliotek, utvecklingssystem och system för modellgenomförande.
Biblioteket kontrollerar livscykeln för modellen frÄn idén till utveckling, implementering i PROB, övervakning och avveckling. MÄnga av bibliotekets funktioner dikteras av regulatorernas regler, sÄsom rapportering och lagring av utbildnings- och valideringsdata. I praktiken Àr detta ett register över alla vÄra modeller.
Utvecklingssystemet Àr avsett för visuell utveckling av modeller och valideringsmetoder. De utvecklade modellerna genomgÄr en initial validering och levereras till körsystemet för att utföra sina affÀrsfunktioner. I körsystemet kan modellen ocksÄ stÀllas in pÄ en skÀrm för regelbunden körning av valideringsmetoder för att övervaka dess funktion.
Systemet har flera typer av noder. Vissa Àr avsedda för att koppla upp mot olika datakÀllor, andra för att transformera rÄdata och berika dem (tagga). Det finns mÄnga noder för att bygga olika modeller och noder för deras validering. Utvecklaren kan ladda ner data frÄn valfria kÀllor, omformatera, filtrera och visualisera mellanliggande data, samt dela upp dem i delar.
Plattformen innehÄller Àven fÀrdiga moduler som kan dras och slÀppas pÄ projektomrÄdet. Alla ÄtgÀrder utförs med hjÀlp av ett visualiserat grÀnssnitt. Det Àr faktiskt möjligt att lösa uppgiften utan en enda rad kod.
Om de inbyggda funktionerna inte rÀcker till, erbjuder systemet möjlighet att snabbt skapa sina egna moduler. Vi har skapat ett lÀge för integrerad utveckling baserat pÄ för dem som skapar nya moduler "frÄn grunden".
Sber.DS-arkitekturen Àr byggd pÄ mikrotjÀnster. Det finns mÄnga Äsikter om vad mikrotjÀnster Àr. Vissa anser att det Àr tillrÀckligt att dela upp monolitisk kod i delar, men de arbetar fortfarande med samma databas. VÄr mikrotjÀnst mÄste kommunicera med en annan mikrotjÀnst endast via REST API. Ingen direkt Ätkomst till databasen Àr tillÄten.
Vi strÀvar efter att se till att tjÀnsterna inte blir för stora och klumpiga: en instans bör inte konsumera mer Àn 4-8 gigabyte RAM och mÄste möjliggöra horisontell skalning av begÀrningar genom att starta nya instanser. Varje tjÀnst kommunicerar med andra endast via REST API (). Teamet som ansvarar för tjÀnsten Àr skyldig att behÄlla bakÄtkompatibiliteten för API:et till den senaste klienten som anvÀnder det.
ApplikationskÀrnan Àr skriven i Java med hjÀlp av Spring Framework. Lösningen designades ursprungligen för snabb distribatering i molninfrastruktur, dÀrför Àr applikationen byggd med hjÀlp av ett containeriseringssystem (). Plattformen utvecklas stÀndigt, bÄde nÀr det gÀller att öka affÀrsfunktionaliteten (nya anslutningar, AutoML lÀggs till) och nÀr det gÀller teknisk effektivitet.
En av vÄra plattformsunika funktioner Àr att vi kan köra kod utvecklad i det visuella grÀnssnittet pÄ vilket system som helst för Sberbanks modellkörning. Just nu finns det tvÄ: en pÄ Hadoop och en annan pÄ OpenShift (Docker). Vi stannar inte hÀr utan skapar integrationsmoduler för att köra kod pÄ vilken infrastruktur som helst, inklusive on-premise och i molnet. NÀr det gÀller möjligheterna för effektiv integrering i Sberbanks ekosystem planerar vi ocksÄ att stödja arbete med befintliga körmiljöer. I framtiden kan lösningen flexibelt integreras "rakt ur lÄdan" i vilket landskap som helst av vilken organisation som helst.
De som nÄgon gÄng har försökt stödja en lösning som kör Python pÄ Hadoop i PROG vet att det handlar om mer Àn att bara förbereda och leverera anvÀndarmiljön för Python till varje datanod. En stor mÀngd C/C++-bibliotek för maskininlÀrning som anvÀnder Python-moduler ger dig ingen ro. Man mÄste ocksÄ komma ihÄg att uppdatera paketen nÀr nya bibliotek eller servrar tillkommer och behÄlla bakÄtkompatibilitet med redan implementerad kod för modeller.
Det finns flera metoder för hur man gör detta. Till exempel kan man förbereda nÄgra vanliga bibliotek och implementera dem i PROG. I Hadoop-distributionen frÄn Cloudera anvÀnds vanligtvis . Dessutom finns det nu möjlighet att köra -containrar i Hadoop. I vissa enkla fall kan man leverera koden tillsammans med paketet .
Banken Àr mycket seriös nÀr det gÀller sÀkerheten för att köra tredjepartskod, dÀrför utnyttjar vi i största möjliga utstrÀckning de nya möjligheterna i Linux-kÀrnan, dÀr processen körs i en isolerad miljö , kan begrÀnsa, till exempel, Ätkomst till nÀtverket och lokala diskar, vilket avsevÀrt minskar möjligheterna för skadlig kod. DataomrÄdena för varje avdelning Àr skyddade och endast tillgÀngliga för Àgarna av dessa data. Plattformen garanterar att data frÄn ett omrÄde kan nÄ ett annat omrÄde, endast genom datapubliceringsprocessen med kontroll vid alla steg frÄn Ätkomst till kÀllor till landning av data i mÄlvitrinen.
I Är planerar vi att avsluta MVP-lanseringen av modeller skrivna i Python/R/Java pÄ Hadoop. Vi har satt oss en ambitiös uppgift att lÀra oss att köra vilken anvÀndarmiljö som helst pÄ Hadoop, för att inte begrÀnsa anvÀndarna av vÄr plattform.
Dessutom visar det sig att mÄnga data scientist-specialister Àr utmÀrkta pÄ matematik och statistik, skapar fantastiska modeller, men inte Àr sÄ kunniga i transformationer av stora data, och de behöver hjÀlp av vÄra dataingenjörer för att förbereda trÀningsdataset. Vi har beslutat att hjÀlpa vÄra kollegor och skapa anvÀndarvÀnliga moduler för standardtransformation och beredning av funktioner för modeller pÄ Spark-motorn. Detta gör att mer tid kan Àgnas Ät utvecklingen av modeller och att man inte behöver vÀnta pÄ att dataingenjörerna ska förbereda en ny dataset.
Vi har mÀnniskor med kunskaper inom olika omrÄden: Linux och DevOps, Hadoop och Spark, Java och Spring, Scala och Akka, OpenShift och Kubernetes. NÀsta gÄng kommer vi att berÀtta om modellbiblioteket, hur en modell gÄr igenom livscykeln inom företaget och hur validering och implementering gÄr till.
KĂ€lla: habr.com
