Ogni giorno nascono idee e discussioni su quali ulteriori processi possano essere automatizzati nelle aziende di diverse dimensioni. Tuttavia, oltre al tempo necessario per creare un modello, è fondamentale dedicare tempo alla sua valutazione e verificare che il risultato ottenuto non sia casuale. Dopo l'implementazione, è necessario monitorare il modello e controllarlo periodicamente.
Questi sono tutti passaggi che devono essere seguiti in qualsiasi azienda, indipendentemente dalle sue dimensioni. Parlando delle dimensioni e dell'eredità di Sberbank, il numero di impostazioni dettagliate aumenta considerevolmente. Entro la fine del 2019, Sber utilizzava già oltre 2000 modelli. Non basta semplicemente sviluppare un modello; è necessario integrarsi con i sistemi industriali, creare vetrine dati per la costruzione dei modelli e garantire il controllo del suo funzionamento nel cluster.
Il nostro team sta sviluppando la piattaforma Sber.DS. Questa piattaforma consente di risolvere le sfide del machine learning, accelera il processo di verifica delle ipotesi, semplifica lo sviluppo e la validazione dei modelli e monitora i risultati ottenuti dai modelli nel settore.
Per non deludere le vostre aspettative, voglio dire in anticipo che questo post è introduttivo, e sotto trovate una panoramica di ciò che si cela dietro la piattaforma Sber.DS. Racconteremo separatamente la storia del ciclo di vita del modello dalla creazione all'implementazione.
Sber.DS è composto da diversi componenti, tra cui la libreria, il sistema di sviluppo e il sistema di esecuzione dei modelli.
La libreria gestisce il ciclo di vita del modello dall'idea iniziale fino all'implementazione nel settore, alla fase di monitoraggio e dismissione. Molte funzionalità della libreria sono dettate dalle normative, come la reportistica e la conservazione dei set di dati di addestramento e validazione. In sostanza, è 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 iniziale e vengono forniti al sistema di esecuzione per svolgere le loro funzioni aziendali. Inoltre, nel sistema di esecuzione, il modello può essere impostato su un monitor per l'avvio periodico delle metodologie di validazione al fine di controllarne il funzionamento.
Nel sistema ci sono diversi tipi di nodi. Alcuni sono destinati a collegarsi a varie fonti di dati, mentre altri servono per trasformare i dati di origine e per arricchirli (etichettatura). Ci sono molti nodi per costruire vari modelli e nodi per la loro validazione. Gli sviluppatori possono caricare dati da qualsiasi fonte, trasformarli, filtrarli, visualizzare dati intermedi e suddividerli in parti.
La piattaforma contiene anche moduli già pronti che possono essere trascinati nell'area di progetto. Tutte le operazioni vengono eseguite utilizzando un'interfaccia visualizzata. In effetti, è possibile risolvere un compito senza scrivere nemmeno una riga di codice.
Se le funzionalità integrate non sono sufficienti, il sistema offre la possibilità di creare rapidamente i propri moduli. Abbiamo realizzato una modalità di sviluppo integrata 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 dividere il codice monolitico in parti, ma poi continuano a utilizzare lo stesso database. Nel nostro caso, un microservizio deve comunicare con un altro microservizio solo tramite REST API. Nessuna via di accesso diretto al database.
Ci impegniamo affinché i servizi non diventino troppo grandi e rigidi: un'istanza non deve consumare più di 4-8 gigabyte di memoria RAM e deve garantire la possibilità di scalare orizzontalmente le richieste avviando 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.
Ядро приложения написано на Java с использованием Spring Framework. Решение изначально проектировалось для быстрого развертывания в облачной инфраструктуре, поэтому приложение построено с использованием системы контейнеризации (). Платформа постоянно развивается, как в части наращивания бизнес функционала (добавляются новые коннекторы, AutoML), так и в части технологической эффективности.
Одна из «фишек» нашей платформы состоит в том, что мы можем запускать код, разработанный в визуальном интерфейсе, на любой системе исполнения моделей Сбербанка. Сейчас их уже две: одна на Hadoop, другая — на OpenShift (Docker). Мы на этом не останавливаемся и создаем интеграционные модули для запуска кода на любой инфраструктуре, в том числе on-premise и в облаке. В части возможностей эффективного встраивания в экосистему Сбербанка, мы также планируем поддержать работу с имеющимися средами исполнения. В перспективе – решение может быть гибко встроено «из коробки» в любой ландшафт любой организации.
Chiunque abbia mai provato a mantenere una soluzione che esegue Python su Hadoop in PRODE, sa che non è sufficiente preparare e consegnare un ambiente Python personalizzato a ciascun nodo dati. Un'enorme quantità di librerie C/C++ per il machine learning che utilizzano moduli Python non ti permetterà di rilassarti. È fondamentale tenere aggiornati i pacchetti quando si aggiungono nuove librerie o server, mantenendo la retrocompatibilità con il codice delle modelli già implementati.
Ci sono diversi approcci per farlo. Ad esempio, si può preparare in anticipo un insieme di librerie comunemente utilizzate e integrarle in PRODE. Nella distribuzione di Hadoop di Cloudera, di solito si utilizza . Inoltre, ora in Hadoop c'è la possibilità di eseguire -container. In alcuni casi semplici, è possibile distribuire il codice insieme al pacchetto .
La banca affronta con grande serietà la sicurezza nell'esecuzione di codice di terze parti, quindi sfruttiamo al massimo le nuove funzionalità del kernel Linux, dove il processo in esecuzione in un ambiente isolato , è possibile limitare, ad esempio, l'accesso alla rete e al disco locale, il che riduce notevolmente le possibilità di malware. Le aree dati di ciascun dipartimento sono protette e accessibili solo ai proprietari di tali dati. La piattaforma garantisce che i dati da un'area possano arrivare a un'altra area solo tramite un processo di pubblicazione dei dati con controlli in tutte le fasi, dall'accesso alle fonti all'arrivo dei dati nella vetrina di destinazione.
Quest'anno prevediamo di completare l'MVP del lancio dei modelli scritti in Python/R/Java su Hadoop. Abbiamo fissato per noi un obiettivo ambizioso: imparare a eseguire qualsiasi ambiente personalizzato su Hadoop, in modo da non limitare gli utenti della nostra piattaforma.
Inoltre, come si è rivelato, molti specialisti DS conoscono bene la matematica e la statistica, creano modelli fantastici, ma non sono molto esperti nelle trasformazioni dei big data e necessitano dell'aiuto dei nostri data engineer per preparare set di dati di addestramento. Abbiamo deciso di aiutare i colleghi creando moduli facili da usare per la trasformazione standard e la preparazione delle funzionalità per i modelli sulla piattaforma Spark. Questo permetterà di dedicare più tempo allo sviluppo dei modelli senza dover attendere che i data engineer preparino un nuovo dataset.
Da noi lavorano persone con competenze 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 un modello attraversa il ciclo di vita all'interno dell'azienda, e del processo di validazione e implementazione.
Fonte: habr.com
