データに依存しないインジェスト エンジン

この記事では、Azure Data Factory 内でどのように PowerApps、Azure Logic Apps、メタデータ駆動型のコピー タスクを組み合わせて使用すると、データに依存しないインジェスト エンジンのシナリオを実装できるかについて説明します。

データに依存しないインジェスト エンジンのシナリオは、一般的に、非技術系の (データ エンジニアではない) ユーザーが、さらに処理を行うためにデータ資産を Data Lake に発行できるようにすることに重点が置かれます。 このシナリオを実装するには、以下を可能にするオンボード機能が必要です。

• データ資産の登録
• ワークフローのプロビジョニングとメタデータのキャプチャ
• インジェストのスケジュール設定

以下で、これらの機能がどのように相互作用するかを確認できます。

図 1: データ登録機能の相互作用。

次の図は、Azure サービスを組み合わせて使用し、このプロセスを実装する方法を示しています。

図 2: 自動インジェスト プロセス。

データ資産の登録

自動インジェストを動作させるために使用されるメタデータを提供するには、データ資産の登録が必要です。 キャプチャする情報には、次のものが含まれます。

• 技術情報: データ資産名、ソース システム、種類、形式、頻度。
• ガバナンス情報: 所有者、スチュワード、可視性 (検出目的の場合)、秘密度。

PowerApps は、各データ資産を記述しているメタデータをキャプチャするために使用されます。 モデル駆動型アプリを使用して、カスタム Dataverse テーブルに保持される情報を入力します。 Dataverse 内でメタデータが作成または更新されると、さらに処理手順を呼び出す自動クラウド フローがトリガーされます。

図 3: データ資産の登録。

ワークフローのプロビジョニング/メタデータ キャプチャ

ワークフローのプロビジョニング段階では、登録段階で収集されたデータを検証し、メタストアに保持します。 技術面とビジネス面の両方の検証手順が実行されます。これには以下が含まれます。

• 入力データ フィードの検証
• 承認ワークフローのトリガー
• メタデータ ストアへのメタデータの保持をトリガーするロジック処理
• アクティビティの監査

図 4: 登録ワークフロー。

インジェスト要求が承認されると、ワークフローでは、Azure Purview REST API を使用して Azure Purview にソースが挿入されます。

データ製品のオンボードに関する詳細なワークフロー

図 5: 新しいデータセットを取り込む方法 (自動化)。

図 5 は、新しいデータ ソースのインジェストを自動化するための、詳細な登録プロセスを示しています。

• 運用やデータ ファクトリの環境を含めて、ソースの詳細が登録されます。
• データ シェイプ、形式、品質の制約がキャプチャされます。
• データが機密 (個人情報) であるかどうかは、データ アプリケーション チームが指定する必要があります。この分類によって、未加工データ、エンリッチ データ、キュレーション データを取り込むためにデータ レイク フォルダーが作成されるプロセスが駆動されます。 ソースによって未加工データとエンリッチ データの名前が指定され、データ製品によってキュレーション データの名前が指定されます。
• データセットの取り込みとアクセスの付与のために、サービス プリンシパルとセキュリティ グループが作成されます。
• インジェスト ジョブが、Data Factory メタストアのデータ ランディング ゾーンに作成されます。
• API によって、データ定義が Azure Purview に挿入されます。
• 運用チームによるデータ ソースの検証と承認に応じて、詳細が Data Factory メタデータ ストアに発行されます。

インジェストのスケジュール設定

Azure Data Factory 内では、メタデータ駆動型のコピー タスクが、Azure SQL Database に格納されている制御テーブル内の行によってオーケストレーション パイプラインを駆動できるようにする機能を提供します。 データ コピー ツールを使用して、メタデータ駆動型のパイプラインを事前に作成できます。

パイプラインが作成されると、データ資産登録メタデータによって識別されるソースからのインジェストをサポートするためのエントリが、プロビジョニング ワークフローによって制御テーブルに追加されます。 Azure Data Factory パイプラインと、制御テーブル メタストアを格納している Azure SQL Database は、どちらも各データ ランディング ゾーン内に存在して、新しいデータ ソースを作成し、それらをデータ ランディング ゾーンに取り込むことができます。

図 6: データ資産インジェストのスケジュール設定。

新しいデータ ソースのインジェストに関する詳細なワークフロー

次の図は、Data Factory SQL Database メタストアに登録されたデータ ソースがどのようにプルされるかと、データが最初にどのように取り込まれるかを示しています。

Data Factory インジェスト マスター パイプラインは、Data Factory SQL Database メタストアからの構成の読み取り後、正しいパラメーターを使用して繰り返し実行されます。 変更がわずかであったりまったくないデータは、ソースから Azure Data Lake 内の未加工レイヤーに移動します。 データ シェイプは、Data Factory メタストアに基づいて検証されます。 ファイル形式は、Apache Parquet または Avro 形式のいずれかに変換されてから、エンリッチ レイヤーにコピーされます。

