Motore di inserimento indipendente dai dati

Questo articolo illustra come implementare scenari di motore di inserimento indipendenti dai dati usando una combinazione di powerApps, App per la logica di Azure e attività di copia basate sui metadati all'interno di Azure Data Factory.

Gli scenari del motore di inserimento indipendente dai dati sono in genere incentrati sulla possibilità di consentire agli utenti non tecnici (non data engineer) di pubblicare asset di dati in un Data Lake per un'ulteriore elaborazione. Per implementare questo scenario, è necessario disporre di funzionalità di onboarding che abilitano:

• Registrazione dell'asset di dati
• Provisioning del flusso di lavoro e acquisizione dei metadati
• Pianificazione dell'inserimento

È possibile vedere come interagiscono queste funzionalità:

Figura 1: Interazioni con le funzionalità di registrazione dei dati.

Il diagramma seguente illustra come implementare questo processo usando una combinazione di servizi di Azure:

Figura 2: Processo di inserimento automatico.

Registrazione dell'asset di dati

Per fornire i metadati usati per l'inserimento automatico, è necessaria la registrazione degli asset di dati. Le informazioni acquisite contengono:

• Informazioni tecniche: nome dell'asset dati, sistema di origine, tipo, formato e frequenza.
• Informazioni sulla governance: proprietario, amministratori, visibilità (a scopo di individuazione) e riservatezza.

PowerApps viene usato per acquisire i metadati che descrivono ogni asset di dati. Usare un'app basata su modello per immettere le informazioni che vengono rese persistenti in una tabella Dataverse personalizzata. Quando i metadati vengono creati o aggiornati all'interno di Dataverse, attiva un flusso cloud automatizzato che richiama ulteriori passaggi di elaborazione.

Figura 3: Registrazione dell'asset di dati.

Provisioning del flusso di lavoro/acquisizione dei metadati

Nella fase del flusso di lavoro di provisioning i dati raccolti nella fase di registrazione vengono convalidati e salvati in modo permanente nel metastore. Vengono eseguiti sia passaggi tecnici che di convalida aziendale, tra cui:

• Convalida del feed di dati di input
• Attivazione del flusso di lavoro di approvazione
• Elaborazione logica per attivare la persistenza dei metadati nell'archivio metadati
• Controllo attività

Figura 4: Flusso di lavoro di registrazione.

Dopo l'approvazione delle richieste di inserimento, il flusso di lavoro usa l'API REST di Azure Purview per inserire le origini in Azure Purview.

Flusso di lavoro dettagliato per l'onboarding di prodotti dati

Figura 5: Come vengono inseriti nuovi set di dati (automatizzati).

La figura 5 mostra il processo di registrazione dettagliato per automatizzare l'inserimento di nuove origini dati:

• I dettagli di origine vengono registrati, inclusi gli ambienti di produzione e data factory.
• Vengono acquisiti vincoli di forma, formato e qualità dei dati.
• I team dell'applicazione dati devono indicare se i dati sono sensibili (dati personali) Questa classificazione determina il processo durante il quale vengono create cartelle data lake per inserire dati non elaborati, arricchiti e curati. I nomi di origine non elaborati e arricchiti e i nomi dei prodotti dati curati.
• Vengono creati gruppi di sicurezza e entità servizio per l'inserimento e l'accesso a un set di dati.
• Viene creato un processo di inserimento nel metastore di Data Factory della zona di destinazione.
• Un'API inserisce la definizione dei dati in Azure Purview.
• In base alla convalida dell'origine dati e all'approvazione da parte del team operativo, i dettagli vengono pubblicati in un metastore di Data Factory.

Pianificazione dell'inserimento

All'interno di Azure Data Factory, le attività di copia basate sui metadati offrono funzionalità che consentono alle pipeline di orchestrazione di essere guidate da righe all'interno di una tabella di controllo archiviata in database SQL di Azure. È possibile usare lo strumento Copia dati per creare pipeline basate su metadati.

Dopo aver creato una pipeline, il flusso di lavoro di provisioning aggiunge voci alla tabella di controllo per supportare l'inserimento da origini identificate dai metadati di registrazione degli asset di dati. Le pipeline di Azure Data Factory e le database SQL di Azure contenenti il metastore Tabella di controllo possono esistere entrambi all'interno di ogni zona di destinazione dei dati per creare nuove origini dati e inserirle nelle zone di destinazione dei dati.

