Características y terminología de Azure Event Hubs

Azure Event Hubs es un servicio escalable de procesamiento de eventos que recopila y procesa grandes volúmenes de eventos y datos, con una baja latencia y una alta fiabilidad. Consulte ¿Qué es Event Hubs? para obtener una introducción detallada.

Este artículo se basa en el contenido del artículo de información general e incluye detalles técnicos y de implementación de las características y los componentes de Event Hubs.

Sugerencia

La compatibilidad del protocolo con los clientes de Apache Kafka (versiones >= 1.0) proporciona puntos de conexión de red que permiten que las aplicaciones compiladas usen Apache Kafka con cualquier cliente para utilizar Event Hubs. La mayoría de las aplicaciones de Kafka existentes se pueden volver a configurar simplemente para que apunten a un espacio de nombres del centro de eventos en lugar de a un servidor de arranque del clúster de Kafka.

Desde la perspectiva del costo, el esfuerzo operativo y la confiabilidad, Azure Event Hubs es una excelente alternativa a la implementación y el uso de sus propios clústeres de Kafka y Zookeeper y a las ofertas de Kafka como servicio no nativas para Azure.

Además de conseguir la misma funcionalidad básica que la del agente de Apache Kafka, también se obtiene acceso a las características del centro de eventos de Azure, como el procesamiento por lotes y el archivado automáticos a través de Event Hubs Capture, el equilibrio y el escalado automáticos, la recuperación ante desastres, la compatibilidad con zonas de disponibilidad sin costos adicionales, la integración de red flexible y segura y la compatibilidad con varios protocolos, como el protocolo compatible con firewall AMQP sobre WebSockets.

Espacio de nombres

Un espacio de nombres de Event Hubs es un contenedor de administración de centros de eventos (o temas, en la terminología de Kafka). Proporciona puntos de conexión de red integrados de DNS y una variedad de características de administración de control de acceso e integración de red, como filtrado de IP, punto de conexión de servicio de red virtual y Private Link.

Imagen que muestra un espacio de nombres de Event Hubs

Publicadores de eventos

Toda entidad que envíe datos a un centro de eventos es un publicador de eventos (que se usa como sinónimo de productor de eventos). Los publicadores de eventos pueden publicar eventos mediante HTTPS o AMQP 1.0 o el protocolo de Kafka. Para obtener acceso de publicación, los publicadores de eventos usan la autorización basada en Azure Active Directory con tokens JWT emitidos por OAuth2 o un token de firma de acceso compartido (SAS) específico del centro de eventos.

Publicación de un evento

Puede publicar un evento a través de AMQP 1.0, el protocolo de Kafka o HTTPS. El servicio Event Hubs proporciona API REST y bibliotecas cliente para .NET, Java, Python, JavaScript y Go para publicar eventos en un centro de eventos. Para otras plataformas y tiempos de ejecución, puede usar cualquier cliente de AMQP 1.0, como Apache Qpid.

La opción de usar AMQP o HTTPS es específica para el escenario de uso. AMQP requiere el establecimiento de un socket bidireccional persistente, además de la seguridad de nivel de transporte (TLS) o SSL/TLS. AMQP tiene un mayor costo de red al inicializar la sesión, sin embargo, HTTPS requiere una sobrecarga de TLS adicional para cada solicitud. AMQP presenta un rendimiento bastante mayor para publicadores frecuentes y puede lograr latencias mucho menores cuando se usa con código de publicación asincrónico.

Los eventos se pueden publicar de forma individual o por lotes. Una sola publicación tiene un límite de 1 MB, con independencia de si es un evento único o un lote. La publicación de eventos que superen este umbral se rechazará.

El rendimiento de Event Hubs se ajusta mediante particiones y asignaciones de unidades de rendimiento (consulte a continuación). Se recomienda que los publicadores no estén informados del modelo de particionamiento específico elegido para un centro de eventos y que solo especifiquen una clave de partición que se usa para asignar de forma coherente eventos relacionados a la misma partición.

Claves de partición

Event Hubs garantiza que todos los eventos que comparten un valor de clave de partición se almacenen juntos y se entreguen en el orden de llegada. Si se usan claves de partición con directivas de publicador, la identidad del publicador y el valor de la clave de partición deben coincidir. De lo contrario, se produce un error.

Retención de eventos

