Features für die Leistungsoptimierung bei Kopieraktivitäten

GILT FÜR: Azure Data Factory Azure Synapse Analytics

In diesem Artikel werden die Features für die Leistungsoptimierung bei Kopieraktivitäten beschrieben, die Sie in Azure Data Factory- und Synapse-Pipelines nutzen können.

Konfigurieren von Leistungsfunktionen mit der Benutzeroberfläche

Wenn Sie eine Copy-Aktivität im Canvas-Panel des Pipeline-Editors auswählen und die Registerkarte Einstellungen im Aktivitätskonfigurationsbereich unterhalb des Canvas-Panels auswählen, werden Optionen zum Konfigurieren aller unten aufgeführten Leistungsfunktionen angezeigt.

Datenintegrationseinheiten

Eine Datenintegrationseinheit ist eine Messgröße für die Leistungsfähigkeit (Kombination aus zugeteilten CPU-, Speicher- und Netzwerkressourcen) einer einzelnen Einheit innerhalb des Diensts. Die Datenintegrationseinheit gilt nur für die Azure-Integration Runtime, aber nicht für selbstgehostete Integration Runtimes.

Die zulässige Anzahl von DIUs für die Ausführung einer Copy-Aktivität liegt zwischen 4 und 256. Wenn diese Option nicht angegeben ist oder Sie auf der Benutzeroberfläche „Auto“ auswählen, wendet der Dienst dynamisch die optimale DIU-Einstellung auf dem Quelle-Senke-Paar und dem Datenmuster basierend an. In der nachstehenden Tabelle sind die unterstützten DIU-Bereiche und das Standardverhalten in verschiedenen Kopierszenarien aufgeführt:

Sie können die für die einzelnen Kopiervorgänge verwendeten DIUs in der Überwachungsansicht der Kopieraktivität oder der Aktivitätsausgabe anzeigen. Weitere Informationen finden Sie unter Überwachung der Kopieraktivität. Wenn Sie diese Standardeinstellung überschreiben möchten, geben Sie einen Wert für die Eigenschaft dataIntegrationUnits wie folgt an. Die tatsächliche Anzahl von DIUs, die der Kopiervorgang zur Laufzeit verwendet, entspricht maximal dem konfigurierten Wert. Dies ist abhängig von Ihrem Datenmuster.

Ihnen wird die Anzahl der verwendeten DIUs * Kopierdauer * Einheitenpreis/DIU-Stunde in Rechnung gestellt. Sehen Sie sich hier die aktuellen Preise an. Je nach Abonnementtyp können lokale Währungen und separate Rabatte gelten.

Beispiel:

"activities":[
    {
        "name": "Sample copy activity",
        "type": "Copy",
        "inputs": [...],
        "outputs": [...],
        "typeProperties": {
            "source": {
                "type": "BlobSource",
            },
            "sink": {
                "type": "AzureDataLakeStoreSink"
            },
            "dataIntegrationUnits": 128
        }
    }
]

Skalierbarkeit der selbstgehosteten Integration Runtime (IR)

Wenn Sie einen höheren Durchsatz erreichen möchten, können Sie die selbstgehostete IR zentral oder horizontal hochskalieren:

• Wenn die CPU und der verfügbare Arbeitsspeicher auf dem Knoten der selbstgehosteten IR nicht vollständig genutzt werden, bei der Ausführung paralleler Aufträge aber das Limit erreicht wird, sollten Sie eine zentrale Hochskalierung durchführen, indem Sie die Anzahl der parallelen Aufträge vergrößern, die auf einem Knoten ausgeführt werden können. Anweisungen dazu finden Sie hier.
• Ist jedoch die CPU-Auslastung auf dem Knoten der selbstgehosteten IR hoch oder der verfügbare Arbeitsspeicher gering, können Sie einen neuen Knoten hinzufügen, um die Last über mehrere Knoten horizontal zu skalieren. Anweisungen dazu finden Sie hier.

Beachten Sie in den folgenden Szenarien, dass bei der Ausführung einer einzelnen Kopieraktivität mehrere Knoten einer selbstgehosteten IR genutzt werden können:

• Kopieren Sie Daten aus dateibasierten Speichern, je nach Anzahl und Größe der Dateien.
• Kopieren von Daten aus einem Datenspeicher mit aktivierter Partitionsoption (einschließlich Azure SQL-Datenbank, Azure SQL Managed Instance, Azure Synapse Analytics, Oracle, Netezza, SAP HANA, SAP Open Hub, SAP Table, SQL Server und Teradata), abhängig von der Anzahl der Datenpartitionen.

Parallele Kopie

