Ide të reja dhe takime mbi proceset që mund të automatizohen shfaqen çdo ditë në biznese të ndryshme. Por, përveçse merr shumë kohë për të krijuar një model, është e nevojshme të investohet kohë në vlerësimin dhe verifikimin e rezultateve për të siguruar që ato nuk janë rastësore. Pas zbatimit, çdo model duhet të monitorohet dhe të kontrollohet në mënyrë periodike.
Dhe këto janë të gjitha etapa që duhet të kalohen në çdo kompani, pavarësisht nga madhësia e saj. Nëse flasim për shkallën dhe trashëgiminë e Sberbank, numri i konfigurimeve delikate rritet shumëfish. Deri në fund të vitit 2019, në Sber ishin përdorur më shumë se 2000 modele. Nuk mjafton thjesht të krijoni një model, është e nevojshme të integroheni me sistemet industriale, të zhvilloni vitrina të dhënash për ndërtimin e modeleve dhe të siguroheni për kontrollin e funksionimit të saj në klaster.
Ekipa jonë po zhvillon platformën Sber.DS. Ajo mundëson zgjidhjen e problemeve të mësimit të makinerive, përshpejton procesin e verifikimit të hipotezave, e thjeshton në përgjithësi procesin e zhvillimit dhe validimit të modeleve, si dhe kontrollon rezultatin e punës së modelit në PRO.M.
Për të mos e zhgënjyer pritshmërinë tuaj, dua të theksoj paraprakisht se ky postim është hyrës, dhe më poshtë discutohet për atë që është në thelb platforma Sber.DS. Historinë e ciklit të jetës së modelit nga krijimi deri te implementimi do ta tregojmë veçmas.
Sber.DS përbëhet nga disa komponentë, ndër të cilët kyç janë biblioteka, sistemi i zhvillimit dhe sistemi i ekzekutimit të modeleve.
Biblioteka kontrollon ciklin e jetës së modelit nga momenti i ideimit për zhvillim deri te implementimi në PROM, vendosja në monitorim dhe tërheqja nga përdorimi. Shumë mundësi të bibliotekës janë të diktuara nga rregulloret e autoriteteve, për shembull, raportimi dhe ruajtja e grupeve të trajnimit dhe validimit. Në fakt, kjo është një regjistër i të gjitha modeleve tona.
Sistemi i zhvillimit është i destinuar për zhvillimin vizual të modeleve dhe metodologjive të validimit. Modelet e zhvilluara kalojnë një verifikim fillestar dhe dërgohen në sistemin e ekzekutimit për të realizuar funksionet e tyre të biznesit. Po ashtu, në sistemin e ekzekutimit, modeli mund të vendoset në monitor për qëllimin e realizimit periodik të metodologjive të validimit për kontrollin e punës së tij.
Sistemi ka disa tipe nyjesh. Disa janë të destinuara për t'u lidhur me burime të ndryshme të të dhënave, të tjera për të transformuar të dhënat e burimit dhe për ta pasuruar ato (etiketim). Ka shumë nyje për ndërtimin e modeleve të ndryshme dhe nyje për validimin e tyre. Zhvilluesi mund të ngarkojë të dhënat nga çdo burim, t'i transformojë, t'i filtrojë, të vizualizojë të dhënat ndërmjetëse dhe t'i ndajë ato në pjesë.
Gjithashtu, platforma përmban modulet e gatshme, të cilat mund të tërhiqen në zonën e projektit. Të gjitha veprimet kryhen duke përdorur një ndërfaqe të vizualizuar. Në fakt, mund të zgjidhni problemin pa shkruar asnjë rresht kod.
Nëse mundësitë e ndërtuara nuk janë të mjaftueshme, sistemi ofron mundësinë për krijimin e shpejtë të moduleve tuaja. Ne e kemi bërë modalitetin e zhvillimit të integruar në bazë të për ata që krijojnë module të reja "nga e para".
Arkitektura Sber.DS është ndërtuar mbi mikrosisteme. Ka shumë mendime se çfarë janë mikrosistemet. Disa mendojnë se është e mjaftueshme të ndajmë kodin monolit në pjesë, por ata vazhdojnë të përdorin të njëjtën bazë të të dhënave. Në sistemin tonë, një mikrosistem duhet të komunika me një mikrosistem tjetër vetëm përmes REST API. Asnjë rrugëalternative për qasje direkt 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Ă« instancĂ« nuk duhet tĂ« konsumojĂ« mĂ« shumĂ« se 4-8 gigabajt memorie RAM dhe duhet tĂ« ofrojĂ« mundĂ«sinĂ« pĂ«r shkallĂ«zim horizontal tĂ« kĂ«rkesave duke nisur instanca tĂ« reja. Ădo shĂ«rbim komunikon me tĂ« tjerĂ«t vetĂ«m pĂ«rmes REST API (). Ekipa qĂ« Ă«shtĂ« pĂ«rgjegjĂ«se pĂ«r shĂ«rbimin Ă«shtĂ« e detyruar tĂ« ruajĂ« mbĂ«shtetje prapavijĂ« tĂ« API deri te klienti i fundit qĂ« e pĂ«rdor atĂ«.
Nuk i aplikacionit është shkruajtur në Java duke përdorur Spring Framework. Zgjidhja fillimisht është projektuar për të shpejt shpërndarjen në infrastrukturën cloud, për këtë arsye aplikacioni është ndërtuar duke përdorur sistemin e kontejnerizimit. (). Platforma vazhdon të zhvillohet si në aspektin e funsionalitetit të biznesit (konnektorë të rinj, AutoML), ashtu dhe në aspektin e eficiencës teknologjike.
NjĂ« nga karakteristikat e platformĂ«s tonĂ« Ă«shtĂ« se ne mund tĂ« ekzekutojmĂ« kod tĂ« zhvilluar nĂ« ndĂ«rfaqen vizuale nĂ« çdo sistem ekzekutimi tĂ« modeleve tĂ« Sberbank. Aktualisht, ekzistojnĂ« dy sisteme: njĂ« nĂ« Hadoop dhe njĂ« tjetĂ«r nĂ« OpenShift (Docker). Ne nuk ndalemi kĂ«tu dhe krijojmĂ« module integruese pĂ«r ekzekutimin e kodit nĂ« çdo infrastrukturĂ«, pĂ«rfshirĂ« on-premise dhe nĂ« cloud. NĂ« aspektin e mundĂ«sive tĂ« integrimit efektiv nĂ« ekosistemin e Sberbank, ne gjithashtu planifikojmĂ« tĂ« mbĂ«shtesim punĂ«n me ambientet ekzistuese tĂ« ekzekutimit. NĂ« tĂ« ardhmen â zgjidhja mund tĂ« integrohet fleksibĂ«l "nga kutia" nĂ« çdo peizazh tĂ« çdo organizate.
Ata që kanë provuar ndonjëherë të mbajnë një zgjidhje që ekzekuton Python në Hadoop në PRO, e dinë se është pak të përgatitësh dhe të shpërndash ambientin e përdoruesit të Pythonit në çdo datanod. 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ë qetë. Duhet të mos harrosh të përmirësosh paketat kur shton biblioteka ose servera të rinj, duke ruajtur përputhshmërinë me kodin e modeleve që janë tashmë të implementuara.
Ekzistojnë disa qasje për ta bërë këtë. Për shembull, mund të përgatitësh paraprakisht disa biblioteka të përdorura shpesh dhe t'i integrosh ato në PRO. Në shpërndarjen e Hadoop nga Cloudera, zakonisht përdoret . Po ashtu, tani në Hadoop po shfaqet mundësia e ekzekutimit të -kontejnerëve. Në disa raste të thjeshta, mund të dorëzoni kodin me paketën .
Banku e merr shumĂ« seriozisht sigurinĂ« e ekzekutimit tĂ« kodit nga jashtĂ«, prandaj ne pĂ«rfitojmĂ« maksimalisht nga mundĂ«sitĂ« e reja tĂ« bĂ«rthamĂ«s Linux, ku procesi i ekzekutuar nĂ« njĂ« ambient izoluese , mund tĂ« kufizoni, pĂ«r shembull, qasjen nĂ« rrjet dhe nĂ« diskun lokal, gjĂ« qĂ« zvogĂ«lon ndjeshĂ«m mundĂ«sitĂ« e kodit tĂ« dĂ«mshĂ«m. Sferat e tĂ« dhĂ«nave tĂ« çdo departamenti janĂ« tĂ« mbrojtura dhe tĂ« ĐŽĐŸŃŃŃĐżshme vetĂ«m pĂ«r pronarĂ«t e kĂ«tyre tĂ« dhĂ«nave. Platforma garanton qĂ« tĂ« dhĂ«nat nga njĂ« sferĂ« mund tĂ« kalojnĂ« nĂ« njĂ« tjetĂ«r vetĂ«m pĂ«rmes procesit tĂ« publikimit tĂ« tĂ« dhĂ«nave me kontroll nĂ« tĂ« gjitha fazat nga qasja nĂ« burimet deri nĂ« uljen e tĂ« dhĂ«nave nĂ« vitrinĂ«n pĂ«rfundimtare.
Këtë vit planifikojmë të kompletojmë MVP-në e lançimit të modeleve të shkruara në Python/R/Java në Hadoop. Ne kemi vendosur një objektiv ambicioz 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ë.
Për më tepër, siç duket, shumë specialistë të DS kanë njohuri të mira në matematikë dhe statistikë, ndjekin modele të shkëlqyera, por nuk janë shumë të njohur me transformimet e të dhënave të mëdha dhe u nevojitet ndihma e inxhinierëve tanë të të dhënave për përgatitjen e grupeve të të dhënave për trajnime. Ne vendosëm të ndihmojmë kolegët dhe të krijojmë module të përshtatshme për transformimin standard dhe përgatitjen e tipareve për modelet në motorin Spark. Kjo do të lejojë që të shpenzohet më shumë kohë në zhvillimin e modeleve dhe të mos pritet që inxhinierët e të dhënave të përgatisin një dataset të ri.
Në ekipin tonë punojnë njerëz me njohuri në fusha të ndryshme: Linux dhe DevOps, Hadoop dhe Spark, Java dhe Spring, Scala dhe Akka, OpenShift dhe Kubernetes. Në herën tjetër do të flasim për bibliotekën e modeleve, për mënyrën si kalon modeli në ciklin e jetës brenda kompanisë, si ndodh validimi dhe implementimi.
Burimi: habr.com
