データ ファクトリ パイプラインをデバッグする

顧客の要求や期待はデータ統合に関連して変化しています。 そのため、ユーザーの間で ETL (抽出、変換、読み込み) と ELT (抽出、読み込み、変換) のワークフローを繰り返し開発およびデバッグする必要性がますます高まっています。

Azure Data Factory は、データ統合ソリューションを開発するときに、データ ファクトリ パイプラインの反復デバッグを構築して開発するのに役立ちます。 パイプライン キャンバスを使用してパイプラインを作成すると、デバッグ機能を使ってアクティビティとパイプラインをテストできます。

Azure Data Factory では、デバッグする前に、パイプラインやアクティビティの変更を発行する必要はありません。 これは、実際に保存して発行する前に、変更をテストして、期待どおりに動作するかどうかを確認するシナリオで役立ちます。

また、パイプライン全体をデバッグするのではなく、パイプラインの一部をテストしたいと考える場合もあります。 デバッグの実行では、そのような操作を行うことができます。 パイプラインの端から端までテストすることも、ブレークポイントを設定することもできます。 デバッグ モードで実行すると、パイプラインを構築してデバッグするときに、各ステップの結果を対話形式で確認できます。

パイプラインをデバッグして発行する

実行中のパイプラインを作成または変更するときは、パイプライン キャンバスの [出力] タブで各アクティビティの結果を確認できます。

テストの実行が成功し、結果に問題がなければ、パイプラインにさらにアクティビティを追加し、反復的な方法でデバッグを続行できます。 結果に満足できないか、パイプラインのデバッグを中止する場合は、テストの実行中に実行を取り消すことができます。 デバッグ スライダーを選択すると、実際にパイプラインが実行されることに注意してください。 たとえば、パイプラインにコピー アクティビティが含まれている場合、テストの実行によって、データがソースからターゲットにコピーされます。

ベスト プラクティスとして、デバッグ時はコピー アクティビティとその他のアクティビティでテスト フォルダーを使用します。これにより、結果に問題がなく、パイプラインのデバッグを完了した時点で、通常の操作のために実際のフォルダーに切り替えることができます。

パイプラインをデバッグするには、ツール バーの [デバッグ ] を選択します。 パイプライン実行の状態は、ウィンドウの下部にある [出力 ] タブに表示されます。

パイプラインが正常に実行されたら、上部のツール バーで [ すべて発行] を選択します。 これにより、作成したエンティティ (データセットとパイプライン) が Data Factory に発行されます。

[正常に発行されました] というメッセージが表示されるまで待ちます。 通知メッセージを表示するには、ポータルの右上にある [通知の表示 ] (ベル アイコン) を選択します (ベル ボタン)。

マップ データフローのデバッグ

マッピング データフローの構築中は、データのシェイプと変換をデバッグできるように、それらがどのように実行されているかを対話形式で監視できます。 この機能を使用するには、最初に "データ フローのデバッグ" 機能を有効にする必要があります。

デバッグ セッションは、データ フロー設計セッションと、データ フローのパイプライン デバッグ実行中の両方で使用できます。 デバッグ モードがオンになった後、実際にはアクティブな Spark クラスターを使用してデータ フローを構築することになります。 デバッグが無効になると、この Spark クラスターは終了します。 どのコンピューティングを使用するかを選択できます。 既存のデバッグ クラスターを使用すると、起動時間が短縮されます。 ただし、複雑なワークロードや並列ワークロードの場合は、独自の Just-In-Time クラスターを作成することをお勧めします。

データ フローをデバッグするためのベストプラクティスは、デバッグ モードをオンにしたままで、データ フローに含まれるビジネス ロジックを確認および検証することです。 データの変換とシェイプを視覚的に表示すると、変更を確認する場合に役立ちます。

作成したパイプラインでデータフローをテストする場合は、パイプライン パネルの [デバッグ ] ボタンを使用することをお勧めします。 データ プレビューではデータが書き込まれませんが、データフロー内でのデバッグの実行では、パイプラインのデバッグと同様に、データがシンクのターゲットに書き込まれます。

デバッグの設定

前述のように、Azure Data Factory ユーザー インターフェイスから開始される各デバッグ セッションは、独自の Spark クラスターを使用した新しいセッションと見なされます。 セッションを監視するために、デバッグ セッションの監視ビューを使用して、設定されている Data Factory ごとにデバッグ セッションを管理できます。

Spark クラスターがデバッグ用に準備できているかどうかを確認するには、デザイン サーフェイスの上部にあるクラスター状態の表示を確認します。 緑色の場合は、準備ができています。 デバッグ モードに入ったときにクラスターが実行されなかった場合、クラスターのスピンアップが必要であるため、待機時間は約 5 分から 7 分になる可能性があります。

デバッグを完了した後、Spark クラスターが終了するようにデバッグ モードをオフにすることをお勧めします。

デバッグ中は、[ デバッグ設定] を選択して、データ フロー内のデータのプレビューを編集できます。 データのプレビューを変更する例としては、ソース変換を使用した場合の行制限やファイル ソースなどがあります。 ステージング リンク サービスを選択すると、ソースとして Azure Synapse Analytics を使用できます。

データ フローまたはその参照先データセットにパラメーターがある場合は、[ パラメーター ] タブを選択して、デバッグ中に使用する値を指定できます。デバッグ中、シンクは必須ではなく、データフローでは無視されます。 変換されたデータをテストしてシンクに書き込む場合は、パイプラインからデータ フローを実行し、そのパイプラインからデバッグの実行を使用できます。

前述のように、Azure Data Factory 内では、特定の場所またはアクティビティまでのデバッグのみを行うことができます。 これを行うには、アクティビティのブレークポイントをテストする場所まで使用し、[ デバッグ] を選択します。 Debug Until オプションは、要素の右上隅に空の赤い円として表示されます。 Debug Until オプションを選択すると、これがブレークポイントが有効であることを示す、塗りつぶされた赤い円に変わります。 その後、Azure Data Factory ではパイプライン内のそのブレークポイント アクティビティまでテストが確実に実行されるようにします。 この機能は、パイプライン内のアクティビティのサブセットのみをテストする場合に便利です。

ほとんどのシナリオでは、Azure Data Factory のデバッグ機能で十分です。 ただし、複製されたサンドボックス環境でパイプラインの変更をテストすることが必要になる場合があります。 これを行うユース ケースとして、ファイルの到着をトリガーするときと、タンブリング時間枠でトリガーするときのパラメーター化された ETL パイプラインの動作をテストする場合があります。 この場合は、サンドボックス環境の複製の方が適している可能性があります。

Azure Data Factory について知っておくとよいことは、課金は主に実行回数単位でのみ行われるため、2 つ目の Data Factory によって追加料金が発生することはないということです。

デバッグ実行を監視する

デバッグ実行を監視するために、出力タブを確認できますが、閲覧セッション内で行われた最新の実行のみが対象となります。これは、履歴が表示されないためです。 デバッグ実行の履歴を表示する場合、またはすべてのアクティブなデバッグ実行を表示する場合は、[ 監視 ] タブに移動します。

注意すべき点は、Azure Data Factory サービスでは、デバッグの実行履歴の保持期間が 15 日間のみということです。 データ フロー デバッグ セッションの監視に関連して、[ 監視 ] タブにも移動します。