Sie können eine parallele Kopie (parallelCopies-Eigenschaft in der JSON-Definition der Copy-Aktivität oder Degree of parallelism-Einstellung auf der Registerkarte Einstellungen der Copy-Aktivitätseigenschaften auf der Benutzeroberfläche) für die Kopieraktivität festlegen, um den Parallelismus anzugeben, den die Kopieraktivität verwenden soll. Diese Eigenschaft können Sie sich als die maximale Anzahl von Threads in der Kopieraktivität vorstellen, die parallel aus Ihrer Datenquelle lesen oder in Ihre Senkendatenspeicher schreiben.

Die parallele Kopie ist orthogonal zu Datenintegrationseinheiten oder Knoten der selbstgehosteten IR. Sie wird für alle DIUs oder Knoten der selbstgehosteten IR gezählt.

Bei jeder Ausführung einer Kopieraktivität wendet der Dienst standardmäßig die optimale Einstellung für parallele Kopien basierend auf Ihrem Quell-Senke-Paar und Datenmuster dynamisch an.

In der folgenden Tabelle wird das parallele Kopierverhalten aufgeführt:

Sie können den Standardwert jedoch überschreiben und einen Wert für die Eigenschaft parallelCopies angeben, um die Last für die Computer zu steuern, auf denen Ihre Datenspeicher gehostet werden, oder um die Kopierleistung zu optimieren. Der Wert muss eine ganze Zahl größer als oder gleich 1 sein. Zur Laufzeit verwendet die Kopieraktivität maximal den von Ihnen festgelegten Wert, um eine optimale Leistung zu erzielen.

Berücksichtigen Sie bei der Angabe eines Werts für die Eigenschaft parallelCopies die höhere Auslastung Ihrer Quell- und Senkendatenspeicher. Berücksichtigen Sie auch den Lastanstieg zur selbstgehosteten Integration Runtime, wenn die Kopieraktivität davon abhängt. Dieser Lastanstieg tritt insbesondere auf, wenn Sie über mehrere Aktivitäten oder gleichzeitige Ausführungen der gleichen Aktivitäten verfügen, die für den gleichen Datenspeicher ausgeführt werden. Wenn Sie eine Überlastung des Datenspeichers oder der selbstgehosteten Integration Runtime feststellen, verringern Sie den Wert parallelCopies, um die Last zu verringern.

Beispiel:

"activities":[
    {
        "name": "Sample copy activity",
        "type": "Copy",
        "inputs": [...],
        "outputs": [...],
        "typeProperties": {
            "source": {
                "type": "BlobSource",
            },
            "sink": {
                "type": "AzureDataLakeStoreSink"
            },
            "parallelCopies": 32
        }
    }
]

gestaffeltem Kopieren

Beim Kopieren von Daten aus einem Quelldatenspeicher in einen Senkendatenspeicher können Sie ggf. Azure Blob Storage oder Azure Data Lake Storage Gen2 als Stagingzwischenspeicher verwenden. Staging ist besonders in folgenden Fällen hilfreich:

• Sie möchten Daten aus verschiedenen Datenspeichern in Azure Synapse Analytics über PolyBase erfassen, Daten aus/in Snowflake kopieren oder Daten aus Amazon Redshift/HDFS leistungsstark erfassen. Ausführliche Informationen finden Sie unter:
  • Verwenden von PolyBase zum Laden von Daten in Azure Synapse Analytics.
  • Snowflake-Connector
  • Amazon Redshift-Connector
  • HDFS-Connector
• Aufgrund der IT-Richtlinien des Unternehmens sollten Sie mit Ausnahme der Ports 80 und 443 keine weiteren Ports in der Firewall öffnen. Ein Beispiel: Beim Kopieren von Daten aus einem lokalen Datenspeicher in eine Azure SQL-Datenbank oder Azure Synapse Analytics müssen Sie die ausgehende TCP-Kommunikation über den Port 1433 sowohl für die Windows-Firewall als auch für Ihre Unternehmensfirewall aktivieren. In diesem Szenario kann das gestaffelte Kopieren die selbstgehostete Integration Runtime nutzen, um Daten zunächst per HTTP oder HTTPS über den Port 443 in einen Stagingspeicher zu kopieren und anschließend aus dem Stagingspeicher in SQL-Datenbank oder Azure Synapse Analytics zu laden. Dadurch muss der Port 1433 nicht geöffnet werden.
• Hybriddatenverschiebungen (also das Kopieren aus einem lokalen Datenspeicher in einen Clouddatenspeicher) können bei einer langsamen Netzwerkverbindung eine Weile dauern. Zur Verbesserung der Leistung können Sie gestaffeltes Kopieren verwenden, um die Daten lokal zu komprimieren und dadurch die Verschiebung in den Stagingdatenspeicher in der Cloud zu beschleunigen. Anschließend können Sie die Daten im Stagingspeicher wieder dekomprimieren, bevor Sie sie in den Zieldatenspeicher laden.

