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

注意

この記事は、Data Factory のバージョン 1 に適用されます。This article applies to version 1 of Data Factory. 現在のバージョンの Data Factory サービスを使用している場合は、Data Factory のコピー アクティビティのパフォーマンスとチューニングに関するガイドに関するページを参照してください。If you are using the current version of the Data Factory service, see Copy activity performance and tuning guide for Data Factory.

Azure Data Factory コピー アクティビティは、優れたセキュリティで保護された、信頼性とパフォーマンスに優れたデータ読み込みソリューションを提供します。Azure Data Factory Copy Activity delivers a first-class secure, reliable, and high-performance data loading solution. これにより、数十テラバイトのデータを、さまざまなクラウドおよびオンプレミスのデータ ストアの間で毎日コピーすることができます。It enables you to copy tens of terabytes of data every day across a rich variety of cloud and on-premises data stores. データ読み込みのパフォーマンスを劇的に高めることが、高度な分析ソリューションを構築してすべてのデータから深い洞察を得るという、"ビッグ データ" の中心的問題に集中するための鍵となります。Blazing-fast data loading performance is key to ensure 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, and Copy Activity offers a highly optimized data loading experience that is easy to configure and set up. 1 つのコピー アクティビティで次のことを実現できます。With just a single copy activity, you can achieve:

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

注意

コピー アクティビティ全般に慣れていない場合は、この記事を読む前に「 コピー アクティビティを使用したデータの移動 」を参照してください。If you are not familiar with Copy Activity in general, see Move data by using Copy Activity before reading this article.

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

参考として、社内テストに基づく特定のソースとシンクのペアにおけるコピーのスループット (Mbps 単位) を次の表に示します。As a reference, below table shows the copy throughput number in MBps for the given source and sink pairs based on in-house testing. 比較のために、クラウド データの移動単位または Data Management Gateway のスケーラビリティ (複数のゲートウェイ ノード) の異なる設定によってコピーのパフォーマンスがどのように変化するかも示しています。For comparison, it also demonstrates how different settings of cloud data movement units or Data Management Gateway scalability (multiple gateway nodes) can help on copy performance.

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

重要

Azure Data Factory バージョン 1 では、クラウド間のコピーの最小のクラウドデータ移動単位は 2 です。In Azure Data Factory version 1, the minimal cloud data movement units for cloud-to-cloud copy is two. 指定しない場合、クラウド データ移動単位で使用されている既定のデータ移動単位を参照してください。If not specified, see default data movement units being used in cloud data movement 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 using TPC-H data set in a single copy activity run.
  • 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 gateway node was running on a machine that was separate from the on-premises data store with below specification. ゲートウェイで 1 つのアクティビティが実行されていた場合、コピー操作で使用されたのは、テスト コンピューターの CPU、メモリ、またはネットワーク帯域幅のごく一部だけでした。When a single activity was running on gateway, the copy operation consumed only a small portion of the test machine's CPU, memory, or network bandwidth. 詳細については、「Data Management Gateway に関する考慮事項」を参照してください。Learn more from consideration for Data Management Gateway.
    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

ヒント

既定の最大データ移動単位 (DMU) は、クラウド間のコピー アクティビティの実行では 32 ですが、これよりも大きい DMU を利用すると、より高いスループットを得ることができます。You can achieve higher throughput by leveraging more data movement units (DMUs) than the default maximum DMUs, which is 32 for a cloud-to-cloud copy activity run. たとえば、100 DMU にすると、Azure BLOB から Azure Data Lake Store に 1.0 Gbps でデータをコピーすることができます。For example, with 100 DMUs, you can achieve copying data from Azure Blob into Azure Data Lake Store at 1.0GBps. この機能の詳細とサポートされるシナリオについては、「クラウド データ移動単位」セクションを参照してください。See the Cloud data movement units section for details about this feature and the supported scenario. DMU の追加依頼は、Azure サポートに連絡してください。Contact Azure support to request more DMUs.

並列コピーParallel copy

ソースからのデータ読み取りまたはターゲットへのデータ書き込みは、 コピー アクティビティの実行中に並行して実行できます。You can read data from the source or write data to the destination in parallel within a Copy Activity run. この機能によって、コピー操作のスループットが向上し、データの移動にかかる時間が短縮されます。This feature enhances the throughput of a copy operation and reduces the time it takes to move data.

この設定は、アクティビティ定義の concurrency プロパティとは異なります。This setting is different from the concurrency property in the activity definition. concurrency プロパティでは、さまざまなアクティビティ ウィンドウ (午前 1 時から 2 時、午前 2 時から 3 時、午前 3 時から 4 時など) のデータを処理するために、コピー アクティビティのコンカレンシーの数を決定します。The concurrency property determines the number of concurrent Copy Activity runs to process data from different activity windows (1 AM to 2 AM, 2 AM to 3 AM, 3 AM to 4 AM, and so on). この機能は、履歴を読み込む場合に便利です。This capability is helpful when you perform a historical load. 並列コピー機能は、 1 つのアクティビティの実行に適用されます。The parallel copy capability applies to a single activity run.

