Teilen über

Zugreifen auf Daten in einem Auftrag

  • Artikel

GILT FÜR:Azure CLI ML-Erweiterung v2 (aktuell)Python SDK azure-ai-ml v2 (aktuell)

In diesem Artikel wird Folgendes behandelt:

  • Hier erfahren Sie, wie Sie Daten aus Azure Storage in einem Azure Machine Learning-Auftrag lesen.
  • Hier erfahren Sie, wie Sie Daten aus Ihrem Azure Machine Learning-Auftrag in Azure Storage schreiben.
  • Der Unterschied zwischen den Modi Einbindung und Download.
  • Hier erfahren Sie, wie Sie die Benutzeridentität und die verwaltete Identität für den Zugriff auf Daten verwenden.
  • Einbindungseinstellungen, die in einem Auftrag verfügbar sind.
  • Optimale Einbindungseinstellungen für häufige Szenarien.
  • Hier erfahren Sie, wie Sie auf V1-Datenressourcen zugreifen.

Voraussetzungen

Schnellstart

Bevor Sie die detaillierten Optionen untersuchen, die Ihnen beim Zugriff auf Daten zur Verfügung stehen, beschreiben wir zunächst die relevanten Codeschnipsel für den Datenzugriff.

Lesen von Daten aus Azure Storage in einem Azure Machine Learning-Auftrag

In diesem Beispiel übermitteln Sie einen Azure Machine Learning-Auftrag, der aus einem öffentlichen Blobspeicherkonto auf Daten zugreift. Sie können den Codeschnipsel jedoch anpassen, um auf Ihre eigenen Daten in einem privaten Azure-Speicherkonto zuzugreifen. Aktualisieren Sie den Pfad wie hier beschrieben. Azure Machine Learning verarbeitet die Authentifizierung beim Cloudspeicher nahtlos mit Microsoft Entra-Passthrough. Wenn Sie einen Auftrag übermitteln, können Sie Folgendes auswählen:

  • Benutzeridentität: Passthrough Ihrer Microsoft Entra-Identität für den Zugriff auf die Daten
  • Verwaltete Identität: Verwenden der verwalteten Identität des Computeziels für den Zugriff auf Daten
  • Keine: Keine Identität für den Zugriff auf die Daten. Verwenden Sie „Keine“, wenn Sie auf Anmeldeinformationen basierende Datenspeicher (Schlüssel/SAS-Token) verwenden oder auf öffentliche Daten zugreifen

Tipp

Wenn Sie Schlüssel oder SAS-Token für die Authentifizierung verwenden, empfiehlt es sich, einen Azure Machine Learning-Datenspeicher zu erstellen, da die Runtime automatisch eine Verbindung mit dem Speicher herstellt, ohne den Schlüssel/Token verfügbar zu machen.

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)

Schreiben von Daten aus Ihrem Azure Machine Learning-Auftrag in Azure Storage

In diesem Beispiel übermitteln Sie einen Azure Machine Learning-Auftrag, der Daten in Ihren Azure Machine Learning-Standarddatenspeicher schreibt. Sie können optional den name-Wert Ihres Datenobjekts festlegen, um ein Datenobjekt in der Ausgabe zu erstellen.

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)

Die Azure Machine Learning Data Runtime

Wenn Sie einen Auftrag übermitteln, steuert die Azure Machine Learning Data Runtime die Datenlast vom Speicherort an das Computeziel. Die Azure Machine Learning Daten-Runtime ist für Geschwindigkeit und Effizienz bei maschinellen Lernaufgaben optimiert. Die wichtigsten Vorteile sind:

  • Datenlasten sind in der Programmiersprache Rust geschrieben, die für hohe Geschwindigkeit und hohe Speichereffizienz bekannt ist. Bei gleichzeitigen Datendownloads vermeidet Rust Probleme mit Global Interpreter Lock (GIL) von Python
  • Geringes Gewicht; Rust hat keine Abhängigkeiten von anderen Technologien – z. B. JVM. Daher wird die Runtime schnell installiert, und es werden keine zusätzlichen Ressourcen (CPU, Arbeitsspeicher) auf dem Computeziel verbraucht
  • Laden von Daten mit mehreren Prozessen (parallel)
  • Vorabrufen von Daten als Hintergrundaufgabe für die CPU(n), um eine bessere Auslastung der GPU(s) beim Deep Learning zu ermöglichen
  • Nahtlose Authentifizierungsverarbeitung für Cloudspeicher
  • Stellt Optionen zum Einbinden von Daten (Streamen) oder Herunterladen aller Daten bereit. Weitere Informationen finden Sie in den Abschnitten Einbinden (Streaming) und Herunterladen.
  • Nahtlose Integration mit fsspec, einer einheitlichen Python-Schnittstelle für lokale, Remote- und eingebettete Dateisysteme und Bytespeicher.

Tipp

Es wird empfohlen, die Azure Machine Learning Daten-Runtime zu nutzen, anstatt Ihre eigene Einbindungs-/Downloadfunktion in Ihrem Trainingscode (Client) zu erstellen. Wir haben festgestellt, dass der Speicherdurchsatz eingeschränkt ist, wenn der Clientcode Python zum Herunterladen von Daten aus dem Speicher verwendet, weil es Probleme mit Global Interpreter Lock (GIL) gibt.

Paths

Wenn Sie eine Dateneingabe/-ausgabe für einen Auftrag bereitstellen, müssen Sie den Parameter path angeben, der auf den Datenspeicherort verweist. In dieser Tabelle werden die verschiedenen in Azure Machine Learning unterstützten Datenspeicherorte und Beispiele für den Parameter path gezeigt:

Standort Beispiele Eingabe Ausgabe
Ein Pfad auf Ihrem lokalen Computer ./home/username/data/my_data Y N
Ein Pfad auf einem öffentlichen HTTP(S)-Server https://raw.githubusercontent.com/pandas-dev/pandas/main/doc/data/titanic.csv Y N
Ein Pfad in Azure Storage wasbs://<container_name>@<account_name>.blob.core.windows.net/<path>
abfss://<file_system>@<account_name>.dfs.core.windows.net/<path>		 Y, nur für identitätsbasierte Authentifizierung. N
Ein Pfad in einem Azure Machine Learning-Datenspeicher azureml://datastores/<data_store_name>/paths/<path> Y J
Ein Pfad zu einer Datenressource azureml:<my_data>:<version> J N, aber Sie können name und version verwenden, um eine Datenressource aus der Ausgabe zu erstellen

