Compartilhar via

Acessar dados em um trabalho

  • Artigo

APLICA-SE A:Extensão de ML da CLI do Azure v2 (atual)SDK do Python azure-ai-ml v2 (atual)

Neste artigo, você aprende:

  • Como ler dados do armazenamento do Azure em um trabalho do Azure Machine Learning.
  • Como gravar dados de seu trabalho do Azure Machine Learning no Armazenamento do Azure.
  • A diferença entre os modos de montagem e download.
  • Como usar a identidade do usuário e a identidade gerenciada para acessar dados.
  • Configurações de montagem disponíveis em um trabalho.
  • Configurações ideais de montagem para cenários comuns.
  • Como acessar os ativos de dados V1.

Pré-requisitos

Início Rápido

Antes de explorar as opções detalhadas disponíveis para você ao acessar dados, primeiro descrevemos os snippets de código relevantes para acesso a dados.

Ler dados do armazenamento do Azure em um trabalho do Azure Machine Learning

Neste exemplo, você envia um trabalho do Azure Machine Learning que acessa dados de uma conta de armazenamento de blob pública. No entanto, você pode adaptar o snippet para acessar seus próprios dados em uma conta privada do Armazenamento do Azure. Atualize o caminho conforme descrito aqui. O Azure Machine Learning lida perfeitamente com a autenticação no armazenamento em nuvem usando a passagem do Microsoft Entra. Ao enviar um trabalho, você pode escolher:

  • Identidade do usuário: passe sua identidade do Microsoft Entra para acessar os dados
  • Identidade gerenciada: use a identidade gerenciada do destino de computação para acessar dados
  • Nenhum: não especifique uma identidade para acessar os dados. Use Nenhum ao usar armazenamentos de dados baseados em credenciais (chave/token SAS) ou ao acessar dados públicos

Dica

Se você usar chaves ou tokens SAS para autenticar, sugerimos que crie um armazenamento de dados do Azure Machine Learning, pois o runtime se conectará automaticamente ao armazenamento sem a exposição da chave/token.

from azure.ai.ml import command, Input, MLClient, UserIdentityConfiguration, ManagedIdentityConfiguration
from azure.ai.ml.entities import Data
from azure.ai.ml.constants import AssetTypes, InputOutputModes
from azure.identity import DefaultAzureCredential

# Set your subscription, resource group and workspace name:
subscription_id = "<SUBSCRIPTION_ID>"
resource_group = "<RESOURCE_GROUP>"
workspace = "<AML_WORKSPACE_NAME>"

# connect to the AzureML workspace
ml_client = MLClient(
    DefaultAzureCredential(), subscription_id, resource_group, workspace
)

# ==============================================================
# Set the URI path for the data.
# Supported `path` formats for input include:
# local: `./<path>
# Blob: wasbs://<container_name>@<account_name>.blob.core.windows.net/<path>
# ADLS: abfss://<file_system>@<account_name>.dfs.core.windows.net/<path>
# Datastore: azureml://datastores/<data_store_name>/paths/<path>
# Data Asset: azureml:<my_data>:<version>
# Supported `path` format for output is:
# Datastore: azureml://datastores/<data_store_name>/paths/<path>
# We set the input path to a file on a public blob container
# ==============================================================
path = "wasbs://data@azuremlexampledata.blob.core.windows.net/titanic.csv"


# ==============================================================
# What type of data does the path point to? Options include:
# data_type = AssetTypes.URI_FILE # a specific file
# data_type = AssetTypes.URI_FOLDER # a folder
# data_type = AssetTypes.MLTABLE # an mltable
# The path we set above is a specific file
# ==============================================================
data_type = AssetTypes.URI_FILE

# ==============================================================
# Set the mode. The popular modes include:
# mode = InputOutputModes.RO_MOUNT # Read-only mount on the compute target
# mode = InputOutputModes.DOWNLOAD # Download the data to the compute target
# ==============================================================
mode = InputOutputModes.RO_MOUNT

# ==============================================================
# You can set the identity you want to use in a job to access the data. Options include:
# identity = UserIdentityConfiguration() # Use the user's identity
# identity = ManagedIdentityConfiguration() # Use the compute target managed identity
# ==============================================================
# This example accesses public data, so we don't need an identity.
# You also set identity to None if you use a credential-based datastore
identity = None

# Set the input for the job:
inputs = {
    "input_data": Input(type=data_type, path=path, mode=mode)
}

# This command job uses the head Linux command to print the first 10 lines of the file
job = command(
    command="head ${{inputs.input_data}}",
    inputs=inputs,
    environment="azureml://registries/azureml/environments/sklearn-1.1/versions/4",
    compute="cpu-cluster",
    identity=identity,
)

# Submit the command
ml_client.jobs.create_or_update(job)

Grave dados de seu trabalho do Azure Machine Learning no Armazenamento do Azure

Nesse exemplo, envie um trabalho do Azure Machine Learning que grava dados no armazenamento de dados do Azure Machine Learning padrão. Opcionalmente, você pode definir o valor name de seu ativo de dados para criar um ativo de dados na saída.

from azure.ai.ml import command, Input, Output, MLClient
from azure.ai.ml.constants import AssetTypes, InputOutputModes
from azure.identity import DefaultAzureCredential

# Set your subscription, resource group and workspace name:
subscription_id = "<SUBSCRIPTION_ID>"
resource_group = "<RESOURCE_GROUP>"
workspace = "<AML_WORKSPACE_NAME>"

# connect to the AzureML workspace
ml_client = MLClient(
    DefaultAzureCredential(), subscription_id, resource_group, workspace
)

# ==============================================================
# Set the URI path for the data.
# Supported `path` formats for input include:
# local: `./<path>
# Blob: wasbs://<container_name>@<account_name>.blob.core.windows.net/<path>
# ADLS: abfss://<file_system>@<account_name>.dfs.core.windows.net/<path>
# Datastore: azureml://datastores/<data_store_name>/paths/<path>
# Data Asset: azureml:<my_data>:<version>
# Supported `path` format for output is:
# Datastore: azureml://datastores/<data_store_name>/paths/<path>
# As an example, we set the input path to a file on a public blob container
# As an example, we set the output path to a folder in the default datastore
# ==============================================================
input_path = "wasbs://data@azuremlexampledata.blob.core.windows.net/titanic.csv"
output_path = "azureml://datastores/workspaceblobstore/paths/quickstart-output/titanic.csv"

# ==============================================================
# What type of data are you pointing to?
# AssetTypes.URI_FILE (a specific file)
# AssetTypes.URI_FOLDER (a folder)
# AssetTypes.MLTABLE (a table)
# The path we set above is a specific file
# ==============================================================
data_type = AssetTypes.URI_FILE

