PR

アクティビティの実行結果を一覧

 続いて、ETLフローを実行したときに、アクティビティの状態を確認・管理する方法に話を進める。

 アクティビティの実行結果は、「監視と管理」から開く画面で行う。

 この機能はAzureポータルとは別の専用UIが用意されている。これも2017年9月時点でプレビューだが、Azureポータルと比べて利便性が高い。通常は、専用UIを利用するのがよいだろう。

 専用UIでは、左にリソースのツリービュー、中央にダイアグラムとアクティビティ一覧(ACTIVITY WINDOWS)、右にプロパティなどが表示される(画面3)。

画面3 アクティビティの実行結果の確認
画面3 アクティビティの実行結果の確認
[画像のクリックで拡大表示]

 ダイアグラム上のパイプラインやデータセットを選択すると、関連するアクティビティが強調表示されるなど、使い勝手が良い。

 アクティビティ一覧では、フィルターによって絞り込むことも可能だ。例えばStatusの条件で、失敗したアクティビティだけ表示できる。

 さらに、表示されたアクティビティを選択すると、右側にプロパティが表示され、失敗している場合はエラーメッセージやスタックトレースを確認できる。

 アクティビティが失敗したときのアラートを、画面3の一番左の時計アイコンから設定することも可能だ。ただし設定できる通知手段はメールのみである。

 Azureの他サービスと同様に、Webhook機能などが備わることを期待したい。

【検証内容】
データコピーのフロー 二つの環境で所要時間を測定

 検証では、Data Factoryのユースケースを二つ用意している。

 目的は典型的なシナリオでETLフローを実行する過程を紹介することで、パフォーマンスチューニングに用いるパラメーターへの理解や、オンプレミス環境との接続に対する理解を深めてもらうことだ。性能設計の基礎材料を提供することではないことを了承してほしい。

 検証1では、Azure Blob Storage上のログデータをSQL Databaseにコピーする(図2)。Azure内に閉じた環境でのETLフローだ。

図2 ユースケース1の対象範囲
図2 ユースケース1の対象範囲
[画像のクリックで拡大表示]

 検証2は、オンプレミス環境にあるSQL ServerのデータをAzure SQL Databaseにコピーする(図3)。

図3 ユースケース2の対象範囲
図3 ユースケース2の対象範囲
[画像のクリックで拡大表示]

 SQL Serverはファイアウォールの中にあるという想定で、オンプレミス環境のサーバーでData Management Gatewayを動作させる。Data Management GatewayがSQL ServerのデータをData Factoryに送信する。

 実際の用途では、ユースケース1とユースケース2のどちららにおいても、Azure Machine Learningで分析したりPower BIで可視化したりすることが考えられるが、ここでは対象外とする。

 検証に入る前に、Data Factoryのパフォーマンスチューニングにおける重要なパラメーターを三つ挙げておく。

 時間軸で分割されたアクティビティの並列実行数を意味する「concurrency」、1個のアクティビティ当たりの処理能力である「DMU(cloudDataMovementUnits)」、1個のアクティビティ内のIOスレッド数「parallelCopies」である。

 検証1では、これらのパラメーターのうちDMUとparallelCopiesよるパフォーマンスチューニングを行う。