はじめに

本記事では、現在Previewで公開されているAzure Purviewを用いてデータの系列を確認します。内容としては非常にシンプルでAzure Blob StorageのデータをAzure Data Lake StorageにCopyし、ADLS側をスキャンしたときにそのデータの系列が辿れていることを確認します。

ちなみにAzure Purviewの辿れるデータ処理システムは現状かなり限られています。その分Informatica等と比較してかなりコストは安いように設定されています。

データの系列とは

データ系列は、データの送信元にまたがるライフサイクルとして広く認識されており、データ資産間で時間の経過と共に移動します。これは、トラブルシューティング、データパイプラインでの根本原因のトレース、デバッグなど、さまざまな種類の後方検索シナリオに使用されます。また、系列は、データ品質分析、コンプライアンス、および影響分析と呼ばれる "What-If" シナリオにも使用されます。系列は、データの変換方法を含め、移動元から移動先へのデータを表示するために視覚的に表現されます。ほとんどのエンタープライズデータ環境は複雑であるため、これらのビューは、周辺機器データポイントの統合やマスキングを行わないと理解しづらい場合があります。

必要なリソースの準備

実験用として以下のものを用意します。

Azure Blob Storage
Azure Data Lake Storage Gen2(ADLS)
Azure Purview Account
Azure Data Factory(ADF)

Azure Portalから検索すると作成できます。

Azure Data Factory上でCOPYパイプラインの作成

単純にBlobストレージからADLSにデータをコピーするパイプラインをADF上に構築します。[移動と変換]->[データのコピー]を配置します。

ソースの場所とシンク先を設定します。
このコピー先であるADLS側をAzure Purviewでスキャンしてみましょう。

Azure PurviewからAzure Data Lake Storageをスキャンして系列を確認する

Purview Studioを開き、Sourcesペインからデータソースを登録します。RegistarまたはNew collectionを選択し、データを選択します。

Collectionに紐づける形で登録できました。

マネージドID認証をする場合は、スキャンしたいData LakeのIAMロールから、Azure Purviewのリソースに対してストレージBlobデータ閲覧者権限以上を与える必要があるのでご注意ください。[ストレージBlob閲覧者]でないと、データの中身にアクセスできずリネージュが作成されません。KeyVaultに保存したシークレットを利用して認証することも可能です。

実際にスキャンしてみます。このスキャンは手動で実行することもバッチのスケジュールを基にした自動実行も可能です。

スキャンされたデータを確認してみると、カラムにタグ付けされていることが分かります。

肝心のデータ系列が見れない。

原因は分からないのですが、Linaegeの欄を見てみると[Not Available]と言われます。これはPreviewが故なのか、自分の設定の何かが悪かったのか分かりませんが、想定していた結果が得られませんでした。

#追記：解決しました
データの系列が見れるようになりました。

原因は、Azure Purview上でAzure Data Factoryを登録していなかったことでした。データの系列に関する情報はADFに蓄積されている情報なのでADFとの接続は必須でした。Purview上の[Management Center]から設定可能です。

※[ADFリソースの登録]⇒[ADFパイプラインの実行]⇒[Purviewスキャンの実行]の順で再度実行が必要になる点だけご注意ください。

おわりに

データ系列の作成の部分は、そもそもAzure Data Factoryでの処理にしか対応していないなど制限が多いようです。今回想定していた結果が得られなかったのも、何かパイプライン上での設定が必要だったのかもしれません。まだ検証は続けていくので、原因が分かり次第記事のアップデートをしようと思います。無念。

ETLツールとしてAzure Data Factoryを利用しているユーザにとっては非常に魅力的なツールだと思います。そもそもADF自体AWS S3など外部のデータソースにも対応しているので、外部データをADFでETLしている場合にはデータ管理がより一層しやすくなるかと思います。