Compartilhar via


Práticas recomendadas para projetos de ciência de dados com análise em escala de nuvem no Azure

Recomendamos essas práticas recomendadas para usar a análise em escala de nuvem no Microsoft Azure para operacionalizar projetos de ciência de dados.

Desenvolver um modelo

Desenvolva um modelo que agrupe um conjunto de serviços para seus projetos de ciência de dados. Use um modelo que agrupe um conjunto de serviços para ajudar a fornecer consistência entre os casos de uso de várias equipes de ciência de dados. Recomendamos que você desenvolva um blueprint consistente na forma de um repositório de modelos. Você pode usar esse repositório para vários projetos de ciência de dados em sua empresa para ajudar a reduzir os tempos de implantação.

Diretrizes para modelos de ciência de dados

Desenvolva um modelo de ciência de dados para sua organização com as seguintes diretrizes:

  • Desenvolva um conjunto de modelos de infraestrutura como código (IaC) para implantar um espaço de trabalho do Aprendizado de Máquina do Azure. Inclua recursos como um cofre de chaves, uma conta de armazenamento, um registro de contêiner e o Application Insights.

  • Inclua a configuração de armazenamentos de dados e destinos de computação nesses modelos, como instâncias de computação, clusters de computação e Azure Databricks.

Melhores práticas de implantação

Tempo real

  • Inclua uma implantação do Azure Data Factory ou do Azure Synapse em modelos e Serviços Cognitivos do Azure.
  • Os modelos devem fornecer todas as ferramentas necessárias à execução da fase de exploração da ciência de dados e à operacionalização inicial do modelo.

Considerações sobre uma configuração inicial

Em alguns casos, os cientistas de dados em sua organização podem exigir um ambiente para análise rápida conforme necessário. Essa situação é comum quando um projeto de ciência de dados não é formalmente configurado. Por exemplo, um gerente de projeto, código de custo ou centro de custo que pode ser necessário para cobrança cruzada no Azure pode estar faltando porque o elemento ausente precisa de aprovação. Os usuários na sua organização ou equipe talvez precisem acessar um ambiente de ciência de dados para entender os dados e, possivelmente, avaliar a viabilidade de um projeto. Além disso, alguns projetos podem não exigir um ambiente completo de ciência de dados devido ao pequeno número de produtos de dados.

Em outros casos, pode ser necessário um projeto de ciência de dados completo, complementado por um ambiente dedicado, gerenciamento de projetos, código de custo e centro de custo. Projetos completos de ciência de dados são úteis para vários membros da equipe que desejam colaborar, compartilhar resultados e precisam operacionalizar modelos após o sucesso da fase de exploração.

Processo de configuração

Após a configuração, os modelos devem ser implantados por projeto. Cada projeto deve receber pelo menos duas instâncias, para que ambientes de desenvolvimento e produção fiquem separados. No ambiente de produção, nenhuma pessoa individual deve ter acesso e tudo deve ser implantado por meio de integração contínua ou pipelines de desenvolvimento contínuo e uma entidade de serviço. Esses princípios de ambiente de produção são importantes porque o Aprendizado de Máquina do Azure não fornece um modelo granular de controle de acesso baseado em função em um espaço de trabalho. Não é possível limitar o acesso do usuário a um conjunto específico de experimentos, pontos de extremidade ou pipelines.

Os mesmos direitos de acesso normalmente se aplicam a diferentes tipos de artefatos. É importante separar o desenvolvimento da produção para evitar a exclusão de pipelines de produção ou pontos de extremidade em um espaço de trabalho. Junto com o modelo, deve ser criado um processo para dar às equipes de produtos de dados a opção de solicitar novos ambientes.

É recomendável configurar diferentes serviços de IA, como Serviços Cognitivos do Azure por projeto. Ao configurar diferentes serviços de IA por projeto, ocorrem implantações para cada grupo de recursos de produto de dados. Essa política cria uma separação clara do ponto de vista de acesso a dados e reduz o risco de acesso não autorizado a dados pelas equipes erradas.

Cenário de streaming

