コピー アクティビティのパフォーマンスとチューニングに関するガイドCopy activity performance and tuning guide

Azure Data Factory コピー アクティビティは、優れたセキュリティで保護された、信頼性とパフォーマンスに優れたデータ読み込みソリューションを提供します。The Azure Data Factory copy activity delivers a first-class secure, reliable, and high-performance data loading solution. これを利用することで、数十テラバイトのデータを、さまざまなクラウドとオンプレミスのデータ ストアの間で毎日コピーできます。You can use it to copy tens of terabytes of data every day across a rich variety of cloud and on-premises data stores. データ読み込みのパフォーマンスを高めることは、高度な分析ソリューションを構築してすべてのデータから深い洞察を得るという、ビッグ データの中心的問題に集中するための鍵となります。Fast data-loading performance is key to ensure that you can focus on the core big data problem: building advanced analytics solutions and getting deep insights from all that data.

Azure からは、一連の大企業規模のデータ ストレージとデータ ウェアハウス ソリューションが提供されます。Azure provides a set of enterprise-grade data storage and data warehouse solutions. コピー アクティビティでは、データの読み込みが高度に最適化されており、構成や設定が簡単です。The copy activity offers a highly optimized data loading experience that's easy to configure and set up. 1 回のコピー アクティビティで次のようにデータを読み込むことができます。With a single copy activity, you can load data into:

  • Azure SQL Data Warehouse に 1.2 GBps で。Azure SQL Data Warehouse at 1.2 GBps.
  • Azure BLOB ストレージに 1.0 GBps で。Azure Blob storage at 1.0 GBps.
  • Azure Data Lake Store に 1.0 GBps で。Azure Data Lake Store at 1.0 GBps.

この記事では、次の内容について説明します。This article describes:

注意

コピー アクティビティ全般に慣れていない場合は、この記事を読む前に、コピー アクティビティの概要に関するページを参照してください。If you aren't familiar with the copy activity in general, see the copy activity overview before you read this article.

パフォーマンス リファレンスPerformance reference

参考として、社内テストに基づいて、1 回のコピー アクティビティの実行での特定のソースとシンクのペアにおけるコピー スループット (MBps 単位) を次の表に示します。As a reference, the following table shows the copy throughput number in MBps for the given source and sink pairs in a single copy activity run based on in-house testing. 比較のために、データ統合単位またはセルフホステッド統合ランタイムのスケーラビリティ (複数のノード) の異なる設定によって、コピーのパフォーマンスがどのように変化するかも示しています。For comparison, it also demonstrates how different settings of Data Integration Units or self-hosted integration runtime scalability (multiple nodes) can help on copy performance.

パフォーマンス マトリックス

重要

コピー アクティビティが Azure Integration Runtime で実行される場合、許可される最小のデータ統合単位 (旧称: データ移動単位) は 2 です。When the copy activity runs on an Azure integration runtime, the minimal allowed Data Integration Units (formerly known as Data Movement Units) is two. 指定しない場合に使用される既定のデータ統合単位については、「データ統合単位」をご覧ください。If not specified, see the default Data Integration Units being used in Data Integration Units.

注意する点:Points to note:

  • スループットの計算には、[ソースから読み取られたデータ サイズ]/[コピー アクティビティの実行時間] という数式を使用します。Throughput is calculated by using the following formula: [size of data read from source]/[copy activity run duration].
  • 表のパフォーマンスの参考数値は、1 回のコピー アクティビティ実行で TPC-H データセットを使用して測定されました。The performance reference numbers in the table were measured by using a TPC-H dataset in a single copy activity run. ファイル ベースのストア用のテスト ファイルは、サイズが 10 GB の複数のファイルです。Test files for file-based stores are multiple files with 10 GB in size.
  • Azure データ ストアでは、ソースとシンクは同じ Azure リージョンにあります。In Azure data stores, the source and sink are in the same Azure region.
  • オンプレミスとクラウドのデータ ストア間のハイブリッド コピーの場合、各セルフホステッド統合ランタイム ノードは、次の仕様でデータストアとは別のマシンで実行されました。For hybrid copy between on-premises and cloud data stores, each self-hosted integration runtime node was running on a machine that was separate from the data store with the following specification. 1 つのアクティビティの実行中、コピー操作で使用されたのは、テスト コンピューターの CPU、メモリ、またはネットワーク帯域幅のごく一部だけでした。When a single activity was running, the copy operation consumed only a small portion of the test machine's CPU, memory, or network bandwidth.
    CPUCPU 32 コア 2.20 GHz Intel Xeon E5-2660 v232 cores 2.20 GHz Intel Xeon E5-2660 v2
    メモリMemory 128 GB128 GB
    ネットワークNetwork インターネット インターフェイス: 10 Gbps、イントラネット インターフェイス: 40 GbpsInternet interface: 10 Gbps; intranet interface: 40 Gbps

ヒント

使用する DIU を増やすと、より高いスループットを実現できます。You can achieve higher throughput by using more DIUs. たとえば、100 DIU にすると、Azure BLOB ストレージから Azure Data Lake Store に 1.0 Gbps でデータをコピーできます。For example, with 100 DIUs, you can copy data from Azure Blob storage into Azure Data Lake Store at 1.0 GBps. この機能の詳細とサポートされるシナリオについては、「データ統合単位」セクションをご覧ください。For more information about this feature and the supported scenario, see the Data Integration Units section.

データ統合単位Data Integration Units

データ統合単位は、Azure Data Factory の 1 つの単位の能力 (CPU、メモリ、ネットワーク リソース割り当ての組み合わせ) を表す尺度です。A Data Integration Unit is a measure that represents the power (a combination of CPU, memory, and network resource allocation) of a single unit in Azure Data Factory. データ統合単位は Azure 統合ランタイムにのみ適用され、セルフホステッド統合ランタイムには適用されません。Data Integration Unit only applies to Azure integration runtime, but not self-hosted integration runtime.

コピー アクティビティの実行を支援する最小限の DIU は 2 です。The minimal DIUs to empower a copy activity run is two. 指定しない場合、次の表に、さまざまなコピー シナリオで使用される既定の DIU を示します。If not specified, the following table lists the default DIUs used in different copy scenarios:

コピー シナリオCopy scenario サービスによって決定される既定の DIUDefault DIUs determined by service
ファイル ベースのストア間でのデータのコピーCopy data between file-based stores ファイルの数とサイズに応じて 4 〜 32。Between 4 and 32 depending on the number and size of the files
Azure SQL Database または Azure Cosmos DB にデータをコピーするCopy data to Azure SQL Database or Azure Cosmos DB シンクの Azure SQL Database または Cosmos DB の層 (DTU/RU の数) に応じて 4 から 16。Between 4 and 16 depending on the sink Azure SQL Database's or Cosmos DB's tier (number of DTUs/RUs)
その他すべてのコピー シナリオAll the other copy scenarios 44

この既定の動作をオーバーライドするには、dataIntegrationUnits プロパティに次のように値を指定します。To override this default, specify a value for the dataIntegrationUnits property as follows. dataIntegrationUnits プロパティの許容値は最大 256 です。The allowed values for the dataIntegrationUnits property is up to 256. コピー操作が実行時に使用する DIU の実際の数は、データ パターンに応じて、構成されている値以下になります。The actual number of DIUs that the copy operation uses at run time is equal to or less than the configured value, depending on your data pattern. 特定のコピー ソースおよびシンクに、より多くの単位を構成した場合に得られるパフォーマンス向上レベルの情報については、「 パフォーマンス リファレンス」を参照してください。For information about the level of performance gain you might get when you configure more units for a specific copy source and sink, see the performance reference.

アクティビティ実行を監視すると、コピー アクティビティ出力で、各コピーで使用された DIU を確認できます。You can see the DIUs used for each copy run in the copy activity output when you monitor an activity run. 詳細については、コピー アクティビティ監視に関するページを参照してください。For more information, see Copy activity monitoring.

注意

4 より大きい DIU の設定は現在、Azure Storage、Azure Data Lake Storage、Amazon S3、Google Cloud Storage、クラウド FTP、クラウド SFTP から他の任意のクラウド データ ストアに複数のファイルをコピーする場合にのみ適用されます。Setting of DIUs larger than four currently applies only when you copy multiple files from Azure Storage, Azure Data Lake Storage, Amazon S3, Google Cloud Storage, cloud FTP, or cloud SFTP to any other cloud data stores.

Example

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

データ統合単位の課金への影響Data Integration Units billing impact

コピー操作の合計時間に基づいて料金が請求されることにご留意ください。Remember that you're charged based on the total time of the copy operation. データ移動に対して課金される合計継続時間は、DIU 全体の継続時間を足したものになります。The total duration you're billed for data movement is the sum of duration across DIUs. これまで 1 回のコピー ジョブに 2 クラウド単位で 1 時間かかっていたのが、8 クラウド単位で 15 分かかるようになった場合、全体の請求金額はほぼ同じままです。If a copy job used to take one hour with two cloud units and now it takes 15 minutes with eight cloud units, the overall bill remains almost the same.

並列コピーParallel copy

parallelCopies プロパティを使用し、コピー アクティビティで使用する並列処理を指示できます。You can use the parallelCopies property to indicate the parallelism that you want the copy activity to use. このプロパティは、並列でソースから読み取る、またはシンク データ ストアに書き込むことができるコピー アクティビティ内の最大スレッド数と見なすことができます。You can think of this property as the maximum number of threads within the copy activity that can read from your source or write to your sink data stores in parallel.

コピー アクティビティ実行ごとに、Azure Data Factory によって、コピー元のデータ ストアからデータをコピーする際と、コピー先のデータ ストアにデータをコピーする際に使用する並列コピーの数が決定されます。For each copy activity run, Azure Data Factory determines the number of parallel copies to use to copy data from the source data store and to the destination data store. 使用する並列コピーの既定数は、使用するソースやシンクの種類に依存します。The default number of parallel copies that it uses depends on the type of source and sink that you use.

コピー シナリオCopy scenario サービスによって決定される並列コピーの既定数Default parallel copy count determined by service
ファイル ベースのストア間でのデータのコピーCopy data between file-based stores ファイルのサイズと、2 つのクラウド データ ストア間でのデータのコピーで使用される DMU の数またはセルフホステッド統合ランタイム マシンの物理構成によって異なります。Depends on the size of the files and the number of DIUs used to copy data between two cloud data stores, or the physical configuration of the self-hosted integration runtime machine.
任意のコピー元ストアから Azure Table ストレージにデータをコピーするCopy data from any source store to Azure Table storage 44
他のすべてのコピー シナリオAll other copy scenarios 11

ヒント

ファイルベースのストア間でデータをコピーするとき、通常、既定の動作で最適なスループットが与えられます。When you copy data between file-based stores, the default behavior usually gives you the best throughput. 既定の動作は、コピー元のファイル パターンに基づいて自動的に決定されます。The default behavior is auto-determined based on your source file pattern.

データ ストアをホストしているコンピューターの負荷を制御したり、コピーのパフォーマンスをチューニングしたりするには、parallelCopies プロパティの値を指定し、既定値をオーバーライドできます。To control the load on machines that host your data stores, or to tune copy performance, you can override the default value and specify a value for the parallelCopies property. 値は 1 以上の整数でなければなりません。The value must be an integer greater than or equal to 1. 実行時にコピー アクティビティは、設定された値以下でパフォーマンスが最大になる値を使用します。At run time, for the best performance, the copy activity uses a value that is less than or equal to the value that you set.

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

注意する点:Points to note:

  • ファイル ベースのストア間でデータをコピーする場合は、parallelCopies によってファイル レベルでの並列処理が決まります。When you copy data between file-based stores, parallelCopies determines the parallelism at the file level. 単一ファイル内でのチャンク化は裏で自動的かつ透過的に行われます。The chunking within a single file happens underneath automatically and transparently. 指定されたソース データ ストアの種類に最適なチャンク サイズを使用し、parallelCopies とは独立に並行してデータを読み込むよう設計されています。It's designed to use the best suitable chunk size for a given source data store type to load data in parallel and orthogonal to parallelCopies. 実行時にコピー操作でデータ移動サービスに使用される並列コピーの実際の数は、存在するファイルの数以下となります。The actual number of parallel copies the data movement service uses for the copy operation at run time is no more than the number of files you have. コピー動作が mergeFile の場合、コピー アクティビティはファイル レベルでの並列処理を活用できません。If the copy behavior is mergeFile, the copy activity can't take advantage of file-level parallelism.
  • (Oracle データベースをコピー元とし、データ パーティショニングを有効にする場合を除き) ファイル ベース以外のストアからファイル ベースのストアにデータをコピーする場合、データ移動サービスは parallelCopies プロパティを無視します。When you copy data from stores that aren't file-based (except Oracle database as source with data partitioning enabled) to stores that are file-based, the data movement service ignores the parallelCopies property. 並列処理が指定されても、この場合は適用されません。Even if parallelism is specified, it's not applied in this case.
  • parallelCopies プロパティは dataIntegrationUnits と無関係です。The parallelCopies property is orthogonal to dataIntegrationUnits. 前者はすべてのデータ統合単位全体でカウントされます。The former is counted across all the Data Integration Units.
  • parallelCopies プロパティに値を指定するとき、コピー元データ ストアとシンク データ ストアの負荷増加を考慮してください。When you specify a value for the parallelCopies property, consider the load increase on your source and sink data stores. また、ハイブリッド コピーなどで、セルフホステッド統合ランタイムによってコピー アクティビティが支援される場合、セルフホステッド統合ランタイムの負荷増加を考慮してください。Also consider the load increase to the self-hosted integration runtime if the copy activity is empowered by it, for example, for hybrid copy. この負荷増加は、特に複数のアクティビティがある場合や、同じデータ ストアに対して実行される同じアクティビティの同時実行がある場合に発生します。This load increase happens especially when you have multiple activities or concurrent runs of the same activities that run against the same data store. データ ストアまたはセルフホステッド統合ランタイムの負荷の上限に達したことがわかった場合は、parallelCopies の値を減らし、負荷を軽減してください。If you notice that either the data store or the self-hosted integration runtime is overwhelmed with the load, decrease the parallelCopies value to relieve the load.

ステージング コピーStaged copy

ソース データ ストアからシンク データ ストアにデータをコピーする場合、中間のステージング ストアとして Blob Storage を使用できます。When you copy data from a source data store to a sink data store, you might choose to use Blob storage as an interim staging store. ステージングは、特に次のような場合に役立ちます。Staging is especially useful in the following cases:

  • PolyBase を使ってさまざまなデータ ストアから SQL Data Warehouse にデータを取り込む。You want to ingest data from various data stores into SQL Data Warehouse via PolyBase. SQL Data Warehouse は、大量のデータを読み込むための高スループットのメカニズムとして PolyBase を使用します。SQL Data Warehouse uses PolyBase as a high-throughput mechanism to load a large amount of data into SQL Data Warehouse. ソース データが Blob Storage または Azure Data Lake Store にあることと追加の条件を満たすことが必要です。The source data must be in Blob storage or Azure Data Lake Store, and it must meet additional criteria. Blob Storage または Azure Data Lake Store 以外のデータ ストアからデータを読み込む際は、中間ステージング Blob Storage 経由のデータ コピーを有効にすることができます。When you load data from a data store other than Blob storage or Azure Data Lake Store, you can activate data copying via interim staging Blob storage. その場合、Azure Data Factory は、PolyBase の要件を満たすために必要なデータ変換を実行します。In that case, Azure Data Factory performs the required data transformations to ensure that it meets the requirements of PolyBase. その後、PolyBase を使用して、効率的にデータを SQL Data Warehouse に読み込みます。Then it uses PolyBase to load data into SQL Data Warehouse efficiently. 詳細については、「PolyBase を使用して Azure SQL Data Warehouse にデータを読み込む」を参照してください。For more information, see Use PolyBase to load data into Azure SQL Data Warehouse.
  • ネットワーク接続が遅い場合、ハイブリッド データ移動 (オンプレミス データ ストアからクラウド データ ストアへのコピー) の実行に少し時間がかかる場合がある。Sometimes it takes a while to perform a hybrid data movement (that is, to copy from an on-premises data store to a cloud data store) over a slow network connection. パフォーマンスを向上させるため、ステージング コピーを使用してオンプレミスのデータを圧縮することで、クラウド内のステージング データ ストアにデータを移動する時間を短縮できます。To improve performance, you can use staged copy to compress the data on-premises so that it takes less time to move data to the staging data store in the cloud. その後、データは、ターゲット データ ストアに読み込む前に、ステージング ストアで圧縮を解除できます。Then you can decompress the data in the staging store before you load into the destination data store.
  • 企業の IT ポリシーが理由で、ファイアウォールでポート 80 とポート 443 以外のポートを開きたくない。You don't want to open ports other than port 80 and port 443 in your firewall because of corporate IT policies. たとえば、オンプレミス データ ストアから Azure SQL Database シンクまたは SQL Data Warehouse シンクにデータをコピーする場合、Windows ファイアウォールと会社のファイアウォールの両方で、ポート 1433 の送信 TCP 通信を有効にする必要があります。For example, when you copy data from an on-premises data store to an Azure SQL Database sink or an Azure SQL Data Warehouse sink, you need to activate outbound TCP communication on port 1433 for both the Windows firewall and your corporate firewall. このシナリオでは、ステージング コピーは、セルフホステッド統合ランタイムを利用して、まずポート 443 で HTTP または HTTPS 経由で Blob Storage ステージング インスタンスにデータをコピーします。In this scenario, staged copy can take advantage of the self-hosted integration runtime to first copy data to a Blob storage staging instance over HTTP or HTTPS on port 443. 次に、Blob Storage ステージングから SQL Database または SQL Data Warehouse にデータを読み込みます。Then it can load the data into SQL Database or SQL Data Warehouse from Blob storage staging. このフローでは、ポート 1433 を有効にする必要はありません。In this flow, you don't need to enable port 1433.

ステージング コピーのしくみHow staged copy works

ステージング機能を有効にすると、最初にデータがソース データ ストアからステージング Blob Storage (独自に用意) にコピーされます。When you activate the staging feature, first the data is copied from the source data store to the staging Blob storage (bring your own). 次に、データは、ステージング データ ストアからシンク データ ストアにコピーされます。Next, the data is copied from the staging data store to the sink data store. Azure Data Factory では、2 段階のフローが自動的に管理されます。Azure Data Factory automatically manages the two-stage flow for you. Azure Data Factory ではまた、データ移動の完了後、ステージング ストレージから一時データが消去されます。Azure Data Factory also cleans up temporary data from the staging storage after the data movement is complete.

