Ideias e reuniões sobre quais outros processos podem ser automatizados surgem todos os dias em empresas de diversos portes. Mas além do fato de que muito tempo pode ser gasto na criação de um modelo, você precisa gastá-lo avaliando-o e verificando se o resultado não é aleatório. Após a implementação, qualquer modelo deve ser monitorado e verificado periodicamente.
E são todas essas etapas que você precisa passar em qualquer empresa, independente do seu porte. Se estamos falando sobre a escala e o legado do Sberbank, o número de ajustes finos aumenta exponencialmente. No final de 2019, o Sberbank já havia usado mais de 2000 modelos. Não basta apenas desenvolver um modelo, é preciso integrar com sistemas industriais, desenvolver data marts para construção de modelos e garantir o controle de sua operação em um cluster.
Nossa equipe está desenvolvendo a plataforma Sber.DS. Ele permite resolver problemas de aprendizado de máquina, acelera o processo de teste de hipóteses, em princípio simplifica o processo de desenvolvimento e validação de modelos e também controla o resultado do modelo no PROM.
Para não enganar suas expectativas, quero dizer de antemão que este post é introdutório, e no corte, para começar, é contado sobre o que basicamente está sob o capô da plataforma Sber.DS. Contaremos a história sobre o ciclo de vida de um modelo desde a criação até a implementação separadamente.
O Sber.DS consiste em vários componentes, sendo os principais a biblioteca, o sistema de desenvolvimento e o sistema de execução do modelo.
A biblioteca controla o ciclo de vida do modelo desde o momento em que surge a ideia para o desenvolver até à sua implementação no PROM, monitorização e desativação. Muitos recursos da biblioteca são ditados pelas regras do regulador, por exemplo, relatórios e armazenamento de amostras de treinamento e validação. Na verdade, este é um registro de todos os nossos modelos.
O sistema de desenvolvimento destina-se ao desenvolvimento visual de modelos e métodos de validação. Os modelos desenvolvidos passam por uma validação primária e são entregues ao sistema de execução para realizar suas funções de negócio. Além disso, no sistema de execução, o modelo pode ser colocado no monitor para lançar periodicamente métodos de validação para controlar sua operação.
Existem vários tipos de nós no sistema. Alguns são projetados para se conectar a várias fontes de dados, outros - para transformar os dados de origem e enriquecê-los (marcação). Existem muitos nós para construir vários modelos e nós para sua validação. O desenvolvedor pode carregar dados de qualquer fonte, transformar, filtrar, visualizar dados intermediários, dividi-los em partes.
A plataforma também contém módulos prontos que podem ser arrastados para a área do projeto. Todas as ações são executadas usando uma interface visualizada. Na verdade, você pode resolver o problema sem uma única linha de código.
Se os recursos integrados não forem suficientes, o sistema oferece a capacidade de criar rapidamente seus próprios módulos. Fizemos um modo de desenvolvimento integrado com base em para quem cria novos módulos do zero.
A arquitetura Sber.DS é construída em microsserviços. Existem muitas opiniões sobre o que são microsserviços. Algumas pessoas pensam que basta dividir o código monolítico em partes, mas ainda assim vão para o mesmo banco de dados. Nosso microsserviço deve se comunicar com outro microsserviço apenas por meio da API REST. Nenhuma solução alternativa para acessar o banco de dados diretamente.
Tentamos evitar que os serviços se tornem muito grandes e lentos: uma única instância não deve consumir mais de 4 a 8 gigabytes de RAM e deve ser capaz de escalar horizontalmente as solicitações iniciando novas instâncias. Cada serviço se comunica com os outros apenas por meio da API REST (). A equipe responsável pelo serviço é obrigada a manter a API retrocompatível até o último cliente que a utilizar.
O núcleo do aplicativo é escrito em Java usando o Spring Framework. A solução foi originalmente projetada para implantação rápida na infraestrutura de nuvem, portanto, o aplicativo é construído usando um sistema de conteinerização (). A plataforma está em constante evolução, tanto em termos de aumento da funcionalidade do negócio (novos conectores, AutoML são adicionados), quanto em termos de eficiência tecnológica.
Um dos "chips" da nossa plataforma é que podemos executar o código desenvolvido na interface visual em qualquer sistema de execução de modelos do Sberbank. Agora já existem dois deles: um no Hadoop, outro no OpenShift (Docker). Não paramos por aí e criamos módulos de integração para rodar código em qualquer infraestrutura, inclusive on-premise e na nuvem. Em termos de possibilidades de integração efetiva no ecossistema Sberbank, também planejamos apoiar o trabalho com ambientes de tempo de execução existentes. No futuro, a solução pode ser integrada de forma flexível "fora da caixa" em qualquer cenário de qualquer organização.
Quem já tentou manter uma solução que roda Python no Hadoop em PROM sabe que não basta preparar e entregar um ambiente python customizado para cada datanode. Um grande número de bibliotecas C / C ++ para aprendizado de máquina que usam módulos Python não o deixarão descansar em paz. Não devemos esquecer de atualizar os pacotes ao adicionar novas bibliotecas ou servidores, mantendo a compatibilidade com versões anteriores com código de modelo já implementado.
Existem várias abordagens para fazer isso. Por exemplo, prepare antecipadamente várias bibliotecas usadas com frequência e implemente-as no PROM. A distribuição Hadoop da Cloudera geralmente usa . Também agora no Hadoop há uma oportunidade de executar - containers. Em alguns casos simples é possível entregar o código junto com o pacote .
O banco leva muito a sério a segurança da execução de código de terceiros, por isso aproveitamos ao máximo as novidades do kernel do Linux, onde um processo rodando em um ambiente isolado , você pode restringir, por exemplo, o acesso à rede e ao disco local, o que reduz bastante a possibilidade de código malicioso. As áreas de dados de cada departamento são protegidas e estão disponíveis apenas para os proprietários desses dados. A plataforma garante que os dados de um domínio só possam entrar em outro domínio por meio de um processo de publicação de dados com controle em todos os estágios, desde o acesso às fontes até o desembarque de dados no mercado de destino.
Este ano, planejamos concluir o MVP de modelos em execução escritos em Python/R/Java no Hadoop. Nos propusemos a ambiciosa tarefa de aprender a rodar qualquer ambiente de usuário no Hadoop, de forma a não limitar de forma alguma os usuários de nossa plataforma.
Além disso, como se viu, muitos especialistas em DS são excelentes em matemática e estatística, criam modelos interessantes, mas não são muito versados em transformações de big data e precisam da ajuda de nossos engenheiros de dados para preparar amostras de treinamento. Decidimos ajudar nossos colegas e criar módulos convenientes para transformação típica e preparação de recursos para modelos no mecanismo Spark. Isso permitirá que mais tempo seja dedicado ao desenvolvimento de modelos e não espere que os engenheiros de dados preparem um novo conjunto de dados.
Temos pessoas com conhecimento em diferentes áreas: Linux e DevOps, Hadoop e Spark, Java e Spring, Scala e Akka, OpenShift e Kubernetes. Da próxima vez falaremos sobre a biblioteca de modelos, como o modelo passa pelo ciclo de vida dentro da empresa, como ocorre a validação e implementação.
Fonte: habr.com