# ==============================================================
# Set the input mode. The most commonly-used modes:
# InputOutputModes.RO_MOUNT
# InputOutputModes.DOWNLOAD
# Set the mode to Read Only (RO) to mount the data
# ==============================================================
input_mode = InputOutputModes.RO_MOUNT

# ==============================================================
# Set the output mode. The most commonly-used modes:
# InputOutputModes.RW_MOUNT
# InputOutputModes.UPLOAD
# Set the mode to Read Write (RW) to mount the data
# ==============================================================
output_mode = InputOutputModes.RW_MOUNT

# Set the input and output for the job:
inputs = {
    "input_data": Input(type=data_type, path=input_path, mode=input_mode)
}

outputs = {
    "output_data": Output(type=data_type, 
                          path=output_path, 
                          mode=output_mode,
                          # optional: if you want to create a data asset from the output, 
                          # then uncomment `name` (`name` can be set without setting `version`, and in this way, we will set `version` automatically for you)
                          # name = "<name_of_data_asset>", # use `name` and `version` to create a data asset from the output
                          # version = "<version>",
                  )
}

# This command job copies the data to your default Datastore
job = command(
    command="cp ${{inputs.input_data}} ${{outputs.output_data}}",
    inputs=inputs,
    outputs=outputs,
    environment="azureml://registries/azureml/environments/sklearn-1.1/versions/4",
    compute="cpu-cluster",
)

# Submit the command
ml_client.jobs.create_or_update(job)

O runtime de dados do Azure Machine Learning

Quando você envia um trabalho, o runtime de dados do Azure Machine Learning controla a carga de dados, do local de armazenamento até o destino de computação. O runtime de dados do Azure Machine Learning está otimizado para velocidade e eficiência das tarefas de aprendizado de máquina. Os principais benefícios incluem:

  • As cargas de dados são gravadas na linguagem Rust, uma linguagem conhecida pela alta velocidade e alta eficiência de memória. Para downloads simultâneos de dados, o Rust evita problemas de Bloqueio do Interpretador Global (GIL) do Python
  • Peso leve; o Rust não possui nenhuma dependência de outras tecnologias, por exemplo, JVM. Consequentemente, o runtime é instalado rapidamente e não drena recursos extras (CPU, memória) no destino de computação
  • Carregamento de dados de vários processos (paralelos)
  • Faz pré-busca de dados como uma tarefa em segundo plano na(s) CPU(s), para permitir uma melhor utilização da(s) GPU(s) ao fazer aprendizado profundo
  • Tratamento contínuo de autenticação no armazenamento em nuvem
  • Fornece opções para montar dados (fluxo) ou baixar todos os dados. Para obter mais informações, visite as seções Montagem (streaming) e Download.
  • Integração perfeita com fsspec: uma interface pitônica unificada para sistemas de arquivos locais, remotos e incorporados e armazenamento de bytes.

Dica

Sugerimos que você aproveite o runtime de dados do Azure Machine Learning, em vez de criar seu próprio recurso de montagem/download em seu código de treinamento (cliente). Observamos restrições de taxa de transferência de armazenamento quando o código do cliente usa o Python para baixar dados do armazenamento, devido a problemas no Global Interpreter Lock (GIL).

Caminhos

Ao fornecer uma entrada/saída de dados para um trabalho, você deve especificar um parâmetro path que aponte para o local dos dados. Esta tabela mostra os diferentes locais de dados com suporte ao Azure Machine Learning e também mostra path exemplos de parâmetros:

Localização Exemplos Entrada Saída
Um caminho no computador local ./home/username/data/my_data N N
Um caminho em um servidor https(s) público https://raw.githubusercontent.com/pandas-dev/pandas/main/doc/data/titanic.csv N N
Um caminho no Armazenamento do Azure wasbs://<container_name>@<account_name>.blob.core.windows.net/<path>
abfss://<file_system>@<account_name>.dfs.core.windows.net/<path>		 Y, somente para autenticação baseada em identidade. N
Um caminho em um Armazenamento de Dados do Azure Machine Learning azureml://datastores/<data_store_name>/paths/<path> N S
Um caminho para um Ativo de Dados azureml:<my_data>:<version> Y N, mas você pode usar name e version para criar um ativo de dados a partir da saída

Modos

Ao executar um trabalho com entradas/saídas de dados, você pode selecionar entre essas opções de modo:

  • ro_mount: Montar o local de armazenamento como somente leitura no destino de computação do disco local (SSD).

  • rw_mount: Montar o local de armazenamento como leitura e gravação no destino de computação do disco local (SSD).

  • download: Baixe os dados do local de armazenamento para o destino de computação do disco local (SSD).

  • upload: faça upload dos dados do destino de computação para o local de armazenamento.

  • eval_mount/eval_download:Esses modos são exclusivos do MLTable. Em alguns cenários, um MLTable pode produzir arquivos que podem estar localizados em uma conta de armazenamento diferente da conta de armazenamento que hospeda o arquivo MLTable. Ou, um MLTable pode fazer subconjunto ou embaralhar os dados localizados no recurso de armazenamento. Essa exibição do subconjunto/embaralhamento só se torna visível se o runtime de dados do Azure Machine Learning realmente avaliar o arquivo MLTable. Por exemplo, este diagrama mostra como um MLTable usado com eval_mount ou eval_download pode obter imagens de dois contêineres de armazenamento diferentes e um arquivo de anotações localizado em uma conta de armazenamento diferente e, em seguida, montar/baixar para o sistema de arquivos do destino de computação remota.

    Captura de tela mostrando a avaliação da montagem.

    A pasta camera1, a pasta camera2 e o arquivo annotations.csv ficam acessíveis no sistema de arquivos do destino de computação na estrutura de pastas:

    /INPUT_DATA
├── account-a
│   ├── container1
│   │   └── camera1
│   │       ├── image1.jpg
│   │       └── image2.jpg
│   └── container2
│       └── camera2
│           ├── image1.jpg
│           └── image2.jpg
└── account-b
    └── container1
        └── annotations.csv

  • direct: convém ler dados diretamente de um URI através de outras APIs, em vez de passar pelo runtime de dados do Azure Machine Learning. Por exemplo, talvez você queira acessar dados em um bucket s3 (com uma URL https de estilo hospedada virtualmente ou de estilo de caminho) usando o cliente boto s3. Você pode obter o URI da entrada como uma cadeia de caracteres com o modo direct. Você vê o uso do modo direto nos Trabalhos do Spark, porque os métodos spark.read_*() sabem como processar os URIs. Para trabalhos que não são do Spark, é sua responsabilidade gerenciar as credenciais de acesso. Por exemplo, você deve utilizar explicitamente o MSI de computação ou, de outra forma, o acesso do agente.

Essa tabela mostra os possíveis modos para diferentes combinações de tipo/modo/entrada/saída:

