A különböző méretű vállalkozásokban nap mint nap felmerülnek ötletek és találkozások arról, hogy milyen egyéb folyamatokat lehetne automatizálni. De amellett, hogy sok időt el lehet fordítani egy modell létrehozására, azt ki kell töltenie annak értékelésével és annak ellenőrzésével, hogy a kapott eredmény nem véletlenszerű. A megvalósítás után minden modellt felügyelni és időszakonként ellenőrizni kell.
És ezek mind azok a szakaszok, amelyeket minden cégnél teljesíteni kell, mérettől függetlenül. Ha a Sberbank léptékéről és örökségéről beszélünk, a finomhangolások száma jelentősen megnő. 2019 végéig az Sber már több mint 2000 modellt használt. Nem elég egy modellt egyszerűen kidolgozni, integrálni kell az ipari rendszerekkel, ki kell dolgozni a modellek felépítéséhez szükséges adatpiacokat, és biztosítani kell a klaszteren a működésének vezérlését.
Csapatunk a Sber.DS platform fejlesztésén dolgozik. Lehetővé teszi a gépi tanulási problémák megoldását, felgyorsítja a hipotézisek tesztelésének folyamatát, elvileg leegyszerűsíti a modellek fejlesztésének és érvényesítésének folyamatát, valamint a modell eredményét is vezérli a PROM-ban.
Annak érdekében, hogy ne tévesszen meg várakozásait, előre szeretném elmondani, hogy ez a bejegyzés egy bevezető, és a vágás alatt először arról beszélünk, hogy elvileg mi van a Sber.DS platform motorháztetője alatt. Külön elmeséljük a modell életciklusát a létrehozástól a megvalósításig.
A Sber.DS több összetevőből áll, amelyek közül a legfontosabb a könyvtár, a fejlesztőrendszer és a modell-végrehajtási rendszer.
A könyvtár irányítja a modell életciklusát a fejlesztési ötlet megjelenésétől a PROM-ban való megvalósításig, a monitorozásig és a leszerelésig. Számos könyvtári funkciót a szabályozó szabályok határoznak meg, például a képzési és érvényesítési minták jelentését és tárolását. Valójában ez az összes modellünk regisztere.
A fejlesztő rendszert modellek és validációs technikák vizuális fejlesztésére tervezték. A kifejlesztett modellek kezdeti érvényesítésen esnek át, és a végrehajtó rendszerbe kerülnek az üzleti funkcióik ellátásához. A futásidejű rendszerben a modell egy monitoron is elhelyezhető abból a célból, hogy rendszeres időközönként validálási technikákat indítson a működésének figyelésére.
A rendszerben többféle csomópont található. Egyeseket arra terveztek, hogy különféle adatforrásokhoz kapcsolódjanak, mások a forrásadatok átalakítására és gazdagítására szolgálnak (jelölés). Számos csomópont létezik a különböző modellek felépítésére, és csomópontok ezek érvényesítésére. A fejlesztő bármilyen forrásból betöltheti az adatokat, átalakíthatja, szűrheti, megjelenítheti a közbenső adatokat, és részekre bonthatja azokat.
A platform kész modulokat is tartalmaz, amelyek a tervezési területre húzhatók és ejthetők. Minden műveletet egy vizualizált felület segítségével hajtanak végre. Valójában egyetlen kódsor nélkül is megoldhatja a problémát.
Ha a beépített képességek nem elegendőek, a rendszer lehetővé teszi a saját modulok gyors létrehozását. alapján készítettünk egy integrált fejlesztési módot azoknak, akik a semmiből készítenek új modulokat.
A Sber.DS architektúrája mikroszolgáltatásokra épül. Sok vélemény létezik a mikroszolgáltatásokról. Vannak, akik úgy gondolják, hogy elég a monolitikus kódot részekre bontani, ugyanakkor mégis ugyanabba az adatbázisba mennek. Mikroszolgáltatásunknak csak REST API-n keresztül kell kommunikálnia egy másik mikroszolgáltatással. Nincs megoldás az adatbázis közvetlen elérésére.
Arra törekszünk, hogy a szolgáltatások ne legyenek túl nagyok és ügyetlenek: egy példány nem fogyaszthat 4-8 gigabájt RAM-nál többet, és új példányok indításával biztosítania kell a kérések vízszintes skálázását. Minden szolgáltatás csak a REST API-n keresztül kommunikál másokkal (). A szolgáltatásért felelős csapat köteles az API-t visszafelé kompatibilisnek tartani az utolsó kliensig, amely azt használja.
Az alkalmazás magja Java nyelven íródott a Spring Framework segítségével. A megoldást eredetileg a felhő infrastruktúrában történő gyors telepítésre tervezték, így az alkalmazás konténerrendszer segítségével készült (). A platform folyamatosan fejlődik, mind az üzleti funkcionalitás növelése (új csatlakozók, AutoML-el), mind a technológiai hatékonyság szempontjából.
Platformunk egyik jellemzője, hogy vizuális felületen fejlesztett kódot futtathatunk bármely Sberbank modell-végrehajtási rendszeren. Most már kettő van belőlük: az egyik a Hadoop-on, a másik az OpenShift-en (Docker). Nem állunk meg itt, és integrációs modulokat hozunk létre a kód futtatásához bármilyen infrastruktúrán, beleértve a helyszíni és a felhőt is. A Sberbank ökoszisztémába való hatékony integráció lehetőségeivel kapcsolatban a meglévő végrehajtási környezetekkel való munka támogatását is tervezzük. A jövőben a megoldás rugalmasan integrálható „dobozból” bármely szervezet bármely környezetébe.
Azok, akik próbáltak már olyan megoldást támogatni, amely a Hadoopon Python-t futtat a PROM-ban, tudja, hogy nem elég egy Python felhasználói környezetet előkészíteni és eljuttatni minden egyes adatcsomóponthoz. A Python-modulokat használó, gépi tanuláshoz használható C/C++ könyvtárak hatalmas száma nem teszi lehetővé a nyugalmat. Emlékeznünk kell a csomagok frissítésére új könyvtárak vagy kiszolgálók hozzáadásakor, miközben meg kell őriznünk a visszafelé kompatibilitást a már megvalósított modellkóddal.
Ennek több megközelítése is létezik. Például készítsen előre több gyakran használt könyvtárat, és implementálja azokat a PROM-ban. A Cloudera Hadoop disztribúciójában általában használják . Most már a Hadoopban is futhat - konténerek. Néhány egyszerű esetben lehetőség van a kód kézbesítése a csomaggal együtt .
A bank nagyon komolyan veszi a harmadik féltől származó kód futtatásának biztonságát, ezért a legtöbbet hozzuk ki a Linux kernel új szolgáltatásaiból, ahol egy folyamat elszigetelt környezetben fut. , korlátozhatja például a hálózathoz és a helyi lemezhez való hozzáférést, ami jelentősen csökkenti a rosszindulatú kódok képességeit. Az egyes részlegek adatterületei védettek, és csak ezen adatok tulajdonosai férhetnek hozzá. A platform biztosítja, hogy az egyik területről származó adatok csak egy olyan adatközzétételi folyamaton keresztül juthassanak el egy másik területre, amely a forrásokhoz való hozzáféréstől az adatok cél kirakatba való eljutásáig minden szakaszban ellenőrzés alatt áll.
Idén tervezzük befejezni a Python/R/Java nyelven írt modellek Hadoop-on való elindításának MVP-jét. Azt az ambiciózus feladatot tűztük ki magunk elé, hogy megtanuljuk, hogyan kell bármilyen egyéni környezetet futtatni a Hadoop-on, hogy ne korlátozzuk platformunk felhasználóit.
Ezen kívül, mint kiderült, sok DS szakember kiválóan ért a matematikához és a statisztikához, menő modelleket készít, de nem túl jártas a big data transzformációiban, és adatmérnökeink segítségére van szükségük a képzési minták elkészítéséhez. Úgy döntöttünk, hogy segítünk kollégáinknak, és kényelmes modulokat hozunk létre a Spark motoron futó modellek szabványos átalakításához és jellemzőinek előkészítéséhez. Ez lehetővé teszi, hogy több időt töltsön modellek fejlesztésével, és ne várja meg, amíg az adatmérnökök elkészítenek egy új adatkészletet.
Különböző területeken jártas embereket alkalmazunk: Linux és DevOps, Hadoop és Spark, Java és Spring, Scala és Akka, OpenShift és Kubernetes. Legközelebb a modellkönyvtárról fogunk beszélni, arról, hogy a modell hogyan megy végig a vállalaton belüli életcikluson, hogyan történik a validáció és az implementáció.
Forrás: will.com