Para casos de uso em tempo real e streaming, as implantações devem ser testadas em um Serviço de Kubernetes do Azure (AKS) de tamanho reduzido. Para economizar custos, os testes podem ocorrer no ambiente de desenvolvimento antes da implantação no AKS de produção ou no Serviço de Aplicativo do Azure para contêineres. Você deve executar testes de entrada e saída simples para garantir que os serviços respondam conforme o esperado.

Em seguida, você pode implantar modelos no serviço desejado. Esse destino de computação de implantação é o único geralmente disponível e recomendado para cargas de trabalho de produção em um cluster do AKS. Essa etapa será mais necessária se for preciso oferecer suporte à GPU (unidade de processamento de gráficos) ou à matriz de porta programável no campo. No momento, outras opções de implantação nativas com suporte a esses requisitos de hardware não estão disponíveis no Azure Machine Learning.

O Azure Machine Learning requer mapeamento de um para um para clusters do AKS. Cada nova conexão com um espaço de trabalho do Azure Machine Learning interrompe a conexão anterior entre o AKS e o Azure Machine Learning. Depois que essa limitação for atenuada, recomendamos implantar clusters centrais do AKS como recursos compartilhados e anexá-los aos respectivos espaços de trabalho.

Outra instância central de teste do AKS deve ser hospedada se for preciso realizar testes de estresse antes de mover um modelo para o AKS de produção. Os ambientes de teste e de produção devem fornecer o mesmo recurso de computação, para garantir que os resultados sejam tão semelhantes aos do ambiente de produção quanto possível.

Cenário de lote

Nem todos os casos de uso precisam de implantações de cluster AKS. Um caso de uso não precisa de uma implantação de cluster AKS se grandes quantidades de dados só precisarem de pontuação regularmente ou se forem baseadas em um evento. Por exemplo, grandes quantidades de dados podem ser baseadas em quando os dados caem em uma conta de armazenamento específica. Devem ser usados pipelines e clusters de computação do Azure Machine Learning para implantação durante esses tipos de cenários. Esses pipelines devem ser orquestrados e executados no Data Factory.

Identificar os recursos de computação corretos

Antes de implantar um modelo no Azure Machine Learning para um AKS, o usuário precisa especificar os recursos como CPU, RAM e GPU que devem ser alocados para o respectivo modelo. Definir esses parâmetros pode ser um processo complexo e entediante. Você precisa fazer testes de estresse com diferentes configurações para identificar um bom conjunto de parâmetros. Você pode simplificar esse processo com o recurso Criação de Perfil de Modelo no Aprendizado de Máquina do Azure, que é um trabalho de longa execução que testa diferentes combinações de alocação de recursos e usa uma latência identificada e um tempo de ida e volta (RTT) para recomendar uma combinação ideal. Essas informações podem ajudar na real implantação de modelo no AKS.

Para atualizar modelos com segurança no Azure Machine Learning, as equipes devem usar o recurso de distribuição controlada (versão prévia) para minimizar o tempo de inatividade e manter o ponto de extremidade REST do modelo consistente.

Práticas recomendadas e o fluxo de trabalho para MLOps

Incluir código de exemplo em repositórios de ciência de dados

Você pode simplificar e acelerar projetos de ciência de dados se suas equipes tiverem determinados artefatos e práticas recomendadas. Recomendamos a criação de artefatos que todas as equipes de ciência de dados podem usar ao trabalhar com o Aprendizado de Máquina do Azure e as respectivas ferramentas do ambiente de produto de dados. Os engenheiros de dados e aprendizado de máquina devem criar e fornecer os artefatos.

Esses artefatos devem incluir:

  • Exemplos de notebooks que mostrem como:

    • Carregue, monte e trabalhe com produtos de dados.
    • Registrar métricas e parâmetros.
    • Enviar trabalhos de treinamento para clusters de computação.
  • Artifacts necessário à operacionalização:

    • Amostras de pipelines do Azure Machine Learning
    • Amostras do Azure Pipelines
    • Mais scripts necessários à execução de pipelines
  • Documentação

Usar artefatos bem projetados para operacionalizar pipelines

