Minden méretű vállalkozásban naponta felmerülnek ötletek és találkozók arról, hogy milyen további folyamatokat lehet automatizálni. De nemcsak az időt kell ráfordítani a modell létrehozására, hanem azt is értékelni és ellenőrizni kell, hogy a kapott eredmény nem véletlenszerű. A bevezetés után bármilyen modellt figyelemmel kell kísérni, és időben el kell végezni az ellenőrzéseket.
Ezek mind olyan lépések, amelyeken bármely cégnek át kell esnie, függetlenül a méretétől. Ha a Sberbank méretéről és örökölt rendszereiről beszélünk, a finomhangolások száma többszörösére nő. 2019 végére a Sberbank már több mint 2000 modellt használt. Nem elég csak egy modellt kidolgozni, integrálódni kell az ipari rendszerekkel, adatvitrinek készítése szükséges a modellek felépítéséhez, és biztosítani kell a működésének ellenőrzését a klaszterben.
Csapatunk a Sber.DS platformot fejleszti. Ez lehetővé teszi a gépi tanulás feladatainak megoldását, felgyorsítja a hipotézisek ellenőrzési folyamatát, alapvetően leegyszerűsíti a modellek fejlesztését és validálását, valamint ellenőrzi a modell működésének eredményét a PROM-ban.
Annak érdekében, hogy ne csapjam be az elvárásaikat, előre szeretném mondani, hogy ez a bejegyzés bevezető jellegű, és a Sber.DS platform alapkoncepciójáról beszél először. A modellek életciklusának történetét a létrehozástól a bevezetésig külön fogjuk bemutatni.
A Sber.DS több összetevőből áll, a legfontosabbak közé tartozik a könyvtár, a fejlesztési rendszer és a modellek végrehajtási rendszere.
A könyvtár ellenőrzi a modell életciklusát az ötlet megszületésétől a PROM-ba való bevezetéséig, a figyelés beállításáig és a kivonásig. A könyvtár sok lehetősége a szabályozó előírásaiból fakad, például a jelentések és a tanító- és validáló minták tárolásának követelményeiből. A lényegében ez a mi modelljeink nyilvántartása.
A fejlesztési rendszer a modellek és a validálási módszerek vizuális fejlesztésére szolgál. A kidolgozott modellek elsődleges validáción mennek keresztül, és a végrehajtási rendszerbe kerülnek a üzleti funkcióik ellátására. A végrehajtási rendszerben a modell figyelő üzemmódba állítható, hogy időszakosan elindítsa a validálási módszereket a működésének ellenőrzésére.
A rendszerben többféle csomópont található. Egyesek különféle adatforrásokhoz való csatlakozásra szolgálnak, míg mások a bemeneti adatok átalakítására és gazdagítására (címkézés) szolgálnak. Számos csomópont létezik különféle modellek létrehozásához és azok validálásához. A fejlesztő bármely forrástól adatokat tölthet le, átalakíthatja, szűrheti, vizualizálhatja az átmeneti adatokat, és részekre bonthatja azokat.
A platform emellett már kész modulokat is tartalmaz, amelyeket a projektterületre húzhatunk. Minden tevékenységet vizualizált interfészen keresztül végeznek. Gyakorlatilag a feladat megoldható egyetlen kód sor nélkül.
Ha a beépített lehetőségek nem elegendőek, a rendszer gyors saját modulok létrehozását is lehetővé teszi. Integrált fejlesztési módot hoztunk létre a segítségével, a "nulláról" új modulok létrehozói számára.
A Sber.DS architektúrája mikroszolgáltatásokon alapul. Sok vélemény van arról, hogy mi is az a mikroszolgáltatás. Néhányan azt gondolják, elegendő a monolitikus kód részekre bontása, de közben még mindig ugyanabba az adatbázisba nyúlnak. Nálunk a mikroszolgáltatásnak másik mikroszolgáltatással csak REST API-n keresztül kell kommunikálnia. Nincs közvetlen adatbázis-hozzáférés.
Arra törekszünk, hogy a szolgáltatások ne legyenek túl nagyok és nehezen mozgathatóak: egy példány nem fogyaszthat több mint 4-8 GB RAM-ot, és lehetőséget kell biztosítania a lekérdezések horizontális skálázására új példányok indításával. Minden szolgáltatás csak REST API-n keresztül kommunikál (). A szolgáltatásért felelős csapatnak meg kell őriznie az API visszafelé kompatibilitását az utolsó, azt használó kliensig.
Az alkalmazás magja Java nyelven készült, a Spring Framework használatával. A megoldást eredetileg gyors feltelepítésre tervezték felhőinfrastruktúrában, ezért az alkalmazás konténerizáló rendszer segítségével készült. (A platform folyamatosan fejlődik, mind a üzleti funkciók bővítése (új csatlakozók, AutoML hozzáadása), mind a technológiai hatékonyság terén.
Platformunk egyik „fő vonzereje”, hogy a vizuális felületen fejlesztett kódot a Sberbank modellvégrehajtó rendszerein bármilyen platformon futtathatjuk. Jelenleg már két rendszerünk van: az egyik Hadoop-on, a másik OpenShift-en (Docker). Ezen nem állunk meg, és integrációs modulokat hozunk létre a kód bármilyen infrastruktúrán való futtatására, beleértve az on-premise és felhő alapú megoldásokat is. A Sberbank ökoszisztémába való hatékony integrációs lehetőségek tekintetében tervezzük a meglévő végrehajtó környezetek támogatását is. A jövőben a megoldás rugalmasan beépíthető „dobozból” bármely szervezet bármely tájára.
Akik valaha próbálták támogatni a Hadoop-on Python-t futtató megoldásokat a PROM-ban, tudják, hogy nem elég egy felhasználói Python környezetet előkészíteni és eljuttatni minden adatcsomóponthoz. Az óriási mennyiségű C/C++ gépi tanulási könyvtár, amelyek Python modulokat használnak, nem engednek lazítani. Ne felejtsd el frissíteni a csomagokat új könyvtárak vagy szerverek hozzáadásakor, megőrizve a visszafelé kompatibilitást a már bevezetett modellkódokkal.
Több megközelítés létezik erre. Például előre felkészíthetjük a gyakran használt könyvtárakat és beépíthetjük őket a PROM-ba. A Cloudera Hadoop disztribúciójában ez általában a felhasználásával történik. Jelenleg a Hadoop-ban lehetőség nyílik a -konténerek indítására is. Néhány egyszerűbb esetben a kódot együtt szállíthatjuk a .
A bank nagyon komolyan veszi a külső kódok futtatásának biztonságát, ezért maximálisan kihasználjuk a Linux kernel új lehetőségeit, ahol a szigetelt környezetben futó folyamatok esetében a segítségével korlátozhatók a hálózati és helyi lemezhozzáférések, ami jelentősen csökkenti a rosszindulatú kódok hatását. Minden osztály adaterületei védettek és csak az adatok tulajdonosai férhetnek hozzájuk. A platform garantálja, hogy az egyik területről az adatok csak a publikálási folyamaton keresztül, a forrásokhoz való hozzáféréstől kezdve a célvitrinhez történő adatráhelyezésig kontrollálva juthatnak át.
Idén tervezzük befejezni az MVP-t, amelyben Python/R/Java nyelven fejlesztett modellek indítása történik Hadoopon. Ambiciózus célt tűztünk ki magunk elé, hogy megtanuljuk, hogyan indítsunk bármilyen felhasználói környezetet Hadoopon, hogy ezzel ne korlátozzuk platformunk felhasználóit.
Ezenkívül kiderült, hogy sok DS-szakértő remekül ismeri a matematikát és statisztikát, kiváló modelleket készít, de nem igazán ért a nagy adatok átalakításához, így szükségük van a data mérnökeink segítségére a tanulmányi minták előkészítéséhez. Elhatároztuk, hogy segítünk kollégáinknak, és kényelmes modulokat készítünk a tipikus átalakításhoz és a jellemzők előkészítéséhez a Spark-motorral készült modellekhez. Ez lehetővé teszi, hogy több időt szenteljenek a modellek fejlesztésére, anélkül, hogy várniuk kellene, amíg a data mérnökök elkészítik az új adatállományt.
Olyan emberek dolgoznak nálunk, akik különböző területeken rendelkeznek tudással: Linux és DevOps, Hadoop és Spark, Java és Spring, Scala és Akka, OpenShift és Kubernetes. A következő alkalommal a modellek könyvtáráról beszélünk, arról, hogyan halad át a modell életciklusa a vállalaton belül, hogyan zajlik a validálás és a bevezetés.
Forrás: habr.com
