Conexión de datos de Event Grid

  • Artículo

La ingesta de Event Grid es una canalización que escucha en Azure Storage y actualiza Azure Data Explorer para extraer información cuando se producen eventos suscritos. Azure Data Explorer ofrece la ingesta de datos continua desde Azure Storage (Blob Storage y ADLSv2) con una suscripción de Azure Event Grid para las notificaciones sobre blobs creados o cambios de nombre de blobs y la transmisión de estas notificaciones a Azure Data Explorer mediante una instancia de Azure Event Hubs.

La canalización de ingesta de datos de Event Grid tiene varios pasos. Se crea una tabla de destino de Azure Data Explorer en la que se realizará la ingesta de datos en un formato determinado. A continuación, se crea una conexión de datos de Event Grid en Azure Data Explorer. La conexión de datos de Event Grid debe conocer la información de enrutamiento de eventos, como la tabla a la que se van a enviar los datos y la asignación de la tabla. También se especifican las propiedades de la ingesta, que describen los datos que se van a ingerir, la tabla de destino y la asignación. Puede generar datos de ejemplo y cargar blobs o cambiar el nombre de los blobs para probar la conexión. Elimine los blobs después de la ingesta.

La ingesta de Event Grid se puede administrar desde Azure Portal, mediante el asistente para ingesta, mediante programación con C# o Python o con una plantilla de Azure Resource Manager.

Para obtener información general sobre la ingesta de datos en Azure Data Explorer, consulte Introducción a la ingesta de datos de Azure Data Explorer.

Mecanismos de autenticación de conexión de datos de Event Grid

  • Conexión de datos basada en identidad administrada (recomendada): el uso de una conexión de datos basada en identidad administrada es la manera más segura de conectarse a orígenes de datos. Proporciona control total sobre la capacidad de capturar datos de un origen de datos. La configuración de una conexión de datos de Event Grid mediante una identidad administrada requiere los pasos siguientes:

    1. Adición de una identidad administrada al clúster.
    2. Concesión de permisos a la identidad administrada en el origen de datos. Para capturar datos de Azure Storage, la identidad administrada debe tener al menos permisos de Lector de datos de blobs de almacenamiento en la cuenta de Azure Storage.
    3. Concesión de permisos a una identidad administrada en el centro de eventos. Para capturar notificaciones de blobs desde el centro de eventos, la identidad administrada debe tener permisos de Receptor de datos de Azure Event Hubs en Azure Event Hubs.
    4. Establecimiento de una directiva de identidad administrada en las bases de datos de destino.
    5. Creación de una conexión de datos mediante la autenticación de identidad administrada para capturar datos.

    Precaución

    • Si los permisos de identidad administrada se quitan del origen de datos, la conexión de datos ya no funcionará y no podrá capturar datos del origen de datos.
    • Si la autenticación local está deshabilitada en un espacio de nombres de Event Hubs existente en el que se transmiten las notificaciones de blobs, debe usar la autenticación de identidad administrada para la conexión de datos y configurar correctamente los recursos. Para obtener más información, consulte Problemas conocidos de Event Grid.

  • Conexión de datos basada en claves: si no se especifica una autenticación de identidad administrada para la conexión de datos, la conexión establecerá automáticamente como valor predeterminado la autenticación basada en claves. Las conexiones basadas en claves capturan datos mediante una cadena de conexión de recursos, como la cadena de conexión Azure Event Hubs. Azure Data Explorer obtiene la cadena de conexión de recursos para el recurso especificado y la guarda de forma segura. A continuación, la cadena de conexión se usa para capturar datos del origen de datos.

    Precaución

    Si se rota la clave, la conexión de datos ya no funcionará y no podrá capturar datos del origen de datos. Para corregir el problema, actualice o vuelva a crear la conexión de datos.

Formato de datos

  • Consulte los formatos admitidos.
  • Consulte los formatos de compresión admitidos.

    • El tamaño de datos sin comprimir original debe formar parte de los metadatos del blob o, de lo contrario, Azure Data Explorer lo estimará. El límite de tamaño sin comprimir por cada archivo de la ingesta es de 6 GB.

      Nota:

      La suscripción de notificación de Event Grid se puede establecer en cuentas de Azure Storage para BlobStorage, StorageV2 o BlobStorage.

Propiedades de la ingesta

Puede especificar las propiedades de la ingesta de blobs mediante los metadatos del blob. Puede establecer las siguientes propiedades:

Propiedad Descripción
rawSizeBytes Tamaño de los datos sin formato (sin comprimir). En Avro/ORC/Parquet, es el tamaño antes de que se aplique la compresión específica del formato. Proporcione el tamaño de datos original; para ello, establezca esta propiedad en el tamaño de los datos sin comprimir expresado en bytes.
kustoDatabase Nombre de la base de datos de destino en el que se distinguen mayúsculas de minúsculas. De forma predeterminada, los datos se ingieren en la base de datos de destino asociada a la conexión de datos. Use esta propiedad para invalidar la base de datos predeterminada y enviar datos a otra base de datos. Para ello, primero debe configurar la conexión como una conexión de varias bases de datos.
kustoTable Nombre de la tabla de destino existente en el que se distinguen mayúsculas de minúsculas. Invalida el valor de Table establecido en el panel Data Connection.
kustoDataFormat Formato de datos. Invalida el valor de Data format establecido en el panel Data Connection.
kustoIngestionMappingReference Nombre de la asignación de ingesta existente que se va a usar. Invalida el valor de Column mapping establecido en el panel Data Connection.
kustoIgnoreFirstRecord Si se establece en true, Kusto omite la primera fila del blob. Úselo en datos con formato tabular (CSV, TSV o similar) para omitir los encabezados.
kustoExtentTags Cadena que representa etiquetas que se adjuntarán a la extensión resultante.
kustoCreationTime Invalida la hora de creación de la extensión del blob, con formato de cadena ISO 8601. Se usa para la reposición.

Enrutamiento de eventos

Cuando se crea una conexión de datos al clúster, se especifica el enrutamiento a dónde enviar los datos ingeridos. El enrutamiento predeterminado es a la tabla de destino especificada en la cadena de conexión asociada a la base de datos de destino. Al enrutamiento predeterminado de los datos, también se le conoce como enrutamiento estático. Puede especificar un enrutamiento alternativo para los datos mediante las propiedades de los datos de evento.

Enrutamiento de datos de eventos a una base de datos alternativa

El enrutamiento de datos a una base de datos alternativa está desactivado de forma predeterminada. Para enviar los datos a otra base de datos, primero debe establecer la conexión como una conexión de varias bases de datos. Puede hacer esto mediante Azure Portal, C#, Python o una plantilla de ARM. El usuario, grupo, entidad de servicio o identidad administrada que se usa para permitir el enrutamiento de la base de datos debe tener al menos el rol de colaborador y permisos de escritura en el clúster. Para obtener más información, consulte Creación de una conexión de datos de Event Grid para Azure Data Explorer.

Para especificar una base de datos alternativa, establezca la propiedad de ingesta de la base de datos.

Advertencia

Si se especifica una base de datos alternativa sin establecer la conexión como una conexión de datos de varias bases de datos, se producirá un error en la ingesta.

Enrutamiento de datos de eventos a una tabla alternativa

Al configurar una conexión de Blob Storage en el clúster de Azure Data Explorer, especifique las propiedades de la tabla de destino:

  • Nombre de la tabla
  • Formato de datos
  • mapping

También puede especificar las propiedades de la tabla de destino para cada blob mediante los metadatos del blob. Los datos se enrutarán dinámicamente, según lo especificado en las propiedades de la ingesta.

En el ejemplo siguiente se muestra cómo establecer las propiedades de la ingesta en los metadatos del blob antes de la carga. Los blobs se enrutan a tablas diferentes.

Además, puede especificar la base de datos de destino. Una conexión de datos de Event Grid se crea en el contexto de una base de datos específica. Por lo tanto, esta base de datos es el enrutamiento predeterminado de la base de datos de la conexión de datos. Para enviar los datos a otra base de datos, establezca la propiedad de ingesta "KustoDatabase" y establezca la conexión de datos como una conexión de datos de varias bases de datos. El enrutamiento de datos a otra base de datos está deshabilitado de forma predeterminada (no permitido). Si se establece una propiedad de ingesta de base de datos diferente de la base de datos de la conexión de datos, sin permitir el enrutamiento de datos a varias bases de datos (estableciendo la conexión como una conexión de datos de varias bases de datos), se producirá un error en la ingesta.

Para más información, consulte Carga de 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>")));

Cargar blobs

Puede crear un blob a partir de un archivo local, establecer las propiedades de la ingesta en los metadatos del blob y cargarlo. Para obtener ejemplos, consulte Uso de la conexión de datos de Event Grid.

Nota:

  • Se recomienda encarecidamente usar BlockBlob para generar datos, ya que el uso de AppendBlob puede provocar un comportamiento inesperado.
  • El uso del SDK de Azure Data Lake Storage Gen2 requiere el uso de CreateFile para cargar los archivos y el elemento Flush al final con el parámetro de cierre establecido en true. Para obtener un ejemplo detallado del uso correcto del SDK de Data Lake Storage Gen2, consulte Uso de la conexión de datos de Event Grid.
  • No se admite el desencadenamiento de la ingesta después de una operación CopyBlob para las cuentas de almacenamiento que tienen habilitada la característica de espacio de nombres jerárquico.
  • Cuando el punto de conexión del centro de eventos no reconoce la recepción de un evento, Azure Event Grid activa un mecanismo de reintento. Si se produce un error en esta entrega del reintento, Event Grid puede entregar los eventos sin entregar a una cuenta de almacenamiento mediante un proceso de puesta en cola de mensajes fallidos. Para más información, vea Entrega y reintento de entrega de mensajes de Event Grid.

Cambio del nombre de los blobs

Al usar ADLSv2, puede cambiar el nombre de un blob para desencadenar la ingesta de blobs en Azure Data Explorer. Por ejemplo, consulte Cambio de nombre de blobs.

Nota:

  • El cambio de nombre de un directorio es posible en ADLSv2, pero no desencadena eventos de tipo Blob con el nombre cambiado ni la ingesta de blobs dentro del directorio. Para ingerir blobs después de cambiar el nombre, cambie directamente el nombre de los blobs deseados.
  • Si ha definido filtros para realizar el seguimiento de asuntos específicos al crear la conexión de datos o al crear los recursos de Event Grid manualmente, estos filtros se aplican en la ruta de acceso del archivo de destino.

Eliminación de blobs mediante el ciclo de vida de almacenamiento

Azure Data Explorer no eliminará los blobs después de la ingesta. Use Administración del ciclo de vida de Azure Blob Storage para administrar la eliminación de blobs. Se recomienda mantener los blobs de tres a cinco días.

Problemas conocidos de Event Grid

Trabajar sin autenticación local

Si la autenticación local está deshabilitada en el espacio de nombres de Event Hubs que contiene el centro de eventos usado para transmitir notificaciones, siga estos pasos para asegurarse de que los datos fluyen correctamente del almacenamiento al centro de eventos mediante identidades administradas:

  1. Asigne una identidad administrada asignada por el sistema al tema del sistema de Event Grid de la cuenta de almacenamiento. Para obtener más información, consulte Habilitación de identidades administradas para temas del sistema.
  2. Conceda permisos de emisor a la identidad administrada al asignarle el rol Emisor de datos de Azure Event Hubs en el centro de eventos. Para obtener más información, consulte Adición de una identidad a los roles de Azure en destinos.
  3. Asegúrese de que la suscripción de Event Grid usa la identidad administrada para la entrega de eventos. Para obtener más información, consulte Creación de suscripciones de eventos que usan una identidad.

Además, configure la conexión de datos de Event Grid para usar la autenticación de identidad administrada para que Azure Data Explorer pueda recibir notificaciones del centro de eventos.

Configuración de la ingesta de Event Grid en los archivos exportados desde Azure Data Explorer

Al usar Azure Data Explorer para exportar los archivos que se usan para la ingesta de datos de Event Grid, tenga en cuenta lo siguiente:

  • Las notificaciones de Event Grid no se desencadenan si la cadena de conexión proporcionada al comando de exportación o la cadena de conexión proporcionada a una tabla externa es una cadena de conexión en el formato de ADLS Gen2 (por ejemplo, abfss://filesystem@accountname.dfs.core.windows.net) pero la cuenta de almacenamiento no está habilitada para espacios de nombres jerárquicos.
  • Si la cuenta no está habilitada para espacios de nombres jerárquicos, la cadena de conexión debe usar el formato de Blob Storage (por ejemplo, https://accountname.blob.core.windows.net). La exportación funciona según lo previsto incluso cuando se usa la cadena de conexión de ADLS Gen2, pero las notificaciones no se desencadenarán y ingesta de datos de Event Grid no funcionará.

Emulación de eventos de Azure Storage de componentes personalizados

Cuando se usan componentes personalizados para emular eventos de Azure Storage, los eventos emulados deben cumplir estrictamente el esquema de eventos de Azure Blob Storage, ya que Azure Data Explorer descartará los eventos que el SDK de Event Grid no pueda analizar.

Contenido relacionado