Modi

Wenn Sie einen Auftrag mit Dateneingaben/-ausgaben ausführen, können Sie zwischen diesen Modusoptionen wählen:

  • ro_mount: Schreibgeschütztes Einbinden des Speicherorts auf dem lokalen Datenträger (SSD) des Computeziels.

  • rw_mount: Einbinden des Speicherorts mit Lese-/Schreibzugriff auf dem lokalen Datenträger (SSD) des Computeziels.

  • download: Herunterladen der Daten vom Speicherort auf den lokalen Datenträger (SSD) des Computeziels.

  • upload: Hochladen der Daten vom Computeziel an den Speicherort.

  • eval_mount/eval_download: Diese Modi sind einzigartig für MLTable. In einigen Szenarien kann eine MLTable Dateien liefern, die sich möglicherweise in einem Speicherkonto befinden, das sich von dem Speicherkonto unterscheidet, das die MLTable-Datei hostet. Alternativ kann eine MLTable die in der Speicherressource befindlichen Daten unterteilen oder mischen. Diese Ansicht der Teilmenge/das Mischen wird nur sichtbar, wenn die Azure Machine Learning Data Runtime die MLTable-Datei tatsächlich auswertet. In diesem Diagramm wird beispielsweise gezeigt, wie eine MLTable, die mit eval_mount oder eval_download verwendet wird, Bilder aus zwei verschiedenen Speichercontainern und einer Anmerkungsdatei in einem anderen Speicherkonto aufnehmen und dann in das Dateisystem des Remotecomputeziels einbinden/herunterladen kann.

    Screenshot der Auswertung einer Einbindung.

    Auf den Ordner camera1, den Ordner camera2 und die Datei annotations.csv kann dann im Dateisystem des Computeziels in der Ordnerstruktur zugegriffen werden:

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

  • direct: Möglicherweise möchten Sie Daten direkt aus einem URI über andere APIs lesen, anstatt die Azure Machine Learning Data Runtime zu durchlaufen. Sie könnten beispielsweise mit dem boto s3-Client auf Daten in einem s3-Bucket (mit einer URL https im Stil von virtual-hosted oder Pfad) zugreifen wollen. Sie können den URI der Eingabe als Zeichenfolge mit dem direct Modus abrufen. Sie sehen die Verwendung des direkten Modus in Spark-Aufträgen, da die spark.read_*()-Methoden wissen, wie die URIs verarbeitet werden. Für Nicht-Spark-Aufträge liegt es in Ihrer Verantwortung, Zugriffsanmeldeinformationen zu verwalten. Beispielsweise müssen Sie explizit die Compute-MSI verwenden oder den Zugriff auf andere Weise brokern.

In der folgenden Tabelle sind die möglichen Modi für verschiedene Kombinationen von Typ, Modus, Eingabe und Ausgabe aufgeführt:

type Eingabe/Ausgabe upload download ro_mount rw_mount direct eval_download eval_mount
uri_folder Eingabe ✓ ✓ ✓
uri_file Eingabe ✓ ✓ ✓
mltable Eingabe ✓ ✓ ✓ ✓ ✓
uri_folder Ausgabe ✓ ✓
uri_file Ausgabe ✓ ✓
mltable Ausgabe ✓ ✓ ✓

Herunterladen

Im Downloadmodus werden alle Eingabedaten auf den lokalen Datenträger (SSD) des Computeziels kopiert. Die Azure Machine Learning Data Runtime startet das Benutzertrainingsskript, sobald alle Daten kopiert wurden. Wenn das Benutzerskript gestartet wird, liest es Daten vom lokalen Datenträger wie alle anderen Dateien. Nach Abschluss des Auftrags werden die Daten vom Datenträger des Computeziels entfernt.

Vorteile Nachteile
Wenn das Training beginnt, sind alle Daten auf dem lokalen Datenträger (SSD) des Computeziels für das Trainingsskript verfügbar. Es ist keine Azure-Speicher-/Netzwerkinteraktion erforderlich. Das Dataset muss vollständig auf einen Computezieldatenträger passen.
Nach dem Starten des Benutzerskripts bestehen keine Abhängigkeiten von der Speicher-/Netzwerksicherheit. Der gesamte Datensatz wird heruntergeladen (wenn beim Training nur ein kleiner Teil der Daten zufällig ausgewählt werden muss, wird ein Großteil des Downloads verschwendet).
Die Azure Machine Learning Data Runtime kann den Download (erheblicher Unterschied bei vielen kleinen Dateien) und den maximalen Netzwerk-/Speicherdurchsatz parallelisieren. Der Auftrag wartet, bis alle Daten auf den lokalen Datenträger des Computeziels heruntergeladen wurden. Bei einem übermittelten Deep-Learning-Auftrag sind die GPUs im Leerlauf, bis die Daten bereit sind.
Durch die FUSE-Ebene wird kein unvermeidlicher Mehraufwand hinzugefügt (Roundtrip: Benutzerbereichsaufruf im Benutzerskript → Kernel → User Space Fuse Daemon → Kernel → Antwort auf Benutzerskript im Benutzerbereich) Speicheränderungen werden nach dem Herunterladen nicht in den Daten widerspiegelt.

Wann Downloads verwendet werden sollten

  • Die Daten sind klein genug, um auf den Datenträger des Computeziels zu passen, ohne das andere Training zu beeinträchtigen
  • Das Training verwendet den größten Teil oder das gesamte Dataset
  • Beim Training werden Dateien aus einem Dataset mehrmals gelesen
  • Das Training muss zu zufälligen Positionen einer großen Datei springen
  • Es ist in Ordnung, zu warten, bis alle Daten heruntergeladen werden, bevor das Training beginnt

Verfügbare Downloadeinstellungen

Sie können die Download-Einstellungen mit diesen Umgebungsvariablen in Ihrem Auftrag anpassen:

