Idee e incontri su quali altri processi possono essere automatizzati nascono quotidianamente in aziende di diverse dimensioni. Tuttavia, oltre al tempo necessario per creare un modello, è importante anche dedicare del tempo alla sua valutazione e al controllo che il risultato ottenuto non sia casuale. Dopo l'implementazione, è necessario monitorare qualsiasi modello e controllarlo periodicamente.
E questi sono tutti passaggi che devono essere compiuti in qualsiasi azienda, indipendentemente dalle sue dimensioni. Se parliamo della scala e dell'eredità di Sberbank, il numero di configurazioni sottili aumenta notevolmente. Entro la fine del 2019, in Sber erano già utilizzati più di 2000 modelli. Non è sufficiente sviluppare un modello, è necessario integrarsi con sistemi industriali, sviluppare vetrine di dati per la costruzione dei modelli e garantire il monitoraggio delle sue performance nel cluster.
Il nostro team sta sviluppando la piattaforma Sber.DS. Essa consente di risolvere problemi di apprendimento automatico, accelera il processo di verifica delle ipotesi, semplifica in generale il processo di sviluppo e validazione dei modelli, e controlla i risultati del lavoro del modello in produzione.
Per non deludere le vostre aspettative, desidero dire in anticipo che questo post è introduttivo, e di seguito parleremo di cosa c'è sotto il cofano della piattaforma Sber.DS. Racconteremo separatamente la storia del ciclo di vita del modello, dalla creazione all'implementazione.
Sber.DS è composto da diversi componenti, dei quali i principali sono una libreria, un sistema di sviluppo e un sistema di esecuzione dei modelli.
La libreria controlla il ciclo di vita del modello dal momento in cui nasce l'idea di svilupparlo fino all'implementazione in produzione, al monitoraggio e alla dismissione. Molte delle funzionalità della libreria sono dettate dalle regole del regolatore, come la reportistica e la conservazione dei campioni di addestramento e validazione. In effetti, si tratta di un registro di tutti i nostri modelli.
Il sistema di sviluppo è progettato per la creazione visiva di modelli e metodologie di validazione. I modelli sviluppati passano attraverso una validazione preliminare e vengono forniti al sistema di esecuzione per l'esecuzione delle proprie funzioni aziendali. Inoltre, nel sistema di esecuzione, il modello può essere visualizzato su uno schermo con l'obiettivo di avviare periodicamente le metodologie di validazione per controllare il suo funzionamento.
Nel sistema ci sono diversi tipi di nodi. Alcuni sono destinati a collegarsi a varie fonti di dati, altri - a trasformare i dati grezzi e arricchirli (tagging). Ci sono molti nodi per costruire vari modelli e nodi per la loro validazione. Lo sviluppatore può caricare dati da qualsiasi fonte, trasformarli, filtrarli, visualizzare dati intermedi e suddividerli in parti.
Inoltre, la piattaforma contiene già moduli pronti che possono essere trascinati nell'area di progettazione. Tutte le operazioni avvengono tramite un'interfaccia visualizzata. In effetti, è possibile risolvere il problema senza scrivere una sola riga di codice.
Se le funzionalità integrate non sono sufficienti, il sistema offre la possibilità di creare rapidamente i propri moduli. Abbiamo implementato una modalità di sviluppo integrato basata su per coloro che creano nuovi moduli "da zero".
L'architettura Sber.DS è costruita su microservizi. Ci sono molte opinioni su cosa siano i microservizi. Alcuni ritengono che sia sufficiente suddividere il codice monolitico in parti, ma che comunque accedano tutti alla stessa base di dati. Da noi, un microservizio deve comunicare con un altro microservizio solo tramite REST API. Niente vie di accesso alternative dirette al database.
Ci sforziamo affinché i servizi non diventino troppo grandi e ingombranti: un'istanza non deve consumare più di 4-8 gigabyte di memoria RAM e deve garantire la possibilità di scalabilità orizzontale delle richieste tramite l'avvio di nuove istanze. Ogni servizio comunica con gli altri solo tramite REST API (). Il team responsabile del servizio è tenuto a mantenere la compatibilità retroattiva dell'API fino all'ultimo cliente che la utilizza.
Il nucleo dell'applicazione è scritto in Java utilizzando il Spring Framework. La soluzione è stata inizialmente progettata per un rapido deployment nell'infrastruttura cloud, quindi l'applicazione è costruita utilizzando un sistema di containerizzazione. (). La piattaforma è in continua evoluzione, sia per quanto riguarda l'ampliamento delle funzionalità business (vengono aggiunti nuovi connettori, AutoML), sia per quanto riguarda l'efficienza tecnologica.
Una delle "caratteristiche" della nostra piattaforma è che possiamo eseguire codice sviluppato nell'interfaccia visiva su qualsiasi sistema di esecuzione dei modelli di Sberbank. Attualmente ce ne sono già due: uno su Hadoop e l'altro su OpenShift (Docker). Non ci fermiamo qui e stiamo creando moduli di integrazione per eseguire codice su qualsiasi infrastruttura, inclusi sistemi on-premise e cloud. Per quanto riguarda le possibilità di integrazione efficace nell'ecosistema di Sberbank, prevediamo anche di supportare il funzionamento con ambienti di esecuzione esistenti. In prospettiva, la soluzione può essere flessibilmente integrata "out of the box" in qualsiasi paesaggio di qualsiasi organizzazione.
Chiunque abbia mai provato a mantenere una soluzione che esegue Python su Hadoop in produzione, sa che non basta preparare e fornire l'ambiente utente Python su ogni data node. L'enorme quantità di librerie C/C++ per il machine learning che utilizzano moduli Python non vi permetterà di rilassarvi. Non bisogna dimenticare di aggiornare i pacchetti quando si aggiungono nuove librerie o server, mantenendo la retrocompatibilità con il codice dei modelli già implementato.
Ci sono diversi approcci su come farlo. Per esempio, preparare in anticipo alcune librerie frequentemente utilizzate e integrarle in produzione. Nella distribuzione Hadoop di Cloudera, di solito si utilizza . Inoltre, ora in Hadoop sta emergendo la possibilità di eseguire -container. In alcuni casi semplici, è possibile fornire il codice insieme al pacchetto .
La banca adotta un approccio molto serio alla sicurezza dell'esecuzione di codice di terze parti, quindi sfruttiamo il più possibile le nuove funzionalità del kernel Linux, dove il processo, avviato in un ambiente isolato , si può limitare, ad esempio, l'accesso alla rete e al disco locale, il che riduce significativamente le capacità del codice dannoso. Le aree dati di ogni reparto sono protette e accessibili solo ai proprietari di quei dati. La piattaforma garantisce che i dati da un'area possano passare a un'altra area solo attraverso un processo di pubblicazione dei dati con controlli a tutti i livelli, dall'accesso alle fonti fino all'arrivo dei dati nella vetrina finale.
Quest'anno prevediamo di completare il lancio dell'MVP per i modelli scritti in Python/R/Java su Hadoop. Ci siamo posti un obiettivo ambizioso: imparare a eseguire qualsiasi ambiente personalizzato su Hadoop, per non limitare in alcun modo gli utenti della nostra piattaforma.
Inoltre, come si è scoperto, molti specialisti DS hanno ottime conoscenze in matematica e statistica, creano modelli interessanti, ma non sono molto esperti nelle trasformazioni di grandi dati e hanno bisogno dell'assistenza dei nostri data engineer per preparare i set di dati per l'addestramento. Abbiamo deciso di aiutare i colleghi e creare moduli pratici per la trasformazione standard e la preparazione delle feature per i modelli sul motore Spark. Questo permetterà di dedicare più tempo allo sviluppo dei modelli e di non dover aspettare che i data engineer preparino un nuovo set di dati.
Abbiamo persone con competenze in vari settori: Linux e DevOps, Hadoop e Spark, Java e Spring, Scala e Akka, OpenShift e Kubernetes. La prossima volta parleremo della libreria dei modelli, di come un modello passa attraverso il ciclo di vita all'interno dell'azienda, di come avviene la validazione e l'implementazione.
Fonte: habr.com