Los eventos publicados se quitan de un centro de eventos en función de una directiva de retención configurable basada en el tiempo. Estos son algunos puntos importantes:

  • El valor predeterminado y el período de retención más corto posible es de 1 día (24 horas) .
  • En el caso de Event Hubs estándar, el período de retención máximo es de 7 días.
  • En el caso de los niveles Premium y Dedicado de Event Hubs, el período de retención máximo es de 90 días.
  • Si cambia el período de retención, se aplica a todos los eventos, incluidos los que ya están en el centro de eventos.

Event Hubs retiene los eventos durante el tiempo de retención configurado, que se aplica a todas las particiones. Los eventos se eliminan automáticamente cuando se alcanza el período de retención. Si especifica un período de retención de un día, el evento dejará de estar disponible exactamente 24 horas después de que se haya aceptado. No puede eliminar eventos explícitamente.

Si necesita archivar eventos más allá del período de retención permitido, puede hacer que se almacenen automáticamente en Azure Storage o Azure Data Lake activando la característica Event Hubs Capture. Si necesita buscar o analizar estos archivos profundos, puede importarlos fácilmente a Azure Synapse o a otros almacenes y plataformas de análisis similares.

La razón del límite de Event Hubs en la retención de datos basada en el tiempo es evitar que grandes volúmenes de datos históricos del cliente se mantengan en un almacén que solo está indexado por una marca de tiempo y solo permite el acceso secuencial. La filosofía arquitectónica aquí es que los datos históricos necesitan una indexación más enriquecida y un acceso más directo que la interfaz de eventos en tiempo real que proporcionan Event Hubs o Kafka. Los motores de flujos de eventos no son adecuados para desempeñar el papel de los lagos de datos o los archivos a largo plazo para la creación de orígenes de eventos.

Nota:

Event Hubs es un motor de secuencia de eventos en tiempo real y no está diseñado para usarse en lugar de una base de datos o como almacén permanente para secuencias de eventos que se conservan por tiempo indefinido.

Cuanto más profundo sea el historial de una secuencia de eventos, más se necesitarán índices auxiliares para encontrar un segmento histórico determinado de una secuencia dada. La inspección de cargas de eventos y la indexación no se encuentran dentro del ámbito de características de Event Hubs (o Apache Kafka). Las bases de datos y los almacenes y motores de análisis especializados, como Azure Data Lake Store, Azure Data Lake Analytics y Azure Synapse son, por lo tanto, más adecuados para almacenar eventos históricos.

Event Hubs Capture se integra directamente con Azure Blob Storage y Azure Data Lake Storage y, gracias a esa integración, también permite el flujo de eventos directamente a Azure Synapse.

Directiva del publicador

Los Event Hubs permiten un control granular sobre los publicadores de eventos a través de las directivas de publicador. Las directivas de publicador son características de tiempo de ejecución diseñadas para facilitar grandes números de publicadores de eventos independientes. Con las directivas de publicador, cada publicador usa su propio identificador único al publicar los eventos en un centro de eventos mediante el mecanismo siguiente:

//<my namespace>.servicebus.windows.net/<event hub name>/publishers/<my publisher name>

No tiene que crear nombres de publicador con antelación, pero deben coincidir con el token de SAS que se usa al publicar un evento, con el fin de garantizar las identidades de publicador independientes. Cuando use directivas de publicador, el valor PartitionKey debe establecerse en el nombre del publicador. Para que funcione correctamente, estos valores deben coincidir.

Capturar

Event Hubs Capture permite capturar automáticamente los datos de transmisión de Event Hubs y guardarlos en una cuenta de Blob Storage o en una cuenta de Azure Data Lake Storage. Puede habilitar Capture desde Azure Portal y especificar una ventana de tiempo y de tamaño mínimos para realizar la captura. Event Hubs Capture permite especificar una cuenta y un contenedor propios de Azure Blob Storage, o una cuenta de Azure Data Lake Storage, uno de los cuales se usa para almacenar los datos capturados. Los datos capturados se escriben en el formato de Apache Avro.

Imagen que muestra la captura de datos de Event Hubs en Azure Storage o Azure Data Lake Storage

Los archivos que genera Event Hubs Capture tienen el siguiente esquema de Avro:

Imagen que muestra la estructura de los datos capturados

Nota:

Si no usa ningún editor de código en Azure Portal, puede capturar datos de streaming en Event Hubs en una cuenta de Azure Data Lake Storage Gen2 en el formato Parquet. Para más información, vea Procedimiento para capturar datos de Event Hubs en formato Parquet y Tutorial: Captura de datos de Event Hubs en formato Parquet y análisis con Azure Synapse Analytics.

Particiones

Event Hubs organiza las secuencias de eventos que se envían a un centro de eventos en una o más particiones. A medida que llegan eventos más recientes, se agregan al final de esta secuencia.

Event Hubs

Una partición puede considerarse como un "registro de confirmación". Las particiones almacenan datos de eventos que contienen el cuerpo del evento, un contenedor de propiedades definido por el usuario que describe el evento y metadatos, como su desplazamiento en la partición, su número en la secuencia de la transmisión y la marca de tiempo del servicio en el momento que se aceptó.

Diagrama que muestra la secuencia de eventos, de más antiguo o más reciente.

Ventajas de usar particiones

Event Hubs está diseñado para ayudar en el procesamiento de grandes volúmenes de eventos y la creación de particiones ayuda a hacerlo de dos maneras:

  • Aunque Event Hubs sea un servicio PaaS, hay una realidad física subyacente, y el mantenimiento de un registro que conserva el orden de los eventos requiere que estos eventos se mantengan juntos en el almacenamiento subyacente y sus réplicas, y esto crea un límite máximo de rendimiento para este tipo de registro. La creación de particiones permite que se usen varios registros paralelos para el mismo centro de eventos y, por lo tanto, multiplicar la capacidad de rendimiento de E/S sin procesar disponible.
  • Sus propias aplicaciones deben poder mantener el procesamiento del volumen de eventos que se envía a un centro de eventos. Esto puede ser complejo y requiere una capacidad de procesamiento en paralelo importante con escalabilidad horizontal. La capacidad de un único proceso para controlar eventos es limitada, por lo que se necesitan varios procesos. Las particiones son el modo en que la solución alimenta esos procesos y, además, garantiza que cada evento tenga un propietario del proceso claro.

Número de particiones

El número de particiones se especifica en el momento de crear un centro de eventos. Debe tener entre 1 y el número máximo de particiones admitido para cada plan de tarifa. Para ver el límite del número de particiones para cada plan, consulte este artículo.

Se recomienda elegir al menos tantas particiones como espere necesitar durante la carga máxima de la aplicación para ese centro de eventos específico. No se puede cambiar el número de particiones de un centro de eventos después de su creación, excepto en el caso del centro de eventos de un clúster dedicado y el nivel prémium. El número de particiones de un centro de eventos de un clúster de Event Hubs dedicado se puede aumentar tras su creación, pero la distribución de flujos entre las particiones cambiará cuando se realice como la asignación de claves de partición a cambios de las particiones, por lo que es preciso evitar a toda costa ese tipo de cambios si el orden relativo de los es importante en la aplicación.

Establecer el número de particiones en el valor máximo permitido es tentador, pero siempre debe tener en cuenta que los flujos de eventos deben estar estructurados de manera que se puedan aprovechar las ventajas de tener varias particiones. Si necesita conservar el orden absoluto en todos los eventos o solo en un puñado de subsecuencias, es posible que no pueda aprovechar las ventajas de tener muchas particiones. Además, muchas particiones hacen que el procesamiento sea más complejo.

No importa cuántas particiones haya en un centro de eventos en lo que respecta a los precios. Depende del número de unidades de precios (unidades de procesamiento (TU) para el nivel estándar, unidades de procesamiento (PU) para el nivel prémium y unidades de capacidad (CU) para el nivel dedicado) para el espacio de nombres o el clúster dedicado. Por ejemplo, un centro de eventos de nivel estándar con 32 particiones o con 1 partición generan exactamente el mismo costo cuando el espacio de nombres se establece en una capacidad de 1 TU. También puede escalar las TU o PU del espacio de nombres o las CU del clúster dedicado independientemente del número de particiones.

Dado que una partición es un mecanismo de organización de datos que permite publicar y consumir datos de forma paralela, se recomienda equilibrar las unidades de escalado (TU, PU o CU) y las particiones para obtener un escalado óptimo. En general, se recomienda a los usuarios mantener un rendimiento máximo de 1 MB/s por partición y elegir el recuento de particiones para que coincida con el rendimiento máximo que desea controlar. Por ejemplo, si su caso de uso requiere 20 MB/s, se recomienda elegir al menos 20 particiones para obtener el rendimiento óptimo.

Pero si tiene un modelo en el que su aplicación tiene afinidad con una partición determinada, aumentar el número de particiones puede que no suponga ventaja alguna. Para más información, vea Disponibilidad y coherencia.

Asignación de eventos a particiones

Puede usar una clave de partición para asignar datos de eventos entrantes a particiones concretas con fines de organización de los datos. La clave de partición es un valor proporcionado por el remitente que se pasa a un centro de eventos. Se procesa a través de una función hash estática que crea la asignación de la partición. Si no especifica una clave de partición cuando se publica un evento, se usa una asignación de tipo round robin.

El publicador de eventos solo conoce su clave de partición, no la partición en la que se publican los eventos. Este desacoplamiento de la clave y la partición evita al remitente la necesidad de conocer demasiado sobre el procesamiento de bajada. Una identidad única por cada dispositivo o usuario es una buena clave de partición, pero otros atributos como la geografía también pueden usarse para agrupar eventos relacionados en una única partición.

La especificación de una clave de partición permite mantener los eventos relacionados en la misma partición y en el orden exacto en el que han llegado. La clave de partición es una cadena que se deriva del contexto de la aplicación e identifica la interrelación de los eventos. Una secuencia de eventos identificados por una clave de partición es un flujo. Una partición es un almacén de registros multiplexado para muchos de estos flujos.

Nota:

Aunque puede enviar eventos directamente a las particiones, no se recomienda, sobre todo si le da una gran importancia a la alta disponibilidad. Esto degrada la disponibilidad de un centro de eventos en el nivel de partición. Para más información, consulte Disponibilidad y coherencia.

Tokens de SAS

Event Hubs usa firmas de acceso compartido que están disponibles en el nivel del espacio de nombres y del centro de eventos. Un token de SAS se genera a partir de una clave de SAS y es un hash SHA de una dirección URL, codificado en un formato concreto. Event Hubs puede volver a generar el hash mediante el nombre de la clave (directiva) y el token y así autenticar al remitente. Normalmente, los tokens de SAS para publicadores de eventos se crean solo con privilegios de envío en un centro de eventos concreto. Este mecanismo de dirección URL del token de SAS es la base para la identificación del publicador introducida en la directiva del publicador. Para obtener más información sobre el funcionamiento con SAS, consulte Autenticación con firma de acceso compartido en Service Bus.

Consumidores de eventos

Cualquier entidad que lea datos de eventos de un centro de eventos es un consumidor de eventos. Todos los consumidores de Event Hubs se conectan a través de la sesión de AMQP 1.0, y los eventos se entregan a través de la sesión a medida que están disponibles. El cliente no necesita realizar un sondeo de disponibilidad de los datos.

Grupos de consumidores

El mecanismo de publicación y suscripción de Event Hubs se habilita a través de los grupos de consumidores. Un grupo de consumidores es una vista (estado, posición o desplazamiento) de un centro de eventos completo. Los grupos de consumidores habilitan varias aplicaciones consumidoras para que cada una tenga una vista separada del flujo de eventos y para que lean el flujo de forma independiente a su propio ritmo y con sus propios desplazamientos.

En una arquitectura de procesamiento de flujos, cada aplicación de bajada se corresponde con un grupo de consumidores. Si quiere escribir datos de eventos para el almacenamiento a largo plazo, esa aplicación de escritura de almacenamiento es un grupo de consumidores. Otro grupo de consumidores independiente puede realizar el procesamiento de eventos complejos. Solo puede obtener acceso a las particiones a través de un grupo de consumidores. Siempre hay un grupo de consumidores predeterminado en un centro de eventos y puede crear hasta el número máximo de grupos de consumidores para el plan de tarifa correspondiente.

Como máximo, puede haber cinco lectores simultáneos en una partición por grupo de consumidores; pero se recomienda que solo haya un receptor activo en una partición por grupo de consumidores. Cada lector recibe todos los eventos dentro de una sola partición. Si tiene varios lectores en la misma partición, procesará los eventos duplicados. Debe controlar esto en su código, pues no puede ser trivial. Sin embargo, es un enfoque válido en algunos escenarios.

Algunos clientes que ofrecen los SDK de Azure son agentes de consumidor inteligentes que administran automáticamente los detalles para asegurarse de que cada partición tenga un lector único y que se estén leyendo todas las particiones para un centro de eventos. Esto permite que el código se centre en el procesamiento de los eventos que se leen desde el centro de eventos de modo que pueda omitir muchos detalles de las particiones. Para más información, consulte Conexión a una partición.

A continuación se muestran ejemplos de la convención de URI del grupo de consumidores:

//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>

La siguiente ilustración muestra la arquitectura de procesamiento del flujo de Event Hubs:

Arquitectura de Event Hubs

Desplazamientos de los flujos

Un desplazamiento es la posición de un evento dentro de una partición. Puede pensar en un desplazamiento como un cursor de lado cliente. El desplazamiento es una numeración de byte del evento. Este desplazamiento permite que un consumidor de eventos (lector) especifique un punto en el flujo de eventos desde el que quiere empezar a leer los eventos. Puede especificar el desplazamiento como una marca de tiempo o como un valor de desplazamiento. Los consumidores son responsables de almacenar sus propios valores de desplazamiento fuera del servicio de Event Hubs. Dentro de una partición, cada evento incluye un desplazamiento.

Desplazamiento de partición

Puntos de control

Puntos de control es un proceso en el que los lectores marcan o confirman su posición dentro de la secuencia de eventos de una partición. La creación de puntos de comprobación es responsabilidad del consumidor y se realiza por partición dentro de un grupo de consumidores. Esta responsaibilidad significa que por cada grupo de consumidores, cada lector de la partición debe realizar un seguimiento de su posición actual en el flujo del evento y puede informar al servicio cuando considere que el flujo de datos se ha completado.

Si se desconecta un lector de una partición, cuando se vuelve a conectar comienza a leer en el punto de comprobación que envió previamente el último lector de esa partición en ese grupo de consumidores. Cuando se conecta el lector, pasa este desplazamiento al centro de eventos para especificar la ubicación en la que se va a empezar a leer. De este modo, puede usar puntos de comprobación para marcar eventos como "completados" por las aplicaciones de bajada y para ofrecer resistencia en caso de que se produzca una conmutación por error entre lectores que se ejecutan en máquinas distintas. Es posible volver a los datos más antiguos especificando un desplazamiento inferior desde este proceso de puntos de control. Mediante este mecanismo, los puntos de comprobación permiten una resistencia a la conmutación por error y una reproducción del flujo de eventos.

Importante

El servicio Event Hubs proporciona desplazamientos. Es responsabilidad del consumidor crear puntos de comprobación a medida que se procesan los eventos.

Nota:

Si usa Azure Blob Storage como el almacén de puntos de comprobación en un entorno que admite una versión diferente del SDK de blobs de almacenamiento que las que normalmente están disponibles en Azure, tendrá que utilizar código para cambiar la versión de la API del servicio de almacenamiento a la versión admitida por ese entorno. Por ejemplo, si ejecuta Event Hubs en una instancia de Azure Stack Hub versión 2002, la versión más alta disponible para el servicio Storage es 2017-11-09. En este caso, tendrá que usar código para establecer como destino la versión de la API del servicio Storage en 2017-11-09. Para obtener un ejemplo de cómo establecer como destino una versión específica de la API de Storage, vea estos ejemplos en GitHub:

Tareas comunes del consumidor

Todos los consumidores de Event Hubs se conectan a través de una sesión de AMQP 1.0, un canal de comunicación bidireccional con estado. Cada partición tiene una sesión de AMQP 1.0 que facilita el transporte de eventos que deben separarse por partición.

Conexión a una partición

Es una práctica habitual al conectarse a particiones usar un mecanismo de concesiones para coordinar las conexiones del lector a particiones concretas. De este modo, es posible que cada partición de un grupo de consumidores solo tenga un lector activo. Los puntos de comprobación, la concesión y la administración de lectores se simplifican mediante el uso de los clientes de los SDK de Event Hubs, que actúan como agentes de consumidor inteligentes. Dichos componentes son:

Lectura de eventos

Después de abrir una sesión de AMQP 1.0 y el vínculo de una partición específica, el servicio de Centros de eventos entrega los eventos al cliente de AMQP 1.0. Este mecanismo de entrega permite un mayor procesamiento y una menor latencia que los mecanismos basados en extracción como HTTP GET. Los eventos se envían al cliente, cada instancia de datos de eventos contiene metadatos importantes, como el número de secuencia y el desplazamiento que se usan para facilitar la creación de puntos de comprobación en la secuencia de eventos.

Datos de evento:

  • Offset
  • Número de secuencia
  • Body
  • Propiedades de usuario
  • Propiedades del sistema

Es su responsabilidad administrar el desplazamiento.

Grupos de aplicaciones

Un grupo de aplicaciones es una colección de aplicaciones cliente que se conectan a un espacio de nombres de Event Hubs y que comparten una condición de identificación única, como el contexto de seguridad, directiva de acceso compartida o el ID de aplicación de Azure Active Directory (Azure AD).

Azure Event Hubs permite definir directivas de acceso a recursos, como directivas de limitación para un grupo de aplicaciones determinado y controla el streaming de eventos (publicación o consumo) entre las aplicaciones cliente y Event Hubs.

Para más información, consulte Gobernanza de recursos para aplicaciones cliente con grupos de aplicaciones.

Pasos siguientes

Para obtener más información acerca de Event Hubs, visite los vínculos siguientes: