Idetë dhe takimet se cilat procese të tjera mund të automatizohen lindin çdo ditë në biznese të madhësive të ndryshme. Por përveç faktit që mund të shpenzohet shumë kohë për krijimin e një modeli, duhet ta shpenzoni duke e vlerësuar atë dhe duke kontrolluar që rezultati të mos jetë i rastësishëm. Pas zbatimit, çdo model duhet të monitorohet dhe kontrollohet periodikisht.
Dhe këto janë të gjitha fazat që duhet të kaloni në çdo kompani, pavarësisht nga madhësia e saj. Nëse po flasim për shkallën dhe trashëgiminë e Sberbank, numri i rregullimeve të imta rritet në mënyrë eksponenciale. Deri në fund të vitit 2019, Sberbank kishte përdorur tashmë më shumë se 2000 modele. Nuk mjafton vetëm zhvillimi i një modeli, është i nevojshëm integrimi me sistemet industriale, zhvillimi i të dhënave për modelet e ndërtimit dhe sigurimi i kontrollit të funksionimit të tij në një grup.
Ekipi ynë po zhvillon platformën Sber.DS. Kjo ju lejon të zgjidhni problemet e mësimit të makinerive, përshpejton procesin e testimit të hipotezave, në parim thjeshton procesin e zhvillimit dhe vërtetimit të modeleve, dhe gjithashtu kontrollon rezultatin e modelit në PROM.
Për të mos mashtruar pritjet tuaja, dua të them paraprakisht se ky postim është një hyrje, dhe nën prerje, për fillim, tregohet se çfarë është në thelb nën kapuçin e platformës Sber.DS. Ne do të tregojmë veçmas historinë rreth ciklit jetësor të një modeli nga krijimi në zbatim.
Sber.DS përbëhet nga disa komponentë, ku kryesorët janë biblioteka, sistemi i zhvillimit dhe sistemi i ekzekutimit të modelit.
Biblioteka kontrollon ciklin jetësor të modelit që nga momenti kur shfaqet ideja për zhvillimin e tij deri në zbatimin e tij në PROM, monitorimin dhe nxjerrjen nga përdorimi. Shumë veçori të bibliotekës diktohen nga rregullat e rregullatorit, për shembull, raportimi dhe ruajtja e mostrave të trajnimit dhe vërtetimit. Në fakt, ky është një regjistër i të gjitha modeleve tona.
Sistemi i zhvillimit ka për qëllim zhvillimin vizual të modeleve dhe metodave të vërtetimit. Modelet e zhvilluara i nënshtrohen vlefshmërisë parësore dhe i dorëzohen sistemit të ekzekutimit për të kryer funksionet e tyre të biznesit. Gjithashtu, në sistemin e ekzekutimit, modeli mund të vendoset në monitor për të nisur periodikisht metodat e vlefshmërisë për të kontrolluar funksionimin e tij.
Ekzistojnë disa lloje të nyjeve në sistem. Disa janë krijuar për t'u lidhur me burime të ndryshme të të dhënave, të tjerët - për të transformuar të dhënat burimore dhe për t'i pasuruar ato (shënjimi). Ka shumë nyje për ndërtimin e modeleve të ndryshme dhe nyje për vërtetimin e tyre. Zhvilluesi mund të ngarkojë të dhëna nga çdo burim, të transformojë, filtrojë, vizualizojë të dhëna të ndërmjetme, t'i ndajë ato në pjesë.
Platforma përmban gjithashtu module të gatshme që mund të tërhiqen në zonën e projektit. Të gjitha veprimet kryhen duke përdorur një ndërfaqe të vizualizuar. Në fakt, ju mund ta zgjidhni problemin pa një rresht të vetëm kodi.
Nëse aftësitë e integruara nuk janë të mjaftueshme, atëherë sistemi ofron mundësinë për të krijuar shpejt modulet tuaja. Ne kemi bërë një mënyrë zhvillimi të integruar bazuar në për ata që krijojnë module të reja nga e para.
Arkitektura Sber.DS është ndërtuar mbi mikroshërbime. Ka shumë mendime se çfarë janë mikroshërbimet. Disa njerëz mendojnë se është e mjaftueshme për të ndarë kodin monolit në pjesë, por ata ende shkojnë në të njëjtën bazë të dhënash. Mikroshërbimi ynë duhet të komunikojë me një mikroshërbim tjetër vetëm nëpërmjet API-së REST. Nuk ka rrugëdalje për të hyrë drejtpërdrejt në bazën e të dhënave.
Ne përpiqemi që shërbimet të mos bëhen shumë të mëdha dhe të ngadalta: një shembull i vetëm nuk duhet të konsumojë më shumë se 4-8 gigabajt RAM dhe duhet të jetë në gjendje të shkallëzojë kërkesat horizontalisht duke lëshuar shembuj të rinj. Çdo shërbim komunikon me të tjerët vetëm nëpërmjet API-së REST (). Ekipi përgjegjës për shërbimin kërkohet të mbajë API-në të pajtueshme deri në klientin e fundit që e përdor atë.
Bërthama e aplikacionit është shkruar në Java duke përdorur Spring Framework. Zgjidhja fillimisht u krijua për vendosje të shpejtë në infrastrukturën cloud, kështu që aplikacioni është ndërtuar duke përdorur një sistem kontejnerizimi (). Platforma po evoluon vazhdimisht, si në drejtim të rritjes së funksionalitetit të biznesit (shtohen lidhës të rinj, AutoML), ashtu edhe në aspektin e efikasitetit teknologjik.
Një nga "çipet" e platformës sonë është se ne mund të ekzekutojmë kodin e zhvilluar në ndërfaqen vizuale në çdo sistem ekzekutimi të modelit Sberbank. Tani ka dy prej tyre: njëra në Hadoop, tjetra në OpenShift (Docker). Ne nuk ndalemi këtu dhe krijojmë module integrimi për të ekzekutuar kodin në çdo infrastrukturë, duke përfshirë në premisë dhe në cloud. Për sa i përket mundësive për integrim efektiv në ekosistemin Sberbank, ne gjithashtu planifikojmë të mbështesim punën me mjediset ekzistuese të funksionimit. Në të ardhmen, zgjidhja mund të integrohet në mënyrë fleksibël "jashtë kutisë" në çdo peizazh të çdo organizate.
Ata që janë përpjekur ndonjëherë të mbajnë një zgjidhje që ekzekuton Python në Hadoop në PROM, e dinë se nuk mjafton të përgatitësh dhe të dorëzosh një mjedis të personalizuar python në secilën nyje të dhënash. Një numër i madh bibliotekash C / C ++ për mësimin e makinerive që përdorin module Python nuk do t'ju lënë të pushoni në paqe. Nuk duhet të harrojmë të përditësojmë paketat kur shtojmë biblioteka ose serverë të rinj, duke ruajtur përputhshmërinë e prapambetur me kodin e modelit tashmë të implementuar.
Ka disa qasje se si ta bëni këtë. Për shembull, përgatitni paraprakisht disa biblioteka të përdorura shpesh dhe zbatoni ato në PROM. Shpërndarja Hadoop e Cloudera zakonisht përdor . Gjithashtu tani në Hadoop ka një mundësi për të kandiduar - kontejnerë. Në disa raste të thjeshta është e mundur të dorëzohet kodi së bashku me paketën .
Banka e merr shumë seriozisht sigurinë e ekzekutimit të kodit të palës së tretë, kështu që ne shfrytëzojmë në maksimum veçoritë e reja të kernelit Linux, ku një proces funksionon në një mjedis të izoluar , mund të kufizoni, për shembull, aksesin në rrjet dhe në diskun lokal, gjë që redukton shumë mundësinë e kodit me qëllim të keq. Zonat e të dhënave të çdo departamenti janë të mbrojtura dhe të disponueshme vetëm për pronarët e atyre të dhënave. Platforma siguron që të dhënat nga një domen mund të futen në një domen tjetër vetëm përmes një procesi publikimi të të dhënave me kontroll në të gjitha fazat nga qasja në burime deri te vendosja e të dhënave në mars të synuar.
Këtë vit ne planifikojmë të përfundojmë MVP-në e modeleve të ekzekutimit të shkruara në Python/R/Java në Hadoop. Ne i vendosëm vetes detyrën ambicioze për të mësuar se si të ekzekutojmë çdo mjedis përdoruesi në Hadoop, në mënyrë që të mos kufizojmë përdoruesit e platformës sonë në asnjë mënyrë.
Për më tepër, siç doli, shumë specialistë të DS janë të shkëlqyeshëm në matematikë dhe statistika, bëjnë modele të lezetshme, por nuk janë shumë të aftë për transformimet e të dhënave të mëdha dhe ata kanë nevojë për ndihmën e inxhinierëve tanë të të dhënave për të përgatitur mostra trajnimi. Ne vendosëm të ndihmojmë kolegët tanë dhe të krijojmë module të përshtatshme për transformimin tipik dhe përgatitjen e veçorive për modelet në motorin Spark. Kjo do të lejojë që t'i kushtohet më shumë kohë zhvillimit të modeleve dhe të mos pritet që inxhinierët e të dhënave të përgatisin një grup të ri të dhënash.
Ne kemi njerëz me njohuri në fusha të ndryshme: Linux dhe DevOps, Hadoop dhe Spark, Java dhe Spring, Scala dhe Akka, OpenShift dhe Kubernetes. Herën tjetër do të flasim për bibliotekën e modeleve, si e kalon modeli ciklin e jetës brenda kompanisë, si bëhet vlefshmëria dhe zbatimi.
Burimi: www.habr.com