Name der Umgebungsvariablen Typ Standardwert BESCHREIBUNG
RSLEX_DOWNLOADER_THREADS u64 NUMBER_OF_CPU_CORES * 4 Anzahl der gleichzeitigen Threads, die ein Download verwenden kann
AZUREML_DATASET_HTTP_RETRY_COUNT u64 7 Anzahl der Wiederholungsversuche einzelner Speicher-/http-Anforderung zur Wiederherstellung nach vorübergehenden Fehlern.

In Ihrem Auftrag können Sie die oben genannten Standardwerte ändern, indem Sie die Umgebungsvariablen festlegen, z. B.:

Aus Gründen der Kürze zeigen wir nur, wie die Umgebungsvariablen im Auftrag definiert werden.

from azure.ai.ml import command

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

job = command(
        environment_variables=env_var
)

Herunterladen von Leistungsmetriken

Die VM-Größe Ihres Computeziels wirkt sich auf die Downloadzeit Ihrer Daten aus. Dies gilt insbesondere in folgenden Fällen:

  • Die Anzahl der Kerne. Je mehr Kerne verfügbar sind, desto mehr Parallelität und somit schnellere Downloadgeschwindigkeit.
  • Die erwartete Netzwerkbandbreite. Jeder virtuelle Computer in Azure verfügt über einen maximalen Durchsatz von der Netzwerkschnittstellenkarte (Network Interface Card, NIC).

Hinweis

Bei A100-GPU-VMs kann die Azure Machine Learning Data Runtime beim Herunterladen von Daten auf das Computeziel (~24 Gbit/s) die NIC (Netzwerkschnittstellenkarte) überlasten: Der theoretische maximale Durchsatz.

Diese Tabelle zeigt die Downloadleistung, die die Azure Machine Learning Data Runtime für eine 100-GB-Datei auf eine Standard_D15_v2-VM verarbeiten kann (20 Kerne, 25 Gbit/s Netzwerkdurchsatz):

Datenstruktur Nur Download (Sek.) Herunterladen und Berechnen von MD5 (Sek.) Erreichter Durchsatz (Gbit/s)
10 x 10-GB-Dateien 55,74 260,97 14,35 GBit/s
100 x 1-GB-Dateien 58,09 259,47 13,77 GBit/s
1 x 100-GB-Datei 96,13 300,61 8,32 GBit/s

Wir sehen, dass eine größere Datei, die in kleinere Dateien unterteilt ist, die Downloadleistung aufgrund von Parallelität verbessern kann. Es wird empfohlen, nicht zu kleine Dateien zu verwenden (weniger als 4 MB), da die Zeit, die für Speicheranforderungsübermittlungen erforderlich ist, im Verhältnis zur Zeit, die für das Herunterladen der Nutzlast aufgewendet wird, zunimmt. Weitere Informationen finden Sie unter Problem mit vielen kleinen Dateien.

Einbinden (Streaming)

Im Einbindungsmodus verwendet die Azure Machine Learning-Datenfunktion das Linux-Feature FUSE (Filesystem in User Space, Dateisystem im Benutzerbereich), um ein emuliertes Dateisystem zu erstellen. Anstatt alle Daten auf den lokalen Datenträger (SSD) des Computeziels herunterzuladen, kann die Runtime in Echtzeit auf die Skriptaktionen des Benutzers reagieren. Beispiel: „Datei öffnen“, „2-KB-Block von Position X lesen“, „Verzeichnisinhalt auflisten“.

Vorteile Nachteile
Daten, die die Kapazität des lokalen Computeziels überschreiten, können verwendet werden (nicht durch Computehardware beschränkt) Zusätzlicher Mehraufwand für das Linux-FUSE-Modul.
Keine Verzögerung zu Beginn des Trainings (im Gegensatz zum Downloadmodus). Abhängigkeit vom Codeverhalten des Benutzers (wenn der Trainingscode, der kleine Dateien in einem einzigen Thread-Mount sequentiell liest, auch Daten aus dem Speicher anfordert, maximiert er möglicherweise nicht den Netzwerk- oder Speicherdurchsatz).
Mehr verfügbare Einstellungen zur Optimierung für ein Nutzungsszenario. Keine Windows-Unterstützung.
Nur Daten, die für das Training benötigt werden, werden aus dem Speicher gelesen.

Wenn die Einbindung verwendet werden sollte

  • Die Daten sind groß und passen nicht auf die lokale Festplatte des Computeziels.
  • Jeder einzelne Computeknoten in einem Cluster muss nicht das gesamte Dataset lesen (zufällige Datei oder Zeilen in CSV-Dateiauswahl usw.).
  • Verzögerungen, die darauf warten, dass alle Daten heruntergeladen werden, bevor das Training beginnt, können zu einem Problem werden (GPU-Leerlaufzeit).

Verfügbare Einbindungseinstellungen

Sie können die Einbindungseinstellungen mit diesen Umgebungsvariablen in Ihrem Auftrag anpassen:

Env-Variablenname Typ Standardwert BESCHREIBUNG
DATASET_MOUNT_ATTRIBUTE_CACHE_TTL u64 Nicht festgelegt (Cache läuft nie ab) Zeit in Millisekunden, die benötigt wird, um die getattr-Ergebnisse des Aufrufs im Cache zu halten und zu verhindern, dass spätere Anfragen dieser Informationen erneut gespeichert werden.
DATASET_RESERVED_FREE_DISK_SPACE u64 150 MB Vorgesehen für eine Systemkonfiguration, um die Computeleistung fehlerfrei zu halten. Unabhängig davon, welche Werte die anderen Einstellungen haben, verwendet die Azure Machine Learning Daten-Runtime nicht die letzten RESERVED_FREE_DISK_SPACE-Bytes des Speicherplatzes.
DATASET_MOUNT_CACHE_SIZE usize Unbegrenzt Steuert, wie viel Speicherplatz die Bereitstellung von Datenträgern verwenden kann. Ein positiver Wert legt den absoluten Wert in Bytes fest. Ein negativer Wert legt fest, wie viel Speicherplatz frei bleiben soll. Diese Tabelle bietet weitere Optionen für den Datenträgercache. Unterstützt KB-, MB- und GB-Modifizierer zur Vereinfachung.
DATASET_MOUNT_FILE_CACHE_PRUNE_THRESHOLD f64 1.0 Die Volumebereitstellung startet die Cachebereinigung, wenn der Cache auf AVAILABLE_CACHE_SIZE * DATASET_MOUNT_FILE_CACHE_PRUNE_THRESHOLD gefüllt ist. Der Wert sollte zwischen 0 und 1 liegen. Wenn Sie ihn auf < 1 festlegen, wird eine vorherige Cachebereinigung im Hintergrund ausgelöst. AVAILABLE_CACHE_SIZE ist keine Umgebungsvariable, die Sie direkt ändern oder anzeigen können. In diesem Zusammenhang bezieht sie sich auf die „Anzahl der Bytes, die das System als für die Zwischenspeicherung verfügbar berechnet.“ Dieser Wert hängt von Faktoren wie Datenträgergröße, des für die Systemintegrität erforderlichen Speicherplatzes und der Konfigurationen ab, die in Umgebungsvariablen festgelegt sind, z. B. in DATASET_RESERVED_FREE_DISK_SPACE und DATASET_MOUNT_CACHE_SIZE.
DATASET_MOUNT_FILE_CACHE_PRUNE_TARGET f64 0.7 Beim Löschen des Caches wird versucht, mindestens (1-DATASET_MOUNT_FILE_CACHE_PRUNE_TARGET) des Cachespeicherplatzes frei zu geben.
DATASET_MOUNT_READ_BLOCK_SIZE usize 2 MB Größe des Streamingleseblocks. Wenn die Datei groß genug ist, werden mindestens DATASET_MOUNT_READ_BLOCK_SIZEder Daten aus dem Speicher und dem Cache angefordert, auch wenn die Sicherung für weniger Daten angefordert wurde.
DATASET_MOUNT_READ_BUFFER_BLOCK_COUNT usize 32 Anzahl der Blöcke, die vorab abgerufen werden sollen (Leseblock k löst Hintergrundvorrufe von Blöcken k+1, ..., k.+DATASET_MOUNT_READ_BUFFER_BLOCK_COUNT aus)
DATASET_MOUNT_READ_THREADS usize NUMBER_OF_CORES * 4 Anzahl der Hintergrundthreads, die vorab abgerufen werden.
DATASET_MOUNT_BLOCK_BASED_CACHE_ENABLED bool false Aktivieren der blockbasierten Zwischenspeicherung.
DATASET_MOUNT_MEMORY_CACHE_SIZE usize 128 MB Gilt nur für blockbasierte Zwischenspeicherung. Größe des Arbeitsspeichers, den das blockbasierte Caching verwenden kann. Der Wert 0 deaktiviert das Zwischenspeichern des Arbeitsspeichers vollständig.
DATASET_MOUNT_BLOCK_FILE_CACHE_ENABLED bool true Gilt nur für blockbasierte Zwischenspeicherung. Wenn diese Einstellung auf „wahr“ festgelegt ist, verwendet die blockbasierte Zwischenspeicherung die lokale Festplatte, um Blöcke zwischenzuspeichern.
DATASET_MOUNT_BLOCK_FILE_CACHE_MAX_QUEUE_SIZE usize 512 MB Gilt nur für blockbasierte Zwischenspeicherung. Die blockbasierte Zwischenspeicherung schreibt einen zwischengespeicherten Block im Hintergrund auf einen lokalen Datenträger. Diese Einstellung steuert, welche Arbeitsspeichereinbindung zum Speichern von Blöcken verwendet werden kann, die darauf warten, in den Cache des lokalen Datenträgers geleert zu werden.
DATASET_MOUNT_BLOCK_FILE_CACHE_WRITE_THREADS usize NUMBER_OF_CORES * 2 Gilt nur für blockbasierte Zwischenspeicherung. Anzahl der Hintergrund-Threads, die das blockbasierte Zwischenspeichern verwendet, um heruntergeladene Blöcke auf den lokalen Datenträger des Computeziels zu schreiben.
DATASET_UNMOUNT_TIMEOUT_SECONDS u64 30 Zeit in Sekunden für unmount, um alle anstehenden Vorgänge (z. B. Flush-Aufrufe) (anstandslos) zu beenden, bevor die Schleife für die Einbindungsnachricht zwangsweise beendet wird.

In Ihrem Auftrag können Sie die oben genannten Standardwerte ändern, indem Sie die Umgebungsvariablen festlegen, z. B.:

from azure.ai.ml import command

env_var = {
"DATASET_MOUNT_BLOCK_FILE_CACHE_ENABLED": True
}

job = command(
        environment_variables=env_var
)

Blockbasierter offener Modus

Im blockbasierten Öffnungsmodus wird jede Datei in Blöcke einer vordefinierten Größe aufgeteilt (mit Ausnahme des letzten Blocks). Eine Leseanforderung von einer angegebenen Position fordert einen entsprechenden Block aus dem Speicher an und gibt die angeforderten Daten sofort zurück. Ein Lesevorgang löst auch das Vorabrufen von N nächsten Blöcken im Hintergrund aus, wobei mehrere Threads verwendet werden (optimiert für sequenzielles Lesen). Heruntergeladene Blöcke werden im Cache mit zwei Ebenen (RAM und lokaler Datenträger) zwischengespeichert.

Vorteile Nachteile
Schnelle Datenübermittlung an das Trainingsskript (weniger Blockierung für Blöcke, die noch nicht angefordert wurden). Zufällige Lesevorgänge können vorab abgerufene Blöcke verschwenden.
Mehr Arbeitsverlagerungen auf Hintergrund-Threads (Prefetching/Caching). Das Training kann dann fortgesetzt werden. Zusätzlicher Mehraufwand für die Navigation zwischen Caches im Vergleich zu direkten Lesevorgängen aus einer Datei in einem lokalen Datenträgercache (z. B. im Cachemodus für ganze Dateien).
Nur angeforderte Daten (plus Vorabruf) werden aus dem Speicher gelesen.
Für ausreichend kleine Daten wird ein schneller RAM-basierter Cache verwendet.
Wann der blockbasierte offene Modus verwendet werden sollte