取り込まれたデータは Azure Databricks のデータ サイエンスおよびエンジニアリングのワークスペースに接続され、データ ランディング ゾーンの Apache Hive メタストア内にデータ定義が作成されます。

Azure Synapse サーバーレス SQL プールを使用してデータを公開する必要がある場合は、レイク内のデータに対するビューを、カスタム ソリューションで作成する必要があります。

行レベルまたは列レベルの暗号化が必要な場合は、カスタム ソリューションによって、データをデータ レイクに配置してから、SQL プール内の内部テーブルにデータを直接取り込んで、SQL プール コンピューティングに対して適切なセキュリティを設定する必要があります。

キャプチャされたメタデータ

自動データ インジェストの使用時には、関連付けられているメタデータに対してクエリを実行し、ダッシュボードを作成して以下のことができます。

• ジョブと、ジョブの関数に関連するデータ製品の最新のデータ読み込みタイムスタンプを追跡します。
• 使用できるデータ製品を追跡します。
• データ ボリュームを増やします。
• ジョブの失敗に関するリアルタイムの更新を取得します。

運用メタデータは次の追跡に使用されます。

• ジョブ、ジョブ ステップ、およびそれらの依存関係。
• ジョブのパフォーマンスとパフォーマンス履歴。
• データ ボリュームの増加。
• ジョブの失敗。
• ソース メタデータの変更。
• データ製品に依存する業務機能。

Azure Purview REST API を使用してデータを検出する

最初のインジェスト中に、Azure Purview REST API を使用してデータを登録する必要があります。 API を使用して、データが取り込まれたらすぐにデータ カタログにデータを送信できます。

詳細については、Azure Purview REST API の使用方法に関するページを参照してください。

データ ソースの登録

次の API 呼び出しを使用して、新しいデータ ソースを登録します。

PUT https://{accountName}.scan.purview.azure.com/datasources/{dataSourceName}

データ ソースの URI パラメーター：

名前	Required	タイプ	説明
accountName	True	String	Azure Purview アカウントの名前
dataSourceName	○	String	データ ソースの名前

登録のために Azure Purview REST API を使用する

次の例では、Azure Purview REST API を使用して、ペイロードを含むデータ ソースを登録する方法を示します。

Azure Data Lake Storage Gen2 データ ソースの登録：

{
  "kind":"AdlsGen2",
  "name":"<source-name> (for example, My-AzureDataLakeStorage)",
  "properties":{
    "endpoint":"<endpoint> (for example, https://adls-account.dfs.core.windows.net/)",
    "subscriptionId":"<azure-subscription-guid>",
    "resourceGroup":"<resource-group>",
    "location":"<region>",
    "parentCollection":{
      "type":"DataSourceReference",
      "referenceName":"<collection-name>"
    }
  }
}

SQL Database データ ソースの登録：

{
  "kind":"<source-kind> (for example, AdlsGen2)",
  "name":"<source-name> (for example, My-AzureSQLDatabase)",
  "properties":{
    "serverEndpoint":"<server-endpoint> (for example, sqlservername.database.windows.net)",
    "subscriptionId":"<azure-subscription-guid>",
    "resourceGroup":"<resource-group>",
    "location":"<region>",
    "parentCollection":{
      "type":"DataSourceReference",
      "referenceName":"<collection-name>"
    }
  }
}

Note

<collection-name> は、Azure Purview アカウントに存在する現在のコレクションです。

スキャンを作成する

スキャンを設定して実行する前に、Azure Purview でソースを認証するための資格情報を作成する方法を確認してください。

次の API 呼び出しを使用して、データ ソースをスキャンします。

PUT https://{accountName}.scan.purview.azure.com/datasources/{dataSourceName}/scans/{newScanName}/

スキャンの URI パラメーター：

名前	Required	タイプ	説明
accountName	True	String	Azure Purview アカウントの名前
dataSourceName	○	String	データ ソースの名前
newScanName	○	String	新しいスキャンの名前

スキャンのために Azure Purview REST API を使用する

以下の例では、Azure Purview REST API をどのように使用すると、ペイロードを含むデータ ソースをスキャンできるかを示しています。

Azure Data Lake Storage Gen2 データ ソースのスキャン：

{
  "name":"<scan-name>",
  "kind":"AdlsGen2Msi",
  "properties":
  {
    "scanRulesetType":"System",
    "scanRulesetName":"AdlsGen2"
  }
}

SQL Database データ ソースのスキャン：

{
  "name":"<scan-name>",
  "kind":"AzureSqlDatabaseMsi",
  "properties":
  {
    "scanRulesetType":"System",
    "scanRulesetName":"AzureSqlDatabase",
    "databaseName": "<database-name>",
    "serverEndpoint": "<server-endpoint> (for example, sqlservername.database.windows.net)"
  }
}

次の API 呼び出しを使用して、データ ソースをスキャンします。

POST https://{accountName}.scan.purview.azure.com/datasources/{dataSourceName}/scans/{newScanName}/run

次のステップ

• クラウド規模の分析に向けた Azure Data Lake Storage の概要