ステージング コピー

ステージング ストアを使用したデータ移動を有効にすると、ソース データ ストアから中間またはステージング データ ストアにデータを移動する前にデータを圧縮し、中間またはステージング データ ストアからシンク データ ストアにデータを移動する前にそのデータの圧縮を解除するかどうかを指定できます。When you activate data movement by using a staging store, you can specify whether you want the data to be compressed before you move data from the source data store to an interim or staging data store and then decompressed before you move data from an interim or staging data store to the sink data store.

現在のところ、ステージング コピーの使用に関係なく、異なるセルフホステッド統合ランタイムで接続されている 2 つのデータ ストア間でデータをコピーできません。Currently, you can't copy data between two data stores that are connected via different Self-hosted IRs, neither with nor without staged copy. このようなシナリオの場合、コピー元からステージングにコピーし、その後、ステージングからシンクにコピーするよう、明示的につながれた 2 つのコピー アクティビティを構成できます。For such scenario, you can configure two explicitly chained copy activity to copy from source to staging then from staging to sink.

構成Configuration

コピー アクティビティの enableStaging 設定を構成して、目的のデータ ストアに読み込む前にデータを Blob Storage にステージングするかどうかを指定します。Configure the enableStaging setting in the copy activity to specify whether you want the data to be staged in Blob storage before you load it into a destination data store. enableStagingTRUE に設定した場合は、次の表に記載されている追加のプロパティを指定する必要があります。When you set enableStaging to TRUE, specify the additional properties listed in the following table. ステージング用に Azure Storage または Storage Shared Access Signature のリンクされたサービスがない場合は、作成する必要もあります。You also need to create an Azure Storage or Storage shared access signature-linked service for staging if you don’t have one.

プロパティProperty 説明Description 既定値Default value 必須Required
enableStagingenableStaging 中間ステージング ストアを経由してデータをコピーするかどうかを指定します。Specify whether you want to copy data via an interim staging store. FalseFalse いいえNo
linkedServiceNamelinkedServiceName AzureStorage のリンクされたサービスの名前を指定します。これは、中間ステージング ストアとして使用する Storage のインスタンスを表します。Specify the name of an AzureStorage linked service, which refers to the instance of Storage that you use as an interim staging store.

PolyBase を使用してデータを SQL Data Warehouse に読み込むために、Shared Access Signature を持つ Storage を使用することはできません。You can't use Storage with a shared access signature to load data into SQL Data Warehouse via PolyBase. それ以外のすべてのシナリオでは使用できます。You can use it in all other scenarios.
該当なしN/A はい ( enableStaging が TRUE に設定されている場合)Yes, when enableStaging is set to TRUE
pathpath ステージング データを格納する Blob Storage のパスを指定します。Specify the Blob storage path that you want to contain the staged data. パスを指定しないと、一時データを格納するコンテナーがサービスによって作成されます。If you don't provide a path, the service creates a container to store temporary data.

パスを指定するのは、Shared Access Signature を持つ Storage を使用する場合、または一時データを特定の場所に保存する必要がある場合のみです。Specify a path only if you use Storage with a shared access signature, or you require temporary data to be in a specific location.
該当なしN/A いいえNo
enableCompressionenableCompression データをコピーする前に圧縮するかどうかを指定します。Specifies whether data should be compressed before it's copied to the destination. この設定により、転送するデータの量が減ります。This setting reduces the volume of data being transferred. FalseFalse いいえNo

注意

圧縮を有効にしてステージング コピーを使用する場合、サービスとリンクされたステージング Blob でのサービス プリンシパルと MSI 認証はサポートされません。If you use staged copy with compression enabled, the service principal or MSI authentication for staging blob linked service isn't supported.

上の表に記載されているプロパティを持つコピー アクティビティの定義の例を次に示します。Here's a sample definition of a copy activity with the properties that are described in the preceding table:

"activities":[
    {
        "name": "Sample copy activity",
        "type": "Copy",
        "inputs": [...],
        "outputs": [...],
        "typeProperties": {
            "source": {
                "type": "SqlSource",
            },
            "sink": {
                "type": "SqlSink"
            },
            "enableStaging": true,
            "stagingSettings": {
                "linkedServiceName": {
                    "referenceName": "MyStagingBlob",
                    "type": "LinkedServiceReference"
                },
                "path": "stagingcontainer/path",
                "enableCompression": true
            }
        }
    }
]

ステージング コピーの課金への影響Staged copy billing impact

コピーの期間とコピーの種類という 2 つのステップに基づいて課金されます。You're charged based on two steps: copy duration and copy type.

  • クラウド コピー (クラウド データ ストアから別のクラウド データ ストアへのデータのコピー、どちらのステージも Azure 統合ランタイムで強化されている) でステージングを使用する場合、料金は、"ステップ 1 とステップ 2 のコピー時間の合計" x "クラウド コピーの単価" で計算されます。When you use staging during a cloud copy, which is copying data from a cloud data store to another cloud data store, both stages empowered by Azure integration runtime, you're charged the [sum of copy duration for step 1 and step 2] x [cloud copy unit price].
  • ハイブリッド コピー (オンプレミス データ ストアからクラウド データ ストアへのデータのコピー、1 つのステージがセルフホステッド統合ランタイムで強化されている) でステージングを使用する場合、料金は、"ハイブリッド コピーの時間" x "ハイブリッド コピーの単価" + "クラウド コピーの時間" x "クラウド コピーの単価" で計算されます。When you use staging during a hybrid copy, which is copying data from an on-premises data store to a cloud data store, one stage empowered by a self-hosted integration runtime, you're charged for [hybrid copy duration] x [hybrid copy unit price] + [cloud copy duration] x [cloud copy unit price].

パフォーマンス チューニングの手順Performance tuning steps