Tipo Entrada/Saída upload download ro_mount rw_mount direct eval_download eval_mount
uri_folder Entrada ✓ ✓ ✓
uri_file Entrada ✓ ✓ ✓
mltable Entrada ✓ ✓ ✓ ✓ ✓
uri_folder Saída ✓ ✓
uri_file Saída ✓ ✓
mltable Saída ✓ ✓ ✓

Baixar

No modo de download, todos os dados de entrada são copiados para o disco local (SSD) do destino de computação. O runtime de dados do Azure Machine Learning inicia o script de treinamento do usuário, uma vez que todos os dados são copiados. Quando o script do usuário é iniciado, ele lê os dados do disco local, como qualquer outro arquivo. Quando o trabalho é concluído, os dados são removidos do disco do destino de computação.

Vantagens Desvantagens
Quando o treinamento é iniciado, todos os dados estão disponíveis no disco local (SSD) do destino de computação para o script de treinamento. Não é necessária nenhuma interação de rede/armazenamento do Azure. O conjunto de dados deve caber completamente em um disco de destino de computação.
Depois que o script do usuário é iniciado, não há dependências na confiabilidade do armazenamento / rede. Todo o conjunto de dados é baixado (se o treinamento precisar selecionar aleatoriamente apenas uma pequena parte de um dado, grande parte do download será desperdiçado).
O tempo de execução de dados do Azure Machine Learning pode paralelizar o download (diferença significativa em muitos arquivos pequenos) e a taxa de transferência máxima de rede/armazenamento. O trabalho aguarda até que todos os dados sejam baixados para o disco local do destino de computação. Para um trabalho de aprendizado profundo enviado, as GPUs ficarão ociosas até que os dados estejam prontos.
Nenhuma sobrecarga inevitável adicionada pela camada FUSE (ida e volta: chamada de espaço do usuário no script do usuário → kernel → daemon fuse no espaço do usuário → kernel → resposta ao script do usuário no espaço do usuário) As alterações de armazenamento não são refletidas nos dados após a conclusão do download.

Quando usar o download

  • Os dados são pequenos o suficiente para caber no disco do destino de computação sem interferência com outros treinamentos
  • O treinamento usa a maior parte ou todo o conjunto de dados
  • O treinamento lê arquivos de um conjunto de dados mais de uma vez
  • O treinamento deve saltar para posições aleatórias de um arquivo grande
  • Não há problema em esperar até que todos os dados sejam baixados antes de iniciar o treinamento

Configurações de download disponíveis

Você pode ajustar as configurações de download com essas variáveis de ambiente em seu trabalho:

Nome de variável de ambiente Type Valor padrão Descrição
RSLEX_DOWNLOADER_THREADS u64 NUMBER_OF_CPU_CORES * 4 Número de threads simultâneos que o download pode usar
AZUREML_DATASET_HTTP_RETRY_COUNT u64 7 Número de tentativas de repetição de armazenamento individual/solicitação de http para recuperação de erros transitórios.

Em seu trabalho, você pode alterar os padrões acima definindo as variáveis de ambiente, por exemplo:

Para resumir, mostramos apenas como definir as variáveis de ambiente no trabalho.

from azure.ai.ml import command

env_var = {
"RSLEX_DOWNLOADER_THREADS": 64,
"AZUREML_DATASET_HTTP_RETRY_COUNT": 10
}

job = command(
        environment_variables=env_var
)

Download das métricas de desempenho

O tamanho da VM do destino de computação afeta o tempo de download dos dados. Especificamente:

  • O número de núcleos. Quanto mais núcleos disponíveis, maior a simultaneidade e, portanto, maior a velocidade do download.
  • A largura de banda de rede esperada. Cada VM no Azure tem uma taxa de transferência máxima da NIC (placa do adaptador de rede).

Observação

Para VMs de GPU A100, o runtime de dados do Azure Machine Learning pode saturar a Placa de Interface de Rede (NIC) ao fazer o download de dados para o destino de computação (~24 Gbit/s): A taxa de transferência máxima teórica possível.

Esta tabela mostra o desempenho de download que o runtime de dados do Azure Machine Learning pode suportar para um arquivo de 100 GB em uma VM Standard_D15_v2 (20 núcleos, taxa de transferência de rede de 25 Gbit/s):

Estrutura de dados Somente download (segundos) Download e cálculo do MD5 (segundos) Taxa de Transferência Alcançada (Gbit/s)
Arquivos de 10 x 10 GB 55,74 260,97 14,35 Gbit/s
Arquivos de 100 x 1 GB 58,09 259,47 13,77 Gbit/s
Arquivo de 1 x 100 GB 96,13 300,61 8,32 Gbit/s

Podemos ver que um arquivo maior, dividido em arquivos menores, pode melhorar o desempenho do download devido ao paralelismo. Recomendamos evitar arquivos que se tornem muito pequenos (menos de 4 MB) porque o tempo necessário para o envio de solicitações de armazenamento aumenta em relação ao tempo gasto no download da carga útil. Para obter mais informações, leia Problema com muitos arquivos pequenos.

Montagem (streaming)

No modo de montagem, o recurso de dados do Azure Machine Learning usa o recurso FUSE (sistema de arquivos no espaço do usuário) do Linux para criar um sistema de arquivos emulado. Em vez de fazer o download de todos os dados para o disco local (SSD) do destino de computação, o runtime pode reagir às ações do script do usuário em tempo real. Por exemplo, "abrir arquivo","ler parte de 2 KB da posição X", "listar conteúdo do diretório".

Vantagens Desvantagens
Os dados que excedem a capacidade do disco local do destino de computação podem ser usados (não limitados pelo hardware de computação) Adição de sobrecarga do módulo FUSE do Linux.
Sem atraso no início do treinamento (ao contrário do modo de download). Dependência do comportamento de código do usuário (se o código de treinamento que lê sequencialmente arquivos pequenos em uma única montagem de thread também solicitar dados do armazenamento, ele poderá não maximizar a taxa de transferência da rede ou do armazenamento).
Mais configurações disponíveis para ajustar a um cenário de uso. Sem suporte do Windows.
Somente os dados necessários para o treinamento são lidos do armazenamento.

Quando usar a montagem

  • Os dados são grandes e não cabem no disco local de destino da computação.
  • Cada nó de computação individual em um cluster não precisa ler todo o conjunto de dados (arquivo aleatório ou linhas na seleção do arquivo csv etc.).
  • Os atrasos na espera pelo download de todos os dados antes do início do treinamento podem se tornar um problema (tempo de GPU ocioso).

Configurações de montagem disponíveis

Você pode ajustar as configurações de montagem com essas variáveis de ambiente em seu trabalho:

