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 análises 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 plano 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 Azure Machine Learning. 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.
Práticas recomendadas de implantação
Em 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 para executar a fase de exploração da ciência de dados e a operacionalização inicial do modelo.
Considerações para uma configuração inicial
Em alguns casos, os cientistas de dados em sua organização podem precisar de um ambiente para uma 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 em sua organização ou equipe podem precisar 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, um projeto completo de ciência de dados pode ser necessário, completo com 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.
O processo de configuração
Os modelos devem ser implantados por projeto depois de configurados. Cada projeto deve receber pelo menos duas instâncias para que os ambientes de desenvolvimento e produção sejam 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 Azure Machine Learning 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 utilizador a um conjunto específico de experimentos, endpoints 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 eliminação das pipelines de produção ou dos endpoints num espaço de trabalho. Junto com o modelo, um processo precisa ser criado para dar às equipes de produtos de dados a opção de solicitar novos ambientes.
Recomendamos configurar diferentes serviços de IA, como os Serviços Cognitivos do Azure, por projeto. Ao configurar diferentes serviços de IA por projeto, as implantações ocorrem para cada grupo de recursos de produto de dados. Esta política cria uma separação clara do ponto de vista do acesso aos dados e reduz o risco de acesso não autorizado aos dados pelas equipas erradas.
Cenário de streaming
Para casos de uso em tempo real e de streaming, as implantações devem ser testadas em umde Serviço Kubernetes (AKS) do Azure reduzido
Em seguida, você pode implantar modelos no serviço desejado. Este alvo de computação de implementação é o único amplamente disponível e recomendado para cargas de trabalho de produção num cluster de AKS. Esta etapa é mais necessária se for preciso suporte para GPU (unidade de processamento gráfico) ou FPGA (matriz de porta programável em campo). Outras opções de implantação nativas que dão suporte a esses requisitos de hardware não estão atualmente disponíveis no Aprendizado de Máquina do Azure.
O Azure Machine Learning requer mapeamento um-para-um para clusters AKS. Cada nova conexão com um espaço de trabalho do Azure Machine Learning quebra a conexão anterior entre o AKS e o Azure Machine Learning. Depois que essa limitação for mitigada, recomendamos implantar clusters AKS centrais como recursos compartilhados e anexá-los aos seus respetivos espaços de trabalho.
Outra instância central de teste AKS deve ser hospedada se os testes de estresse devem ser feitos antes de mover um modelo para o AKS de produção. O ambiente de teste deve fornecer o mesmo recurso de computação que o ambiente de produção para garantir que os resultados sejam o mais semelhantes possível ao ambiente de produção.
Cenário em 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 forem baseadas em um evento. Por exemplo, grandes volumes de dados podem ser determinados pelo momento em que os dados são armazenados em uma conta de armazenamento específica. Os pipelines do Azure Machine Learning e os clusters de computação do Azure Machine Learning devem ser usados 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 certos
Antes de implantar um modelo no Aprendizado de Máquina do Azure em um AKS, o usuário precisa especificar os recursos como CPU, RAM e GPU que devem ser alocados para o respetivo modelo. Definir esses parâmetros pode ser um processo complexo e tedioso. Você precisa fazer testes de estresse com diferentes configurações para identificar um bom conjunto de parâmetros. Você pode simplificar este processo com o recurso de Perfilagem de Modelo no Azure Machine Learning, 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 viagem de ida e volta (RTT) para recomendar uma combinação ideal. Essas informações podem ajudar na implantação real do modelo no AKS.
Para atualizar modelos com segurança no Azure Machine Learning, as equipas devem usar o recurso de distribuição controlada (preview) 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 respetivas ferramentas do ambiente do produto de dados. Os engenheiros de dados e aprendizado de máquina devem criar e fornecer os artefatos.
Esses artefatos devem incluir:
Exemplos de blocos de notas que mostram como:
- Carregue, monte e trabalhe com produtos de dados.
- Registrar métricas e parâmetros.
- Envie trabalhos de treinamento para clusters de computação.
Artefatos necessários para a operacionalização:
- Exemplos de Pipelines de Aprendizado de Máquina do Azure
- Pipelines do Azure de exemplo
- Mais scripts necessários para executar pipelines
Documentação
Use artefatos bem projetados para operacionalizar dutos
Os artefatos podem acelerar as fases de exploração e operacionalização de projetos de ciência de dados. Uma estratégia de ramificação de DevOps pode ajudar a dimensionar estes 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
Os pipelines de exemplo do Azure Machine Learning devem ser criados com o SDK (Software Developer Kit) Python ou com base na linguagem YAML. A nova experiência YAML será mais preparada para o futuro, já que a equipe de produto do Azure Machine Learning está atualmente trabalhando em um novo SDK e interface de linha de comando (CLI). A equipe do produto Azure Machine Learning está confiante de que o YAML servirá como a linguagem de definição para todos os artefatos no Azure Machine Learning.
Os pipelines de amostra não funcionam automaticamente para cada projeto, mas podem ser usados como um ponto de partida. Você pode ajustar pipelines de exemplo para projetos. Um pipeline deve incluir os aspetos 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. Os Pipelines do Azure também devem usar o SDK ou CLI do Azure Machine Learning.
Os pipelines devem demonstrar como:
- Conecte-se a um espaço de trabalho de dentro de um pipeline de DevOps.
- Verifique se a computação necessária está disponível.
- Submeta um trabalho.
- Registre e implante 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, Amazon Web Services, Palantir e 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:
As seguintes finalidades aplicam-se 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, incluindo definições de destino de computação, trabalhos, modelos registrados e pontos de extremidade. |
.ado/.github |
Armazene artefatos do Azure DevOps ou GitHub, como pipelines YAML ou gestores de código, nesta pasta. |
code |
Inclua o código real que é desenvolvido como parte do projeto nesta pasta. Esta pasta pode conter pacotes Python e alguns scripts que são usados para as respetivas etapas do pipeline de aprendizado de máquina. Recomendamos separar as etapas individuais que precisam ser feitas nesta pasta. As etapas comuns são de pré-processamento, de treinamento do modelo e de registro do modelo. Defina dependências como dependências Conda, imagens do Docker ou outras para cada pasta. |
docs |
Use esta pasta para fins de documentação. Esta pasta armazena arquivos Markdown e imagens para descrever o projeto. |
pipelines |
Armazene definições de pipelines do Azure Machine Learning 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 Jupyter do projeto Python real com esta pasta. Dentro da pasta, cada pessoa deve ter uma subpasta para verificar os seus cadernos e evitar conflitos de fusão do Git. |