Azure Data Factory サービスとコピー アクティビティのパフォーマンスをチューニングするには、次の手順を実行します。Take these steps to tune the performance of your Azure Data Factory service with the copy activity.

  1. ベースラインを確立する。Establish a baseline. 開発フェーズでは、代表的なデータ サンプルに対してコピー アクティビティを使用して、パイプラインをテストします。During the development phase, test your pipeline by using the copy activity against a representative data sample. コピー アクティビティの監視の後に、実行の詳細とパフォーマンス特性を収集します。Collect execution details and performance characteristics following copy activity monitoring.

  2. パフォーマンスを診断して最適化する。Diagnose and optimize performance. 観測したパフォーマンスが予測どおりでない場合は、パフォーマンスのボトルネックを特定します。If the performance you observe doesn't meet your expectations, identify performance bottlenecks. 次に、パフォーマンスを最適化して、ボトルネックの影響を除去するか軽減します。Then, optimize performance to remove or reduce the effect of bottlenecks.

    場合によっては、Azure Data Factory でコピー アクティビティを実行すると、次の例に示されているように、コピー アクティビティの監視ページの上部に "パフォーマンス チューニングに関するヒント" が直接表示されます。In some cases, when you run a copy activity in Azure Data Factory, you see a "Performance tuning tips" message on top of the copy activity monitoring page, as shown in the following example. このメッセージからは、特定のコピー実行で確認されたボトルネックが伝えられます。The message tells you the bottleneck that was identified for the given copy run. コピー スループットを上げるために変更すべき点も指摘されます。It also guides you on what to change to boost copy throughput. パフォーマンス チューニングのヒントからは現在のところ、次のような提案が表示されます。The performance tuning tips currently provide suggestions like:

    • Azure SQL Data Warehouse にデータをコピーするとき PolyBase を使用する。Use PolyBase when you copy data into Azure SQL Data Warehouse.
    • データ ストア側のリソースがボトルネックのとき、Azure Cosmos DB の要求ユニットまたは Azure SQL Database の DTU (データベース スループット ユニット) を増やす。Increase Azure Cosmos DB Request Units or Azure SQL Database DTUs (Database Throughput Units) when the resource on the data store side is the bottleneck.
    • 不要なステージング コピーを削除する。Remove the unnecessary staged copy.

    パフォーマンスのチューニングのルールも、徐々に強化されていきます。The performance tuning rules will be gradually enriched as well.

    例:パフォーマンス チューニングのヒントを参考にして Azure SQL Database にコピーするExample: Copy into Azure SQL Database with performance tuning tips

    このサンプルでは、コピー実行の間、Azure Data Factory では、シンク Azure SQL Database の DTU 利用率が高くなり、それが書き込み操作を遅らせていることが検出されます。In this sample, during a copy run, Azure Data Factory notices the sink Azure SQL Database reaches high DTU utilization, which slows down the write operations. DTU を増やし、Azure SQL Database 層を増やすことが提案されます。The suggestion is to increase the Azure SQL Database tier with more DTUs.

    パフォーマンスのチューニングに関するヒントを使用したコピーの監視

    さらに、いくつかの一般的な考慮事項を次に示します。In addition, the following are some common considerations. この記事では、パフォーマンスの診断に関する詳細な説明は省略します。A full description of performance diagnosis is beyond the scope of this article.

  3. 構成をデータセット全体まで拡張します。Expand the configuration to your entire dataset. 実行の結果とパフォーマンスに問題がなければ、データセット全体を網羅するよう、定義とパイプラインを拡張できます。When you're satisfied with the execution results and performance, you can expand the definition and pipeline to cover your entire dataset.

セルフホステッド統合ランタイムの考慮事項Considerations for self-hosted integration runtime

セルフホステッド統合ランタイムでコピー アクティビティを実行する場合、次の点に注意します。If your copy activity runs on a self-hosted integration runtime, note the following:

セットアップ: 専用のコンピューターを使用して統合ランタイムをホストすることをお勧めします。Setup: We recommend that you use a dedicated machine to host integration runtime. セルフホステッド統合ランタイムの使用時の考慮事項に関するページを参照してください。See Considerations for using self-hosted integration runtime.

スケールアウト:1 つまたは複数のノードを持つ 1 つの論理セルフホステッド統合ランタイムは、同時実行される複数のコピー アクティビティに対応できます。Scale out: A single logical self-hosted integration runtime with one or more nodes can serve multiple copy activity runs at the same time concurrently. ハイブリッド データ移動で大量のコピー アクティビティを同時実行するか大量のデータをコピーする高いニーズがある場合は、コピー能力を高めるためにより多くのリソースをプロビジョニングできるように、セルフホステッド統合ランタイムをスケール アウトすることを検討してください。If you have heavy need on hybrid data movement either with a large number of concurrent copy activity runs or with a large volume of data to copy, consider scaling out the self-hosted integration runtime to provision more resources to empower copy.

ソースに関する考慮事項Considerations for the source

全般General

基になるデータ ストアが、そこで実行されるその他のワークロードで手一杯になっていないことを確認します。Be sure that the underlying data store isn't overwhelmed by other workloads that are running on or against it.

Microsoft のデータ ストアについては、データ ストアに特化した監視とチューニングに関するトピックを参照してください。For Microsoft data stores, see monitoring and tuning topics that are specific to data stores. これらのトピックでは、データ ストアのパフォーマンス特性に関する説明と、応答時間を短縮しスループットを最大限に高める方法が記載されています。These topics can help you understand data store performance characteristics and how to minimize response times and maximize throughput.

ファイル ベースのデータ ストアFile-based data stores

  • ファイル サイズとファイル数の平均: コピー アクティビティではデータを 1 ファイルずつ転送します。Average file size and file count: The copy activity transfers data one file at a time. 移動するデータ量は同じでも、データが少数の大きなファイルでなく、多数の小さなファイルで構成されている場合、ファイルごとにブートストラップ フェーズが存在するため、全体的なスループットは低下します。With the same amount of data to be moved, the overall throughput is lower if the data consists of many small files rather than a few large files due to the bootstrap phase for each file. 可能であれば、小さなファイルをまとめて大きなファイルとすることで、スループットを高めてください。If possible, combine small files into larger files to gain higher throughput.
  • ファイルの形式と圧縮: パフォーマンスを向上させるその他の方法については、「シリアル化と逆シリアル化に関する考慮事項」セクションと「圧縮に関する考慮事項」セクションを参照してください。File format and compression: For more ways to improve performance, see the Considerations for serialization and deserialization and Considerations for compression sections.