Empfohlen für die meisten Szenarien, außer wenn Sie schnelle Lesevorgänge aus zufälligen Dateispeicherorten benötigen. Verwenden Sie in diesen Fällen den Offenen Modus für den gesamten Dateicache.

Offener Modus für den gesamten Dateicache

Wenn eine Datei unter einem Einbindungsordner geöffnet wird (z. B. f = open(path, args)), wird der Aufruf im gesamten Dateimodus blockiert, bis die gesamte Datei in einen Computezielcacheordner auf dem Datenträger heruntergeladen wurde. Alle nachfolgenden Leseaufrufe leiten an die zwischengespeicherte Datei um, sodass keine Speicherinteraktion erforderlich ist. Wenn der Cache nicht über genügend verfügbaren Speicherplatz für die aktuelle Datei verfügt, versucht die Einbindung, die zuletzt verwendete Datei aus dem Cache zu löschen. In Fällen, in denen die Datei nicht auf den Datenträger passt (in Bezug auf Cacheeinstellungen), greift die Data Runtime auf den Streamingmodus zurück.

Vorteile Nachteile
Nach dem Öffnen der Datei gibt es keine Speichersicherheits-/Durchsatzabhängigkeiten. Der Öffnen-Aufruf wird blockiert, bis die gesamte Datei heruntergeladen wurde.
Schnelle zufällige Lesevorgänge (Lesen von Blöcken aus zufälligen Stellen der Datei). Die gesamte Datei wird aus dem Speicher gelesen, auch wenn einige Teile der Datei möglicherweise nicht benötigt werden.
Einsatzgebiete

Wenn zufällige Lesevorgänge für relativ große Dateien erforderlich sind, die 128 MB überschreiten.

Nutzung

Legen Sie die Umgebungsvariable DATASET_MOUNT_BLOCK_BASED_CACHE_ENABLED in Ihrem Auftrag auf false fest:

from azure.ai.ml import command

env_var = {
"DATASET_MOUNT_BLOCK_BASED_CACHE_ENABLED": False
}

job = command(
        environment_variables=env_var
)

Einbinden: Auflisten von Dateien

Wenn Sie mit Millionen von Dateien arbeiten, vermeiden Sie eine rekursive Auflistung, z. B. ls -R /mnt/dataset/folder/. Eine rekursive Auflistung löst viele Aufrufe aus, um den Verzeichnisinhalt des übergeordneten Verzeichnisses aufzulisten. Anschließend ist ein separater rekursiver Aufruf für jedes Verzeichnis in allen untergeordneten Ebenen erforderlich. Normalerweise erlaubt Azure Storage nur die Rückgabe von 5000 Elementen pro einzelner Listenanfrage. Als Ergebnis erfordert eine rekursive Auflistung von 1M-Ordnern mit jeweils 10 Dateien 1,000,000 / 5000 + 1,000,000 = 1,000,200 Anforderungen zum Speichern. Im Vergleich dazu benötigen 1.000 Ordner mit 10.000 Dateien nur 1001 Anforderungen für eine rekursive Auflistung.

Die Azure Machine Learning-Bereitstellung verarbeitet die Auflistung auf eine verzögerte Weise. Um viele kleine Dateien aufzulisten, ist es daher besser, einen iterativen Clientbibliothekaufruf (z. B. os.scandir() in Python) anstelle eines Clientbibliotheksaufrufs zu verwenden, der die vollständige Liste zurückgibt (z. B. os.listdir() in Python). Ein iterativer Clientbibliotheksaufruf gibt einen Generator zurück, was bedeutet, dass er nicht warten muss, bis die gesamte Liste geladen wird. Es kann dann schneller fortfahren.

Diese Tabelle vergleicht die Zeit, die für die Python os.scandir() und os.listdir()-Funktionen benötigt werden, um einen Ordner aufzulisten, der ~4M Dateien in einer flachen Struktur enthält:

Metrik os.scandir() os.listdir()
Zeit zum Abrufen des ersten Eintrags (Sek.) 0,67 553,79
Zeit zum Abrufen der ersten 50.000 Einträge (Sek.) 9,56 562,73
Zeit zum Abrufen aller Einträge (Sek.) 558,35 582,14

Optimale Einbindungseinstellungen für häufige Szenarien

Für bestimmte gängige Szenarien zeigen wir die optimalen Einbindungseinstellungen, die Sie in Ihrem Azure Machine Learning-Auftrag festlegen müssen.

Einmaliges sequenzielles Lesen großer Dateien (Verarbeitungszeilen in CSV-Datei)

Fügen Sie die folgenden Einbindungseinstellungen in den environment_variables-Abschnitt Ihres Azure Machine Learning-Auftrags ein:

Hinweis

Wenn Sie serverloses Computing verwenden möchten, löschen Sie compute="cpu-cluster", in diesem Code.

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
)
Einmaliges Lesen einer großen Datei aus mehreren Threads (Verarbeitung einer partitionierten CSV-Datei in mehreren Threads)

Fügen Sie die folgenden Einbindungseinstellungen in den environment_variables-Abschnitt Ihres Azure Machine Learning-Auftrags ein:

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
)
Einmaliges Lesen von Millionen von kleinen Dateien (Bildern) aus mehreren Threads (Training für Bilder aus einer einzelnen Epoche)

Fügen Sie die folgenden Einbindungseinstellungen in den environment_variables-Abschnitt Ihres Azure Machine Learning-Auftrags ein:

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
)
Mehrmaliges Lesen von Millionen von kleinen Dateien (Bildern) aus mehreren Threads (Training für Bilder aus mehreren Epochen)

Fügen Sie die folgenden Einbindungseinstellungen in den environment_variables-Abschnitt Ihres Azure Machine Learning-Auftrags ein:

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
)
Lesen einer großen Datei mit zufälligen Suchvorgängen (z. B. Bereitstellen einer Dateidatenbank aus eingebundenen Ordnern)

Fügen Sie die folgenden Einbindungseinstellungen in den environment_variables-Abschnitt Ihres Azure Machine Learning-Auftrags ein:

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
)

Diagnostizieren und Beheben von Engpässen beim Laden von Daten