サンプル シナリオを見てみましょう。Let's look at a sample scenario. 次の例では、過去の複数のスライスを処理する必要があります。In the following example, multiple slices from the past need to be processed. Data Factory は、スライスごとにコピー アクティビティ (アクティビティ実行) のインスタンスを実行します。Data Factory runs an instance of Copy Activity (an activity run) for each slice:

  • 1 番目のアクティビティ ウィンドウのデータ スライス (午前 1 時から午前 2 時) ==> アクティビティの実行 1The data slice from the first activity window (1 AM to 2 AM) ==> Activity run 1
  • 2 番目のアクティビティ ウィンドウのデータ スライス (午前 2 時から午前 3 時) ==> アクティビティの実行 2The data slice from the second activity window (2 AM to 3 AM) ==> Activity run 2
  • 3 番目のアクティビティ ウィンドウのデータ スライス (午前 3 時から午前 4 時) ==> アクティビティの実行 3The data slice from the second activity window (3 AM to 4 AM) ==> Activity run 3

同様に続きます。And so on.

この例では、concurrency 値が 2 に設定されると、アクティビティの実行 1アクティビティの実行 2 が 2 つのアクティビティ ウィンドウからデータを同時にコピーできるため、データ移動のパフォーマンスが向上します。In this example, when the concurrency value is set to 2, Activity run 1 and Activity run 2 copy data from two activity windows concurrently to improve data movement performance. ただし、複数のファイルがアクティビティの実行 1 に関連付けられている場合、データ移動サービスは、ソースからターゲットへのファイルのコピーを 1 度に 1 ファイルずつ行います。However, if multiple files are associated with Activity run 1, the data movement service copies files from the source to the destination one file at a time.

クラウド データ移動単位Cloud data movement units

クラウド データ移動単位 (DMU) は、Data Factory の 1 つの単位の能力 (CPU、メモリ、ネットワーク リソース割り当ての組み合わせ) を表す尺度です。A cloud data movement unit (DMU) is a measure that represents the power (a combination of CPU, memory, and network resource allocation) of a single unit in Data Factory. DMU はクラウド間のコピー操作では適用できますが、ハイブリッド コピーでは適用されません。DMU is applicable for cloud-to-cloud copy operations, but not in a hybrid copy.

コピー アクティビティの実行を強化する最小クラウドデータ移動単位は 2 です。The minimal cloud data movement units to empower Copy Activity run is two. 指定しない場合、次の表に、さまざまなコピー シナリオで使用される既定の DMU を示します。If not specified, the following table lists the default DMUs used in different copy scenarios:

コピー シナリオCopy scenario サービスによって決定される既定の DMUDefault DMUs determined by service
ファイル ベースのストア間でのデータのコピーCopy data between file-based stores ファイルの数とサイズに応じて 4 〜 16。Between 4 and 16 depending on the number and size of the files.
他のすべてのコピー シナリオAll other copy scenarios 44

この既定の動作をオーバーライドするには、 cloudDataMovementUnits プロパティに次のように値を指定します。To override this default, specify a value for the cloudDataMovementUnits property as follows. cloudDataMovementUnits プロパティに使用できる値は、2、4、8、16、32 です。The allowed values for the cloudDataMovementUnits property are 2, 4, 8, 16, 32. コピー操作が実行時に使用する クラウド DMU の実際の数 は、データ パターンに応じて、構成されている値以下になります。The actual number of cloud DMUs 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.

"activities":[
    {
        "name": "Sample copy activity",
        "description": "",
        "type": "Copy",
        "inputs": [{ "name": "InputDataset" }],
        "outputs": [{ "name": "OutputDataset" }],
        "typeProperties": {
            "source": {
                "type": "BlobSource",
            },
            "sink": {
                "type": "AzureDataLakeStoreSink"
            },
            "cloudDataMovementUnits": 32
        }
    }
]

注意

スループットをより高めるためにさらにクラウド DMU が必要な場合は、 Azure サポートにお問い合わせください。If you need more cloud DMUs for a higher throughput, contact Azure support. 現在、8 以上を設定できるのは、複数のファイルを、Blob Storage/Data Lake Store/Amazon S3/クラウド FTP/クラウド SFTP から Blob Storage/Data Lake Store/Azure SQL Database にコピーする場合のみです。Setting of 8 and above currently works only when you copy multiple files from Blob storage/Data Lake Store/Amazon S3/cloud FTP/cloud SFTP to Blob storage/Data Lake Store/Azure SQL Database.

parallelCopiesparallelCopies

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

コピー アクティビティの実行ごとに、Data Factory は、ソース データ ストアからターゲット データ ストアへのデータ コピーで使用する並列コピーの数を決定します。For each Copy Activity run, 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 are using.

