Ligação de dados do Event Grid
A ingestão do Event Grid é um pipeline que escuta o armazenamento do Azure e atualiza o Azure Data Explorer para extrair informações quando ocorrem eventos subscritos. O Azure Data Explorer oferece ingestão contínua do Armazenamento do Azure (Armazenamento de blobs e ADLSv2) com Azure Event Grid subscrição para blobs criados ou notificações com nomes de blobs e transmissão em fluxo destas notificações para o Azure Data Explorer através de um Hubs de Eventos do Azure.
O pipeline de ingestão do Event Grid passa por vários passos. Cria uma tabela de destino no Azure Data Explorer na qual os dados num formato específico serão ingeridos. Em seguida, crie uma ligação de dados do Event Grid no Azure Data Explorer. A ligação de dados do Event Grid precisa de conhecer as informações de encaminhamento de eventos , como a tabela para onde enviar os dados e o mapeamento da tabela. Também especifica propriedades de ingestão, que descrevem os dados a serem ingeridos, a tabela de destino e o mapeamento. Pode gerar dados de exemplo e carregar blobs ou mudar o nome dos blobs para testar a sua ligação. Eliminar blobs após a ingestão.
A ingestão do Event Grid pode ser gerida através do portal do Azure, utilizando o assistente de ingestão, programaticamente com C# ou Python, ou com o modelo Resource Manager do Azure.
Para obter informações gerais sobre a ingestão de dados no Azure Data Explorer, veja Descrição geral da ingestão de dados do Azure Data Explorer.
Mecanismos de autenticação de ligação de dados do Azure Data Explorer
-
Ligação de dados baseada em Identidade Gerida (recomendado): utilizar uma ligação de dados baseada em identidade gerida é a forma mais segura de ligar a origens de dados. Fornece controlo total sobre a capacidade de obter dados de uma origem de dados.
A configuração de uma ligação de dados com a identidade gerida requer os seguintes passos:
- Adicione uma identidade gerida ao cluster.
- Conceda permissões à identidade gerida na origem de dados.
- Defina uma política de identidade gerida nas bases de dados de destino.
- Crie uma ligação de dados com a autenticação de identidade gerida para obter dados.
Atenção
Se as permissões de identidade gerida forem removidas da origem de dados, a ligação de dados será desativada e não conseguirá obter dados da origem de dados.
- Ligação de dados baseada em chave: se uma identidade gerida não for especificada na ligação de dados, a ligação será automaticamente predefinida para autenticação baseada em chaves. As ligações baseadas em chaves obtêm dados com um recurso cadeia de ligação, como o Hubs de Eventos do Azure cadeia de ligação. O Azure Data Explorer gera o recurso cadeia de ligação para o recurso especificado e guarda-o em segurança na ligação de dados. O cadeia de ligação é utilizado para obter dados da origem de dados.
Atenção
Se a chave for rodada, a ligação de dados será desativada e não conseguirá obter dados da origem de dados. Para corrigir o problema, atualize ou recrie a ligação de dados.
- Para que o MI possa obter dados do Armazenamento do Azure, deve ter, pelo menos:
- Hubs de Eventos do Azure Recetor de Dados no Hubs de Eventos do Azure.
- Leitor de Dados de Blobs de Armazenamento na conta de Armazenamento do Azure.
Formato de dados
- Veja os formatos suportados.
- Veja compressões suportadas.
- O tamanho original dos dados não comprimidos deve fazer parte dos metadados do blob ou o Azure Data Explorer irá estimá-lo. O limite de tamanho não comprimido de ingestão por ficheiro é de 6 GB.
Nota
A subscrição de notificação do Event Grid pode ser definida em contas de Armazenamento do Azure para BlobStorage
, StorageV2
ou Data Lake Storage Gen2.
Propriedades de ingestão
Pode especificar as propriedades de ingestão da ingestão de blobs através dos metadados do blob. Pode definir as seguintes propriedades:
Propriedade | Descrição |
---|---|
rawSizeBytes |
Tamanho dos dados não processados (não comprimidos). Para Avro/ORC/Parquet, este é o tamanho antes da aplicação da compressão específica do formato. Indique o tamanho dos dados original ao definir esta propriedade para o tamanho dos dados não comprimidos em bytes. |
kustoDatabase |
O nome sensível às maiúsculas e minúsculas da base de dados de destino. Por predefinição, os dados são ingeridos na base de dados de destino associada à ligação de dados. Utilize esta propriedade para substituir a base de dados predefinida e enviar dados para uma base de dados diferente. Para tal, primeiro tem de configurar a ligação como uma ligação de várias bases de dados. |
kustoTable |
O nome sensível às maiúsculas e minúsculas da tabela de destino existente. Substitui o Table conjunto no Data Connection painel. |
kustoDataFormat |
Formato de dados. Substitui o Data format conjunto no Data Connection painel. |
kustoIngestionMappingReference |
Nome do mapeamento de ingestão existente a utilizar. Substitui o Column mapping conjunto no Data Connection painel. |
kustoIgnoreFirstRecord |
Se definido como true , Kusto ignora a primeira linha do blob. Utilize em dados de formato tabular (CSV, TSV ou semelhantes) para ignorar cabeçalhos. |
kustoExtentTags |
Cadeia que representa etiquetas que serão anexadas à extensão resultante. |
kustoCreationTime |
Substitui o tempo de Criação da Extensão do blob, formatado como uma cadeia ISO 8601. Utilize para efetuar o backfilling. |
Encaminhamento de eventos
Quando cria uma ligação de dados ao cluster, especifica o encaminhamento para onde enviar dados ingeridos. O encaminhamento predefinido é para a tabela de destino especificada na cadeia de ligação que está associada à base de dados de destino. O encaminhamento predefinido para os seus dados também é referido como encaminhamento estático. Pode especificar um encaminhamento alternativo para os seus dados com as propriedades de dados do evento.
Encaminhar dados de eventos para uma base de dados alternativa
Por predefinição, o encaminhamento de dados para uma base de dados alternativa está desativado. Para enviar os dados para uma base de dados diferente, primeiro tem de definir a ligação como uma ligação de várias bases de dados. Pode fazê-lo no modelo portal do Azure, C#, Python ou ARM. O utilizador, grupo, principal de serviço ou identidade gerida utilizada para permitir o encaminhamento de bases de dados tem, pelo menos, de ter a função de contribuidor e as permissões de escrita no cluster. Para obter mais informações, veja Criar uma ligação de dados do Event Grid para o Azure Data Explorer.
Para especificar uma base de dados alternativa, defina a propriedade Ingestão debases de dados.
Aviso
Especificar uma base de dados alternativa sem definir a ligação como uma ligação de dados de várias bases de dados fará com que a ingestão falhe.
Encaminhar dados de eventos para uma tabela alternativa
Ao configurar uma ligação de armazenamento de blobs ao cluster de Data Explorer do Azure, especifique as propriedades da tabela de destino:
- nome da tabela
- formato de dados
- mapeamento
Também pode especificar as propriedades da tabela de destino para cada blob com metadados de blobs. Os dados serão encaminhados dinamicamente, conforme especificado pelas propriedades de ingestão.
O exemplo abaixo mostra-lhe como definir propriedades de ingestão nos metadados do blob antes de carregá-lo. Os blobs são encaminhados para tabelas diferentes.
Além disso, pode especificar a base de dados de destino. É criada uma ligação de dados do Event Grid no contexto de uma base de dados específica. Por conseguinte, esta base de dados é o encaminhamento predefinido da base de dados da ligação de dados. Para enviar os dados para uma base de dados diferente, defina a propriedade de ingestão "KustoDatabase" e defina a ligação de dados como uma ligação de dados De várias bases de dados. O encaminhamento de dados para outra base de dados está desativado por predefinição (não permitido). Definir uma propriedade de ingestão de bases de dados diferente da base de dados da ligação de dados, sem permitir o encaminhamento de dados para várias bases de dados (definindo a ligação como uma ligação de dados de várias bases de dados), fará com que a ingestão falhe.
Para obter mais informações, veja carregar blobs.
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>")));
Carregar blobs
Pode criar um blob a partir de um ficheiro local, definir propriedades de ingestão para os metadados do blob e carregá-lo. Por exemplo, veja Utilizar a ligação de dados do Event Grid.
Nota
- Recomendamos vivamente a utilização
BlockBlob
para gerar dados, uma vez que a utilizaçãoAppendBlob
pode resultar num comportamento inesperado. - A utilização do SDK de armazenamento do Azure Data Lake Gen2 requer a utilização
CreateFile
para carregar ficheiros eFlush
, no final, com o parâmetro close definido comotrue
. Para obter um exemplo detalhado da utilização correta do SDK do Data Lake Gen2, veja Utilizar a ligação de dados do Event Grid. - Acionar a ingestão após uma
CopyBlob
operação não é suportado para contas de armazenamento que tenham a funcionalidade de espaço de nomes hierárquico ativada. - Quando o ponto final do hub de eventos não reconhece a receção de um evento, Azure Event Grid ativa um mecanismo de repetição. Se esta entrega de repetição falhar, o Event Grid pode entregar os eventos não entregues a uma conta de armazenamento através de um processo de mensagens não entregues. Para obter mais informações, veja Entrega e repetição de mensagens do Event Grid.
Mudar o nome dos blobs
Ao utilizar o ADLSv2, pode mudar o nome de um blob para acionar a ingestão de blobs para o Azure Data Explorer. Por exemplo, veja Mudar o nome dos blobs.
Nota
- O nome do diretório é possível no ADLSv2, mas não aciona eventos com o nome do blob mudado e a ingestão de blobs dentro do diretório. Para ingerir blobs após mudar o nome, mude diretamente o nome dos blobs pretendidos.
- Se definiu filtros para controlar assuntos específicos ao criar a ligação de dados ou ao criar recursos do Event Grid manualmente, estes filtros são aplicados no caminho do ficheiro de destino.
Eliminar blobs com o ciclo de vida do armazenamento
O Azure Data Explorer não elimina os blobs após a ingestão. Utilize o ciclo de vida do armazenamento de Blobs do Azure para gerir a eliminação de blobs. Recomenda-se manter os blobs durante três a cinco dias.
Problemas conhecidos do Event Grid
- Ao utilizar o Azure Data Explorer para exportar os ficheiros utilizados para a ingestão do Event Grid, tenha em atenção:
- As notificações do Event Grid não são acionadas se o cadeia de ligação fornecido ao comando de exportação ou o cadeia de ligação fornecido a uma tabela externa for uma cadeia de ligação no formato ADLS Gen2 (por exemplo,
abfss://filesystem@accountname.dfs.core.windows.net
), mas a conta de armazenamento não estiver ativada para o espaço de nomes hierárquico. - Se a conta não estiver ativada para o espaço de nomes hierárquico, cadeia de ligação tem de utilizar o formato de Armazenamento de Blobs (por exemplo,
https://accountname.blob.core.windows.net
). A exportação funciona conforme esperado mesmo quando utiliza o ADLS Gen2 cadeia de ligação, mas as notificações não serão acionadas e a ingestão do Event Grid não funcionará.
- As notificações do Event Grid não são acionadas se o cadeia de ligação fornecido ao comando de exportação ou o cadeia de ligação fornecido a uma tabela externa for uma cadeia de ligação no formato ADLS Gen2 (por exemplo,