Wenn ein Azure Machine Learning-Auftrag mit Daten ausgeführt wird, bestimmt der mode einer Eingabe, wie Bytes aus dem Speicher gelesen und auf dem lokalen SSD-Datenträger des Computeziels zwischengespeichert werden. Im Downloadmodus werden alle Daten auf dem Datenträger zwischengespeichert, bevor der Benutzercode mit der Ausführung beginnt. Daher wirken sich Faktoren wie

  • Anzahl paralleler Threads
  • Anzahl der Dateien
  • Dateigröße

auf die maximalen Downloadgeschwindigkeiten aus. Für die Einbindung muss der Benutzercode mit dem Öffnen von Dateien beginnen, bevor die Daten zwischengespeichert werden. Unterschiedliche Einbindungseinstellungen führen zu einem unterschiedlichen Verhalten beim Lesen und Zwischenspeichern. Verschiedene Faktoren wirken sich auf die Geschwindigkeit aus, mit der Daten aus dem Speicher geladen werden:

  • Datenlokalität für Compute: Ihre Speicher- und Computezielstandorte sollten identisch sein. Wenn sich Ihr Speicher- und Computeziel in verschiedenen Regionen befinden, verschlechtert sich die Leistung, da Daten regionsübergreifend übertragen werden müssen. Weitere Informationen dazu, wie Sie sicherstellen können, dass Ihre Daten mit „Compute“ gemeinsam installiert sind, finden Sie unter Daten mit „Compute“ gemeinsam installieren.
  • Die Computezielgröße: Kleine Computes weisen eine geringere Kernanzahl (weniger Parallelität) und eine geringere erwartete Netzwerkbandbreite im Vergleich zu größeren Computegrößen auf. Beide Faktoren wirken sich auf die Leistung des Datenladevorgangs aus.
    • Wenn Sie beispielsweise eine kleine VM-Größe verwenden, z. B. Standard_D2_v2 (2 Kerne, 1500 MBit/s NIC), und Sie versuchen, 50.000 MB (50 GB) Daten zu laden, beträgt die am besten erreichbare Datenladezeit ca. 270 Sekunden (vorausgesetzt, Sie übersättigen die NIC mit einem Durchsatz von 187,5 MB/s). Im Gegensatz dazu würde ein Standard_D5_v2 (16 Kerne, 12.000 MBit/s) die gleichen Daten in ca. 33 Sekunden laden (vorausgesetzt, Sie übersättigen die NIC mit einem Durchsatz von 1500 MB/s).
  • Speicherebene: Für die meisten Szenarien – einschließlich großer Sprachmodelle (LLM) – bietet Standardspeicher das beste Kosten-/Leistungsprofil. Wenn Sie jedoch über viele kleine Dateien verfügen, bietet Premium-Speicher ein besseres Kosten-/Leistungsprofil. Weitere Informationen finden Sie unter Azure-Speicheroptionen.
  • Speicherlast: Wenn das Speicherkonto unter hoher Auslastung steht, z. B. viele GPU-Knoten in einem Cluster, die Daten anfordern, riskieren Sie, die ausgehende Kapazität des Speichers zu erreichen. Weitere Informationen finden Sie unter Speicherlast. Wenn Sie viele kleine Dateien haben, auf die Sie parallel zugreifen müssen, stoßen Sie möglicherweise an die Grenzen der Speicherplatzanforderung. Lesen Sie aktuelle Informationen zu den Grenzwerten für ausgehende Kapazität und Speicheranforderungen in Skalierungsziele für Standardspeicherkonten.
  • Datenzugriffsmuster im Benutzercode: Wenn Sie den Bereitstellungsmodus verwenden, werden Daten basierend auf den Aktionen zum Öffnen/Lesen in Ihrem Code abgerufen. Wenn Sie beispielsweise zufällige Abschnitte einer großen Datei lesen, können die Standardeinstellungen für das Vorababrufen von Daten von Bereitstellungen zu Downloads von Blöcken führen, die nicht gelesen werden. Möglicherweise müssen Sie einige Einstellungen optimieren, um den maximalen Durchsatz zu erreichen. Weitere Informationen finden Sie unter Optimale Einbindungseinstellungen für häufige Szenarien.

Verwenden von Protokollen zum Diagnostizieren von Problemen

So greifen Sie von Ihrem Auftrag aus auf die Protokolle der Data Runtime zu:

  1. Wählen Sie auf der Auftragsseite die Registerkarte Ausgaben+Protokolle aus.
  2. Wählen Sie den Ordner system_logs gefolgt vom Ordner data_capability aus.
  3. Sie sollten zwei Protokolldateien sehen: Screenshot: Data Runtime-Protokolle.

Die Protokolldatei data-capability.log zeigt die allgemeinen Informationen über die Zeit, die für das Laden wichtiger Daten aufgewendet wurde. Wenn Sie beispielsweise Daten herunterladen, protokolliert die Runtime die Start- und Endzeiten der Downloadaktivität:

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]

Wenn der Downloaddurchsatz ein Bruchteil der erwarteten Netzwerkbandbreite für die VM-Größe ist, können Sie die Protokolldatei rslex.log.<TIMESTAMP> überprüfen. Diese Datei enthält alle Feinkornprotokollierungen aus der Rust-basierten Runtime, zum Beispiel: Parallelisierung:

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

Die Datei rslex.log enthält Details zu allen Dateikopierungen, unabhängig davon, ob Sie den Bereitstellungs- oder Downloadmodus ausgewählt haben oder nicht. Außerdem werden die verwendeten Einstellungen (Umgebungsvariablen) beschrieben. Um mit dem Debuggen zu beginnen, überprüfen Sie, ob Sie optimale Einbindungseinstellungen für häufige Szenarien festgelegt haben.

Überwachen von Azure Storage

Im Azure-Portal können Sie Ihr Speicherkonto und dann Metriken auswählen, um die Speichermetriken anzuzeigen:

Screenshot: Blobmetriken.