ソースとシンクSource and sink サービスによって決定される並列コピーの既定数Default parallel copy count determined by service
ファイル ベースのストア (Blob Storage、Data Lake Store、Amazon S3、オンプレミスのファイル システム、オンプレミスの HDFS) 間のデータのコピーCopy data between file-based stores (Blob storage; Data Lake Store; Amazon S3; an on-premises file system; an on-premises HDFS) 1 ~ 32 の範囲。Between 1 and 32. どの数にするかは、ファイルのサイズと、2 つのクラウド データ ストア間でのデータのコピーで使用されるクラウド データ移動単位の数 (DMU) またはハイブリッド コピー (オンプレミス データ ストアとの間のデータのコピー) で使用されるゲートウェイ コンピューターの物理構成によって決まります。Depends on the size of the files and the number of cloud data movement units (DMUs) used to copy data between two cloud data stores, or the physical configuration of the Gateway machine used for a hybrid copy (to copy data to or from an on-premises data store).
任意のソース データ ストアから Azure Table Storage へのCopy data from any source data store to Azure Table storage 44
その他のすべてのソースとシンクのペアAll other source and sink pairs 11

通常は、既定の動作で最適なスループットが得られます。Usually, the default behavior should give you the best throughput. ただし、データ ストアをホストしているコンピューターの負荷を制御したり、コピーのパフォーマンスをチューニングしたりするには、 parallelCopies プロパティの値を指定して、既定値をオーバーライドできます。However, to control the load on machines that host your data stores, or to tune copy performance, you may choose to override the default value and specify a value for the parallelCopies property. 1 ~ 32 の値 (両端の値を含む) を指定する必要があります。The value must be between 1 and 32 (both inclusive). 実行時にコピー アクティビティは、設定された値以下でパフォーマンスが最大になる値を使用します。At run time, for the best performance, Copy Activity uses a value that is less than or equal to the value that you set.

"activities":[
    {
        "name": "Sample copy activity",
        "description": "",
        "type": "Copy",
        "inputs": [{ "name": "InputDataset" }],
        "outputs": [{ "name": "OutputDataset" }],
        "typeProperties": {
            "source": {
                "type": "BlobSource",
            },
            "sink": {
                "type": "AzureDataLakeStoreSink"
            },
            "parallelCopies": 8
        }
    }
]

注意する点:Points to note:

  • ファイル ベースのストア間でデータをコピーする場合は、parallelCopies によってファイル レベルでの並列処理が決まります。When you copy data between file-based stores, the parallelCopies determine the parallelism at the file level. 単一ファイル内でのチャンク化は裏で自動的かつ透過的に行われます。また、指定されたソース データ ストアの種類に最適なチャンク サイズを使用し、parallelCopies とは独立に並行してデータを読み込むよう設計されています。The chunking within a single file would happen underneath automatically and transparently, and 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, Copy Activity cannot take advantage of file-level parallelism.
  • parallelCopies プロパティの値を指定すると、ソースおよびシンク データ ストアで負荷 (ハイブリッド コピーの場合はゲートウェイへの負荷) が増えることを考慮してください。When you specify a value for the parallelCopies property, consider the load increase on your source and sink data stores, and to gateway if it is a hybrid copy. これは、特に複数のアクティビティがある場合や、同じデータ ストアに対して実行される同じアクティビティの同時実行がある場合によくあります。This 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 Gateway is overwhelmed with the load, decrease the parallelCopies value to relieve the load.
  • ファイル ベース以外のストアからファイル ベースのストアにデータをコピーする場合、データ移動サービスは parallelCopies プロパティを無視します。When you copy data from stores that are not file-based 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 機能を使用するには、Data Management Gateway のバージョン 1.11 以降を使用する必要があります。You must use Data Management Gateway version 1.11 or later to use the parallelCopies feature when you do a hybrid copy.

これらの 2 つのプロパティをうまく利用し、データ移動のスループットを向上させるには、ユース ケースのサンプルを参照してください。To better use these two properties, and to enhance your data movement throughput, see the sample use cases. 既定の動作を活用する場合は、 parallelCopies を構成する必要はありません。You don't need to configure parallelCopies to take advantage of the default behavior. 構成しても parallelCopies が小さすぎる場合は、複数のクラウド DMU が十分に活用されない可能性があります。If you do configure and parallelCopies is too small, multiple cloud DMUs might not be fully utilized.

課金への影響Billing impact

重要 なのは、コピー操作の合計時間に基づいて料金が請求されることです。It's important to remember that you are charged based on the total time of the copy operation. これまで 1 回のコピー ジョブに 1 クラウド単位で 1 時間かかっていたのが、4 クラウド単位で 15 分かかるようになった場合、全体的な請求金額はほぼ同じままです。If a copy job used to take one hour with one cloud unit and now it takes 15 minutes with four cloud units, the overall bill remains almost the same. たとえば、4 クラウド単位を使用するとします。For example, you use four cloud units. 1 回のコピー アクティビティの実行で、1 つ目のクラウド単位に 10 分、2 つ目に 10 分、3 つ目に 5 分、4 つ目に 5 分かかります。The first cloud unit spends 10 minutes, the second one, 10 minutes, the third one, 5 minutes, and the fourth one, 5 minutes, all in one Copy Activity run. コピー (データ移動) の合計時間は 10 + 10 + 5 + 5 で 30 分になり、その分の料金が発生します。You are charged for the total copy (data movement) time, which is 10 + 10 + 5 + 5 = 30 minutes. parallelCopies を使用しても、課金には影響しません。Using parallelCopies does not affect billing.

