Connessione dati a Griglia di eventi

L'acquisizione tramite Event Grid è una pipeline che resta in ascolto di Archiviazione di Azure e aggiorna Esplora dati di Azure affinché recuperi le informazioni quando si verificano gli eventi a cui è iscritta. Esplora dati di Azure offre l'inserimento continuo da Archiviazione di Azure (archiviazione BLOB e ADLSv2) con una sottoscrizione di Griglia di eventi di Azure per le notifiche di creazione o ridenominazione dei BLOB e lo streaming di tali notifiche ad Esplora dati di Azure tramite Hub eventi di Azure.

La pipeline di acquisizione di Event Grid si articola in diverse fasi. Si crea una tabella di destinazione in Azure Esplora dati in cui verranno inseriti i dati in un formato specifico. Quindi si crea una connessione dati di Event Grid in Esplora dati di Azure. La connessione dati di Griglia di eventi deve conoscere le informazioni di routing degli eventi, ad esempio la tabella a cui inviare i dati e il mapping della tabella. Specificare anche le proprietà di inserimento, che descrivono i dati da inserire, la tabella di destinazione e il mapping. È possibile generare dati di esempio e caricare BLOB o rinominare BLOB per testare la connessione. Eliminare i BLOB dopo l'acquisizione.

L'inserimento di Griglia di eventi può essere gestito tramite la portale di Azure, usando l'inserimento guidato, a livello di codice con C# o Python o con il modello di Azure Resource Manager.

Per informazioni generali sull'inserimento dati in Azure Esplora dati, vedere Panoramica dell'inserimento di dati in Azure Esplora dati.

Meccanismi di autenticazione per la connessione dati di Event Grid

  • Connessione dati basata su identità gestita (scelta consigliata): l'uso di una connessione dati basata sull'identità gestita è il modo più sicuro per connettersi alle origini dati. Consente il pieno controllo sulla facoltà di recuperare dati da un'origine dati.

    Per configurare una connessione dati di Griglia di eventi tramite l'identità gestita sono necessari i passaggi e le autorizzazioni seguenti:

    1. Assicurarsi di avere l'assegnazione di ruolo Collaboratore EventGrid nella sottoscrizione di Azure dell'account di archiviazione dati di origine.
    2. Aggiungere un'identità gestita al cluster.
    3. Concedi le autorizzazioni all'identità gestita per l'origine dati. Per recuperare i dati da Archiviazione di Azure, l'identità gestita deve disporre almeno delle autorizzazioni Storage Blob Data Reader sull'account Archiviazione di Azure.
    4. Concedi le autorizzazioni all'identità gestita nell'event hub. Per recuperare le notifiche blob da Hub eventi di Azure, l'identità gestita deve avere le autorizzazioni Ricevitore dati di Hub eventi di Azure per Hub eventi di Azure.
    5. Impostare criteri di identità gestiti nei database di destinazione.
    6. Crea una connessione dati tramite autenticazione con identità gestita per recuperare i dati.

    Nota

    • Il gruppo di consumer dell'hub eventi deve essere univoco per ciascun consumer. Creare un gruppo di consumatori dedicato per ogni connessione dati di Esplora dati di Azure.

    Attenzione

    • Se le autorizzazioni dell'identità gestita vengono rimosse dall'origine dati, la connessione dati non funzionerà più e non sarà più in grado di recuperare i dati dall'origine dati.
    • Se l'autenticazione locale è disabilitata in uno spazio dei nomi di Hub di eventi esistente in cui vengono trasmesse le notifiche dei blob, è necessario usare l'autenticazione tramite identità gestita per la connessione dei dati e configurare correttamente le risorse. Per altre informazioni, vedere Problemi noti di Griglia di eventi.
  • Connessione dati basata su chiave: se non viene specificata un'autenticazione basata su identità gestita per la connessione dati, per impostazione predefinita la connessione viene automaticamente eseguita con l'autenticazione basata su chiave. Le connessioni basate su chiave recuperano i dati usando una stringa di connessione della risorsa, ad esempio la stringa di connessione di Hub eventi di Azure. Esplora dati di Azure ottiene la stringa di connessione della risorsa specificata e la salva in modo sicuro. La stringa di connessione viene quindi usata per recuperare i dati dall'origine dati.

    Attenzione

    Se la chiave viene ruotata, la connessione dati non funzionerà più e non sarà in grado di recuperare i dati dall'origine dati. Per risolvere il problema, aggiornare o ricreare la connessione dati.

Formato dei dati

  • Vedere i formati supportati.
  • Vedere le compressioni supportate.
    • La dimensione originale dei dati non compressi dovrebbe far parte dei metadati del blob, altrimenti Esplora dati di Azure la stimerà. Il limite di dimensioni di inserimento non compresso per ogni file è di 6 GB.

      Nota

      La sottoscrizione di notifica di Griglia di eventi può essere impostata sugli account di archiviazione di Azure per BlobStorage, StorageV2 o Data Lake Storage Gen2.

Proprietà di acquisizione

È possibile specificare le proprietà di acquisizione del blob tramite i metadati del blob. È possibile impostare le proprietà seguenti:

