次の方法で共有

コピーアクティビティーのパフォーマンスのトラブルシューティング

適用対象: Azure Data Factory Azure Synapse Analytics

ヒント

Data Factory in Microsoft Fabric は、よりシンプルなアーキテクチャ、組み込みの AI、および新機能を備えた次世代のAzure Data Factoryです。 データ統合を初めて使用する場合は、Fabric Data Factory から始めます。 既存の ADF ワークロードをFabricにアップグレードして、データ サイエンス、リアルタイム分析、レポートの新機能にアクセスできます。

この記事では、Azure Data Factoryのコピー アクティビティのパフォーマンスの問題をトラブルシューティングする方法について説明します。

コピー アクティビティを実行した後、コピー アクティビティのモニタリング ビューで、実行結果とパフォーマンスの統計情報を収集できます。 次のイメージは一例を示しています。

コピー アクティビティの実行詳細を監視

パフォーマンスのチューニングのヒント

一部のシナリオでは、Copy アクティビティを実行するときに、前の図に示すように、上部に [パフォーマンス チューニングのヒント] が表示されます。 このヒントでは、この特定のコピーの実行に対してサービスが特定したボトルネックと、コピーのスループットを向上させる方法についての提案を示しています。 推奨されている変更を行ってみてから、コピーを再度実行してください。

参考として、現在、パフォーマンス チューニングのヒントには、次のような場合の提案が示されています。

カテゴリ パフォーマンスのチューニングのヒント
データ ストア固有 Azure Synapse Analytics へのデータの読み込み: PolyBase ステートメントまたは COPY ステートメントをまだ使用していない場合は、使用することをお勧めします。
  Azure SQL Database へのデータのコピー: DTU の使用率が高い場合は、上位レベルにアップグレードすることをお勧めします。
  Azure Cosmos DBへのデータのコピー: RUの使用率が高い場合は、より大きなRUにアップグレードすることをお勧めします。
SAP テーブルからのデータのコピー: 大量のデータをコピーする場合は、SAP コネクタのパーティション オプションを使って並列読み込みを有効にし、最大パーティション数を増やすことをお勧めします。
  Amazon Redshiftからデータを取り込み: 使用されていない場合は、UNLOAD を使用することをお勧めします。
データ ストアの調整 コピー中にデータ ストアによって多数の読み取り/書き込み操作が抑制される場合は、データ ストアに対して許可されている要求レートを調べて増やすか、同時実行ワークロードを減らすことをお勧めします。
統合ランタイム セルフホステッド Integration Runtime (IR)を使用し、IR で使用可能なリソースが実行されるまでコピー アクティビティがキューで長時間待機する場合は、IR のスケールアウト/アップを提案します。
  Azure Integration Runtimeが最適でないリージョンで読み取り/書き込みが遅くなる場合は、別のリージョンで IR を使用するように構成することをお勧めします。
障害耐性 フォールト トレランスを構成し、互換性のない行をスキップすると、パフォーマンスが低下します。ソースとシンクのデータに互換性があることを確認することをお勧めします。
ステージング コピー ステージング コピーが構成されていても、ソースシンク ペアには役に立たない場合は、削除することをお勧めします。
履歴書 コピー アクティビティが最後の障害点から再開されたが、元の実行後に DIU 設定を偶然に変更した場合は、新しい DIU 設定が有効にならないことに注意してください。

コピー アクティビティの実行の詳細を理解する

コピー アクティビティの監視ビューの下部にある [実行の詳細] と [期間] には、コピー アクティビティが通過するキー ステージが記述されています (この記事の冒頭にある例を参照してください)。これは、コピーのパフォーマンスのトラブルシューティングに特に役立ちます。 コピー実行のボトルネックは、実行時間が最も長いものです。 各ステージの定義に関する次の表を参照し、この情報を使用してAzure IRでのコピーアクティビティのトラブルシューティングおよびセルフホステッドIRでのコピーアクティビティのトラブルシューティング方法を学習してください。

