Idee e incontri su quali altri processi possono essere automatizzati nascono ogni giorno in aziende di varie dimensioni. Ma oltre al fatto che si può dedicare molto tempo alla creazione di un modello, è necessario spenderlo valutandolo e verificando che il risultato non sia casuale. Dopo l'implementazione, qualsiasi modello deve essere monitorato e verificato periodicamente.
E queste sono tutte le fasi che devi attraversare in qualsiasi azienda, indipendentemente dalle sue dimensioni. Se parliamo delle dimensioni e dell'eredità di Sberbank, il numero di perfezionamenti aumenta in modo esponenziale. Alla fine del 2019, Sberbank aveva già utilizzato più di 2000 modelli. Non è sufficiente solo sviluppare un modello, è necessario integrarsi con i sistemi industriali, sviluppare data mart per la costruzione di modelli e garantire il controllo del suo funzionamento su un cluster.
Il nostro team sta sviluppando la piattaforma Sber.DS. Ti consente di risolvere problemi di apprendimento automatico, accelera il processo di verifica delle ipotesi, in linea di principio semplifica il processo di sviluppo e convalida dei modelli e controlla anche il risultato del modello in PROM.
Per non ingannare le tue aspettative, voglio dire in anticipo che questo post è introduttivo, e sotto il taglio, per cominciare, viene raccontato cosa c'è fondamentalmente sotto il cofano della piattaforma Sber.DS. Racconteremo separatamente la storia del ciclo di vita di un modello dalla creazione all'implementazione.
Sber.DS è costituito da diversi componenti, i principali sono la libreria, il sistema di sviluppo e il sistema di esecuzione del modello.
La biblioteca controlla il ciclo di vita del modello dal momento in cui l'idea di svilupparlo appare alla sua implementazione nella PROM, monitoraggio e dismissione. Molte funzionalità della libreria sono dettate dalle regole dell'autorità di regolamentazione, ad esempio la segnalazione e l'archiviazione di campioni di addestramento e convalida. Infatti, questo è un registro di tutti i nostri modelli.
Il sistema di sviluppo è destinato allo sviluppo visivo di modelli e metodi di validazione. I modelli sviluppati vengono sottoposti a convalida primaria e vengono consegnati al sistema di esecuzione per svolgere le loro funzioni aziendali. Inoltre, nel sistema di esecuzione, il modello può essere messo sul monitor per lanciare periodicamente metodi di validazione per controllarne il funzionamento.
Esistono diversi tipi di nodi nel sistema. Alcuni sono progettati per connettersi a varie origini dati, altri per trasformare i dati di origine e arricchirli (markup). Esistono molti nodi per la creazione di vari modelli e nodi per la loro convalida. Lo sviluppatore può caricare dati da qualsiasi fonte, trasformare, filtrare, visualizzare dati intermedi, suddividerli in parti.
La piattaforma contiene anche moduli già pronti che possono essere trascinati nell'area del progetto. Tutte le azioni vengono eseguite utilizzando un'interfaccia visualizzata. In effetti, puoi risolvere il problema senza una sola riga di codice.
Se le funzionalità integrate non sono sufficienti, il sistema offre la possibilità di creare rapidamente i propri moduli. Abbiamo creato una modalità di sviluppo integrata basata su per chi crea nuovi moduli da zero.
L'architettura Sber.DS è basata su microservizi. Ci sono molte opinioni su cosa siano i microservizi. Alcune persone pensano che sia sufficiente dividere il codice monolitico in parti, ma vanno comunque allo stesso database. Il nostro microservizio deve comunicare con un altro microservizio solo tramite l'API REST. Nessuna soluzione alternativa per l'accesso diretto al database.
Cerchiamo di evitare che i servizi diventino molto grandi e lenti: una singola istanza non dovrebbe consumare più di 4-8 gigabyte di RAM e dovrebbe essere in grado di scalare orizzontalmente le richieste avviando nuove istanze. Ogni servizio comunica con gli altri solo tramite l'API REST (). Il team responsabile del servizio è tenuto a mantenere l'API retrocompatibile fino all'ultimo client che la utilizza.
Il nucleo dell'applicazione è scritto in Java utilizzando Spring Framework. La soluzione è stata originariamente progettata per una rapida implementazione nell'infrastruttura cloud, pertanto l'applicazione viene creata utilizzando un sistema di containerizzazione (). La piattaforma è in continua evoluzione, sia in termini di funzionalità aziendali crescenti (vengono aggiunti nuovi connettori, AutoML), sia in termini di efficienza tecnologica.
Uno dei "chip" della nostra piattaforma è che possiamo eseguire il codice sviluppato nell'interfaccia visiva su qualsiasi sistema di esecuzione del modello Sberbank. Ora ce ne sono già due: uno su Hadoop, l'altro su OpenShift (Docker). Non ci fermiamo qui e creiamo moduli di integrazione per eseguire il codice su qualsiasi infrastruttura, inclusi on-premise e nel cloud. In termini di possibilità di integrazione efficace nell'ecosistema Sberbank, prevediamo anche di supportare il lavoro con gli ambienti di runtime esistenti. In futuro, la soluzione può essere integrata in modo flessibile "out of the box" in qualsiasi panorama di qualsiasi organizzazione.
Coloro che hanno mai provato a mantenere una soluzione che esegue Python su Hadoop in PROM sanno che non è sufficiente preparare e fornire un ambiente Python personalizzato a ciascun datanode. Un numero enorme di librerie C / C ++ per l'apprendimento automatico che utilizzano moduli Python non ti lasceranno riposare in pace. Non dobbiamo dimenticare di aggiornare i pacchetti quando si aggiungono nuove librerie o server, mantenendo la retrocompatibilità con il codice del modello già implementato.
Esistono diversi approcci su come eseguire questa operazione. Ad esempio, prepara in anticipo diverse librerie utilizzate di frequente e implementale in PROM. La distribuzione Hadoop di Cloudera di solito utilizza . Anche ora in Hadoop c'è l'opportunità di correre - contenitori. In alcuni casi semplici è possibile consegnare il codice insieme al pacco .
La banca prende molto sul serio la sicurezza dell'esecuzione di codice di terze parti, quindi sfruttiamo al massimo le nuove funzionalità del kernel Linux, in cui un processo in esecuzione in un ambiente isolato , è possibile limitare, ad esempio, l'accesso alla rete e al disco locale, il che riduce notevolmente la possibilità di codice dannoso. Le aree dati di ciascun dipartimento sono protette e disponibili solo per i proprietari di tali dati. La piattaforma garantisce che i dati di un dominio possano entrare in un altro dominio solo attraverso un processo di pubblicazione dei dati con controllo in tutte le fasi, dall'accesso alle fonti all'arrivo dei dati nel mercato di destinazione.
Quest'anno prevediamo di completare l'MVP dei modelli in esecuzione scritti in Python/R/Java su Hadoop. Ci siamo dati l'ambizioso compito di imparare a far funzionare qualsiasi ambiente utente su Hadoop, in modo da non limitare in alcun modo gli utenti della nostra piattaforma.
Inoltre, come si è scoperto, molti specialisti DS sono eccellenti in matematica e statistica, realizzano modelli interessanti, ma non sono molto esperti nelle trasformazioni di big data e hanno bisogno dell'aiuto dei nostri ingegneri dei dati per preparare campioni di addestramento. Abbiamo deciso di aiutare i nostri colleghi e creare moduli convenienti per la tipica trasformazione e preparazione delle funzionalità per i modelli sul motore Spark. Ciò consentirà di dedicare più tempo allo sviluppo di modelli e non aspettare che i data engineer preparino un nuovo set di dati.
Abbiamo persone con conoscenze in diverse aree: Linux e DevOps, Hadoop e Spark, Java e Spring, Scala e Akka, OpenShift e Kubernetes. La prossima volta parleremo della libreria di modelli, di come il modello attraversa il ciclo di vita all'interno dell'azienda, di come avvengono la convalida e l'implementazione.
Fonte: habr.com