[CDGC] Azure Data Factory のスキャン

# はじめに
[インフォマティカ](https://www.informatica.com/jp/)が提供する [CDGC](https://www.informatica.com/jp/products/data-governance/cloud-data-governance-and-catalog.html)(データガバナンス＆カタログ) を使って Azure Data Factory(以降、ADF とします)に関するメタデータを取得(スキャン)するためのガイドです。
※2023/08時点の情報を元にしています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/eaaf3177-eddb-d5e1-25f9-4c861be77a0a.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/0a3ae605-c574-97a2-fcff-fd3009cfe324.png)

<!-- 各チャプター -->
 
# 事前準備
CDGC がセットアップ済みであり、メタデータコマンドセンターのメニューにアクセスできるライセンス、およびユーザロール、ユーザである事を確認して下さい。詳細は [こちらのナレッジベース](https://knowledge.informatica.com/s/article/FAQ-CDGC-apps-licenses-roles?language=ja) を確認頂ければと思います。
 
# 前提
[前回](https://qiita.com/tmasudaf23/items/1548c53f3634e1ee2bca)の投稿では Azure Data Lake Storage gen2 上のファイルをスキャンする内容をご紹介しました。実はこのファイルは[前々回](https://qiita.com/tmasudaf23/items/45add1b3b298e2aae8ea)の Microsoft SQL Server のテーブルを Azure Data Lake Storage gen2 にコピーする、以下の様なシンプルな ADF のパイプラインで生成したものでした。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/c39844fa-7f5e-a10b-08b6-730b156246fc.png)

つまり、この ADLS gen2 上のデータは SQL Server => ADF => ADLS gen2 と流れてきたデータになります。こういったデータの流れを "系統" であったり、"リネージ"、"リネージュ" と言います。

今回の記事ではこのパイプラインを使用し、メタデータを抽出するまでと、SQL Server => ADF => ADLS gen2 のリネージュを確認するまでの手順を紹介してみようと思います。

# スキャン設定
それでは早速、ADF のメタデータをまずは抽出してみましょう。

## 1.メニューから "メタデータコマンドセンター" を起動
メニューから "メタデータコマンドセンター" を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/6a86ebd0-df29-e8f1-7c8f-88cfe590d312.png)

## 2.メタデータコマンドセンターから "新規" を選択
新しくカタログソースを設定する為、"新規"をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/68591ed1-5efc-cf90-76b5-5a6ca93dfe02.png)

## 3.カタログソースから "Microsoft Azure Data Factory" を選択
カタログソースにリストされる一覧から "Microsoft Azure Data Factory" を選択します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/219c52de-a785-69a0-9d82-33892086af22.png)

## 4.Microsoft Azure Data Factory への接続を設定
ADF にアクセス可能なサービスプリンシパル情報を入力し、"次へ" をクリックします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/31751367-dde7-dbf7-298a-13807cfe9f14.png)

:::note warn
上で指定したサービスプリンシパルで ADF にアクセスできるように IAM は設定した前提で実施しています。サービスプリンシパルに関しては Azure 管理者様にご相談ください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/0e64a66b-cc59-fb07-920b-3b52f004e31e.png)

:::

## 5."メタデータの抽出" を設定
"メタデータの抽出" タブで以下の各項目を設定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/3fc67758-bb2d-1df6-cc4b-b04768139b94.png)

### 5-1.ランタイム環境
ランタイム環境から利用する Secure Agent を選択します。
### 5-2.メタデータ変更オプション
"メタデータ変更オプション" には今回も "削除" を設定しておきます。