段階 説明
キュー コピー アクティビティが統合ランタイムで実際に開始されるまでの経過時間。
コピー前スクリプト Copy アクティビティが IR で開始してから、Copy アクティビティによるシンク データ ストアでのコピー前スクリプトの実行が終了するまでの経過時間。 たとえば、新しいデータをコピーする前にクリーンアップを行うAzure SQL Databaseにデータを書き込むときに、データベース シンクの事前コピー スクリプトを構成するときに適用されます。
転送 前のステップが終了してから、IR がソースからシンクにすべてのデータを転送するまでの経過時間。
転送のサブステップは並列に実行され、一部の操作 (ファイル形式の解析や生成など) は現在表示されないことに注意してください。

- 1 バイト目にかかる時間: ( )前の手順が終了してから、IR がソース データ ストアから最初のバイトを受信するまでの経過時間。 ファイルベース以外のソースに適用されます。
- ソースのリスト: ソース ファイルまたはデータ パーティションを列挙するために費やされた時間。 後者は、Oracle/SAP HANA/Teradata/Netezza などのデータベースからデータをコピーする場合など、データベース ソースのパーティション オプションを構成する場合に適用されます。
- ソースからの読み取り: ソース データ ストアからデータを取得するために費やされた時間。
- シンクへの書き込み: シンク データ ストアにデータを書き込むために費やされた時間。 現時点では、Azure AI 検索、Azure Data Explorer、Azure Table Storage、Oracle、SQL Server、Common Data Service、Dynamics 365、Dynamics CRM、Salesforce/Salesforce Service Cloud など、一部のコネクタにはこのメトリックが含まれていないことに注意してください.

Azure IR でのコピー アクティビティのトラブルシューティング

パフォーマンス チューニングの手順 に従って、シナリオのパフォーマンステストを計画および実施します。