Artefatos podem acelerar as fases de exploração e operacionalização de projetos de ciência de dados. Uma estratégia de bifurcação de DevOps pode ajudar a dimensionar esses artefatos em todos os projetos. Como essa configuração promove o uso do Git, os usuários e o processo geral de automação podem se beneficiar dos artefatos fornecidos.

Dica

Exemplos de pipelines do Azure Machine Learning devem ser compilados com o SDK (software developer kit) do Python ou com base na linguagem YAML. A nova experiência YAML será mais durável, pois, no momento, a equipe de produtos do Azure Machine Learning está trabalhando em um novo SDK e em uma nova CLI (interface de linha de comando). A equipe de produto do Aprendizado de Máquina do Azure está confiante de que o YAML servirá como a linguagem de definição para todos os artefatos no Aprendizado de Máquina do Azure.

Os pipelines de exemplo não funcionam prontos para cada projeto, mas podem ser usados como uma linha de base. Você pode ajustar pipelines de amostra para projetos. Um pipeline deve incluir os aspectos mais relevantes de cada projeto. Por exemplo, um pipeline pode fazer referência a um destino de computação, fazer referência a produtos de dados, definir parâmetros, definir entradas e definir as etapas de execução. O mesmo processo deve ser feito para o Azure Pipelines. O Azure Pipelines também deve usar o SDK ou a CLI do Azure Machine Learning.

O Pipelines deve demonstrar como:

  • Conectar-se a um espaço de trabalho de dentro de um pipeline de DevOps.
  • Verificar se a computação necessária está disponível.
  • Enviar um trabalho.
  • Registrar e implantar um modelo.

Os artefatos não são adequados para todos os projetos o tempo todo e podem exigir personalização, mas ter uma base pode acelerar a operacionalização e a implantação de um projeto.

Estruturar o repositório MLOps

Você pode ter situações em que os usuários perdem o controle de onde podem encontrar e armazenar artefatos. Para evitar essas situações, você deve solicitar mais tempo para se comunicar e construir uma estrutura de pastas de nível superior para o repositório padrão. Todos os projetos devem seguir a estrutura de pastas.

Observação

Os conceitos mencionados nesta seção podem ser usados em ambientes locais, do Amazon Web Services, Palantir e do Azure.

A estrutura de pastas de nível superior proposta para um repositório MLOps (operações de aprendizado de máquina) é ilustrada no diagrama a seguir:

Diagrama da estrutura do repositório para MLOps.

As finalidades a seguir se aplicam a cada pasta no repositório:

Pasta Finalidade
.cloud Armazene código e artefatos específicos da nuvem nesta pasta. Os artefatos incluem arquivos de configuração para o espaço de trabalho do Azure Machine Learning, inclusive definições de destino de computação, trabalhos, modelos registrados e pontos de extremidade.
.ado/.github Armazene artefatos do Azure DevOps ou do GitHub, como pipelines YAML ou proprietários de código nesta pasta.
code Inclua o código real que é desenvolvido como parte do projeto nesta pasta. Essa pasta pode conter pacotes do Python e alguns scripts usados para as respectivas etapas do pipeline de aprendizado de máquina. É recomendável separar etapas individuais que precisem ser executadas nessa pasta. Etapas comuns são pré-processamento, treinamento de modelos e registro de modelos. Defina dependências como dependências do Conda, imagens do Docker ou outras para cada pasta.
docs Use esta pasta para fins de documentação. Essa pasta armazena arquivos e imagens Markdown para descrever o projeto.
pipelines Armazene as definições de pipelines do Aprendizado de Máquina do Azure em YAML ou Python nesta pasta.
tests Escreva testes de unidade e integração que precisam ser executados para descobrir bugs e problemas no início do projeto nesta pasta.
notebooks Separe os blocos de anotações do Jupyter do projeto Python real com esta pasta. Nessa pasta, cada indivíduo deve ter uma subpasta para verificar seus notebooks e evitar conflitos de mesclagem do Git.

Próxima etapa

Produtos de dados da análise em escala de nuvem no Azure