データ フローがシンクに書き込まれると、カスタム パーティション分割は書き込みの直前に行われます。 ソースと同様に、ほとんどの場合、選択したパーティション オプションとして 現在のパーティション分割を使用 することをお勧めします。 パーティション分割されたデータは、パーティション分割されていないデータよりもはるかに高速に書き込まれます。ターゲットがパーティション分割されていない場合でも、 さまざまなシンクの種類に関する個々の考慮事項を次に示します。
Azure SQL Database シンク
Azure SQL Database では、ほとんどの場合、既定のパーティション分割が機能します。 シンクにパーティションが多すぎて SQL データベースが処理できない可能性があります。 これを実行している場合は、SQL Database シンクによって出力されるパーティションの数を減らします。
ソースの不足している行に基づいてシンク内の行を削除するためのベスト プラクティス
この一般的なパターンを実現するために、存在、行の変更、シンク変換でデータ フローを使用する方法のビデオ チュートリアルを次に示します。
エラー行処理のパフォーマンスへの影響
シンク変換でエラー行処理 ("エラー時に続行") を有効にすると、互換性のある行を変換先テーブルに書き込む前に、サービスが追加の手順を実行します。 この追加の手順は、小さなパフォーマンスのペナルティを伴い、ステップごとに最大で5％増加する可能性があります。また、互換性のない行をログファイルに書き込むオプションを設定すると、さらに小さなパフォーマンスの影響が追加される場合があります。
SQL スクリプトを使用したインデックスの無効化
SQL データベースの読み込み前にインデックスを無効にすると、テーブルへの書き込みのパフォーマンスが大幅に向上します。 SQL シンクに書き込む前に、次のコマンドを実行します。
ALTER INDEX ALL ON dbo.[Table Name] DISABLE
書き込みが完了したら、次のコマンドを使用してインデックスを再構築します。
ALTER INDEX ALL ON dbo.[Table Name] REBUILD
これらはどちらも、マッピング データ フローの Azure SQL Database または Synapse シンク内の Pre スクリプトと Post-SQL スクリプトを使用してネイティブに実行できます。
Warnung
インデックスを無効にすると、データ フローはデータベースを効果的に制御するため、現時点ではクエリが成功する可能性は低いです。 その結果、この競合を回避するために、多くの ETL ジョブが深夜にトリガーされます。 詳細については、SQL インデックスを無効にする制約について説明します
データベースのスケールアップ
パイプラインを実行する前にソースとシンクの Azure SQL DB と DW のサイズ変更をスケジュールして、スループットを向上させ、DTU の制限に達したら Azure の調整を最小限に抑えます。 パイプラインの実行が完了したら、データベースのサイズを通常の実行速度に戻します。
Azure Synapse Analytics データ出力先
Azure Synapse Analytics に書き込む場合は、[ ステージングを有効にする] が true に設定されていることを確認します。 これにより、サービスは SQL COPY コマンドを使用して書き込むことができます。これにより、データが効率的に一括で読み込まれます。 ステージングを使用する場合は、データをステージングするために Azure Data Lake Storage gen2 または Azure Blob Storage アカウントを参照する必要があります。
ステージング以外のベスト プラクティスは、Azure SQL Database と同じベスト プラクティスが Azure Synapse Analytics に適用されます。
ファイル ベースのシンク
データ フローではさまざまな種類のファイルがサポートされますが、読み取りと書き込みの最適な時間を実現するために、Spark ネイティブの Parquet 形式をお勧めします。
データが均等に分散されている場合は、ファイルを書き込むための最速のパーティション分割オプションとして 、現在 のパーティション分割を使用します。
ファイル名のオプション
ファイルを書き込む場合は、それぞれパフォーマンスに影響を与える名前付けオプションを選択できます。
[既定] オプションを選択すると、最も高速に書き込まれます。 各パーティションは、Spark の既定の名前を持つファイルに相当します。 これは、データのフォルダーから読み取るだけの場合に便利です。
名前付け パターン を設定すると、各パーティション ファイルの名前がよりわかりやすい名前に変更されます。 この操作は書き込み後に行われ、既定値を選択するよりも少し遅くなります。
パーティションごとに 、個々のパーティションに手動で名前を付けることができます。
列がデータの出力方法に対応する場合は、[ 名前ファイル] を列データとして選択できます。 これにより、データが再シャッフされ、列が均等に分散されていない場合のパフォーマンスに影響する可能性があります。
列がフォルダー名の生成方法に対応する場合は、[フォルダーの 名前を列データとして選択します] を選択します。
1 つのファイルへの出力 では、すべてのデータが 1 つのパーティションに結合されます。 これにより、書き込み時間が長くなります(特に大規模なデータセットの場合)。 このオプションを使用する明示的なビジネス上の理由がない限り、このオプションは推奨されません。
Azure Cosmos DB シンク
Azure Cosmos DB に書き込む場合、データ フローの実行中にスループットとバッチ サイズを変更すると、パフォーマンスが向上する可能性があります。 これらの変更は、データ フロー アクティビティの実行中にのみ有効になり、結論後に元のコレクション設定に戻ります。
バッチ サイズ: 通常、既定のバッチ サイズから始めて十分です。 この値をさらに調整するには、データの大まかなオブジェクト サイズを計算し、オブジェクト サイズ * バッチ サイズが 2 MB 未満であることを確認します。 その場合は、バッチ サイズを増やしてスループットを向上させることができます。
スループット： ドキュメントが Azure Cosmos DB への書き込みを高速化できるように、ここでより高いスループット設定を設定します。 高スループットの設定に基づいて、RU コストが高くなる点に注意してください。
書き込みスループットの予算: 1 分あたりの RU の合計よりも小さい値を使用します。 Spark パーティションの数が多いデータ フローがある場合は、予算スループットを設定すると、それらのパーティション間でより多くのバランスを取ることができます。
関連するコンテンツ
パフォーマンスに関連するその他のデータ フローに関する記事を参照してください。