ステージング コピー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:

  1. 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 にあることと追加の条件を満たすことが必要です。However, the source data must be in Blob storage, and it must meet additional criteria. Blob Storage 以外のデータ ストアからデータを読み込む際は、中間ステージング Blob Storage 経由のデータ コピーを有効にすることができます。When you load data from a data store other than Blob storage, you can activate data copying via interim staging Blob storage. その場合、Data Factory は、PolyBase の要件を満たすために必要なデータ変換を実行します。In that case, 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. 詳細については、「 PolyBase を使用して Azure SQL Data Warehouse にデータを読み込む」を参照してください。For more details, see Use PolyBase to load data into Azure SQL Data Warehouse. ユース ケースを使用したチュートリアルについては、1 TB のデータを Azure Data Factory を使用して 15 分以内に Azure SQL Data Warehouse に読み込む方法に関するページを参照してください。For a walkthrough with a use case, see Load 1 TB into Azure SQL Data Warehouse under 15 minutes with Azure Data Factory.
  2. ネットワーク接続が遅い場合、ハイブリッド データ移動 (オンプレミス データ ストアとクラウド データ ストアの間でのコピー) の実行に少し時間がかかる場合があるSometimes it takes a while to perform a hybrid data movement (that is, to copy between an on-premises data store and a cloud data store) over a slow network connection. パフォーマンスを向上させるために、オンプレミスのデータを圧縮することで、クラウド内のステージング データ ストアにデータを移動する時間を短縮できます。To improve performance, you can 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 it into the destination data store.
  3. 企業の 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, take advantage of the gateway 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, 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

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

(ソース データ ストアとシンク データ ストアの両方がクラウドにある) クラウド コピーのシナリオでは、ゲートウェイは使用されません。In the cloud copy scenario (both source and sink data stores are in the cloud), gateway is not used. コピー操作は、Data Factory サービスによって実行されます。The Data Factory service performs the copy operations.

ステージング コピー:クラウド シナリオ

(ソースがオンプレミスにあり、シンクがクラウドにある) ハイブリッド コピーのシナリオでは、ゲートウェイが、ソース データ ストアのデータをステージング データ ストアに移動します。In the hybrid copy scenario (source is on-premises and sink is in the cloud), the gateway moves data from the source data store to a staging data store. Data Factory サービスは、データをステージング データ ストアからシンク データ ストアにコピーします。Data Factory service moves data from the staging data store to the sink data store. ステージングによるクラウド データ ストアからオンプレミス データ ストアへのデータのコピーも逆のフローでサポートされています。Copying data from a cloud data store to an on-premises data store via staging also is supported with the reversed flow.

ステージング コピー:ハイブリッド シナリオ

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

現時点では、ステージング ストアを使用して 2 つのオンプレミス データ ストア間でデータをコピーすることはできません。Currently, you can't copy data between two on-premises data stores by using a staging store. このオプションは、間もなく利用できるようになる予定です。We expect this option to be available soon.

構成Configuration

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

プロパティProperty 説明Description 既定値Default value 必須Required
enableStagingenableStaging 中間ステージング ストアを経由してデータをコピーするかどうかを指定します。Specify whether you want to copy data via an interim staging store. FalseFalse いいえNo
linkedServiceNamelinkedServiceName AzureStorage または AzureStorageSas のリンクされたサービスの名前を指定します。これは、中間ステージング ストアとして使用する Storage のインスタンスです。Specify the name of an AzureStorage or AzureStorageSas 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 cannot 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 do not 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 is copied to the destination. この設定により、転送するデータの量が減ります。This setting reduces the volume of data being transferred. FalseFalse いいえNo

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

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

課金への影響Billing impact

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

  • クラウド コピー (クラウド データ ストアから別のクラウド データ ストアへのデータのコピー) でステージングを使用する場合、料金は、"ステップ 1 とステップ 2 のコピー時間の合計" x "クラウド コピーの単価" で計算されます。When you use staging during a cloud copy (copying data from a cloud data store to another cloud data store), you are charged the [sum of copy duration for step 1 and step 2] x [cloud copy unit price].
  • ハイブリッド コピー (オンプレミス データ ストアからクラウド データ ストアへのデータのコピー) でステージングを使用する場合、料金は、"ハイブリッド コピーの時間" x "ハイブリッド コピーの単価" + "クラウド コピーの時間" x "クラウド コピーの単価" で計算されます。When you use staging during a hybrid copy (copying data from an on-premises data store to a cloud data store), you are charged for [hybrid copy duration] x [hybrid copy unit price] + [cloud copy duration] x [cloud copy unit price].

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