Nome da variável de ambiente Type Valor padrão Descrição
DATASET_MOUNT_ATTRIBUTE_CACHE_TTL u64 Não definido (o cache nunca expira) Tempo, em milissegundos, necessário para manter os resultados das chamadas getattr no cache e para evitar solicitações subsequentes dessas informações do armazenamento novamente.
DATASET_RESERVED_FREE_DISK_SPACE u64 150 MB Destinado a uma configuração do sistema para manter a computação íntegra. Independentemente dos valores das outras configurações, o runtime de dados do Azure Machine Learning não usa os últimos bytes RESERVED_FREE_DISK_SPACE de espaço em disco.
DATASET_MOUNT_CACHE_SIZE usize Ilimitado Controla a quantidade de espaço em disco que a montagem pode usar. Um valor positivo define o valor absoluto em bytes. O valor negativo define quanto de um espaço em disco deixar livre. Esta tabela fornece mais opções de cache de disco. Dá suporte a modificadores KB, MB e GB para conveniência.
DATASET_MOUNT_FILE_CACHE_PRUNE_THRESHOLD f64 1.0 A montagem de volume inicia o corte de cache quando o cache é preenchido até AVAILABLE_CACHE_SIZE * DATASET_MOUNT_FILE_CACHE_PRUNE_THRESHOLD. Deve estar entre 0 e 1. Defini-lo < 1 dispara a remoção de cache em segundo plano anteriormente. AVAILABLE_CACHE_SIZE não é uma variável de ambiente que você pode modificar ou visualizar diretamente. Nesse contexto, refere-se ao "número de bytes que o sistema calcula como disponíveis para armazenamento em cache." Esse valor depende de fatores como tamanho do disco, quantidade de espaço em disco necessária para a integridade do sistema e configurações definidas em variáveis ​​de ambiente (como DATASET_RESERVED_FREE_DISK_SPACE e DATASET_MOUNT_CACHE_SIZE).
DATASET_MOUNT_FILE_CACHE_PRUNE_TARGET f64 0,7 O cache de remoção tenta liberar pelo menos (1-DATASET_MOUNT_FILE_CACHE_PRUNE_TARGET) de um espaço de cache.
DATASET_MOUNT_READ_BLOCK_SIZE usize 2 MB Tamanho do bloco de leitura de streaming. Quando o arquivo for grande o suficiente, solicite pelo menos DATASET_MOUNT_READ_BLOCK_SIZE de dados do armazenamento e do cache, mesmo quando a operação de leitura solicitada pelo fuse for menor.
DATASET_MOUNT_READ_BUFFER_BLOCK_COUNT usize 32 Número de blocos a serem pré-buscados (a leitura do bloco k dispara a pré-busca em segundo plano dos blocos k+1, ..., k.+DATASET_MOUNT_READ_BUFFER_BLOCK_COUNT)
DATASET_MOUNT_READ_THREADS usize NUMBER_OF_CORES * 4 Número de threads de pré-busca em segundo plano.
DATASET_MOUNT_BLOCK_BASED_CACHE_ENABLED bool false Habilitação do cache baseado em blocos.
DATASET_MOUNT_MEMORY_CACHE_SIZE usize 128 MB Aplica-se somente ao cache baseado em blocos. Tamanho do cache baseado em blocos de RAM que pode ser usado. Um valor 0 desabilita completamente o cache de memória.
DATASET_MOUNT_BLOCK_FILE_CACHE_ENABLED bool true Aplica-se somente ao cache baseado em blocos. Quando definido como verdadeiro, o cache baseado em blocos usa o disco rígido local para armazenar blocos em cache.
DATASET_MOUNT_BLOCK_FILE_CACHE_MAX_QUEUE_SIZE usize 512 MB Aplica-se somente ao cache baseado em blocos. O cache baseado em blocos grava o bloco em cache em um disco local em segundo plano. Essa configuração controla a quantidade de montagem de memória que pode ser usada para armazenar blocos aguardando liberação para o cache de disco local.
DATASET_MOUNT_BLOCK_FILE_CACHE_WRITE_THREADS usize NUMBER_OF_CORES * 2 Aplica-se somente ao cache baseado em blocos. Número de threads em segundo plano que o cache baseado em blocos usa para gravar blocos baixados no disco local do destino de computação.
DATASET_UNMOUNT_TIMEOUT_SECONDS u64 30 Tempo em segundos para unmount para concluir (graciosamente) todas as operações pendentes (por exemplo, liberar chamadas) antes de encerrar forçadamente o loop de mensagens de montagem.

Em seu trabalho, você pode alterar os padrões acima definindo as variáveis de ambiente, por exemplo:

from azure.ai.ml import command

env_var = {
"DATASET_MOUNT_BLOCK_FILE_CACHE_ENABLED": True
}

job = command(
        environment_variables=env_var
)

Modo de abertura baseado em blocos

No modo de abertura baseado em blocos, cada arquivo é dividido em blocos de tamanho predefinido (exceto o último bloco). Uma solicitação de leitura de uma posição especificada solicita um bloco correspondente do armazenamento e retorna os dados solicitados imediatamente. Uma leitura também dispara a pré-busca em segundo plano de N blocos seguintes, usando vários threads (otimizados para leitura sequencial). Os blocos baixados são armazenados em cache de duas camadas (RAM e disco local).

Vantagens Desvantagens
Entrega rápida de dados para o script de treinamento (menos bloqueios para partes que ainda não foram solicitadas). As leituras randômicas podem desperdiçar os blocos pré-buscados.
Mais descarregamentos de trabalho para threads em segundo plano (pré-busca/cache). O treinamento pode continuar. Adição de sobrecarga para navegar nos caches, em comparação com leituras diretas de um arquivo em um cache de disco local (por exemplo, no modo de cache de arquivo inteiro).
Somente os dados solicitados (mais a pré-busca) são lidos do armazenamento.
Para dados pequenos o suficiente, é usado um cache rápido baseado em RAM.
Quando usar o modo de abertura baseado em blocos

Recomendado para a maioria dos cenários, exceto ao precisar de leituras rápidas de locais de arquivos aleatórios. Nesses casos, use o modo de abertura do cache de arquivo inteiro.

Modo de abertura do cache de arquivo inteiro

Quando um arquivo em uma pasta de montagem é aberto (por exemplo, f = open(path, args)) no modo de arquivo inteiro, a chamada é bloqueada até que o arquivo inteiro seja baixado para uma pasta de cache de destino de computação no disco. Todas as chamadas de leitura subsequentes redirecionam para o arquivo em cache, portanto, não é necessária nenhuma interação com o armazenamento. Se o cache não tiver espaço disponível suficiente para acomodar o arquivo atual, a montagem tentará remover o arquivo usado menos recentemente do cache. Nos casos em que o arquivo não cabe no disco (em relação às configurações de cache), o runtime dos dados volta ao modo de streaming.

Vantagens Desvantagens
Nenhuma dependência de confiabilidade/taxa de transferência de armazenamento depois que o arquivo é aberto. A chamada aberta é bloqueada até que o arquivo inteiro seja baixado.
Leituras aleatórias rápidas (leitura de pedaços de locais aleatórios do arquivo). O arquivo inteiro é lido do armazenamento, mesmo quando algumas partes do arquivo podem não ser necessárias.
Quando usar isso

Quando leituras aleatórias são necessárias para arquivos relativamente grandes que excedem 128 MB.

Uso

Defina a variável de ambiente DATASET_MOUNT_BLOCK_BASED_CACHE_ENABLED como false em seu trabalho:

from azure.ai.ml import command

env_var = {
"DATASET_MOUNT_BLOCK_BASED_CACHE_ENABLED": False
}

job = command(
        environment_variables=env_var
)

Montagem: listar arquivos

Ao trabalhar com milhões de arquivos, evite uma listagem recursiva, por exemplo, ls -R /mnt/dataset/folder/. Uma listagem recursiva dispara várias chamadas para listar o conteúdo do diretório pai. Em seguida, é necessária uma chamada recursiva separada para cada diretório interno, em todos os níveis filhos. Normalmente, o Armazenamento do Azure permite que apenas 5.000 elementos sejam retornados por solicitação de lista única. Como resultado, uma listagem recursiva de 1 milhão de pastas contendo 10 arquivos cada uma requer 1,000,000 / 5000 + 1,000,000 = 1,000,200 solicitações ao armazenamento. Em comparação, 1.000 pastas com 10.000 arquivos precisariam apenas de 1001 solicitações para armazenamento para uma listagem recursiva.

A montagem do Azure Machine Learning lida com a listagem de maneira lenta. Portanto, para listar muitos arquivos pequenos, é melhor usar uma chamada iterativa da biblioteca do cliente (por exemplo, os.scandir() em Python) em vez de uma chamada da biblioteca do cliente que retorna a lista completa (por exemplo, os.listdir() em Python). Uma chamada iterativa à biblioteca cliente retorna um gerador, o que significa que não é necessário esperar até que a lista inteira seja carregada. Assim, ele pode prosseguir mais rapidamente.

Essa tabela compara o tempo necessário para que o Python e as funções os.scandir() e os.listdir() listem uma pasta quem contém cerca de 4 milhões de arquivos em uma estrutura plana:

Métrica os.scandir() os.listdir()
Tempo para obter a primeira entrada (segundos) 0.67 553,79
Tempo para obter as primeiras 50 mil entradas (segundos) 9,56 562,73
Tempo para obter todas as entradas (segundos) 558,35 582,14

Configurações de montagem ideais para cenários comuns

Para determinados cenários comuns, mostramos as configurações de montagem ideais que você precisa definir em seu trabalho do Azure Machine Learning.

Leitura de arquivo grande sequencialmente uma vez (processamento de linhas em arquivo csv)

Inclua essas configurações de montagem na seção environment_variables do trabalho do Azure Machine Learning:

Observação

Para usar a computação sem servidor, exclua compute="cpu-cluster", neste código.

from azure.ai.ml import command

env_var = {
  "DATASET_MOUNT_BLOCK_BASED_CACHE_ENABLED": True, # Enable block-based caching
  "DATASET_MOUNT_BLOCK_FILE_CACHE_ENABLED": False, # Disable caching on disk
  "DATASET_MOUNT_MEMORY_CACHE_SIZE": 0, # Disabling in-memory caching

  # Increase the number of blocks used for prefetch. This leads to use of more RAM (2 MB * #value set).
  # Can adjust up and down for fine-tuning, depending on the actual data processing pattern.
  # An optimal setting based on our test ~= the number of prefetching threads (#CPU_CORES * 4 by default)
  "DATASET_MOUNT_READ_BUFFER_BLOCK_COUNT": 80,
}

job = command(
        environment_variables=env_var
)
Leitura de um arquivo grande de uma só vez em vários threads (processamento de arquivo csv particionado em vários threads)

Inclua essas configurações de montagem na seção environment_variables do trabalho do Azure Machine Learning:

from azure.ai.ml import command

env_var = {
  "DATASET_MOUNT_BLOCK_BASED_CACHE_ENABLED": True, # Enable block-based caching
  "DATASET_MOUNT_BLOCK_FILE_CACHE_ENABLED": False, # Disable caching on disk
  "DATASET_MOUNT_MEMORY_CACHE_SIZE": 0, # Disabling in-memory caching
}

job = command(
        environment_variables=env_var
)
Leitura de milhões de arquivos pequenos (imagens) de vários threads de uma só vez (treinamento de época única em imagens)

Inclua essas configurações de montagem na seção environment_variables do trabalho do Azure Machine Learning:

from azure.ai.ml import command

env_var = {
  "DATASET_MOUNT_BLOCK_BASED_CACHE_ENABLED": True, # Enable block-based caching
  "DATASET_MOUNT_BLOCK_FILE_CACHE_ENABLED": False, # Disable caching on disk
  "DATASET_MOUNT_MEMORY_CACHE_SIZE": 0, # Disabling in-memory caching
}

job = command(
        environment_variables=env_var
)
Leitura de milhões de arquivos pequenos (imagens) de vários threads várias vezes (treinamento de várias épocas em imagens)

Inclua essas configurações de montagem na seção environment_variables do trabalho do Azure Machine Learning:

from azure.ai.ml import command

env_var = {
  "DATASET_MOUNT_BLOCK_BASED_CACHE_ENABLED": True, # Enable block-based caching
}

job = command(
        environment_variables=env_var
)
Leitura de arquivos grandes com buscas aleatórias (como servir banco de dados de arquivos a partir de uma pasta montada)

Inclua essas configurações de montagem na seção environment_variables do trabalho do Azure Machine Learning:

from azure.ai.ml import command

env_var = {
  "DATASET_MOUNT_BLOCK_BASED_CACHE_ENABLED": False, # Disable block-based caching
}

job = command(
        environment_variables=env_var
)

Diagnosticar e resolver gargalos no carregamento de dados

Quando um trabalho do Azure Machine Learning é executado com dados, o mode de uma entrada determina como os bytes são lidos no armazenamento e armazenados em cache no disco SSD local do destino de computação. Para o modo de download, todos os dados são armazenados em cache no disco, antes do código do usuário iniciar sua execução. Portanto, fatores como

  • número de threads paralelos
  • o número de arquivos
  • tamanho de arquivo

têm efeito sobre as velocidades máximas de download. Para montar, o código do usuário deve começar a abrir arquivos antes que os dados comecem a ser armazenados em cache. Diferentes configurações de montagem resultam em diferentes comportamentos de leitura e cache. Vários fatores afetam a velocidade de carregamento dos dados do armazenamento:

  • Localidade dos dados para computação: os locais de destino do armazenamento e da computação devem ser os mesmos. Se seu armazenamento e destino de computação estiverem localizados em regiões diferentes, o desempenho será prejudicado porque os dados precisam ser transferidos entre as regiões. Para obter mais informações sobre como garantir que seus dados sejam colocados com computação, visite Colocar dados com computação.
  • O tamanho do destino de computação: Computações pequenas têm menor número de núcleos (menos paralelismo) e menor largura de banda de rede esperada em comparação com computações maiores; ambos os fatores afetam o desempenho do carregamento de dados.
    • Por exemplo, se você usar uma VM de tamanho pequeno, como Standard_D2_v2 (2 núcleos, NIC de 1500 Mbps), e tentar carregar 50.000 MB (50 GB) de dados, o melhor tempo de carregamento de dados possível seria de aproximadamente 270 segundos (supondo que você sature a NIC com uma taxa de transferência de 187,5 MB/s). Por outro lado, um Standard_D5_v2 (16 núcleos, 12.000 Mbps) carregaria os mesmos dados em aproximadamente 33 segundos (supondo que você sature a NIC com uma taxa de transferência de 1.500 MB/s).
  • Camada de armazenamento: para a maioria dos cenários, incluindo LLM (modelos de linguagem grande), o armazenamento padrão oferece o melhor perfil de custo/desempenho. No entanto, se você tiver muitos arquivos pequenos, o armazenamento premium oferece um melhor perfil de custo/desempenho. Para obter mais informações, leia Opções de armazenamento do Azure.
  • Carga de armazenamento: se a conta de armazenamento estiver sob alta carga, por exemplo, muitos nós de GPU em um cluster solicitando dados, você corre o risco de atingir a capacidade de saída do armazenamento. Para obter mais informações, leia Carga de armazenamento. Se você tiver muitos arquivos pequenos que precisam ser acessados em paralelo, poderá atingir os limites de solicitação de armazenamento. Leia informações atualizadas sobre os limites da capacidade de saída e das solicitações de armazenamento em Destinos de escala para contas de armazenamento padrão.
  • Padrão de acesso a dados no código do usuário: ao usar o modo de montagem, os dados são buscados com base nas ações de abertura/leitura no código. Por exemplo, ao ler seções aleatórias de um arquivo grande, as configurações padrão de pré-busca de dados das montagens podem levar a downloads de blocos que não serão lidos. Talvez seja necessário ajustar algumas configurações para atingir a taxa de transferência máxima. Para obter mais informações, leia Configurações de montagem ideais para cenários comuns.

Uso de registros para diagnosticar problemas

Para acessar os logs do runtime de dados do trabalho:

  1. Selecione a guia Saídas+Logs na página do trabalho.
  2. Selecione a pasta system_logs, seguida da pasta data_capability.
  3. Você deverá ver dois arquivos de registro: Captura de tela mostrando os registros de runtime de dados.

O arquivo de log data-capability.log mostra as informações de alto nível sobre o tempo gasto nas principais tarefas de carregamento de dados. Por exemplo, ao fazer download de dados, o runtime registra os horários de início e término da atividade de download:

INFO 2023-05-18 17:14:47,790 sdk_logger.py:44 [28] - ActivityStarted, download
INFO 2023-05-18 17:14:50,295 sdk_logger.py:44 [28] - ActivityCompleted: Activity=download, HowEnded=Success, Duration=2504.39 [ms]

Se a taxa de transferência de download for uma fração da largura de banda de rede esperada para o tamanho da VM, você poderá inspecionar o arquivo de log rslex.log.<TIMESTAMP>. Esse arquivo contém todo o registro em log refinado do runtime baseado em Rust; por exemplo, paralelização:

2023-05-18T14:08:25.388670Z  INFO copy_uri:copy_uri:copy_dataset:write_streams_to_files:collect:reduce:reduce_and_combine:reduce:get_iter: rslex::prefetching: close time.busy=23.2µs time.idle=1.90µs sessionId=012ea46a-341c-4258-8aba-90bde4fdfb51 source=Dataset[Partitions: 1, Sources: 1] file_name_column=None break_on_first_error=true skip_existing_files=false parallelization_degree=4 self=Dataset[Partitions: 1, Sources: 1] parallelization_degree=4 self=Dataset[Partitions: 1, Sources: 1] parallelization_degree=4 self=Dataset[Partitions: 1, Sources: 1] parallelization_degree=4 i=0 index=0
2023-05-18T14:08:25.388731Z  INFO copy_uri:copy_uri:copy_dataset:write_streams_to_files:collect:reduce:reduce_and_combine:reduce: rslex::dataset_crossbeam: close time.busy=90.9µs time.idle=9.10µs sessionId=012ea46a-341c-4258-8aba-90bde4fdfb51 source=Dataset[Partitions: 1, Sources: 1] file_name_column=None break_on_first_error=true skip_existing_files=false parallelization_degree=4 self=Dataset[Partitions: 1, Sources: 1] parallelization_degree=4 self=Dataset[Partitions: 1, Sources: 1] parallelization_degree=4 self=Dataset[Partitions: 1, Sources: 1] parallelization_degree=4 i=0
2023-05-18T14:08:25.388762Z  INFO copy_uri:copy_uri:copy_dataset:write_streams_to_files:collect:reduce:reduce_and_combine:combine: rslex::dataset_crossbeam: close time.busy=1.22ms time.idle=9.50µs sessionId=012ea46a-341c-4258-8aba-90bde4fdfb51 source=Dataset[Partitions: 1, Sources: 1] file_name_column=None break_on_first_error=true skip_existing_files=false parallelization_degree=4 self=Dataset[Partitions: 1, Sources: 1] parallelization_degree=4 self=Dataset[Partitions: 1, Sources: 1] parallelization_degree=4 self=Dataset[Partitions: 1, Sources: 1] parallelization_degree=4

O arquivo rslex.log fornece detalhes sobre todas as cópias de arquivos, independentemente de você ter escolhido ou não os modos de montagem ou download. Ele também descreve as configurações (variáveis de ambiente) usadas. Para iniciar a depuração, verifique se você definiu as Configurações de montagem ideais para cenários comuns .

Monitoramento do armazenamento do Azure

No portal do Azure, você pode selecionar sua conta de Armazenamento e, em seguida, Métricas, para ver as métricas de armazenamento:

Captura de tela mostrando as métricas de blob.