:::note warn
"メタデータ変更オプション" のチェック項目の日本語訳が正しくなく、[修正予定](https://network.informatica.com/s/ideadetail?id=0876S000000wpVNQAY)がまだ先になりますので簡単に補足しておきます。この設定は既にカタログに取り込まれたアセットがソースシステム側で削除された場合にどう処理されるかを決定します。それぞれの設定に対して以下の様な動作となります。

| オプション |動作|
|:-:|:--|
|保持|カタログソースからオブジェクトが削除されたり、フィルタ条件の変更でオブジェクトがヒットしなくなった場合でも、既にカタログ内に存在する変更前のアセットはカタログに保持されます。|
|削除|カタログソースからオブジェクトが削除された場合及びフィルタ条件の変更でオブジェクトがヒットしない場合、メタデータがカタログから削除されます。|

つまり、過去に一度でもアセットとして存在していたら残したい、という場合には"保持"を設定する必要がありますが、現在の最新のスキャン対象の最新状態、フィルタ条件に応じたアセットを抽出、検索したい場合、"削除"を設定します。
:::

### 5-3.メタデータフィルタ
データベースと同様にメタデータ抽出にフィルタを設定できます。設定可能な詳細は "サポートされているワイルドカードと例を非表示にする" を展開すると、フィルタ構文を確認する事が出来ますので別途確認してみてください。
今回の ADF 内には以下の様に幾つかパイプラインがあるのですが、デモ用のパイプラインだけにしたかったので、"リソース名/パイプライン名"(CST-Data-Factory/DEMO_qiita_ADF_pipeline/*)で指定しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/37c10f01-3a8b-fee4-1c37-8146cb50c61c.png)


## 6."実行"でスキャンを開始
他にも設定項目はありますが、今回の記事のフォーカスポイントは設定し終わったので、"実行" をクリックし、スキャンを実行します。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/b5abb502-7fd9-40f2-4858-b48bbb182e5a.png)

## 7.実行スコープの設定
初回実行時、以下の様にオプションはグレーアウトしていますので、そのまま進めます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/261c2e33-ca31-06d0-5b76-fe4d0155fb88.png)

## 8.ジョブ監視画面で結果を確認
ジョブ監視画面に自動で遷移するので、しばらく待ってステータスが完了した事を確認します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/bf9094a8-9e30-14f2-73bb-38169ce43b56.png)

以下の様にパイプライン内のコピーアクティビティ、データセットなどが確認できますね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/b19b62ef-73d0-b2c4-1872-c6e11297f23a.png)

# リネージュの確認と参照データセット
スキャンが完了しましたので、ADF 内のアクティビティからリネージュを一旦確認してみましょう。すると以下の様なリネージュが確認できるかと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/f3bfb733-f2a3-6d51-451e-0a53339497ed.png)

ソース => コピーアクティビティ => シンク のようなデータの系統、リネージュが確認できますね。ただ、トップレベルのリソースはいずれも、ADF リソースになっています。

この点について少し、補足したいと思います。CDGC はスキャンした ADF の定義から、このパイプラインが SQL Server のテーブルと ADLS gen2 上のファイル間のコピーアクティビティである事はわかっています。しかし、これらのテーブルやファイルはパイプラインのような ADF の実オブジェクトではありません。とはいえ、仮にこのような参照されるテーブルやファイルなどが合わさって表示されないと、どのような処理なのか、せっかく ADF のメタデータを抽出しても意味が分かりませんよね。なので CDGC はこのようなスキャン対象のリソースの外で参照されているようなアセット(これを "参照データセット" と呼んでいます)を CDGC がリソースを作成時に併せて作成するように動作します。結果として、スキャンが成功すると ADF が参照している参照データセット同士の、ADF 内での閉じたようなリネージュの表記として表示されている、という感じです。

:::note info
以下はソース側の SQL Server 側の参照データセットにマウスポインタを合わせた際に表示されるポップアップの拡大画像です。今回定義した ADF リソースの定義より、こういうデータセット(ソース、シンク)を使用しているはずだ、というものが参照データアセットとして作成され、リネージュに表示されている様子がわかります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/e3abfe86-9eea-1300-15c0-20a3eb449a52.png)
:::

しかし、前提の個所でも触れたように今回のコピーアクティビティが使用するソースとシンクはどちらも、既に前回までに CDGC でカタログ化されていましたよね。参照データセットではなく、実際に既にカタログ化されたメタデータと紐づけてリネージュ出来るように、"接続割り当て" を実行してみましょう。


# 接続割り当て
メタデータコマンドセンターを開き、"監視" => "接続割り当て" をクリックします。すると、以下の画面の様に 左側に ADF のリンクされたサービス名(Linked Service名)がリストされているのが見えると思います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/a451dc1a-4785-8bbd-f400-7c711d434abe.png)

ここでリンクされたサービス名の右端の三点リーダーから、"Assign" をクリックすると以下の様にリソースの選択画面が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/5ef0e9bd-db63-a845-e12e-e75c82994978.png)
前回スキャンした ADLS gen2 リソースが表示されていますね。もし、同じタイプのリソースが多数ある場合には "フィルタの追加" をクリックし、絞り込みをかけるとよいでしょう。左のチェックボックスにチェックを入れ、"Assign" をクリックします。また、もう 1 つの接続には同じ手順で SQL Server 側を割り当てます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/90f3b0b4-7688-c596-224c-5a62792fd288.png)

しばらく待つと以下の様に接続割り当てが完了した事が確認できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/34b4acee-1a39-e24c-be53-fbde2f42685c.png)


# 結果の確認
さぁ、それでは結果を確認してみましょう。

## 1.取得したアセットの一覧を表示
CDGC の画面(データガバナンスとデータカタログ)を呼出し、該当のカタログリソースが閲覧できることを確認します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/e893d93d-2d46-a438-a61b-9065bc15e023.png)


## 2.リネージュの確認
ADLS gen2 上に出力されたファイルからリネージュを確認してみましょう。最終的に以下の様に CDGC 内の SQL Server 上の CUSTOMER_DETAILS テーブルから、ADF のコピーアクティビティを経て、CDGC 内の ADLS gen2 へデータが流れた事が確認できますね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3520029/e5f5a96e-71de-d8c4-20fe-4e3b85ecd603.png)


# Tips
- スキャンなどが失敗する場合、ナレッジベース(KB)を参照し、エラーメッセージから検索を実施して下さい。
- 何らかの理由でスキャンが失敗し、該当するような事例がナレッジベースからも見つからない場合、サポート契約があればご支援が可能です。その場合、[初期情報](https://knowledge.informatica.com/s/article/HOW-TO-Collect-Cloud-Data-Governance-and-Catalog-Information?language=ja)を纏めてお問い合わせください。


# 参考文献
- [マニュアル(ログインが必要)](https://docs.informatica.com/data-governance-and-quality-cloud/metadata-command-center/current-version/microsoft-azure-data-factory-sources/preface.html)
- [ナレッジベース(KB) - How to Library(H2L)](https://knowledge.informatica.com/s/article/How-To-Configure-an-Azure-Data-Factory-Resource-in-CDGC?language=en_US)