Figura 6: Pianificazione dell'inserimento di asset di dati.

Flusso di lavoro dettagliato per l'inserimento di nuove origini dati

Il diagramma seguente illustra come eseguire il pull delle origini dati registrate in un metastore database SQL Data Factory e come i dati vengono inseriti per la prima volta:

La pipeline master di inserimento di Data Factory legge le configurazioni da un metastore di data factory database SQL, quindi esegue in modo iterativo con i parametri corretti. I dati vengono trasferiti dall'origine al livello non elaborato in Azure Data Lake senza alcuna modifica. La forma dei dati viene convalidata in base al metastore di Data Factory. I formati di file vengono convertiti in formati Apache Parquet o Avro, quindi copiati nel livello arricchito.

I dati inseriti si connettono a un'area di lavoro di data science e progettazione di Azure Databricks e una definizione di dati viene creata all'interno del metastore Apache Hive della zona di destinazione dei dati.

Se è necessario usare un pool SQL serverless di Azure Synapse per esporre i dati, la soluzione personalizzata deve creare viste sui dati nel lake.

Se è necessaria la crittografia a livello di riga o a livello di colonna, la soluzione personalizzata deve trasferire i dati nel data lake, quindi inserire i dati direttamente nelle tabelle interne nei pool SQL e configurare la sicurezza appropriata nel calcolo dei pool SQL.

Metadati acquisiti

Quando si usa l'inserimento automatico dei dati, è possibile eseguire query sui metadati associati e creare dashboard per:

• Tenere traccia dei processi e dei timestamp di caricamento dei dati più recenti per i prodotti dati correlati alle relative funzioni.
• Tenere traccia dei prodotti dati disponibili.
• Aumentare i volumi di dati.
• Ottenere aggiornamenti in tempo reale sugli errori dei processi.

I metadati operativi possono essere usati per tenere traccia di:

• Processi, passaggi di processo e relative dipendenze.
• Cronologia delle prestazioni e prestazioni dei processi.
• Aumento del volume di dati.
• Errori dei processi.
• Modifiche ai metadati di origine.
• Funzioni aziendali che dipendono dai prodotti dati.

Usare l'API REST di Azure Purview per individuare i dati

Le API REST di Azure Purview devono essere usate per registrare i dati durante l'inserimento iniziale. È possibile usare le API per inviare i dati al catalogo dati subito dopo l'inserimento.

Per altre informazioni, vedere come usare le API REST di Azure Purview.

Registrare le origini dati

Usare la chiamata API seguente per registrare nuove origini dati:

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

Parametri URI per l'origine dati:

Nome	Obbligatorio	Type	Descrizione
accountName	Vero	String	Nome dell'account Azure Purview
dataSourceName	Vero	String	Nome dell'origine dati

Usare l'API REST di Azure Purview per la registrazione

Gli esempi seguenti illustrano come usare l'API REST di Azure Purview per registrare le origini dati con i payload:

Registrare un'origine dati di 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>"
    }
  }
}

Registrare un'origine dati di Database SQL:

{
  "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>"
    }
  }
}

Nota

<collection-name> è una raccolta corrente presente in un account Azure Purview.

Creare un'analisi

Informazioni su come creare credenziali per autenticare le origini in Azure Purview prima di configurare ed eseguire un'analisi.

Usare la chiamata API seguente per analizzare le origini dati:

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

Parametri URI per un'analisi:

Nome	Obbligatorio	Type	Descrizione
accountName	Vero	String	Nome dell'account Azure Purview
dataSourceName	Vero	String	Nome dell'origine dati
newScanName	Vero	String	Nome della nuova analisi

Usare l'API REST di Azure Purview per l'analisi

Gli esempi seguenti illustrano come usare l'API REST di Azure Purview per analizzare le origini dati con payload:

Analizzare un'origine dati di Azure Data Lake Storage Gen2:

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

Analizzare un'origine dati di Database SQL:

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

Usare la chiamata API seguente per analizzare le origini dati:

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

Passaggi successivi

• Panoramica dei Archiviazione di Azure Data Lake per l'analisi su scala cloud