コピー アクティビティのパフォーマンスが期待を満たしていない場合は、Azure Integration Runtimeで実行されている単一のコピー アクティビティのトラブルシューティングを行います。パフォーマンスチューニングのヒントコピー監視ビューに表示されている場合は、提案を適用して、もう一度やり直してください。 それ以外の場合は、コピー アクティビティの実行の詳細を理解し、最長 期間を持つステージを確認し、以下のガイダンスを適用してコピーのパフォーマンスを向上させます。

  • "コピー前スクリプト" に長い時間がかかっています: シンク データベースで実行されているコピー前スクリプトが完了するまでに時間がかかることを意味します。 パフォーマンスを向上させるには、指定されたコピー前スクリプトのロジックを調整します。 スクリプトの改善についてさらに支援が必要な場合は、データベース チームにお問い合わせください。

  • "転送 - 最初のバイトまでの時間" で長い作業時間が発生しました。ソース クエリがデータを返すのに長い時間がかかります。 これは、ソースが他のタスクでビジー状態になっているか、クエリが最適でない、またはデータが取得に時間がかかるように格納されるため、ソースでクエリの処理に時間がかかることを意味する可能性があります。 そのソースで他のクエリが同時に実行されているか、またはクエリに対して更新を行ってデータをより迅速に取得できるかどうかを検討します。 データ ソースを管理するチームがある場合は、そのチームに連絡してクエリを変更するか、ソースのパフォーマンスを確認してください。

  • "転送 - リスト ソース" の作業時間が長くなっています: これは、ソース ファイルまたはソース データベースのデータ パーティションの列挙に時間がかかることを意味します。

    • ファイルベースのソースからデータをコピーする場合、フォルダー パスまたはファイル名 ( または wildcardFolderPath) で wildcardFileName を使用するか、ファイルの最終変更時刻フィルター (modifiedDatetimeStart またはmodifiedDatetimeEnd) を使用すると、このようなフィルターにより、指定したフォルダーにあるすべてのファイルがクライアント側にリスト化されます。 このようなファイル列挙は、フィルター規則に一致するファイルのセットが少数しかない場合に、特にボトルネックになる可能性があります。

      • datetime パーティション分割されたファイルパスまたは名前に基づいてファイルをコピーできるかどうかを確認します。 このような方法では、ソース側のリスト化に負担がかかりません。

      • 代わりに、データ ストアのネイティブ フィルター (Amazon S3/Azure Blob Storage/Azure Files の場合は "prefix"、ADLS Gen1 の場合は "listAfter/listBefore" を使用できるかどうかを確認します。 これらのフィルターはデータ ストアのサーバー側フィルターであり、パフォーマンスが向上します。

      • 単一の大きなデータ セットをいくつかの小さいデータ セットに分割し、それらのコピー ジョブをデータの各部分の処理と同時に実行することを検討してください。 これは、Lookup/GetMetadata + ForEach + Copy を使用して行うことができます。 一般的な例として、「複数のコンテナーからファイルをコピーする」 または 「Amazon S3 から ADLS Gen2 ソリューションテンプレートにデータを移行する」を参照してください。

    • サービスがソースでスロットリングエラーを報告しているか、またはデータストアが高負荷状態にあるかどうかを確認します。 その場合は、データ ストアのワークロードを減らすか、データ ストアの管理者に連絡して調整制限または使用可能なリソースを増やしてみてください。

    • Azure IR は、ソース データ ストア リージョンと同じまたは近くに使用します。

  • "転送 - ソースからの読み取り" に長い時間がかかっています:

    • 適用する場合は、コネクタ固有のデータ読み込みのベスト プラクティスを採用します。 たとえば、Amazon Redshiftからデータをコピーする場合は、Redshift UNLOAD を使用するように構成します。

    • サービスがソースで調整エラーを報告するかどうか、またはデータ ストアの使用率が高いかどうかを確認します。 その場合は、データ ストアのワークロードを減らすか、データ ストアの管理者に連絡して調整制限または使用可能なリソースを増やしてみてください。

    • コピー ソースとシンク パターンを確認します。

    • Azure IR は、ソース データ ストア リージョンと同じまたは近くに使用します。

  • "転送 - シンクへの書き込み" で、長い処理時間がかかっている:

    • 適用する場合は、コネクタ固有のデータ読み込みのベスト プラクティスを採用します。 たとえば、データを Azure Synapse Analytics にコピーする場合は、PolyBase または COPY ステートメントを使用します。

    • サービスがシンクで調整エラーを報告するかどうか、またはデータ ストアの使用率が高いかどうかを確認します。 その場合は、データ ストアのワークロードを減らすか、データ ストアの管理者に連絡して調整制限または使用可能なリソースを増やしてみてください。

    • コピー ソースとシンク パターンを確認します。

      • コピー パターンでサポートされているデータ統合ユニット (DIU) が 4 より多い場合、詳しくはこちらのセクションをご覧ください。通常、DIU を増やしてパフォーマンスが向上するか試すことができます。

      • それ以外の場合は、並列コピーを少しずつ調整します。 並列コピーが多すぎると、パフォーマンスが低下する可能性があります。

    • シンク データ ストアリージョンと同じまたは近いAzure IR を使用します。

セルフホステッド IR でのコピー アクティビティのトラブルシューティング

パフォーマンス チューニングの手順 に従って、シナリオのパフォーマンステストを計画および実施します。

コピーのパフォーマンスが期待を満たしていない場合は、Azure Integration Runtimeで実行されている単一のコピー アクティビティのトラブルシューティングを行います。パフォーマンスチューニングのヒントコピー監視ビューに表示されている場合は、提案を適用して、もう一度やり直してください。 それ以外の場合は、コピー アクティビティの実行の詳細を理解し、最長 期間を持つステージを確認し、以下のガイダンスを適用してコピーのパフォーマンスを向上させます。

  • "Queue" に長い時間がかかっています: 実行に必要なリソースをセルフホステッド IR が確保するまで、コピー アクティビティがキュー内で長時間待機していることを意味します。 IR の容量と使用量を確認し、ワークロードに応じて スケールアップまたはスケールアウトします。

  • "転送 - 最初のバイトまでの転送時間" に長い時間がかかっています: ソース クエリで任意のデータが返されるまでに時間がかかることを意味します。 クエリまたはサーバーを確認して最適化します。 さらに支援が必要な場合は、データ ストア チームにお問い合わせください。

  • "転送 - リスト ソース" の作業時間が長くなっています: これは、ソース ファイルまたはソース データベースのデータ パーティションの列挙に時間がかかることを意味します。

    • セルフホスティッド IR マシンのソースデータストアへの接続の待機時間が短いかどうかを確認してください。 ソースがAzureにある場合は、このツールを使用して、セルフホステッド IR マシンから Azure リージョンまでの待機時間を確認できます。値が低いほど良くなります。

    • ファイルベースのソースからデータをコピーする場合、フォルダー パスまたはファイル名 ( または wildcardFolderPath) で wildcardFileName を使用するか、ファイルの最終変更時刻フィルター (modifiedDatetimeStart またはmodifiedDatetimeEnd) を使用すると、このようなフィルターにより、指定したフォルダーにあるすべてのファイルがクライアント側にリスト化されます。 このようなファイル列挙は、フィルター規則に一致するファイルのセットが少数しかない場合に、特にボトルネックになる可能性があります。

      • datetime パーティション分割されたファイルパスまたは名前に基づいてファイルをコピーできるかどうかを確認します。 このような方法では、ソース側のリスト化に負担がかかりません。

      • 代わりに、データ ストアのネイティブ フィルター (Amazon S3/Azure Blob Storage/Azure Files の場合は "prefix"、ADLS Gen1 の場合は "listAfter/listBefore" を使用できるかどうかを確認します。 これらのフィルターはデータ ストアのサーバー側フィルターであり、パフォーマンスが向上します。

      • 単一の大きなデータ セットをいくつかの小さいデータ セットに分割し、それらのコピー ジョブをデータの各部分の処理と同時に実行することを検討してください。 これは、Lookup/GetMetadata + ForEach + Copy を使用して行うことができます。 一般的な例として、「複数のコンテナーからファイルをコピーする」 または 「Amazon S3 から ADLS Gen2 ソリューションテンプレートにデータを移行する」を参照してください。

    • サービスがソースでスロットリングエラーを報告しているか、またはデータストアが高負荷状態にあるかどうかを確認します。 その場合は、データ ストアのワークロードを減らすか、データ ストアの管理者に連絡して調整制限または使用可能なリソースを増やしてみてください。

  • "転送 - ソースからの読み取り" に長い時間がかかっています:

    • セルフホスティッド IR マシンのソースデータストアへの接続の待機時間が短いかどうかを確認してください。 ソースがAzureにある場合は、このツールを使用して、セルフホステッド IR マシンから Azure リージョンまでの待機時間を確認できます。値が低いほど良くなります。

    • データの読み取りと転送を効率的に行うために、セルフホステッド IR マシンに十分な受信帯域幅があるかどうかを確認します。 ソース データ ストアがAzureにある場合は、このツールを使用してダウンロード速度を確認できます。

    • Azure ポータルのデータ ファクトリまたは Synapse ワークスペースの概要ページで、セルフホステッド IR の CPU とメモリの使用率の傾向を確認します。 CPU 使用率が高い場合、または使用可能なメモリが少ない場合は、IR のスケールアップ/スケールアウト を検討してください。

    • 当てはまる場合は、コネクタ固有のデータ読み込みのベスト プラクティスを採用します。 次に例を示します。

      • Oracle、Netezza Teradata、SAP HANA、SAP Table、および SAP Open Hub) を有効にすると、データ パーティション オプションでデータを並列にコピーできます。

      • HDFSからデータをコピーする場合は、DistCp を使用するように構成します。

      • 例えば、Amazon Redshift からデータをコピーする場合は、Redshift UNLOAD を使用するように構成します。

    • サービスがソースで調整エラーを報告するかどうか、またはデータ ストアの使用率が高いかどうかを確認します。 その場合は、データ ストアのワークロードを減らすか、データ ストアの管理者に連絡して調整制限または使用可能なリソースを増やしてみてください。

    • コピー ソースとシンク パターンを確認します。

  • "転送 - シンクへの書き込み" で、長い処理時間がかかっている:

    • 適用する場合は、コネクタ固有のデータ読み込みのベスト プラクティスを採用します。 たとえば、データを Azure Synapse Analytics にコピーする場合は、PolyBase または COPY ステートメントを使用します。

    • シンク データ ストアへの接続において、セルフホステッド IR マシンのレイテンシが低いかどうかを確認してください。 シンクがAzure内にある場合は、このツールを使用して、セルフホステッド IR マシンから Azure リージョンまでの待機時間を確認できます。

    • セルフホステッド IR マシンに、データの転送とデータ書き込みを効率的に行うための十分な送信帯域幅があるかどうかを確認します。 シンク データ ストアがAzureにある場合は、このツールを使用してアップロード速度を確認できます。

    • Azure portal -> データ ファクトリまたは Synapse ワークスペース -> 概要ページで、セルフホステッド IR の CPU とメモリの使用量の傾向を確認します。 CPU 使用率が高い場合、または使用可能なメモリが少ない場合は、IR のスケールアップ/スケールアウト を検討してください。

    • サービスがシンクで調整エラーを報告するかどうか、またはデータ ストアの使用率が高いかどうかを確認します。 その場合は、データ ストアのワークロードを減らすか、データ ストアの管理者に連絡して調整制限または使用可能なリソースを増やしてみてください。

    • 並列コピーを少しずつ調整することを検討します。 並列コピーが多すぎると、パフォーマンスが低下する可能性があります。

コネクタと IR のパフォーマンス

このセクションでは、特定のコネクタの種類または統合ランタイムに関するパフォーマンスのトラブルシューティング ガイドをいくつか紹介します。

アクティビティの実行時間は、Azure IR と仮想ネットワーク IR Azure使用して異なります

アクティビティの実行時間は、データセットが異なるIntegration Runtimeに基づいている場合に異なります。

  • 現象:データセット内で [リンクされたサービス] ドロップダウンを切り替えるだけで、同じパイプライン アクティビティが実行されますが、実行時間は大幅に異なります。 データセットがマネージド・バーチャル・ネットワーク・インテグレーション・ランタイムに基づいている場合は、既定のインテグレーション・ランタイムに基づく場合より、平均して時間がかかります。

  • Cause: パイプラインの実行の詳細を確認すると、低速パイプラインはマネージド Virtual Network IR で実行されており、通常のものは Azure IR で実行されていることがわかります。 設計上、マネージド仮想ネットワーク IR は、サービス インスタンスごとに 1 つのコンピューティング ノードを予約しないため、Azure IR よりも長いキュー時間を要するため、開始するコピー アクティビティごとにウォームアップが発生し、主に Azure IR ではなく仮想ネットワーク参加で発生します。

Azure SQL Databaseにデータを読み込む際のパフォーマンスが低い

  • Symptoms: Azure SQL Databaseへのデータのコピーが遅くなります。

  • Cause: 問題の根本原因は、主にAzure SQL Database側のボトルネックによってトリガーされます。 以下のいくつかの原因が考えられます。

    • Azure SQL Databaseレベルが十分に高くありません。

    • Azure SQL Database DTU の使用量は 100%に近い。 パフォーマンスを監視し、Azure SQL Databaseの層をアップグレードすることを検討できます。

    • インデックスが正しく設定されていません。 データが読み込まれる前にすべてのインデックスを削除し、読み込みの完了後に再作成します。

    • WriteBatchSize が、スキーマ行のサイズに適合するのに十分な大きさではありません。 問題のプロパティを拡張してみてください。

    • 一括挿入ではなく、ストアド プロシージャが使用されているため、パフォーマンスが低下することが予想されます。

大きなExcel ファイルを解析するときのタイムアウトまたはパフォーマンスの低下

  • 症状:

    • データセットExcel作成し、接続/ストア、プレビュー データ、リスト、または更新ワークシートからスキーマをインポートすると、excel ファイルのサイズが大きい場合にタイムアウト エラーが発生する可能性があります。

    • コピー アクティビティを使用して、大きなExcel ファイル (>= 100 MB) から他のデータ ストアにデータをコピーすると、パフォーマンスが低下したり、OOM の問題が発生したりする可能性があります。

  • 原因:

    • スキーマのインポート、データのプレビュー、Excel データセットでのワークシートの一覧表示などの操作の場合。 タイムアウトは 100 秒で一定です。 大きなExcel ファイルの場合、これらの操作はタイムアウト値内で完了しない可能性があります。

    • コピー アクティビティは、Excel ファイル全体をメモリに読み取り、指定したワークシートとセルを見つけてデータを読み取ります。 サービスが使用する基盤となる SDK のために、このような動作になります。

  • 解決方法:

    • スキーマをインポートする場合は、元のファイルのサブセットとなるより小さいサンプル ファイルを生成し、[接続/ストアからスキーマをインポートする] ではなく、[サンプル ファイルからスキーマをインポートする] を選択します。

    • ワークシートの一覧を表示する場合は、ワークシートのドロップダウンで [編集] を選んで、代わりにシート名とインデックスを入力できます。

    • 他のストアに大きなExcelファイル（>100 MB）をコピーするには、ストリーミング読み取りをサポートしてパフォーマンスを向上させるData Flow Excelソースを使用できます。

大きな JSON/Excel/XML ファイルの読み取りの OOM の問題

  • Symptoms: 大きな JSON/Excel/XML ファイルを読み取ると、アクティビティの実行中にメモリ不足 (OOM) の問題が発生します。

  • 原因:

    • 大きな XML ファイルの場合: 大きな XML ファイルの読み取りの OOM の問題は仕様です。 原因は、XML ファイル全体を 1 つのオブジェクトとしてメモリに読み込む必要があり、その後スキーマが推論され、データが取得されることです。
    • 大きなExcel ファイルの場合: 大きなExcel ファイルを読み取る OOM の問題は仕様です。 原因は、使用する SDK (POI/NPOI) が Excel ファイル全体をメモリに読み込み、スキーマを推論してデータを取得する必要があることです。
    • 大きな JSON ファイルの場合: 大きな JSON ファイルの読み取りの OOM の問題は、JSON ファイルが 1 つのオブジェクトである場合は仕様です。

  • 推奨事項: 問題を解決するには、次のいずれかのオプションを適用します。

    • オプション 1: オンライン セルフホステッド統合ランタイムを強力なマシン (高 CPU/メモリ) に登録して、コピー アクティビティを通じて大きなファイルからデータを読み取ります。
    • オプション 2: 最適化されたメモリと大きいサイズのクラスター (例: 48 コア) を使用して、マッピング データ フロー アクティビティを通じて大きなファイルからデータを読み取ります。
    • オプション 3: 大きなファイルを小さいファイルに分割し、コピー アクティビティまたはマッピング データ フロー アクティビティを使用してフォルダーを読み取ります。
    • Option-4: XML/Excel/JSON フォルダーのコピー中に OOM の問題が発生した場合、パイプラインの foreach アクティビティ + コピー/マッピング データ フロー アクティビティを使用して、各ファイルまたはサブフォルダーを処理します。
    • オプション 5: その他:
      • XML の場合は、メモリ最適化クラスターで Notebook アクティビティを使用して、各ファイルに同じスキーマがある場合にファイルからデータを読み取ります。 現在、Spark では XML を処理するための実装が異なります。
      • JSON の場合は、マッピング データ フロー ソースの JSON 設定で、さまざまなドキュメント フォーム (たとえば、[Single document] (1 つのドキュメント)、[Document per line] (1 行ごとのドキュメント)、[Array of documents] (ドキュメントの配列)) を使用します。 JSON ファイルの内容が 1 行ごとのドキュメントの場合、メモリはほとんど使われません。

その他のリファレンス

ここでは、サポートされているいくつかのデータ ストアについて、パフォーマンスの監視とチューニングに関するリファレンス情報を示します。

関連するコンテンツ

コピー アクティビティの他の記事を参照してください。

  • Last updated on