Funktionsweise des gestaffelten Kopierens

Bei aktivierter Stagingfunktion werden die Daten zunächst aus dem Quelldatenspeicher in den Stagingspeicher kopiert (von Ihnen bereitgestelltes Azure-Blob oder Azure Data Lake Storage Gen2). Danach werden sie aus dem Staging- in den Senkendatenspeicher kopiert. Die Kopieraktivität verwaltet den zweistufigen Ablauf automatisch und löscht außerdem nach Abschluss der Datenverschiebung temporäre Daten aus dem Stagingspeicher.

Sie müssen Ihrer Azure Data Factory-Instanz in Ihrem Stagingspeicher die Berechtigung zum Löschen erteilen, sodass die temporären Daten bereinigt werden können, nachdem die Copy-Aktivität ausgeführt wurde.

Wenn Sie die Datenverschiebung unter Verwendung eines Stagingspeichers aktivieren, können Sie angeben, ob die Daten vor dem Verschieben aus dem Quelldatenspeicher in den Stagingspeicher komprimiert und dann vor dem Verschieben aus einem Zwischen- oder Stagingdatenspeicher in den Senkendatenspeicher dekomprimiert werden sollen.

Derzeit können Sie keine Daten zwischen zwei Datenspeichern kopieren, die über verschiedene selbstgehostete IRs verbunden sind, weder mit noch ohne gestaffeltes Kopieren. Für ein solches Szenario können Sie zwei explizit verkettete Kopiervorgänge konfigurieren, um von der Quelle zum Stagingspeicher und aus dem Stagingspeicher zur Senke zu kopieren.

Konfiguration

Konfigurieren Sie für die Kopieraktivität die Einstellung enableStaging, um anzugeben, ob die Daten vor dem Laden in einen Zielspeicher im Speicher bereitgestellt werden sollen. Wenn Sie enableStaging auf TRUE festlegen, müssen Sie zusätzliche Eigenschaften angeben. Diese sind in der folgenden Tabelle aufgeführt.

Hier sehen Sie eine Beispieldefinition der Kopieraktivität mit den Eigenschaften aus der obigen Tabelle:

"activities":[
    {
        "name": "CopyActivityWithStaging",
        "type": "Copy",
        "inputs": [...],
        "outputs": [...],
        "typeProperties": {
            "source": {
                "type": "OracleSource",
            },
            "sink": {
                "type": "SqlDWSink"
            },
            "enableStaging": true,
            "stagingSettings": {
                "linkedServiceName": {
                    "referenceName": "MyStagingStorage",
                    "type": "LinkedServiceReference"
                },
                "path": "stagingcontainer/path"
            }
        }
    }
]

Auswirkungen auf die Abrechnung von gestaffeltem Kopieren

Die Abrechnung basiert auf zwei Aspekten: Dauer des Kopiervorgangs und Art der Kopie.

• Wenn Sie einen Stagingspeicher während eines Cloudkopiervorgangs (d. h. Kopieren von Daten aus einem Clouddatenspeicher in einen anderen Clouddatenspeicher. Beide Phasen werden von Azure-Integration Runtime unterstützt) verwenden, gilt folgende Formel: [Gesamtkopierdauer für Schritt 1 und 2] [Einzelpreis für Cloudkopien].
• Wenn Sie Staging während eines Hybridkopiervorgangs (d. h. Kopieren von Daten aus einem lokalen Datenspeicher in einen Clouddatenspeicher. Eine Phase wird von der selbstgehosteten Integration Runtime-Infrastruktur unterstützt) verwenden, gilt folgende Formel: [Dauer des Hybridkopiervorgangs] [Einzelpreis für Hybridkopien] + [Dauer des Cloudkopiervorgangs] [Einzelpreis für Cloudkopien].

Zugehöriger Inhalt

Weitere Informationen finden Sie in den anderen Artikeln zur Kopieraktivität:

• Kopieraktivität – Übersicht
• Handbuch zur Leistung und Skalierbarkeit der Kopieraktivität
• Troubleshoot copy activity performance (Problembehandlung bei der Leistung der Kopieraktivität)
• Verwenden von Azure Data Factory zum Migrieren von Daten aus einem Data Lake oder Data Warehouse zu Azure
• Migrieren von Daten aus Amazon S3 zu Azure Storage