Azure Integration Runtime のパフォーマンスの最適化
データ フローは、実行時にスピンアップされる Spark クラスター上で実行されます。 使用されるクラスターの構成は、アクティビティの統合ランタイム (IR) 内に定義されます。 統合ランタイムを定義する際は、クラスターの種類、クラスターのサイズ、Time to Live という 3 つのパフォーマンスに関する考慮事項があります。
Integration Runtime の作成方法の詳細については、Integration Runtime に関する記事を参照してください。
データ フロー統合ランタイムを使い始める最も簡単な方法は、コンピューティング サイズ ピッカーから小、中、または大を選ぶことです。 以下のサイズについては、クラスター構成へのマッピングを参照してください。
クラスター サイズ
データ フローでは、データ処理を Spark クラスター内の異なる複数のコアに分散して、操作を並列で実行します。 コア数が多い Spark クラスターでは、コンピューティング環境のコア数が増加します。 コアが増えると、データ フローの処理能力が向上します。 多くの場合、クラスターのサイズを増やすことは、処理時間を短縮するための簡単な方法です。
既定のクラスター サイズは、4 つのドライバー コアと 4 つのワーカー コア (小) です。 より多くのデータを処理する場合は、より大きなクラスターを使用することをお勧めします。 可能なサイズ変更オプションは次のとおりです。
| ワーカー コア | ドライバー コア | コアの合計 | メモ |
|---|---|---|---|
| 4 | 4 | 8 | 小 |
| 8 | 8 | 16 | Medium |
| 16 | 16 | 32 | Large |
| 32 | 16 | 48 | |
| 64 | 16 | 80 | |
| 128 | 16 | 144 | |
| 256 | 16 | 272 |
データ フローは仮想コア時間で課金されます。つまり、クラスターのサイズと実行時間の両方が考慮されます。 スケールアップすると、1 分あたりのクラスター コストが増加しますが、全体的な時間は減少します。
ヒント
クラスターのサイズがデータ フローのパフォーマンスに与える影響には上限があります。 データのサイズによっては、クラスターのサイズを大きくしてもパフォーマンスが向上しなくなるポイントがあります。 たとえば、データのパーティション数よりも多くのコアがある場合、コアを追加しても役に立ちません。 ベスト プラクティスとして、小規模に開始し、パフォーマンスのニーズに合わせてスケールアップすることをお勧めします。
カスタム シャッフル パーティション
データフローは、データをパーティションに分割し、さまざまなプロセスを使用して変換します。 パーティション内のデータ サイズが、プロセスがメモリに保持できるサイズを超える場合、そのプロセスは OOM (メモリ不足) エラーで失敗します。 データフローに結合/集計を含む大量のデータが含まれている場合は、シャッフル パーティションを段階的に変更してみてください。 これは OOM エラーを回避するために、50 から 2000 まで設定できます。 データフロー ランタイムでカスタム プロパティを計算することは、コンピューティング要件を制御する方法です。 プロパティ名は Shuffle partitions で、整数型です。 このカスタマイズは、既知のシナリオでのみ使用する必要があります。そうしないと、不要なデータフロー エラーが発生する可能性があります。
シャッフル パーティションを増やしながら、データが十分に分散されていることを確認します。 大まかな数値は、パーティションあたり約 1.5 GB のデータを持つことです。 データが偏っている場合は、"Shuffle partitions" を増やしても役に立ちません。 たとえば、500 GB のデータがある場合は、400 から 500 の間の値が適切です。 シャッフル パーティションの既定の制限は 200 で、約 300 GB のデータに適しています。
- ADF ポータルの [管理] で、カスタム統合ランタイムを選択し、編集モードに切り替えます。
- [データフロー ランタイム] タブで、[カスタム プロパティの計算] セクションに移動します。
- [プロパティ名] で [Shuffle Partitions] を選択し、任意の入力値 (250、500 など) を選びます。
cleanup プロパティなど既存のプロパティの後にプロパティ名と値を含む配列を追加して、ランタイムの JSON ファイルを編集しても、同じことができます。
Time to Live
既定では、すべてのデータ フロー アクティビティにより、Azure IR 構成に基づいて新しい Spark クラスターがスピンアップされます。 コールド クラスターの起動にかかる時間は数分で、それが完了するまではデータ処理を開始できません。 パイプラインに複数のシーケンシャル データ フローが含まれている場合は、Time to Live (TTL) 値を有効にすることができます。 Time to Live 値を指定すると、クラスターは実行が完了してから一定の期間、有効な状態に維持されます。 TTL 時間内に IR を使用する新しいジョブを開始すると、既存のクラスターが再利用され、開始時間は大幅に減少します。 2 番目のジョブが完了すると、クラスターは TTL 時間の間、再び有効な状態で維持されます。
ただし、データ フローの大部分が並列で実行される場合は、それらのアクティビティに使用する IR の TTL を有効にしないことをお勧めします。 1 つのクラスターで一度に実行できるジョブは 1 つだけです。 使用可能なクラスターがあり、2 つのデータ フローが開始されている場合は、その 1 つだけにライブ クラスターが使用されます。 2 番目のジョブで、それ専用の分離クラスターがスピンアップされます。
Note
自動解決統合ランタイム (規定値) を使用する場合、Time to Live は使用できません。
関連するコンテンツ
パフォーマンスに関する Data Flow のその他の記事を参照してください。