Data Factory サービスとコピー アクティビティのパフォーマンスをチューニングするには、次の手順を実行することをお勧めします。We suggest that you take these steps to tune the performance of your Data Factory service with Copy Activity:

  1. ベースラインを確立するEstablish a baseline. 開発フェーズでは、代表的なデータ サンプルに対してコピー アクティビティを使用して、パイプラインをテストします。During the development phase, test your pipeline by using Copy Activity against a representative data sample. Data Factory の スライシング モデル を使用することで、操作するデータの量を制限できます。You can use the Data Factory slicing model to limit the amount of data you work with.

    監視と管理アプリを使用して、実行時間とパフォーマンス特性を収集します。Collect execution time and performance characteristics by using the Monitoring and Management App. Data Factory のホーム ページで、 [監視と管理] を選択します。Choose Monitor & Manage on your Data Factory home page. ツリー ビューで、 出力データセットを選択します。In the tree view, choose the output dataset. [Activity Windows (アクティビティ ウィンドウ)] の一覧で、コピー アクティビティの実行を選択します。In the Activity Windows list, choose the Copy Activity run. [Activity Windows (アクティビティ ウィンドウ)] には、コピー アクティビティの期間とコピーされるデータのサイズが表示されます。Activity Windows lists the Copy Activity duration and the size of the data that's copied. スループットは、 [Activity Window Explorer (アクティビティ ウィンドウ エクスプローラー)] に一覧表示されます。The throughput is listed in Activity Window Explorer. このアプリの詳細については、 新しい監視と管理アプリを使用した Azure Data Factory パイプラインの監視と管理に関する記事を参照してください。To learn more about the app, see Monitor and manage Azure Data Factory pipelines by using the Monitoring and Management App.

    アクティビティ実行の詳細

    この記事の後半で、自分のシナリオのパフォーマンスと構成を、当社のテストに基づくコピー アクティビティの パフォーマンス リファレンス と比較できます。Later in the article, you can compare the performance and configuration of your scenario to Copy Activity’s performance reference from our tests.

  2. パフォーマンスを診断して最適化するDiagnose and optimize performance. 観測したパフォーマンスが予測どおりでない場合は、パフォーマンスのボトルネックを特定する必要があります。If the performance you observe doesn't meet your expectations, you need to identify performance bottlenecks. 次に、パフォーマンスを最適化して、ボトルネックの影響を除去するか軽減します。Then, optimize performance to remove or reduce the effect of bottlenecks. この記事では、パフォーマンスの診断に関する詳細な説明は省略しますが、いくつかの一般的な考慮事項を次に示します。A full description of performance diagnosis is beyond the scope of this article, but here are some common considerations:

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

Data Management Gateway に関する考慮事項Considerations for Data Management Gateway

ゲートウェイの設定: Data Management Gateway をホストする専用のマシンを使用することをお勧めします。Gateway setup: We recommend that you use a dedicated machine to host Data Management Gateway. Data Management Gateway を使用する際の考慮事項に関する記事を参照してください。See Considerations for using Data Management Gateway.

ゲートウェイの監視とスケールアップ/スケールアウト: 1 つまたは複数のゲートウェイ ノードを持つ 1 つの論理ゲートウェイは、同時実行される複数のコピー アクティビティに対応できます。Gateway monitoring and scale-up/out: A single logical gateway with one or more gateway nodes can serve multiple Copy Activity runs at the same time concurrently. Azure ポータルで、ゲートウェイ マシンのリソース使用率 (CPU、メモリ、ネットワーク (着信/発信) など) のほぼリアルタイムのスナップショットと、同時実行されているジョブの数と上限を表示できます。「ポータルでのゲートウェイの監視」をご覧ください。You can view near-real time snapshot of resource utilization (CPU, memory, network(in/out), etc.) on a gateway machine as well as the number of concurrent jobs running versus limit in the Azure portal, see Monitor gateway in the portal. ハイブリッド データ移動で大量のコピー アクティビティを同時実行するか大量のデータをコピーする高いニーズがある場合は、リソースをもっと有効に利用したり、コピー能力を高めるためのより多くのリソースのプロビジョニングを実行したりできるように、ゲートウェイをスケール アップするかスケール アウトすることを検討してください。If you have heavy need on hybrid data movement either with large number of concurrent copy activity runs or with large volume of data to copy, consider to scale up or scale out gateway so as to better utilize your resource or to provision more resource to empower copy.

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

全般General

基になるデータ ストアが、そこで実行されるその他のワークロードで手一杯になっていないことを確認します。Be sure that the underlying data store is not 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, and help you understand data store performance characteristics, minimize response times, and maximize throughput.