Em seguida, plote SuccessE2ELatency com SuccessServerLatency. Se as métricas mostrarem alta SuccessE2ELatency e baixa SuccessServerLatency, se os threads disponíveis forem limitados ou se houver poucos recursos, como CPU, memória ou largura de banda de rede, você deverá:

  • Use a exibição de monitoramento no Estúdio do Azure Machine Learning para verificar a utilização da CPU e da memória do trabalho. Se você estiver com pouca CPU e memória, considere aumentar o tamanho da VM de destino de computação.
  • Considere aumentar RSLEX_DOWNLOADER_THREADS se estiver fazendo download e não utilizar a CPU e a memória. Se você usar a montagem, deverá aumentar DATASET_MOUNT_READ_BUFFER_BLOCK_COUNT para fazer mais pré-busca e aumentar DATASET_MOUNT_READ_THREADS para mais threads de leitura.

Se as métricas mostrarem SuccessE2ELatency baixa e SuccessServerLatency baixa, mas o cliente tiver alta latência, você tem um atraso na solicitação de armazenamento que chega ao serviço. Você deve verificar:

  • Se o número de threads usados para montagem/download (DATASET_MOUNT_READ_THREADS/RSLEX_DOWNLOADER_THREADS) está definido como muito baixo, em relação ao número de núcleos disponíveis no destino de computação. Se a configuração estiver muito baixa, aumente o número de threads.
  • Se o número de tentativas de download (AZUREML_DATASET_HTTP_RETRY_COUNT) está definido como muito alto. Se for o caso, diminua o número de novas tentativas.

Monitoramento do uso do disco durante um trabalho

No Estúdio do Azure Machine Learning, você também pode monitorar a E/S do disco de destino de computação e o uso durante a execução do trabalho. Navegue até seu trabalho e selecione a guia Monitoramento. Essa guia fornece insights sobre os recursos do seu trabalho, em uma base sem interrupção de 30 dias. Por exemplo:

Captura de tela mostrando o uso do disco durante a execução do trabalho.

Observação

O monitoramento de trabalhos é suportado apenas por recursos de computação gerenciados pelo Azure Machine Learning. Trabalhos com um runtime de menos de 5 minutos não terão dados suficientes para preencher esse modo de exibição.

O runtime de dados do Azure Machine Learning não usa os últimos RESERVED_FREE_DISK_SPACE bytes do espaço em disco para manter a integridade da computação (o valor padrão é 150MB). Se o disco estiver cheio, seu código está gravando arquivos no disco sem declarar os arquivos como saída. Portanto, verifique seu código para garantir que os dados não estejam sendo gravados erroneamente no disco temporário. Se for necessário gravar arquivos no disco temporário e esse recurso estiver ficando cheio, considere:

  • Aumentar o tamanho da VM para uma que tenha um disco temporário maior
  • Definir um TTL nos dados armazenados em cache (DATASET_MOUNT_ATTRIBUTE_CACHE_TTL), para limpar seus dados do disco

Colocação de dados no local com computação

Cuidado

Se o armazenamento e a computação estiverem em regiões diferentes, o desempenho será prejudicado porque os dados precisam ser transferidos entre as regiões. Isso aumenta os custos. Verifique se a conta de armazenamento e os recursos de computação estão na mesma região.

Se seus dados e o Workspace do Azure Machine Learning estiverem armazenados em regiões diferentes, recomendamos que você copie os dados para uma conta de armazenamento na mesma região com o utilitário azcopy. O AzCopy usa APIs de servidor para servidor, portanto, os dados são copiados diretamente nos servidores de armazenamento. Essas operações de cópia não usam a largura de banda de rede do computador. Você pode aumentar a taxa de transferência dessas operações com a variável de ambiente AZCOPY_CONCURRENCY_VALUE. Para saber mais, confira Aumentar a simultaneidade.

Carga de armazenamento

Uma única conta de armazenamento pode ser limitada quando estiver sob alta carga, quando:

  • Seu trabalho usa muitos nós de GPU
  • Sua conta de armazenamento tem muitos usuários/aplicativos simultâneos que acessam os dados enquanto você executa o trabalho

Esta seção mostra os cálculos para determinar se a limitação pode se tornar um problema para a carga de trabalho e como abordar reduções de limitação.

Calcular limites de largura de banda

Uma conta do Armazenamento do Azure tem um limite de saída padrão de 120 Gbit/s. As VMs do Azure têm larguras de banda de rede diferentes, que afetam o número teórico de nós de computação necessários para atingir a capacidade máxima de saída padrão do armazenamento:

Tamanho Placa de GPU vCPU Memória: GiB Armazenamento temporário (SSD) GiB Número de placas de GPU Memória da GPU: GiB Largura de banda de rede esperada (Gbit/s) Máximo padrão de saída da conta de armazenamento (Gbit/s)* Número de nós para atingir a capacidade de saída padrão
Standard_ND96asr_v4 A100 96 900 6000 8 40 24 120 5
Standard_ND96amsr_A100_v4 A100 96 1900 6400 8 80 24 120 5
Standard_NC6s_v3 V100 6 112 736 1 16 24 120 5
Standard_NC12s_v3 V100 12 224 1474 2 32 24 120 5
Standard_NC24s_v3 V100 24 448 2948 4 64 24 120 5
Standard_NC24rs_v3 V100 24 448 2948 4 64 24 120 5
Standard_NC4as_T4_v3 T4 4 28 180 1 16 8 120 15
Standard_NC8as_T4_v3 T4 8 56 360 1 16 8 120 15
Standard_NC16as_T4_v3 T4 16 110 360 1 16 8 120 15
Standard_NC64as_T4_v3 T4 64 440 2880 4 64 32 120 3

Ambas as SKUs A100 e V100 têm uma largura de banda de rede máxima por nó de 24 Gbit/s. Se cada nó que lê dados de uma única conta puder ler perto do máximo teórico de 24 Gbit/s, a capacidade de saída ocorreria com cinco nós. O uso de seis ou mais nós de computação começaria a degradar a taxa de transferência de dados em todos os nós.

Importante

Se a sua carga de trabalho precisar de mais de 6 nós de A100/V100, ou se você acreditar que excederá a capacidade de saída padrão do armazenamento (120 Gbit/s), entre em contato com o suporte (por meio do Portal do Azure) e solicite um aumento do limite de saída do armazenamento.

Dimensionamento em várias contas de armazenamento

Você pode exceder a capacidade máxima de saída do armazenamento e/ou atingir os limites de taxa de solicitação. Se esses problemas ocorrerem, sugerimos que você entre em contato primeiro com o suporte para aumentar esses limites na conta de armazenamento.

Se não for possível aumentar a capacidade máxima de saída ou o limite da taxa de solicitação, considere a possibilidade de replicar os dados em várias contas de armazenamento. Copie os dados para várias contas com o Azure Data Factory, o Gerenciador de Armazenamento do Azure ou azcopy, e monte todas as contas em seu trabalho de treinamento. Somente os dados acessados em uma montagem são baixados. Portanto, seu código de treinamento pode ler RANK a partir da variável de ambiente para escolher qual das várias montagens de entrada deve ser lida. Sua definição de trabalho passa em uma lista de contas de armazenamento:

$schema: https://azuremlschemas.azureedge.net/latest/commandJob.schema.json
code: src
command: >-
  python train.py
  --epochs ${{inputs.epochs}}
  --learning-rate ${{inputs.learning_rate}}
  --data ${{inputs.cifar_storage1}}, ${{inputs.cifar_storage2}}
inputs:
  epochs: 1
  learning_rate: 0.2
  cifar_storage1:
    type: uri_folder
    path: azureml://datastores/storage1/paths/cifar
  cifar_storage2:
    type: uri_folder
    path: azureml://datastores/storage2/paths/cifar
environment: azureml:AzureML-pytorch-1.9-ubuntu18.04-py37-cuda11-gpu@latest
compute: azureml:gpu-cluster
distribution:
  type: pytorch
  process_count_per_instance: 1
resources:
  instance_count: 2
display_name: pytorch-cifar-distributed-example
experiment_name: pytorch-cifar-distributed-example
description: Train a basic convolutional neural network (CNN) with PyTorch on the CIFAR-10 dataset, distributed via PyTorch.

Seu código Python de treinamento pode então usar RANK para obter a conta de armazenamento específica para esse nó:

import argparse
import os

parser = argparse.ArgumentParser()
parser.add_argument('--data', nargs='+')
args = parser.parse_args()

world_size = int(os.environ["WORLD_SIZE"])
rank = int(os.environ["RANK"])
local_rank = int(os.environ["LOCAL_RANK"])

data_path_for_this_rank = args.data[rank]

Problema com muitos arquivos pequenos

A leitura de arquivos do armazenamento envolve fazer solicitações para cada arquivo. A contagem de solicitações por arquivo varia de acordo com o tamanho do arquivo e as configurações do software que processa as leituras de arquivo.

Os arquivos geralmente são lidos em blocos de 1 a 4 MB. Arquivos menores que um bloco são lidos com uma única solicitação (GET file.jpg 0-4MB) e arquivos maiores que um bloco têm uma solicitação feita por bloco (GET file.jpg 0-4MB, GET file.jpg 4-8 MB). Essa tabela mostra que arquivos menores que um bloco de 4 MB resultam em mais solicitações de armazenamento em comparação com arquivos maiores:

# Arquivos Tamanho do arquivo Tamanho total dos dados Tamanho do bloco # Solicitações de armazenamento
2.000.000 500 KB 1 TB 4 MB 2.000.000
1,000 1 GB 1 TB 4 MB 256.000

Para arquivos pequenos, o intervalo de latência envolve principalmente o tratamento das solicitações ao armazenamento, em vez de transferências de dados. Portanto, oferecemos estas recomendações para aumentar o tamanho do arquivo:

  • Para dados não estruturados (imagens, texto, vídeo etc.), arquive (zip/tar) pequenos arquivos juntos, para armazená-los como um arquivo maior que possa ser lido em várias partes. Esses arquivos maiores arquivados podem ser abertos no recurso de computação e DataPipes de Arquivo PyTorch podem extrair os arquivos menores.
  • Para dados estruturados (CSV, parquet etc.), examine o processo de ETL para garantir que ele una os arquivos para aumentar o tamanho. O Spark tem métodos repartition() e coalesce() para ajudar a aumentar o tamanho dos arquivos.

Se não for possível aumentar o tamanho dos arquivos, explore as opções de Armazenamento do Azure.

Opções de Armazenamento do Azure

O Armazenamento do Azure oferece duas camadas: standard e premium:

Armazenamento Cenário
Blob do Azure – Standard (HDD) Seus dados são estruturados em blocos maiores: imagens, vídeos etc.
Blob do Azure – Premium (SSD) Altas taxas de transação, objetos menores ou requisitos de latência de armazenamento consistentemente baixos

Dica

Para muitos arquivos pequenos (magnitude KB), recomendamos o uso do SSD (Premium), pois o custo do armazenamento é menor do que os custos de execução da computação de GPU.

Ler ativos de dados da v1

Esta seção explica como ler entidades de dados FileDataset e TabularDataset da v1 em um trabalho da v2.

Ler um FileDataset

No objeto Input, especifique o type como AssetTypes.MLTABLE e o mode como InputOutputModes.EVAL_MOUNT:

Observação

Para usar a computação sem servidor, exclua compute="cpu-cluster", neste código.

Para obter mais informações sobre o objeto MLClient, as opções de inicialização de objeto MLClient e como se conectar a um workspace, visite Conectar-se a um workspace.

from azure.ai.ml import command
from azure.ai.ml.entities import Data
from azure.ai.ml import Input
from azure.ai.ml.constants import AssetTypes, InputOutputModes
from azure.ai.ml import MLClient

ml_client = MLClient.from_config(credential=DefaultAzureCredential())

filedataset_asset = ml_client.data.get(name="<filedataset_name>", version="<version>")

my_job_inputs = {
    "input_data": Input(
            type=AssetTypes.MLTABLE,
            path=filedataset_asset.id,
            mode=InputOutputModes.EVAL_MOUNT
    )
}

job = command(
    code="./src",  # Local path where the code is stored
    command="ls ${{inputs.input_data}}",
    inputs=my_job_inputs,
    environment="<environment_name>:<version>",
    compute="cpu-cluster",
)

# Submit the command
returned_job = ml_client.jobs.create_or_update(job)
# Get a URL for the job status
returned_job.services["Studio"].endpoint

Ler um TabularDataset

No objeto Input, especifique o type como AssetTypes.MLTABLE e o mode como InputOutputModes.DIRECT:

Observação

Para usar a computação sem servidor, exclua compute="cpu-cluster", neste código.

from azure.ai.ml import command
from azure.ai.ml.entities import Data
from azure.ai.ml import Input
from azure.ai.ml.constants import AssetTypes, InputOutputModes
from azure.ai.ml import MLClient

ml_client = MLClient.from_config(credential=DefaultAzureCredential())

filedataset_asset = ml_client.data.get(name="<tabulardataset_name>", version="<version>")

my_job_inputs = {
    "input_data": Input(
            type=AssetTypes.MLTABLE,
            path=filedataset_asset.id,
            mode=InputOutputModes.DIRECT
    )
}

job = command(
    code="./src",  # Local path where the code is stored
    command="python train.py --inputs ${{inputs.input_data}}",
    inputs=my_job_inputs,
    environment="<environment_name>:<version>",
    compute="cpu-cluster",
)

# Submit the command
returned_job = ml_client.jobs.create_or_update(job)
# Get a URL for the status of the job
returned_job.services["Studio"].endpoint

Próximas etapas