Proprietà Descrizione
rawSizeBytes Dimensioni dei dati non elaborati (non compressi). Per Avro/ORC/Parquet, ovvero la dimensione prima dell'applicazione della compressione specifica del formato. Specificare le dimensioni dei dati originali impostando questa proprietà sulle dimensioni dei dati non compressi in byte.
kustoDatabase Il nome che è sensibile alle maiuscole del database di destinazione. Per impostazione predefinita, i dati vengono inseriti nel database di destinazione associato alla connessione dati. Utilizzare questa proprietà per eseguire l'override del database predefinito e inviare dati a un database diverso. Per farlo, devi prima configurare la connessione come connessione a più database.
kustoTable Il nome con distinzione tra maiuscole e minuscole della tabella di destinazione esistente. Esegue l'override del set Table nel riquadro Data Connection.
kustoDataFormat Formato dei dati. Sovrascrive il valore Data format impostato nel riquadro Data Connection.
kustoIngestionMappingReference Nome del mapping di inserimento esistente da usare. Esegue l'override del set Column mapping nel riquadro Data Connection.
kustoIgnoreFirstRecord Se impostato su true, Kusto ignora la prima riga del blob. Usare nei dati in formato tabulare (CSV, TSV o simile) per ignorare le intestazioni.
kustoExtentTags Stringa che rappresenta i tag che verranno associati all'extent risultante.
kustoCreationTime Sovrascrive l'ora di creazione dell'extent del BLOB, formattata come stringa ISO 8601. Utilizzare per il back-fill.

Routing degli eventi

Quando si crea una connessione dati al cluster, si specifica il routing per dove inviare i dati inseriti. L'instradamento predefinito è verso la tabella di destinazione specificata nella stringa di connessione associata al database di destinazione. Il routing predefinito per i tuoi dati è anche chiamato routing statico. È possibile specificare un routing alternativo per i dati usando le proprietà dei dati dell'evento.

Instradare i dati degli eventi a un database alternativo

Il routing dei dati a un database alternativo è disattivato per impostazione predefinita. Per inviare i dati a un database diverso, è prima necessario impostare la connessione come connessione multi-database. È possibile farlo nel portale di Azure, con C#, Python o un modello ARM. L'utente, il gruppo, l'entità servizio o l'identità gestita utilizzati per consentire il routing del database devono avere almeno il ruolo Collaboratore e autorizzazioni di scrittura sul cluster. Per ulteriori informazioni, vedi Creare una connessione dati di Event Grid per Esplora dati di Azure.

Per specificare un database alternativo, impostare la Databaseproprietà di acquisizione.

Avviso

Se si specifica un database alternativo senza impostare la connessione come connessione dati multi-database, l'inserimento non riesce.

Indirizzare i dati degli eventi a una tabella alternativa

Quando si configura una connessione di archiviazione BLOB al cluster Esplora dati di Azure, specificare le proprietà della tabella di destinazione:

  • Nome della tabella
  • formato dei dati
  • mappatura

È anche possibile specificare le proprietà della tabella di destinazione per ogni BLOB, usando i metadati del BLOB. I dati verranno indirizzati dinamicamente, come specificato dalle proprietà di inserimento.

L'esempio seguente illustra come impostare le proprietà di inserimento nei metadati del BLOB prima di caricarlo. I BLOB vengono indirizzati a tabelle diverse.

Inoltre, è possibile specificare il database di destinazione. Viene creata una connessione dati di Griglia di eventi all'interno del contesto di un database specifico. Di conseguenza, questo database è il routing predefinito del database della connessione dati. Per inviare i dati a un database diverso, impostare la proprietà di inserimento "KustoDatabase" e impostare la connessione dati come connessione dati multi database. Il routing dei dati a un altro database è disabilitato per impostazione predefinita (non consentito). Se si imposta una proprietà di inserimento del database diversa dal database della connessione dati, senza consentire il routing dei dati a più database (impostando la connessione come connessione dati multi database), l'inserimento avrà esito negativo.

Per altre informazioni, vedere Caricare i BLOB.

var container = new BlobContainerClient("<storageAccountConnectionString>", "<containerName>");
await container.CreateIfNotExistsAsync();
var blob = container.GetBlobClient("<blobName>");
// Blob is dynamically routed to table `Events`, ingested using `EventsMapping` data mapping
await blob.SetMetadataAsync(
    new Dictionary<string, string>
    {
        { "rawSizeBytes", "4096" }, // the uncompressed size is 4096 bytes
        { "kustoTable", "Events" },
        { "kustoDataFormat", "json" },
        { "kustoIngestionMappingReference", "EventsMapping" },
        { "kustoDatabase", "AnotherDB" }
    }
);
await blob.UploadAsync(BinaryData.FromString(File.ReadAllText("<filePath>")));

Caricare i BLOB

È possibile creare un BLOB da un file locale, impostare le proprietà di inserimento sui metadati del BLOB e caricarlo. Per esempi, vedere Usare la connessione dati di Event Grid.