Blob Storage から SQL Data Warehouse にデータをコピーする場合は、 PolyBase を使用してパフォーマンスを向上させることを検討してください。If you copy data from Blob storage to SQL Data Warehouse, consider using PolyBase to boost performance. 詳細については、「 PolyBase を使用して Azure SQL Data Warehouse にデータを読み込む 」を参照してください。See Use PolyBase to load data into Azure SQL Data Warehouse for details. ユース ケースを使用したチュートリアルについては、1 TB のデータを Azure Data Factory を使用して 15 分以内に Azure SQL Data Warehouse に読み込む方法に関するページを参照してください。For a walkthrough with a use case, see Load 1 TB into Azure SQL Data Warehouse under 15 minutes with Azure Data Factory.

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

"(Blob Storage、Data Lake Store、Amazon S3、オンプレミスのファイル システム、オンプレミスの HDFS など)"(Includes Blob storage, Data Lake Store, Amazon S3, on-premises file systems, and on-premises HDFS)

  • ファイル サイズとファイル数の平均: コピー アクティビティではデータを 1 ファイルずつ転送します。Average file size and file count: 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. したがって、可能であれば、小さなファイルをまとめて大きなファイルとすることで、スループットを高めてください。Therefore, 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.
  • Data Management Gateway が必要なオンプレミスのファイル システムのシナリオについては、「Data Management Gateway に関する考慮事項」を参照してください。For the on-premises file system scenario, in which Data Management Gateway is required, see the Considerations for Data Management Gateway section.

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

"(SQL Database、SQL Data Warehouse、Amazon Redshift、SQL Server データベースのほか、Oracle、MySQL、DB2、Teradata、Sybase、PostgreSQL データベースなど)"(Includes SQL Database; SQL Data Warehouse; Amazon Redshift; SQL Server databases; and Oracle, MySQL, DB2, Teradata, Sybase, and PostgreSQL databases, etc.)

  • テーブル スキーマ: テーブル スキーマは、コピーのスループットに影響を与えます。Data pattern: Your table schema affects copy throughput. 同じ量のデータをコピーする場合は、行のサイズが小さいよりも大きい方がパフォーマンスは高くなります。A large row size gives you a better performance than 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.
  • SQL Server や Oracle など、Data Management Gateway を使用する必要があるオンプレミスのリレーショナル データベースの場合は、「Data Management Gateway に関する考慮事項」を参照してください。For on-premises relational databases, such as SQL Server and Oracle, which require the use of Data Management Gateway, see the Considerations for Data Management Gateway section.

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

全般General

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

Microsoft のデータ ストアについては、データ ストアに特化した 監視とチューニングに関するトピック を参照してください。For Microsoft data stores, refer to 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.

Blob Storage から SQL Data Warehouse にデータをコピーする場合は、PolyBase を使用してパフォーマンスを向上させることを検討してください。If you are copying data from Blob storage to SQL Data Warehouse, consider using PolyBase to boost performance. 詳細については、「 PolyBase を使用して Azure SQL Data Warehouse にデータを読み込む 」を参照してください。See Use PolyBase to load data into Azure SQL Data Warehouse for details. ユース ケースを使用したチュートリアルについては、1 TB のデータを Azure Data Factory を使用して 15 分以内に Azure SQL Data Warehouse に読み込む方法に関するページを参照してください。For a walkthrough with a use case, see Load 1 TB into Azure SQL Data Warehouse under 15 minutes with Azure Data Factory.

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

"(Blob Storage、Data Lake Store、Amazon S3、オンプレミスのファイル システム、オンプレミスの HDFS など)"(Includes Blob storage, Data Lake Store, Amazon S3, on-premises file systems, and on-premises HDFS)

  • コピー動作:別のファイル ベースのデータ ストアからデータをコピーする場合、コピー アクティビティには copyBehavior プロパティを使用したオプションが 3 つあります。Copy behavior: If you copy data from a different file-based data store, 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: See the Considerations for serialization and deserialization and Considerations for compression sections for more ways to improve performance.
  • Blob Storage: 現在、Blob Storage では、データ転送およびスループットを最適化するためにブロック BLOB のみをサポートしています。Blob storage: Currently, Blob storage supports only block blobs for optimized data transfer and throughput.
  • Data Management Gateway を使用する必要があるオンプレミスのファイル システムのシナリオについては、「Data Management Gateway に関する考慮事項」を参照してください。For on-premises file systems scenarios that require the use of Data Management Gateway, see the Considerations for Data Management Gateway section.

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

