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 det faktum att mycket tid kan läggas på att skapa en modell måste du lägga den på att utvärdera den och kontrollera att resultatet som erhålls inte är slumpmässigt. Efter implementering måste alla modeller övervakas och regelbundet kontrolleras.
Och det här är alla steg som måste genomföras i vilket företag som helst, oavsett storlek. Om vi pratar om omfattningen och arvet från Sberbank, ökar antalet finjusteringar avsevärt. I slutet av 2019 hade Sber redan använt mer än 2000 XNUMX modeller. Det räcker inte att bara utveckla en modell, det är nödvändigt att integrera med industriella system, utveckla datamarts för att bygga modeller och säkerställa kontroll över dess drift i klustret.
Vårt team utvecklar Sber.DS-plattformen. Det låter dig lösa maskininlärningsproblem, påskyndar processen att testa hypoteser, förenklar i princip processen att utveckla och validera modeller och kontrollerar också resultatet av modellen i PROM.
För att inte lura dina förväntningar vill jag på förhand säga att det här inlägget är ett inledande inlägg, och under skärningen, till att börja med, pratar vi om vad som i princip finns under huven på Sber.DS-plattformen. Vi kommer att berätta historien om modellens livscykel från skapande till implementering separat.
Sber.DS består av flera komponenter, de viktigaste är biblioteket, utvecklingssystemet och modellexekveringssystemet.
Biblioteket kontrollerar modellens livscykel från det att idén att utveckla den dyker upp till dess implementering i PROM, övervakning och avveckling. Många biblioteksmöjligheter dikteras av regulatoriska regler, till exempel rapportering och lagring av utbildnings- och valideringsprover. Detta är faktiskt ett register över alla våra modeller.
Utvecklingssystemet är designat för visuell utveckling av modeller och valideringstekniker. De utvecklade modellerna genomgår initial validering och levereras till exekveringssystemet för att utföra sina affärsfunktioner. I runtime-systemet kan modellen också placeras på en monitor i syfte att periodiskt lansera valideringstekniker för att övervaka dess funktion.
Det finns flera typer av noder i systemet. Vissa är designade för att ansluta till olika datakällor, andra är designade för att transformera källdata och berika den (markup). Det finns många noder för att bygga olika modeller och noder för att validera dem. Utvecklaren kan ladda data från vilken källa som helst, transformera, filtrera, visualisera mellanliggande data och dela upp den i delar.
Plattformen innehåller även färdiga moduler som kan dras och släppas på designområdet. Alla åtgärder utförs med hjälp av ett visualiserat gränssnitt. Faktum är att du kan lösa problemet utan en enda kodrad.
Om de inbyggda funktionerna inte räcker till ger systemet möjlighet att snabbt skapa egna moduler. Vi gjorde ett integrerat utvecklingsläge baserat på för dig som skapar nya moduler från grunden.
Arkitekturen för Sber.DS är byggd på mikrotjänster. Det finns många åsikter om vad mikrotjänster är. Vissa tror att det räcker med att dela upp den monolitiska koden i delar, men samtidigt går de fortfarande till samma databas. Vår mikrotjänst måste endast kommunicera med en annan mikrotjänst via REST API. Inga lösningar för att komma åt databasen direkt.
Vi försöker se till att tjänsterna inte blir väldigt stora och klumpiga: en instans ska inte förbruka mer än 4-8 gigabyte RAM och måste ge möjlighet att horisontellt skala förfrågningar genom att lansera nya instanser. Varje tjänst kommunicerar med andra endast via REST API (). Teamet som ansvarar för tjänsten måste hålla API:et bakåtkompatibelt tills den sista klienten som använder det.
Kärnan i applikationen är skriven i Java med hjälp av Spring Framework. Lösningen designades ursprungligen för snabb implementering i molninfrastrukturen, så applikationen byggdes med ett containersystem (). Plattformen utvecklas ständigt, både när det gäller att öka affärsfunktionaliteten (nya kontakter, AutoML tillkommer) och när det gäller teknisk effektivitet.
En av funktionerna i vår plattform är att vi kan köra kod utvecklad i ett visuellt gränssnitt på alla Sberbanks modellexekveringssystem. Nu finns det redan två av dem: en på Hadoop, den andra på OpenShift (Docker). Vi slutar inte där och skapar integrationsmoduler för att köra kod på vilken infrastruktur som helst, inklusive på plats och i molnet. När det gäller möjligheterna till effektiv integration i Sberbanks ekosystem planerar vi också att stödja arbetet med befintliga exekveringsmiljöer. I framtiden kan lösningen flexibelt integreras "out of the box" i alla landskap i 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 PROM vet att det inte räcker att förbereda och leverera en Python-användarmiljö till varje datanod. Det enorma antalet C/C++-bibliotek för maskininlärning som använder Python-moduler kommer inte att tillåta dig att vara lugn. Vi måste komma ihåg att uppdatera paket när vi lägger till nya bibliotek eller servrar, samtidigt som vi bibehåller bakåtkompatibilitet med redan implementerad modellkod.
Det finns flera sätt att göra detta. Förbered till exempel flera ofta använda bibliotek i förväg och implementera dem i PROM. I Clouderas Hadoop-distribution brukar de använda . Även nu i Hadoop är det möjligt att springa -behållare. I vissa enkla fall är det möjligt att leverera koden tillsammans med paketet .
Banken tar säkerheten med att köra tredjepartskod på största allvar, så vi får ut det mesta av de nya funktionerna i Linux-kärnan, där en process körs i en isolerad miljö , kan du begränsa, till exempel, åtkomst till nätverket och den lokala disken, vilket avsevärt minskar kapaciteten för skadlig kod. Dataområdena för varje avdelning är skyddade och tillgängliga endast för ägarna av dessa data. Plattformen säkerställer att data från ett område endast kan nå ett annat område genom en datapubliceringsprocess med kontroll i alla steg från åtkomst till källor till landning av data i målskyltfönstret.
I år planerar vi att slutföra MVP för lansering av modeller skrivna i Python/R/Java på Hadoop. Vi har satt oss den ambitiösa uppgiften att lära oss hur man kör valfri anpassad miljö på Hadoop, för att inte begränsa användarna av vår plattform på något sätt.
Dessutom, som det visade sig, är många DS-specialister utmärkta på matematik och statistik, gör coola modeller, men är inte så väl insatta i big data-transformationer, och de behöver hjälp av våra dataingenjörer för att förbereda utbildningsprover. Vi bestämde oss för att hjälpa våra kollegor och skapa bekväma moduler för standardtransformation och förberedelse av funktioner för modeller på Spark-motorn. Detta gör att du kan lägga mer tid på att utveckla modeller och inte vänta på att dataingenjörer ska förbereda en ny datamängd.
Vi anställer personer med kunskap inom olika områden: Linux och DevOps, Hadoop och Spark, Java och Spring, Scala och Akka, OpenShift och Kubernetes. Nästa gång ska vi prata om modellbiblioteket, hur modellen går igenom livscykeln inom företaget, hur validering och implementering sker.
Källa: will.com