Nota

  • È consigliabile usare BlockBlob per generare dati, perché l'uso AppendBlob potrebbe comportare un comportamento imprevisto.
  • L'uso di Azure Data Lake Gen2 storage SDK richiede l'uso CreateFile per caricare i file e Flush alla fine con il parametro close impostato su true. Per un esempio dettagliato del corretto utilizzo dell'SDK di Data Lake Gen2, vedere Usare la connessione dati di Event Grid.
  • L'attivazione del processo di inserimento dopo un'operazione CopyBlob non è supportata per gli account di archiviazione in cui è abilitata la funzionalità dello spazio dei nomi gerarchico.
  • Quando l'endpoint dell'hub eventi non conferma la ricezione di un evento, Griglia di eventi di Azure attiva un meccanismo di ripetizione dei tentativi. Se questo nuovo tentativo di recapito non riesce, Event Grid può consegnare gli eventi non recapitati a un account di archiviazione tramite un processo di dead-lettering. Per altre informazioni, vedi recapito dei messaggi e nuovi tentativi di Event Grid.
  • L'uso dell'API "OpenWrite" per scrivere su un blob non è consigliato, perché attiva una notifica quando il blob è vuoto e causa un errore di blob vuoto. Inoltre, svuotare il flusso una sola volta per impedire notifiche duplicate e più acquisizioni dello stesso BLOB.
  • Esplora dati di Azure tenta di filtrare le notifiche duplicate per lo stesso blob inviate dai servizi upstream come Event Grid o Storage. Quando rileva un evento duplicato, ignora l'inserimento e registra l'errore BlobAlreadyReceived_DuplicateEventGridNotification, il che significa che il BLOB è già elaborato.

Rinominare i BLOB

Quando si usa ADLSv2, è possibile rinominare un BLOB per attivare l'acquisizione del BLOB in Esplora dati di Azure. Ad esempio, vedi Rinominare i blob.

Nota

  • La ridenominazione della directory è possibile in ADLSv2, ma non attiva eventi di ridenominazione di BLOB e l'inserimento di BLOB all'interno della directory. Per inserire i BLOB dopo la ridenominazione, rinominare direttamente i BLOB desiderati.
  • Se sono stati definiti filtri per tenere traccia di soggetti specifici durante la creazione della connessione dati o durante la creazione manuale delle risorse di Griglia di eventi, questi filtri vengono applicati al percorso del file di destinazione.

Eliminare i blob utilizzando il ciclo di vita dello storage

La logica compilata in Esplora dati di Azure non eliminerà i BLOB dopo l'inserimento. Usare il ciclo di vita di Azure Blob storage per gestire l'eliminazione del BLOB. È consigliabile conservare i blob da tre a cinque giorni.

Problemi noti di Griglia di eventi

Funzionamento senza autenticazione locale

Se l'autenticazione locale è disabilitata nello spazio dei nomi di Hub eventi che contiene l'hub eventi usato per le notifiche di streaming, seguire questa procedura per garantire che i dati vengano trasmessi correttamente dall'archiviazione all'hub eventi usando identità gestite:

  1. Assegnare un'identità gestita assegnata dal sistema all'argomento di sistema di Event Grid dell'account di archiviazione. Per altre informazioni, vedere Abilitare l'identità gestita per gli argomenti di sistema.
  2. Concedi all'identità gestita le autorizzazioni di mittente assegnandole il ruolo Mittente dati di Hub eventi di Azure sull'hub eventi. Per altre informazioni, vedere Aggiungere identità ai ruoli di Azure nelle destinazioni.
  3. Assicurarsi che la sottoscrizione di Event Grid usi un'identità gestita per il recapito degli eventi. Per altre informazioni, vedere Creare sottoscrizioni di eventi che usano un'identità.

Configurare inoltre la connessione dati di Event Grid in modo che usi l'autenticazione tramite identità gestita, così che Esplora dati di Azure possa ricevere notifiche dall'hub eventi.

Configurare l'inserimento di Griglia di eventi nei file esportati da Azure Esplora dati

Quando si usa Esplora dati di Azure per esportare i file usati per l'acquisizione tramite Event Grid, tenere presente quanto segue:

  • Le notifiche di Griglia di eventi non vengono attivate se la stringa di connessione specificata per il comando di esportazione o la stringa di connessione fornita a una tabella esterna è una stringa di connessione in formato ADLS Gen2, ad esempio abfss://filesystem@accountname.dfs.core.windows.net, ma l'account di archiviazione non è abilitato per lo spazio dei nomi gerarchico.
  • Se l'account non è abilitato per il namespace gerarchico, la stringa di connessione deve usare il formato gestione rete virtuale di Azure (ad esempio, https://accountname.blob.core.windows.net). L'esportazione funziona come previsto anche quando si usa la stringa di connessione in formato ADLS Gen2, ma le notifiche non verranno attivate e l'inserimento di Griglia di eventi non funzionerà.

Emulazione di eventi di archiviazione da componenti personalizzati

Quando si usano componenti personalizzati per emulare gli eventi di Archiviazione di Azure, gli eventi emulati devono essere strettamente conformi allo schema di eventi di Archiviazione BLOB di Azure, perché Esplora dati di Azure eliminerà gli eventi che non possono essere analizzati da Event Grid SDK.