"(SQL Database、SQL Data Warehouse、SQL Server データベース、Oracle データベースなど)"(Includes SQL Database, SQL Data Warehouse, SQL Server databases, and Oracle databases)

  • コピー動作:コピー アクティビティは、sqlSink 用に設定されたプロパティに応じて、さまざまな方法でデータを同期先データベースに書き込みます。Copy behavior: Depending on the properties you've set for sqlSink, Copy Activity writes data to the destination database in different ways.
    • 既定では、データ移動サービスは、一括コピー API を使用して、データを追加モードで挿入します。これにより、最高のパフォーマンスが得られます。By default, the data movement service uses the Bulk Copy API to insert data in append mode, which provides the best performance.
    • シンク内でストアド プロシージャを構成すると、データベースは一括読み込みは行わず、一度に 1 行ずつデータを適用します。If you configure a stored procedure in the sink, the database applies the data one row at a time instead of as a bulk load. パフォーマンスは大幅に低下します。Performance drops significantly. データ セットが大きい場合、代わりに sqlWriterCleanupScript プロパティを使用すること (適用できる場合) を検討してください。If your data set is large, when applicable, consider switching to using the sqlWriterCleanupScript property.
    • 各コピー アクティビティ実行の sqlWriterCleanupScript プロパティを構成すると、サービスによってスクリプトがトリガーされるので、一括コピー API を使用してデータを挿入します。If you configure the sqlWriterCleanupScript property for each Copy Activity run, the service triggers the script, and then you use the Bulk Copy API to insert the data. たとえば、テーブル全体を最新のデータで上書きするには、ソースから新しいデータを一括で読み込む前にすべてのレコードを削除するためのスクリプトを指定することができます。For example, to overwrite the entire table with the latest data, you can specify a script to first delete all records before bulk-loading the new data from the source.
  • データのパターンとバッチ サイズ: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.
    • コピー アクティビティは、一連のバッチでデータを挿入します。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.
  • SQL Server や Oracle など、Data Management Gateway を使用する必要があるオンプレミスのリレーショナル データベースの場合は、「Data Management Gateway に関する考慮事項」を参照してください。For on-premises relational databases like SQL Server and Oracle, which require the use of Data Management Gateway, see the Considerations for Data Management Gateway section.

NoSQL ストアNoSQL stores

(Table Storage、Azure Cosmos DB など)(Includes Table storage and Azure Cosmos DB )

  • Table Storageの場合:For Table storage:
    • パーティション: インターリーブされたパーティションにデータを書き込むと、パフォーマンスが大幅に低下します。Partition: Writing data to interleaved partitions dramatically degrades performance. データが複数のパーティションに順次効率よく挿入されるように、パーティション キーでソース データを並べ替えるか、データが 1 つのパーティションに書き込まれるようにロジックを調整します。Sort your source data by partition key so that the data is inserted efficiently into one partition after another, or adjust the logic to write the data to a single partition.
  • Azure Cosmos DB の場合:For Azure Cosmos DB:
    • バッチ サイズ: writeBatchSize プロパティは、ドキュメントを作成する Azure Cosmos DB サービスへの並列要求の数を設定します。Batch size: The writeBatchSize property sets the number of parallel requests to the Azure Cosmos DB service to create documents. writeBatchSize を増やすとパフォーマンスがよくなります。Azure Cosmos DB に送信される並列要求の数が増えるためです。You can expect better performance when you increase writeBatchSize because more parallel requests are sent to Azure Cosmos DB. ただし、Azure Cosmos DB に書き込む際は、スロットルに注意してください (エラー メッセージは "要求率が大きいです")。However, watch for throttling when you write to Azure Cosmos DB (the error message is "Request rate is large"). スロットルは、ドキュメントのサイズ、ドキュメント内の語句の数、ターゲット コレクションの索引作成ポリシーなど、さまざまな要因によって発生する可能性があります。Various factors can cause throttling, including document size, the number of terms in the documents, and the target collection's indexing policy. コピーのスループットを高めるには、より適切なコレクション (S3 など) の使用を検討してください。To achieve higher copy throughput, consider using a better collection, for example, S3.

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

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

コピー動作:Copy behavior:

  • ファイル ベースのデータ ストア間でファイルをコピーする:Copying files between file-based data stores:
    • 入力データ セットと出力データ セットが、両方とも同じファイル形式であるか、ファイル形式が設定されていない場合、データ移動サービスは、シリアル化または逆シリアル化を実行することなく、バイナリ コピーを実行します。When input and output data sets 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 data sets 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 data sets 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/from a data store that is not 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 の場合は、シリアル化と逆シリアル化によってコピーのスループットが低下するので、テキスト形式と比較してコストがかかります。However, 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; and 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 data set is a file, you can set 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 may see a boost in overall copy throughput.

コーデック: コピー アクティビティでは、圧縮の種類として gzip、bzip2、および Deflate がサポートされています。Codec: Copy Activity supports gzip, bzip2, and Deflate compression types. Azure HDInsight では、3 種類すべてを処理に利用できます。Azure HDInsight can consume all three types for processing. 各圧縮コーデックには、長所があります。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 is 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 is not 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.

考慮事項: オンプレミス ストアとクラウド間で大量のデータをコピーする場合は、中間 Blob Storage と圧縮の使用を検討してください。A consideration: To copy a large amount of data between an on-premises store and the cloud, consider using interim blob storage with compression. 企業ネットワークと 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 data set and output data set both to be in uncompressed form. 具体的には、1 つのコピー アクティビティを 2 つのコピー アクティビティに分割できます。More specifically, you can break a single copy activity into two copy activities. 最初のコピー アクティビティは、圧縮形式で、ソースから中間またはステージング BLOB へのコピーを行います。The first copy activity copies from the source to an interim or staging blob in compressed form. 2 番目のコピー アクティビティは、ステージングから圧縮されたデータをコピーし、シンクへの書き込み中に圧縮を解除します。The second copy activity copies the compressed data from staging, and then decompresses while it writes to the sink.

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

コピー アクティビティの columnMappings プロパティを設定して、入力列のすべてまたはサブセットを出力列にマップすることができます。You can set the columnMappings property in 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 is much more efficient.

その他の考慮事項Other considerations

コピーするデータのサイズが大きい場合は、Data Factory のスライス メカニズムを使用してさらにデータを分割するように、ビジネス ロジックを調整することができます。If the size of data you want to copy is large, you can adjust your business logic to further partition the data using the slicing mechanism in Data Factory. 次に、コピー アクティビティをより頻繁に実行するようにスケジュールして、各コピー アクティビティ実行のデータ サイズを小さくします。Then, schedule Copy Activity to run more frequently to reduce the data size for each Copy Activity run.

Data Factory が同じデータ ストアに同時に接続することを必要とするデータ セットの数とコピー アクティビティの数に注意してください。Be cautious about the number of data sets and copy activities requiring Data Factory to connector 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 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.

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

ご覧のとおり、データは次のようにストリーミングで順次処理および移動されています: SQL Server > LAN > ゲートウェイ > WAN > Blob Storage。As you can see, the data is being processed and moved in a streaming sequential manner: SQL Server > LAN > Gateway > 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.
  • Data Management Gateway:Data Management Gateway:
    • LAN: ゲートウェイは SQL Server マシンから離れた場所にあり、低帯域幅で接続されています。LAN: Gateway is located far from the SQL Server machine and has a low-bandwidth connection.
    • ゲートウェイ: ゲートウェイは、以下の操作を実行して、負荷の上限に達しています。Gateway: Gateway 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 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.

サンプル シナリオ: 並列コピーを使用するSample scenarios: Use parallel copy

シナリオ I: オンプレミスのファイル システムから Blob Storage に 1 MB のファイルを 1,000 個コピーする。Scenario I: Copy 1,000 1-MB files from the on-premises file system to Blob storage.

分析とパフォーマンスのチューニング: たとえば、クアッド コア マシン上にゲートウェイをインストール済みの場合、Data Factory は 16 の並列コピーを使用して、ファイル システムから Blob Storage にファイルを同時に移動します。Analysis and performance tuning: For an example, if you have installed gateway on a quad core machine, Data Factory uses 16 parallel copies to move files from the file system to Blob storage concurrently. この並列実行では、高いスループットが得られます。This parallel execution should result in high throughput. 並列コピーの数を明示的に指定することもできます。You also can explicitly specify the parallel copies count. 多数の小さなファイルをコピーする場合、並列コピーではリソースがより効果的に活用されるため、スループットが大幅に向上します。When you copy many small files, parallel copies dramatically help throughput by using resources more effectively.

シナリオ 1

シナリオ II: Blob Storage から Data Lake Store Analytics にそれぞれ 500 MB の BLOB を 20 個コピーして、パフォーマンスを調整する。Scenario II: Copy 20 blobs of 500 MB each from Blob storage to Data Lake Store Analytics, and then tune performance.

分析とパフォーマンスのチューニング: このシナリオでは、Data Factory は単一のコピー (parallelCopies を 1 に設定) と単一クラウド データ移動単位を使用して、データを Blob Storage から Data Lake Store にコピーします。Analysis and performance tuning: In this scenario, Data Factory copies the data from Blob storage to Data Lake Store by using single-copy (parallelCopies set to 1) and single-cloud data movement units. 観察されるスループットは、「 パフォーマンス リファレンス」セクションで説明されているスループットに近くなります。The throughput you observe will be close to that described in the performance reference section.

シナリオ 2

シナリオ III: 個々のファイル サイズが数十 MB より大きく、総量が巨大である。Scenario III: Individual file size is greater than dozens of MBs and total volume is large.

分析とパフォーマンスのチューニング: parallelCopies を増やしても、単一クラウド DMU のリソース制限があるため、コピーのパフォーマンスは向上しません。Analysis and performance turning: Increasing parallelCopies doesn't result in better copy performance because of the resource limitations of a single-cloud DMU. 代わりに、より多くのクラウド DMU を指定して、データ移動を実行するリソースをより多く取得する必要があります。Instead, you should specify more cloud DMUs to get more resources to perform the data movement. parallelCopies プロパティの値は指定しないでください。Do not specify a value for the parallelCopies property. Data Factory が自動的に並列処理を行います。Data Factory handles the parallelism for you. この場合、 cloudDataMovementUnits を 4 に設定すると、スループットが約 4 倍になります。In this case, if you set cloudDataMovementUnits to 4, a throughput of about four times occurs.

シナリオ 3

リファレンスReference

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