Anschließend plotten Sie die SuccessE2ELatency mit SuccessServerLatency. Wenn die Metriken eine hohe SuccessE2ELatency und eine niedrige SuccessServerLatency aufweisen, stehen Ihnen nur begrenzte Threads zur Verfügung, oder Sie haben wenig Ressourcen wie CPU, Arbeitsspeicher oder Netzwerkbandbreite. Dann sollten Sie:

  • Verwenden Sie die Überwachungsansicht in Azure Machine Learning Studio, um die CPU- und Arbeitsspeicherauslastung Ihres Auftrags zu überprüfen. Wenn Sie wenig CPU und Arbeitsspeicher haben, sollten Sie die Größe der Computeziel-VM erhöhen.
  • Erwägen Sie eine Erhöhung von RSLEX_DOWNLOADER_THREADS, wenn Sie herunterladen und die CPU und den Arbeitsspeicher nicht nutzen. Wenn Sie die Bereitstellung verwenden, sollten Sie DATASET_MOUNT_READ_BUFFER_BLOCK_COUNT erhöhen, um mehr Vorababrufen durchzuführen, und erhöhen Sie DATASET_MOUNT_READ_THREADS für weitere Lesethreads.

Wenn die -Metriken eine niedrige SuccessE2ELatency und eine niedrige SuccessServerLatency aufweisen, der Client jedoch eine hohe Latenz aufweist, deutet dies auf eine Verzögerung der Speicheranforderung hin, die den Dienst erreicht. Überprüfen Sie Folgendes:

  • Ob die Anzahl der Threads, die für die Einbindung/den Download (DATASET_MOUNT_READ_THREADS/RSLEX_DOWNLOADER_THREADS) verwendet werden, relativ zur Anzahl der im Computeziel verfügbaren Kerne zu niedrig eingestellt ist. Wenn die Einstellung zu niedrig ist, erhöhen Sie die Anzahl der Threads.
  • Ob die Anzahl der Wiederholungsversuche für das Herunterladen (AZUREML_DATASET_HTTP_RETRY_COUNT) zu hoch eingestellt ist. Wenn das der Fall ist, erhöhen der Anzahl der Wiederholungen.

Überwachen der Datenträgernutzung während eines Auftrags

Über Azure Machine Learning Studio können Sie auch die E/A-Auslastung des Computezieldatenträgers und die Nutzung während der Auftragsausführung überwachen. Navigieren Sie zu Ihrem Auftrag und wählen Sie die Registerkarte Überwachung aus. Diese Registerkarte bietet Einblicke in die Ressourcen Ihres Auftrags auf 30-tägiger Basis. Zum Beispiel:

Screenshot: Datenträgernutzung während der Auftragsausführung.

Hinweis

Die Auftragsüberwachung unterstützt nur Computeressourcen, die von Azure Machine Learning verwaltet werden. Aufträge mit einer Laufzeit von weniger als fünf Minuten haben nicht genügend Daten, um diese Ansicht zu füllen.

Azure Machine Learning Data Runtime verwendet nicht die letzten RESERVED_FREE_DISK_SPACE Bytes des Speicherplatzes, um die Computeumgebung fehlerfrei zu halten (der Standardwert ist 150MB). Wenn Ihr Datenträger voll ist, schreibt Ihr Code Dateien auf den Datenträger, ohne die Dateien als Ausgabe zu deklarieren. Überprüfen Sie daher Ihren Code, um sicherzustellen, dass Daten nicht fälschlicherweise auf einen temporären Datenträger geschrieben werden. Wenn Sie Dateien auf einen temporären Datenträger schreiben müssen und diese Ressource voll wird, sollten Sie Folgendes in Betracht ziehen:

  • Erhöhen der VM-Größe auf eine VM mit einem größeren temporären Datenträger
  • Festlegen einer Gültigkeitsdauer für die zwischengespeicherten Daten (DATASET_MOUNT_ATTRIBUTE_CACHE_TTL), um Ihre Daten vom Datenträger zu löschen

Bereitstellen von Daten am gleichen Ort mit Compute

Achtung

Wenn sich Ihr Speicher und Compute in verschiedenen Regionen befinden, verschlechtert sich die Leistung, da Daten regionsübergreifend übertragen werden müssen. Dies erhöht die Kosten. Stellen Sie sicher, dass sich Ihr Speicherkonto und die Computeressourcen in derselben Region befinden.

Wenn Ihre Daten und der Azure Machine Learning-Arbeitsbereich in verschiedenen Regionen gespeichert sind, empfiehlt es sich, die Daten mit dem Hilfsprogramm azcopy in ein Speicherkonto in derselben Region zu kopieren. AzCopy verwendet die Server-zu-Server-APIs, sodass Daten direkt zwischen Speicherservern kopiert werden. Für diese Kopiervorgänge wird nicht die Netzwerkbandbreite Ihres Computers genutzt. Sie können den Durchsatz dieser Vorgänge mit der Umgebungsvariable AZCOPY_CONCURRENCY_VALUE erhöhen. Weitere Informationen finden Sie unter Erhöhen der Parallelität.

Speicherladevorgang

Ein einzelnes Speicherkonto kann gedrosselt werden, wenn es stark belastet wird, wenn:

  • Ihr Auftrag verwendet viele GPU-Knoten
  • Ihr Speicherkonto verfügt über viele gleichzeitige Benutzer/Anwendungen, die während der Ausführung Ihres Auftrags auf die Daten zugreifen

In diesem Abschnitt finden Sie die Berechnungen, mit denen Sie feststellen können, ob die Drosselung für Ihre Arbeitsauslastung ein Problem darstellen könnte und wie Sie die Drosselung reduzieren können.

Berechnen von Bandbreitengrenzwerten

Ein Azure Storage-Konto verfügt über einen Standardgrenzwert für ausgehenden Datenverkehr von 120 Gbit/s. Azure-VMs weisen unterschiedliche Netzwerkbandbreiten auf, die sich auf die theoretische Anzahl von Computeknoten auswirken, die erforderlich sind, um die maximale Standardkapazität für ausgehenden Speicher zu erreichen:

Size GPU-Karte vCPU Memory: GiB Temporärer Speicher (SSD): GiB Anzahl der GPU-Kerne GPU-Arbeitsspeicher: GiB Erwartete Netzwerkbandbreite (Gbit/s) Standardwert für vom Speicherkonto ausgehenden Datenverkehr, max. (Gbit/s)* Anzahl der Knoten, die die Standardkapazität für ausgehenden Datenverkehr erreichen sollen
Standard_ND96asr_v4 A100 96 900 6000 8 40 24 120 5
Standard_ND96amsr_A100_v4 A100 96 1.900 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

Beide A100/V100-SKUs verfügen über eine maximale Netzwerkbandbreite pro Knoten von 24 Gbit/s. Wenn jeder Knoten, der Daten von einem einzigen Konto liest, annähernd das theoretische Maximum von 24 Gbit/s lesen kann, würde die ausgehende Kapazität mit fünf Knoten erreicht. Die Verwendung von sechs oder mehr Serverknoten würde den Datendurchsatz auf allen Knoten beeinträchtigen.

Wichtig

Wenn Ihre Arbeitsauslastung mehr als 6 A100/V100-Knoten benötigt oder Sie glauben, dass Sie die standardmäßige ausgehende Kapazität des Speichers (120 Gbit/s) überschreiten werden, wenden Sie sich an den Support (über das Azure-Portal) und fordern Sie eine Erhöhung des Grenzwerts für den ausgehenden Speicher an.

Speicherkontenübergreifendes Skalieren

Möglicherweise überschreiten Sie die maximale Ausgangskapazität des Speichers und/oder Sie stoßen möglicherweise an die Grenzen der Anforderungsrate. Wenn diese Probleme auftreten, empfehlen wir, zuerst den Support zu kontaktieren, um diese Grenzwerte für das Speicherkonto zu erhöhen.

Wenn Sie die maximale Ausgangskapazität oder die maximale Anforderungsrate nicht erhöhen können, sollten Sie erwägen, die Daten über mehrere Speicherkonten hinweg zu replizieren. Kopieren Sie die Daten in mehrere Konten mit Azure Data Factory, Azure Storage-Explorer oder azcopy, und binden Sie alle Konten in Ihrem Trainingsauftrag ein. Es werden nur die Daten heruntergeladen, auf die in einer Einbindung zugegriffen wird. Daher kann Ihr Trainingscode den RANK aus der Umgebungsvariablen lesen, um zu wählen, welche der mehreren Eingaben bereitgestellt wird, aus denen gelesen werden soll. Ihre Auftragsdefinition übergibt eine Liste von Speicherkonten:

$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.

Ihr Python-Trainingscode kann dann RANK verwenden, um das speicherspezifische Konto für diesen Knoten abzurufen:

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]

Problem mit vielen kleinen Dateien

Das Lesen von Dateien aus dem Speicher umfasst das Stellen von Anforderungen für jede Datei. Die Anforderungsanzahl pro Datei variiert je nach Dateigröße und den Einstellungen der Software, die die Dateilesevorgänge verarbeitet.

Dateien werden in der Regel in Blöcken mit einer Größe von 1 bis 4 MB gelesen. Dateien, die kleiner als ein Block sind, werden mit einer einzelnen Anforderung (GET file.jpg 0-4 MB) gelesen, und Dateien, die größer als ein Block sind, enthalten eine Anforderung pro Block (GET file.jpg 0-4 MB, GET file.jpg 4-8 MB). Die folgende Tabelle zeigt, dass Dateien, die kleiner als ein 4-MB-Block sind, im Vergleich zu größeren Dateien zu mehr Speicheranforderungen führen:

Anz. Dateien Dateigröße Gesamtdatengröße Blockgröße Anz. Speicheranforderungen
2\.000.000 500 KB 1 TB 4 MB 2\.000.000
1\.000 1 GB 1 TB 4 MB 256.000

Bei kleinen Dateien umfasst das Latenzintervall hauptsächlich die Verarbeitung der Anforderungen an den Speicher anstelle von Datenübertragungen. Daher bieten wir diese Empfehlungen an, um die Dateigröße zu erhöhen:

  • Für unstrukturierte Daten (Bilder, Text, Video usw.) archivieren Sie kleine Dateien (zip/tar), sodass sie als größere Datei gespeichert werden, die in mehreren Blöcken gelesen werden kann. Diese größeren archivierten Dateien können in der Computeressource geöffnet werden und PyTorch Archive DataPipes kann die kleineren Dateien extrahieren.
  • Untersuchen Sie für strukturierte Daten (CSV, Parquet usw.) Ihren ETL-Prozess, um sicherzustellen, dass Dateien zusammengefügt werden, um die Größe zu erhöhen. Spark verfügt über repartition()- und coalesce()-Methoden, um die Dateigröße zu erhöhen.

Wenn Sie Ihre Dateigröße nicht erhöhen können, sehen Sie sich Ihre Azure Storage-Optionen an.

Azure Storage-Optionen

Azure Storage bietet zwei Tarife: Standard und Premium:

Speicher Szenario
Azure Blob – Standard (HDD) Ihre Daten sind in größere Blobs strukturiert – Bilder, Videos usw.
Azure Blob – Premium (SSD) Hohe Transaktionsraten, kleinere Objekte oder konstant niedrige Speicherlatenzanforderungen

Tipp

Für „viele“ kleine Dateien (KB-Größe) wird die Verwendung von Premium (SSD) empfohlen, da die Speicherkosten geringer sind als die Kosten für die Ausführung von GPU-Compute.

Lesen von V1-Datenressourcen

In diesem Abschnitt wird erläutert, wie Sie FileDataset- und TabularDataset-Datenentitäten vom Typ V1 in einem V2-Auftrag lesen.

Lesen eines Dateidatasets (FileDataset)

Geben Sie im Input-Objekt type als AssetTypes.MLTABLE und mode als InputOutputModes.EVAL_MOUNT an:

Hinweis

Wenn Sie serverloses Computing verwenden möchten, löschen Sie compute="cpu-cluster", in diesem Code.

Weitere Informationen zu den MLClient-Objekt- und MLClient-Objektinitialisierungsoptionen und zum Herstellen einer Verbindung mit einem Arbeitsbereich finden Sie unter Verbinden mit einem Arbeitsbereich.

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

Lesen eines Dateidatasets (TabularDataset)

Geben Sie im Input-Objekt type als AssetTypes.MLTABLE und mode als InputOutputModes.DIRECT an:

Hinweis

Wenn Sie serverloses Computing verwenden möchten, löschen Sie compute="cpu-cluster", in diesem Code.

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

Nächste Schritte