リレーショナル データ ストアRelational data stores

  • テーブル スキーマ: テーブル スキーマは、コピーのスループットに影響を与えます。Data pattern: Your table schema affects copy throughput. 同じ量のデータをコピーする場合は、行のサイズが小さいよりも大きい方がパフォーマンスは高くなります。A large row size gives you better performance than a small row size to copy the same amount of data. これは、データベースは、データのバッチが少ないほど、また含まれている行が少ないほど、そのデータを効率的に取得できるためです。The reason is that the database can more efficiently retrieve fewer batches of data that contain fewer rows.
  • クエリまたはストアド プロシージャ: データをより効率的にフェッチできるように、コピー アクティビティ ソースで指定するクエリまたはストアド プロシージャのロジックを最適化します。Query or stored procedure: Optimize the logic of the query or stored procedure you specify in the copy activity source to fetch data more efficiently.

シンクに関する考慮事項Considerations for the sink

全般General

基になるデータ ストアが、そこで実行されるその他のワークロードで手一杯になっていないことを確認します。Be sure that the underlying data store isn't overwhelmed by other workloads that are running on or against it.

Microsoft のデータ ストアについては、データ ストアに特化した監視とチューニングに関するトピックを参照してください。For Microsoft data stores, see monitoring and tuning topics that are specific to data stores. これらのトピックでは、データ ストアのパフォーマンス特性に関する説明と、応答時間を短縮しスループットを最大限に高める方法が記載されています。These topics can help you understand data store performance characteristics and how to minimize response times and maximize throughput.

ファイル ベースのデータ ストアFile-based data stores

  • コピー動作:別のファイル ベースのデータ ストアからデータをコピーする場合、コピー アクティビティには copyBehavior プロパティを使用したオプションが 3 つあります。Copy behavior: If you copy data from a different file-based data store, the copy activity has three options via the copyBehavior property. それらは、階層の維持、階層の平坦化、およびファイルのマージです。It preserves hierarchy, flattens hierarchy, or merges files. 階層の維持または階層の平坦化では、パフォーマンス オーバーヘッドはほとんどありませんが、ファイルのマージではパフォーマンス オーバーヘッドが増加します。Either preserving or flattening hierarchy has little or no performance overhead, but merging files causes performance overhead to increase.
  • ファイルの形式と圧縮: パフォーマンスを向上させるその他の方法については、「シリアル化と逆シリアル化に関する考慮事項」セクションと「圧縮に関する考慮事項」セクションを参照してください。File format and compression: For more ways to improve performance, see the Considerations for serialization and deserialization and Considerations for compression sections.

リレーショナル データ ストアRelational data stores

  • コピー動作とパフォーマンスの影響:SQL シンクにはさまざまな方法でデータを書き込むことができます。Copy behavior and performance implication: There are different ways to write data into a SQL sink. Best practice for loading data into Azure SQL Database」(Azure SQL Database にデータを読み込む際のベスト プラクティス) を参照してください。Learn more from Best practice for loading data into Azure SQL Database.

  • データのパターンとバッチ サイズ:Data pattern and batch size:

    • テーブル スキーマは、コピーのスループットに影響を与えます。Your table schema affects copy throughput. 同じ量のデータをコピーする場合、行のサイズが小さいよりも行のサイズが大きい方がパフォーマンスは高くなります。これは、データのバッチが少ない方が、データベースがデータを効率的にコミットできるためです。To copy the same amount of data, a large row size gives you better performance than a small row size because the database can more efficiently commit fewer batches of data.
    • コピー アクティビティは、一連のバッチでデータを挿入します。The copy activity inserts data in a series of batches. バッチの行数は、 writeBatchSize プロパティを使用して設定できます。You can set the number of rows in a batch by using the writeBatchSize property. データの行が小さい場合は、 writeBatchSize プロパティをより大きな値に設定することで、バッチ オーバーヘッドを減らし、スループットを向上させることができます。If your data has small rows, you can set the writeBatchSize property with a higher value to benefit from lower batch overhead and higher throughput. データの行サイズが大きい場合は、 writeBatchSizeを大きくするときに注意が必要です。If the row size of your data is large, be careful when you increase writeBatchSize. 値を大きくすると、データベースに過剰な負荷がかかるため、コピーに失敗する可能性があります。A high value might lead to a copy failure caused by overloading the database.

NoSQL ストアNoSQL stores

  • Table Storageの場合:For Table storage:
    • パーティション: インターリーブされたパーティションにデータを書き込むと、パフォーマンスが大幅に低下します。Partition: Writing data to interleaved partitions dramatically degrades performance. データが複数のパーティションに順次効率よく挿入されるように、パーティション キーでソース データを並べ替えます。Sort your source data by partition key so that the data is inserted efficiently into one partition after another. あるいは、データが 1 つのパーティションに書き込まれるようにロジックを調整します。Or, you can adjust the logic to write the data to a single partition.

シリアル化と逆シリアル化に関する考慮事項Considerations for serialization and deserialization

入力データ セットまたは出力データ セットがファイルであると、シリアル化および逆シリアル化が実行されることがあります。Serialization and deserialization can occur when your input dataset or output dataset is a file. コピー アクティビティでサポートされているファイル形式について詳しくは、「サポートされているファイル形式と圧縮形式」をご覧ください。For more information on supported file formats by copy activity, see Supported file and compression formats.

コピー動作:Copy behavior:

  • ファイル ベースのデータ ストア間でファイルをコピーする:Copying files between file-based data stores:
    • 入力データセットと出力データセットが、両方とも同じファイル形式であるか、ファイル形式が設定されていない場合、データ移動サービスは、シリアル化または逆シリアル化を実行することなく、バイナリ コピーを実行します。When input and output datasets both have the same or no file format settings, the data movement service executes a binary copy without any serialization or deserialization. ソースとシンクのファイル形式の設定が互いに異なるシナリオと比較して、より高いスループットが示されます。You see a higher throughput compared to the scenario, in which the source and sink file format settings are different from each other.
    • 入力データセットと出力データセットは両方ともテキスト形式で、エンコードの種類のみが異なる場合、データ移動サービスはエンコード変換のみを行います。When input and output datasets both are in text format and only the encoding type is different, the data movement service only does encoding conversion. バイナリ コピーと比較した場合にパフォーマンス オーバーヘッドがいくらか発生するシリアル化と逆シリアル化は実行しません。It doesn't do any serialization and deserialization, which causes some performance overhead compared to a binary copy.
    • 入力データセットと出力データセットのファイル形式が異なるか、または構成 (区切り記号など) が異なる場合、データ移動サービスは、ソース データをストリームに逆シリアル化し、変換して、指定された出力形式にシリアル化します。When input and output datasets both have different file formats or different configurations, like delimiters, the data movement service deserializes source data to stream, transform, and then serialize it into the output format you indicated. この操作では、他のシナリオと比較して、はるかに大きなパフォーマンス オーバーヘッドが発生します。This operation results in a much more significant performance overhead compared to other scenarios.
  • ファイル ベースではないデータ ストアとの間で (たとえば、ファイル ベースのストアからリレーショナル ストアへの) コピーを行う場合、シリアル化または逆シリアル化の手順が必要になります。When you copy files to or from a data store that isn't file based, for example, from a file-based store to a relational store, the serialization or deserialization step is required. この手順により、大幅なパフォーマンスのオーバーヘッドが発生します。This step results in significant performance overhead.

ファイル形式: ファイル形式の選択は、コピーのパフォーマンスに影響する場合があります。File format: The file format you choose might affect copy performance. たとえば、Avro は、データと共にメタデータを格納するコンパクトなバイナリ形式です。For example, Avro is a compact binary format that stores metadata with data. Hadoop エコシステムでの処理やクエリ実行について、幅広くサポートされています。It has broad support in the Hadoop ecosystem for processing and querying. Avro の場合は、シリアル化と逆シリアル化によってコピーのスループットが低下するので、テキスト形式と比較してコストがかかります。Avro is more expensive for serialization and deserialization, which results in lower copy throughput compared to text format.

処理フロー全体を考慮して、ファイル形式を選択してください。Make your choice of file format throughout the processing flow holistically. 次から開始する:Start with:

  • データを格納する形式、コピー元のデータの格納形式、外部システムから抽出する形式。What form the data is stored in, source data stores or to be extracted from external systems.
  • ストレージ、分析処理、クエリ実行に最適な形式。The best format for storage, analytical processing, and querying.
  • レポート ツールや視覚化ツールのためにデータをデータ マートにエクスポートするときの形式。In what format the data should be exported into data marts for reporting and visualization tools.

ときには、読み取りおよび書き込みパフォーマンスの点では準最適なファイル形式であっても、分析プロセス全体を考慮するとよい選択である場合があります。Sometimes a file format that is suboptimal for read and write performance might be a good choice when you consider the overall analytical process.

圧縮に関する考慮事項Considerations for compression

入力データ セットまたは出力データ セットがファイルである場合は、ターゲットにデータを書き込むときに圧縮または圧縮解除を実行するようにコピー アクティビティを設定することができます。When your input or output dataset is a file, you can set the copy activity to perform compression or decompression as it writes data to the destination. 圧縮を選択すると、入力/出力 (I/O) と CPU の間にトレードオフが生じます。When you choose compression, you make a tradeoff between input/output (I/O) and CPU. データを圧縮すると、コンピューティング リソースの面では余分なコストがかかります。Compressing the data costs extra in compute resources. 代わりに、ネットワーク I/O およびストレージは削減できます。But in return, it reduces network I/O and storage. データによっては、コピーの全体的なスループットが大幅に向上する場合があります。Depending on your data, you might see a boost in overall copy throughput.

コーデック: 各圧縮コーデックには、長所があります。Codec: Each compression codec has advantages. たとえば、bzip2 はコピーのスループットが最も低いのですが、分割して処理できるため、最高の Hive クエリ パフォーマンスを発揮します。For example, bzip2 has the lowest copy throughput, but you get the best Hive query performance with bzip2 because you can split it for processing. Gzip は最もバランスの取れた選択肢であり、最も使用されています。Gzip is the most balanced option, and it's used the most often. エンド ツー エンドのシナリオに最適なコーデックを選択してください。Choose the codec that best suits your end-to-end scenario.

レベル: 各圧縮コーデックに対して、最速圧縮と最適圧縮という 2 つのオプションのいずれかを選択できます。Level: You can choose from two options for each compression codec: fastest compressed and optimally compressed. 最速圧縮オプションでは、可能な限り短時間でデータの圧縮を完了しますが、生成ファイルが最適に圧縮されない場合があります。The fastest compressed option compresses the data as quickly as possible, even if the resulting file isn't optimally compressed. 最適圧縮オプションでは、より多くの時間をデータ圧縮に費やしますが、データ量を最小限まで圧縮します。The optimally compressed option spends more time on compression and yields a minimal amount of data. 両方のオプションを実際にテストして、どちらが全体的なパフォーマンスで優れているかを確認することができます。You can test both options to see which provides better overall performance in your case.

考慮事項: オンプレミス ストアとクラウド間で大量のデータをコピーするには、圧縮を有効にしたステージング コピーの使用を検討してください。A consideration: To copy a large amount of data between an on-premises store and the cloud, consider using Staged copy with compression enabled. 企業ネットワークと Azure サービスの帯域幅が制限要因となっていて、入力データセットと出力データセットの両方を圧縮されない形式にしたい場合は、中間ストレージを使用すると便利です。Using interim storage is helpful when the bandwidth of your corporate network and your Azure services is the limiting factor, and you want the input dataset and output dataset both to be in uncompressed form.

列マッピングに関する考慮事項Considerations for column mapping

コピー アクティビティの columnMappings プロパティを設定して、入力列のすべてまたはサブセットを出力列にマップすることができます。You can set the columnMappings property in a copy activity to map all or a subset of the input columns to the output columns. データ移動サービスは、ソースからデータを読み取った後、データをシンクに書き込む前に、データに対して列マッピングを実行する必要があります。After the data movement service reads the data from the source, it needs to perform column mapping on the data before it writes the data to the sink. この追加の処理により、コピーのスループットが低下します。This extra processing reduces copy throughput.

ソース データ ストアがクエリ可能な場合 (たとえば、SQL Database や SQL Server のようなリレーショナル ストアであるか、Table Storage や Azure Cosmos DB のような NoSQL ストアである場合) は、列マッピングを使用するのでなく、列フィルタリングと順序変更ロジックを query プロパティにプッシュすることを検討してください。If your source data store is queryable, for example, if it's a relational store like SQL Database or SQL Server, or if it's a NoSQL store like Table storage or Azure Cosmos DB, consider pushing the column filtering and reordering logic to the query property instead of using column mapping. そうした場合、データ移動サービスがソース データ ストアからデータを読み取る際にプロジェクションが発生し、効率が大幅に向上します。This way, the projection occurs while the data movement service reads data from the source data store, where it's much more efficient.

詳細については、コピー アクティビティのスキーマ マッピングに関するページを参照してください。Learn more from Copy activity schema mapping.

その他の考慮事項Other considerations

コピーするデータのサイズが大きい場合は、さらにデータを分割するようにビジネス ロジックを調整できます。If the size of data you want to copy is large, you can adjust your business logic to further partition the data. コピー アクティビティをより頻繁に実行するようにスケジュールして、各コピー アクティビティ実行のデータ サイズを小さくします。You can schedule the copy activity to run more frequently to reduce the data size for each copy activity that runs.

Azure Data Factory で同じデータ ストアに同時に接続させる必要があるデータ セットの数とコピー アクティビティの数に注意してください。Be cautious about the number of datasets and copy activities that require Azure Data Factory to connect to the same data store at the same time. 同時コピー ジョブの数が多いと、データ ストアのスロットルが発生し、パフォーマンスの低下、コピー ジョブの内部的な再試行、場合によっては実行の失敗につながるおそれがあります。Many concurrent copy jobs might throttle a data store and lead to degraded performance, copy job internal retries, and in some cases, execution failures.

サンプル シナリオ: オンプレミス SQL Server から Blob Storage へのコピーSample scenario: Copy from an on-premises SQL server to Blob storage

シナリオ: オンプレミスの SQL Server から Blob Storage に CSV 形式でデータをコピーするパイプラインが構築されています。Scenario: A pipeline is built to copy data from an on-premises SQL server to Blob storage in CSV format. コピー ジョブを高速にするために、CSV ファイルは bzip2 形式で圧縮されます。To make the copy job faster, the CSV files should be compressed into bzip2 format.

テストと分析: コピー アクティビティのスループットは 2 MBps 未満で、パフォーマンスのベンチマークをかなり下回っています。Test and analysis: The throughput of the copy activity is less than 2 MBps, which is much slower than the performance benchmark.

パフォーマンスの分析とチューニング: パフォーマンスの問題を解決するために、データが処理、移動されるしくみを見ていきます。Performance analysis and tuning: To troubleshoot the performance issue, let’s look at how the data is processed and moved.

  • データの読み取り: 統合ランタイムは、SQL Server への接続を開き、クエリを送信します。Read data: The integration runtime opens a connection to SQL Server and sends the query. SQL Server は、イントラネット経由で統合ランタイムにデータ ストリームを送信することで応答します。SQL Server responds by sending the data stream to the integration runtime via the intranet.
  • データのシリアル化と圧縮: 統合ランタイムはデータ ストリームを CSV 形式にシリアル化し、データを bzip2 ストリームに圧縮します。Serialize and compress data: The integration runtime serializes the data stream to CSV format and compresses the data to a bzip2 stream.
  • データの書き込み: 統合ランタイムは bzip2 ストリームをインターネット経由で Blob Storage にアップロードします。Write data: The integration runtime uploads the bzip2 stream to Blob storage via the internet.

ご覧のとおり、データは次のようにストリーミングで順次処理および移動されています:SQL Server > LAN > 統合ランタイム > WAN > Blob Storage。As you can see, the data is processed and moved in a streaming sequential manner: SQL Server > LAN > Integration runtime > WAN > Blob storage. 全体的なパフォーマンスは、パイプラインを通じて最低のスループットが上限となっています。The overall performance is gated by the minimum throughput across the pipeline.

Data flow

次に示す要因の 1 つ以上がパフォーマンスのボトルネックの原因である可能性があります。One or more of the following factors might cause the performance bottleneck:

  • ソース: 負荷が大きいため、SQL Server 自体のスループットが低くなっています。Source: SQL Server itself has low throughput because of heavy loads.
  • セルフホステッド統合ランタイム:Self-hosted integration runtime:
    • LAN: 統合ランタイムは SQL Server コンピューターから離れた場所にあり、低帯域幅で接続されています。LAN: Integration runtime is located far from the SQL Server machine and has a low-bandwidth connection.
    • 統合ランタイム: 統合ランタイムは、以下の操作を行って、負荷の上限に達しています。Integration runtime: Integration runtime has reached its load limitations to perform the following operations:
      • シリアル化: CSV へのデータ ストリームのシリアル化で、スループットが低くなっています。Serialization: Serializing the data stream to CSV format has slow throughput.
      • 圧縮: 低速の圧縮コーデック (たとえば、Core i7 で 2.8 MBps の bzip2) を選択しました。Compression: You chose a slow compression codec, for example, bzip2, which is 2.8 MBps with Core i7.
    • WAN: 企業ネットワークと Azure サービス間の帯域幅が小さい状態です (たとえば、T1 = 1,544 kbps、T2 = 6,312 kbps)。WAN: The bandwidth between the corporate network and your Azure services is low, for example, T1 = 1,544 kbps; T2 = 6,312 kbps.
  • シンク: Blob Storage のスループットが低くなっています。Sink: Blob storage has low throughput. サービス レベル アグリーメント (SLA) により最低でも 60 MBps が保証されているため、このシナリオは現実的ではありません。This scenario is unlikely because its service-level agreement (SLA) guarantees a minimum of 60 MBps.

この場合、bzip2 データ圧縮がパイプライン全体を遅くしている可能性があります。In this case, bzip2 data compression might be slowing down the entire pipeline. gzip 圧縮コーデックに切り替えると、このボトルネックが緩和される場合があります。Switching to a gzip compression codec might ease this bottleneck.

参照References

ここでは、サポートされているいくつかのデータ ストアについて、パフォーマンスの監視とチューニングに関するリファレンス情報をいくつか示します。Here are performance monitoring and tuning references for some of the supported data stores:

次の手順Next steps

コピー アクティビティの他の記事を参照してください。See the other copy activity articles: