Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Azure Event Hubs explicado: streaming de datos en tiempo real con particiones, grupos de consumidores y Kafka (Doblaje IA)

Transcript

Azure Event Hubs explicado: streaming de datos en tiempo real con particiones, grupos de consumidores y Kafka (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:00
Speaker 2: Preparado para 10 días de Microsoft 365 Copilot, EA, Azure
0:04
Speaker 2: y las personas que están dando forma al futuro del trabajo,
0:07
Speaker 2: este enero, M365 con regresa y lo hace a lo grande.
0:12
Speaker 2: Únase a nosotros para sesiones en vivo, demostraciones del mundo
0:15
Speaker 2: real y conocimientos prácticos de MVP y expertos del sector
0:17
Speaker 2: de todo el mundo. Sin diapositivas genéricas ni palabras de
0:20
Speaker 2: modo interminable. Estamos abordando los desafíos reales. Copilot Studio, agentes
0:24
Speaker 2: de EA Fabric, seguridad, gobernanza y automatización, FAQ. Ya seas
0:30
Speaker 2: un profesional de TI, un desarrollador o un líder empresarial,
0:33
Speaker 2: hay sesiones diseñadas para ti. Con 10 días completos, puedes
0:37
Speaker 2: explorar múltiples tecnologías y conectar con una comunidad global. Míralo
0:41
Speaker 2: en vivo y aplica conocimientos prácticos a tu organización. Enero
0:45
Speaker 2: de 2027. 10 días. Una comunidad de Microsoft. La inscripción
0:50
Speaker 2: ya está abierta. Ve a tu sitio hoy mismo. Es m365con.net.
1:00
Speaker 2: Únete ahora en m365.com.net y nos vemos en vivo en enero.
1:05
Speaker 2: Bienvenido de nuevo a otro episodio de Microsoft Knowledge Nuggets.
1:08
Speaker 2: Soy su anfitrión Mirko Peters y hoy abordaremos un problema
1:10
Speaker 2: de datos del mundo real. Permítanme preguntarles esto. Imaginen que
1:13
Speaker 2: estén en una fábrica con mil sensores de temperatura, presión
1:15
Speaker 2: y vibración que funcionan constantemente y nos envían una lectura
1:18
Speaker 2: cada segundo. Eso supone mil puntos de datos cada segundo.
1:22
Speaker 2: Hace 20 años la solución era sencilla. recopilarían todos esos
1:25
Speaker 2: datos durante el día, los almacenarían en un archivo y
1:28
Speaker 2: luego ejecutarían un trabajo por lotes a medianoche para procesar.
1:30
Speaker 2: A la mañana siguiente tendrían un informe que mostraría lo
1:32
Speaker 2: que ocurrió ayer. Eso funcionaba bien cuando lo rápido era
1:35
Speaker 2: para mañana por la mañana. Pero el mundo cambió. Los
1:39
Speaker 2: sensores bajaron de precio, las apps son más listas y
1:41
Speaker 2: los usuarios quieren respuestas. Ahora, ese procesamiento nocturno hace que
1:45
Speaker 2: sus datos siempre tengan un día de retraso y si
1:47
Speaker 2: una máquina puede incendiarse en minutos, un día de retraso
1:49
Speaker 2: no sirve de nada. Por lo tanto, pasamos al tiempo
1:52
Speaker 2: real recopilando datos en el momento que se genera. Pero
1:55
Speaker 2: aquí es donde empiezan los problemas. Intentas poner todos esos
1:57
Speaker 2: datos de streaming en una base de datos tradicional y
1:59
Speaker 2: simplemente se bloquea. Las bases de datos están diseñadas para
2:02
Speaker 2: consultas y transacciones, no para ingerir una gran cantidad de eventos.
2:06
Speaker 2: Pruebas con una cola de mensaje es normal y funciona
2:08
Speaker 2: durante un tiempo, pero las colas están diseñadas para que
2:10
Speaker 2: un consumidor tome un mensaje y lo procese. Por lo tanto,
2:14
Speaker 2: no están diseñadas para millones de eventos. Por segundo, con
2:16
Speaker 2: varios sistemas descendentes que desean leer la misma secuencia. Este
2:20
Speaker 2: es el principal desafío. Necesitas una forma de ingerir cantidades
2:23
Speaker 2: masivas de datos, almacenarlos en buffer para no perder nada,
2:26
Speaker 2: y distribuirlos a varios consumidores, todo en tiempo real. Ese
2:29
Speaker 2: no es un problema de base, no es un problema
2:31
Speaker 2: de cola, no es un problema de streaming.¿ Cuál es
2:33
Speaker 2: la solución? Ahí es donde entra Azure Event Hubs.¿ Qué
2:35
Speaker 2: es Azure Event Hubs? Tengo la definición más simple. Azure
2:40
Speaker 2: Event Hubs es una plataforma de streaming de datos en
2:42
Speaker 2: tiempo real y totalmente administrada, creada para ingerir millones de
2:44
Speaker 2: eventos por segundo con baja latencia. Observar que no dije
2:47
Speaker 2: cola de mensajes ni base de datos. Event Hubs no
2:50
Speaker 2: es una cola ni una base de datos. Es un flujo,
2:53
Speaker 2: y la diferencia importa. Una cola retiene un mensaje hasta
2:55
Speaker 2: que un consumidor lo recoge y luego desaparece. Una base
2:58
Speaker 2: de datos guarda datos para consultarlos después. Pero un flujo
3:01
Speaker 2: es distinto. Es un flujo continuo de eventos que varios
3:03
Speaker 2: lectores pueden leer de forma independiente a su propio ritmo,
3:06
Speaker 2: sin eliminar nada del flujo. Ahora aclaremos algunos mitos. Event
3:10
Speaker 2: Caps puede gestionar millones de eventos por segundo. Estamos hablando
3:13
Speaker 2: de ingerir cientos de miles de mensajes cada segundo a
3:16
Speaker 2: miles de productores y lo hace con una latencia muy baja, milisegundos,
3:19
Speaker 2: desde el momento en que se envía un evento hasta
3:21
Speaker 2: el momento en que un consumidor puede leerlo. Que hay
3:25
Speaker 2: algo que sorprende a mucha gente. Event Hubs es compatible
3:27
Speaker 2: con Kafka. Por lo tanto, si has trabajado con Apache
3:30
Speaker 2: Kafka antes, puedes usar tus herramientas y clientes de Kafka
3:32
Speaker 2: existentes para comunicarse con Event Hubs sin aprender un nuevo
3:34
Speaker 2: protocolo ni reescribir tus aplicaciones. Habla el mismo idioma. La
3:38
Speaker 2: forma más sencilla de verlo es considerar a Event Hubs
3:40
Speaker 2: una puerta de entrada de datos rápida. Imagina un edificio
3:43
Speaker 2: de oficinas concurrido en hora punta. Cientos de personas entran
3:47
Speaker 2: por la puerta principal cada minuto y la puerta no
3:49
Speaker 2: los detiene, no les hace preguntas ni les dirige a
3:50
Speaker 2: salas específicas. Simplemente los deja entrar rápidamente. Eso es DevOps.
3:55
Speaker 2: Es la puerta de entrada para tus datos. No los procesa,
3:57
Speaker 2: no los analiza ni decide qué hacer con ellos. Simplemente
4:00
Speaker 2: los introduce en tu entorno de Azure lo más rápido
4:02
Speaker 2: posible para que tus sistemas posteriores puedan hacer el trabajo real.
4:05
Speaker 2: Pero¿ cómo funciona realmente? Vamos a desglosar las piezas. Los
4:08
Speaker 2: componentes básicos, particiones, grupos de consumidores, rendimiento. Por lo tanto,
4:11
Speaker 2: dentro de cada Event Hub hay una estructura que hace
4:13
Speaker 2: que todo funcione. La pieza más importante es la partición.
4:16
Speaker 2: Piensa en una partición con un carril en autopista. Los
4:18
Speaker 2: datos entrañatorizan nuestros carriles. Este es el reclamo. Dentro de
4:21
Speaker 2: cada carril, el orden de los eventos permanece exactamente como llegan.
4:24
Speaker 2: El evento 1 va antes del evento 2. Y el
4:25
Speaker 2: evento 2 antes del evento 3. Ese orden nunca cambia
4:28
Speaker 2: dentro de ese carril. Por lo tanto, si tu aplicación
4:31
Speaker 2: necesita eventos en el orden exacto, los mantienes en la
4:32
Speaker 2: misma partición. Puedes tener entre 2 y 32 particiones por
4:35
Speaker 2: Event Hub y estableces este número al crear el Hub.
4:38
Speaker 2: O puedes cambiarlo más adelante. Debes pensar en tus necesidades
4:41
Speaker 2: de rendimiento desde el principio. Más particiones significa más procesamiento
4:44
Speaker 2: para leer. Si esperas un gran volumen de eventos, necesitas
4:47
Speaker 2: más particiones para que varios consumidores puedan leer desde diferentes
4:50
Speaker 2: carriles al mismo tiempo. Pero más particiones también significa más complejidad.
4:54
Speaker 2: La regla de oro es elegir en función del rendimiento esperado,
4:56
Speaker 2: no al azar. Si no estás seguro, empieza por algo
4:59
Speaker 2: más pequeño y peor. Las particiones no bastan por sí solas.
5:01
Speaker 2: También necesitas grupos de consumidores. Un grupo de consumidores es
5:04
Speaker 2: simplemente una aplicación descendente independiente que lee el mismo flujo.
5:07
Speaker 2: Cada grupo de consumidores obtiene su propia copia independiente. Por
5:10
Speaker 2: lo tanto, si tienes un grupo para análisis en tiempo
5:12
Speaker 2: real y otro para archivar en el almacenamiento, ambos leen
5:15
Speaker 2: los mismos eventos al mismo tiempo sin interferir. El grupo
5:18
Speaker 2: de análisis lee datos de temperatura para detectar anomalías. El
5:20
Speaker 2: grupo de archivado lee los mismos datos y los envía
5:22
Speaker 2: a un lago de datos para su almacenamiento a largo plazo.
5:24
Speaker 2: Ambos grupos ven todos los eventos. Y nueve los grupos bloquean.
5:28
Speaker 2: Esto es algo muy importante. En una cola tradicional, un
5:30
Speaker 2: procesador consume un mensaje y luego desaparece. Aquí varios consumidores
5:33
Speaker 2: pueden leer el mismo flujo de forma independiente. Ese es
5:35
Speaker 2: el poder de los grupos de consumo. Pero¿ cómo se
5:37
Speaker 2: mide la cantidad de datos que puede gestionar el centro
5:39
Speaker 2: de evento?¿ Y a dónde entran las unidades de rendimiento?
5:41
Speaker 2: Una unidad de rendimiento, o TU, mide la capacidad. Una
5:44
Speaker 2: TU proporciona 1 MB por segundo de datos entrantes y
5:47
Speaker 2: 2 MB por segundo de datos salientes. Por lo tanto,
5:50
Speaker 2: si necesita ingerir 10 MB por segundo, necesita al menos
5:52
Speaker 2: 10 TU. Puede escalar manualmente o puede habilitar el inflado
5:55
Speaker 2: automático que aumenta automáticamente las TU cuando hay picos de tráfico.
5:59
Speaker 2: Paga por la cantidad máxima de TU utilizadas en una hora.
6:02
Speaker 2: Por lo tanto, si utiliza 20 TU durante 10 minutos,
6:05
Speaker 2: generará 20 TU para toda esa hora. Una pieza más,
6:08
Speaker 2: la retención. Los eventos no desaparecen del concentrador después de consumirse.
6:12
Speaker 2: Permanecen en el concentrador durante un periodo. En el nivel
6:14
Speaker 2: estándar es de 1 a 7 días. En el nivel
6:16
Speaker 2: prima hasta 90 días. Esto permite algo llamado repetición. Si
6:19
Speaker 2: tu consumidor descendente falla, o si necesitas volver a procesar
6:22
Speaker 2: datos para un nuevo análisis, puedes volver atrás y leer
6:24
Speaker 2: eventos antiguos de nuevo. Eso es diferente de una cola
6:27
Speaker 2: donde una vez que se consume un mensaje, desaparece para siempre.
6:29
Speaker 2: Entonces ahora conoces las partes, pero¿ cómo funcionan realmente juntas
6:32
Speaker 2: en un sistema real?¿ Cómo funciona? El modelo productor y consumidor.
6:36
Speaker 2: Repasemos el flujo de principio a fin. Por un lado
6:39
Speaker 2: tienes productores. Un productor es cualquier aplicación o dispositivo que
6:42
Speaker 2: envíe eventos al concentrado. Podría ser un sensor de temperatura
6:45
Speaker 2: en una fábrica, un servidor web registrando vistas de página
6:48
Speaker 2: o una app bancaria enviando transacciones. Los productores pueden comunicarse
6:51
Speaker 2: con Event Hubs usando tres protocolos distintos, AMQP, HTTPS o Kafka.
6:56
Speaker 2: Sea cual sea el lenguaje o plataforma que use, siempre
6:58
Speaker 2: existe una forma de conectarse. Cuando un productor envía un evento,
7:00
Speaker 2: el concentrador decide a qué partición va. De forma predeterminada,
7:04
Speaker 2: los eventos se distribuyen por turno. El primer evento va
7:06
Speaker 2: a la partición 1, el segundo a la partición 2
7:08
Speaker 2: y así sucesivamente. Pero también puedes utilizar una clave de partición.
7:11
Speaker 2: Si quieres que todos los eventos del mismo dispositivo lleguen
7:13
Speaker 2: a la misma partición, establece el ID del dispositivo como
7:15
Speaker 2: clave de partición. De esa forma se conserva el orden
7:17
Speaker 2: de los eventos de ese dispositivo. El concentrador en sí
7:19
Speaker 2: no realiza mucho proceso. Almacena los eventos en Buffer y
7:22
Speaker 2: los almacena las particiones durante el periodo de retención. Piensa
7:25
Speaker 2: en ello como un aire de espera. Los eventos permanecen
7:27
Speaker 2: allí esperando a que alguien los dé. Por otro lado
7:29
Speaker 2: tienes los consumidores. Los consumidores son aplicaciones posteriores que leen
7:32
Speaker 2: desde el concentrador. Y aquí está la parte importante. Los
7:35
Speaker 2: consumidores utilizan un modelo extractivo. Controlan su propio ritmo. No
7:38
Speaker 2: reciben eventos enviados, sino que solicitan eventos cuando están listos.
7:41
Speaker 2: Esto es diferente de una cola, donde el sistema envía
7:43
Speaker 2: mensajes a un consumidor. Aquí el consumidor decide cuándo extraer
7:47
Speaker 2: el siguiente lote. Cada grupo de consumidores rastrea su posición
7:50
Speaker 2: en el flujo. Esta posición se denomina desplazamiento. Desplazamiento indica
7:54
Speaker 2: al consumidor qué eventos ya ha procesado. El consumidor almacena
7:57
Speaker 2: este desplazamiento en algún lugar duradero, normalmente en Azure Blob Storage.
8:01
Speaker 2: Este proceso se denomina creación de puntos de contacto. Esta
8:03
Speaker 2: es la razón por la que se importa tanto el control.
8:04
Speaker 2: Imagine que su aplicación de consumidor se bloquea a mitad
8:06
Speaker 2: del procesamiento de un lote de eventos. Cuando se reinicia,
8:09
Speaker 2: lee el último punto de control del almacenamiento de blobs
8:11
Speaker 2: y continúa desde ese punto exacto. No vuelve a procesar
8:14
Speaker 2: los eventos antiguos ni omite ningún evento. Continúa justo donde
8:17
Speaker 2: lo dejó. Y eso es confiabilidad sin complejidad. La idea
8:20
Speaker 2: clave es que Event Hubs desvincula por completo a los
8:22
Speaker 2: productores de los consumidores. Los productores no saben quién está
8:25
Speaker 2: leyendo sus datos. Los consumidores no saben quién está meando
8:27
Speaker 2: los datos. No hay independencia. El concentrador se encuentra en
8:30
Speaker 2: el medio, almacenando en buffer y distribuyendo eventos, y cada
8:32
Speaker 2: lado opera su propio ritmo. Y ese desacoplamiento es lo
8:34
Speaker 2: que hace que Event Hub sea tan eficaz para crear
8:36
Speaker 2: sistemas escalables y resilientes. Vamos a concretarlo con escenarios del
8:39
Speaker 2: mundo real. Casos de uso del mundo real. Empezamos por
8:43
Speaker 2: el más importante, la telemetría de la IoT. Imagina una
8:46
Speaker 2: fábrica inteligente con miles de sensores. Cada máquina tiene sensores
8:49
Speaker 2: que miden la temperatura, la presión, la vibración y el
8:51
Speaker 2: consumo de energía, y cada uno envía una lectura cada
8:53
Speaker 2: poco segundo. No son cientos de eventos por segundo, son
8:56
Speaker 2: cientos de miles, quizá millones, según... tamaño de la fábrica.
8:59
Speaker 2: No puedes almacenar eso en una base de datos tradicional,
9:01
Speaker 2: ni procesarlo con un trabajo por lotes que se ejecute
9:03
Speaker 2: una vez al día. Para cuando recibas el informe, es
9:05
Speaker 2: posible que una máquina ya se haya sobrecalentado y haya
9:07
Speaker 2: detenido el plug. Por lo tanto, canalizas todos esos datos
9:10
Speaker 2: de los sensores 7-Hubs que ingieren la manguera contra incendios
9:12
Speaker 2: sin esfuerzo. Luego conectas Azure Stream Analytics al concentrador y
9:15
Speaker 2: éste ejecuta consultas en tiempo real sobre los datos. Cuando
9:18
Speaker 2: una lectura de temperatura supera un umbral, se activa una alerta,
9:21
Speaker 2: se notifica el equipo de mantenimiento y se apaga una
9:23
Speaker 2: máquina antes de que falle. Es un mantenimiento predictivo en acción.
9:27
Speaker 2: Otro caso de uso común es el registro y la
9:28
Speaker 2: supervisión de aplicaciones. Digamos que ejecutas una arquitectura de microservicios
9:32
Speaker 2: con 50 servicios diferentes que hacen cosas distintas. Cada uno
9:35
Speaker 2: genera registros con errores y advertencias simétricas de rendimiento. En
9:38
Speaker 2: el viejo mundo escribías esos registros en archivos en cada
9:40
Speaker 2: servidor y cuando algo fallaba iniciabas sesión en 5 máquinas
9:43
Speaker 2: diferentes para encontrar el error. Es una pesadilla. En su lugar,
9:46
Speaker 2: haces que cada servicio envíe sus registros a un solo
9:49
Speaker 2: centro de eventos, una canalización central. Luego creas varios grupos
9:53
Speaker 2: de consumidores. Un grupo lee la transmisión y envía errores
9:56
Speaker 2: críticos a un sistema de alertas en tiempo real. Otro
9:58
Speaker 2: grupo lee la misma transmisión y escribe todos los registros
10:01
Speaker 2: en Azure Data Lake para su almacenamiento y análisis a
10:02
Speaker 2: largo plazo. Un tercer grupo alimenta un panel en vivo
10:05
Speaker 2: que muestra el estado del sistema. Cada equipo ve los
10:07
Speaker 2: mismos datos en tiempo real sin interferir entre sí. El
10:10
Speaker 2: análisis de flujo de clics es otro gran recurso. Imagina
10:12
Speaker 2: que ejecutas un sitio de comercio editorial. Cada clic, vista
10:14
Speaker 2: de página, consulta y evento de añadir al carrito se
10:17
Speaker 2: envía a Event Hubs. Es un flujo masivo de datos
10:19
Speaker 2: sobre el usuario Los consumidores posteriores analizan el flujo en
10:22
Speaker 2: tiempo real. Un consumidor crea perfiles de usuario que muestran
10:25
Speaker 2: qué productos mira la gente y qué categorías explora. Otro
10:28
Speaker 2: consumidor detecta tendencias y descubre qué productos se vuelven populares
10:30
Speaker 2: de repente. Un tercer consumidor personaliza la experiencia de compra
10:34
Speaker 2: mostrando recomendaciones basadas en los clics que acaba de hacer
10:36
Speaker 2: el usuario. Todo esto ocurre en milisegundos, no de la
10:38
Speaker 2: noche a la mañana. Y luego está la detección de
10:40
Speaker 2: fraudes en las finanzas. Los bancos procesan millones de transacciones
10:43
Speaker 2: cada día. Deslizar tarjetas de crédito, transferencias, pagos en línea.
10:47
Speaker 2: Cada transacción es un evento y cada una debe calificarse
10:49
Speaker 2: para detectar fraudes en tiempo real. No puede esperar un
10:52
Speaker 2: proceso por lotes porque si una transacción fraudulenta se completa,
10:54
Speaker 2: el dinero desaparece. Por lo tanto, el banco transmite cada
10:57
Speaker 2: transacción en MyHabs. En el proceso posterior, modelos de aprendizaje
11:00
Speaker 2: automático consumen el flujo, evalúan cada transacción por riesgo de fraude,
11:03
Speaker 2: y las sospechosas son marcadas y bloqueadas en segundos. Mientras tanto,
11:08
Speaker 2: grupos de consumo distintos envían el mismo flujo a sistemas
11:10
Speaker 2: de cumplimiento para reportes normativos y a paneles operativos para
11:13
Speaker 2: supervisar volúmenes de transacciones. Tres consumidores diferentes que leen el
11:16
Speaker 2: mismo flujo, todos haciendo cosas diferentes. El hilo conductor de
11:20
Speaker 2: todos los escenarios es el mismo. Alto volumen, múltiples consumidores
11:23
Speaker 2: y la necesidad de información en tiempo real. Event Hubs
11:26
Speaker 2: no es la solución a todos los problemas, pero cuando
11:27
Speaker 2: tienes esta combinación, es la herramienta adecuada para el trabajo.
11:30
Speaker 2: Ahora bien, Event Hubs no es el único servicio de
11:33
Speaker 2: mensajería en Azure. Vamos a compararlo con los demás. Event
11:35
Speaker 2: Hubs frente a Event Grid frente a Service Bus. Azure
11:38
Speaker 2: tiene tres servicios principales para mover datos. Event Grid, Event
11:41
Speaker 2: Hubs y Service Bus. La gente los confunde todo el tiempo,
11:44
Speaker 2: así que vamos a aclarar la confusión. Event Grid es
11:46
Speaker 2: la alarma de humo. Es ligero y reactivo. Cuando ocurre algo.
11:50
Speaker 2: Un blob se carga en el almacenamiento. Una máquina virtual
11:53
Speaker 2: cambia de estado. Y se crea un recurso. Event Grid
11:57
Speaker 2: activa un evento. No transporta los datos en sí, solo dice, oye,
12:00
Speaker 2: ha ocurrido algo. Y luego dirige esa notificación a controladores
12:03
Speaker 2: como Azure Functions o Logic Apps. Event Grid no es
12:05
Speaker 2: un flujo y no está diseñado para un alto rendimiento.
12:08
Speaker 2: Es para eventos discretos que necesitan una reacción rápida. Ideal
12:11
Speaker 2: para activadores de carga de blobs, cambios de estado de
12:13
Speaker 2: recursos y flujos sin servidor. Service Bus es servicio postal.
12:16
Speaker 2: Es fiable, ordenado y garantiza la entrega. Cuando envías un
12:20
Speaker 2: mensaje a través de Service Bus, sabe que llegará. Admite
12:22
Speaker 2: el ordenamiento por orden de llegada, la detección de duplicados
12:24
Speaker 2: y las transacciones. Si un mensaje no se procesa, pasa
12:27
Speaker 2: a una cola de mensajes fallidos donde puedes inspeccionarlo más tarde.
12:30
Speaker 2: Service Bus está diseñado para flujos de trabajo críticos como
12:33
Speaker 2: el procesamiento de pagos, el cumplimiento de pedidos y las
12:35
Speaker 2: cadenas de aprobación. Gestiona miles de mensajes por segundo, no millones.
12:38
Speaker 2: Y eso está bien porque cuando procesas un pago no
12:40
Speaker 2: necesitas millones de eventos por segundo. Necesitas que cada mensaje
12:43
Speaker 2: llegue exactamente una vez en el orden correcto. Event Hubs
12:46
Speaker 2: es la cámara de seguridad. Graba todo para su reproducción
12:48
Speaker 2: y análisis. Está diseñado para transmisiones de gran volumen, millones
12:52
Speaker 2: de eventos por segundo. Y varios consumidores pueden leer la
12:54
Speaker 2: misma transmisión de forma independiente. Los eventos quedan en el
12:57
Speaker 2: Hub días o semanas, así que puedes verlos si lo necesitas.
12:59
Speaker 2: Event Hubs no es para mensajería transaccional. Es para telemetría,
13:02
Speaker 2: canalizaciones analíticas y cualquier escenario en el que necesites ingerir
13:05
Speaker 2: cantidades masivas de datos y distribuirlos a múltiples consumidores. Entonces,¿
13:09
Speaker 2: cómo decides? Hazte tres preguntas.¿ Estás reaccionando a un cambio?¿
13:13
Speaker 2: Se cargó un blob?¿ Se creó una máquina virtual o
13:14
Speaker 2: un recurso cambio de estado? Eso es Event Hub.¿ Necesitas
13:18
Speaker 2: una entrega garantizada y un pedido estricto?¿ Procesar pagos?¿ Ejecutar
13:21
Speaker 2: flujos de trabajo?¿ Coordinar transacciones comerciales? Eso es Service Bus.¿
13:24
Speaker 2: Estás transmitiendo cantidades masivas de datos para análisis, telemetría de IoT,
13:27
Speaker 2: registros de aplicaciones, flujos de clics, detección de fraudes? Eso
13:31
Speaker 2: es Event Hub. Aquí está la clave. No tienes que
13:33
Speaker 2: elegir solo. Estos servicios funcionan juntos. Event Hub ingiere el
13:37
Speaker 2: flujo de datos sin procesar. Event Grid reacciona a los
13:39
Speaker 2: eventos dentro de ese flujo y activa acciones posteriores. Service
13:42
Speaker 2: Bus gestiona la mensajería confiable para los flujos de trabajo comercial.
13:45
Speaker 2: Utilízalos juntos y obtendrás lo mejor de ambos mundos. Hablemos
13:48
Speaker 2: del costo de ejecutar este tipo de canalización. Precios y niveles.
13:52
Speaker 2: Hablemos del coste, porque una cosa es saber lo que
13:54
Speaker 2: hace Event Hub y otra muy distinta, saber lo que cuesta.
13:56
Speaker 2: Event Hub tiene cuatro niveles y el más económico es
13:59
Speaker 2: el básico. Te ofrece un día de retención, funciones limitadas
14:02
Speaker 2: y el coste más bajo por unidad de rendimiento. Funciona
14:05
Speaker 2: para situaciones sencillas en las que no necesitas mucho, pero
14:07
Speaker 2: la mayoría de la gente se salta el básico y
14:08
Speaker 2: empieza con el estándar. El estándar es el punto ideal.
14:11
Speaker 2: Ofrece hasta 7 días de retención, Event Hubs Capture para
14:14
Speaker 2: archivo automático en almacenamiento, compatibilidad con Kafka y hasta 20
14:17
Speaker 2: grupos de consumidores. Esto cubre casi todas las cargas de
14:20
Speaker 2: trabajo de producción, así que si creas algo real, normalmente
14:22
Speaker 2: es aquí donde empiezas. Premium es un paso más. Obtienes
14:25
Speaker 2: 90 días de retención, 1 TB de almacenamiento por unidad
14:27
Speaker 2: de procesamiento, rendimiento predecible y compatibilidad con URANET para el
14:30
Speaker 2: aislamiento de área. Al reservar recursos, los vecinos ruidosos no
14:32
Speaker 2: te afectarán. Este nivel es para cargas de trabajo exigentes
14:35
Speaker 2: donde la latencia y el aislamiento importan. El nivel superior
14:38
Speaker 2: es el dedicado. Un clúster de inquilino único solo para
14:40
Speaker 2: ti con 10 TB por unidad de capacidad. Es para
14:42
Speaker 2: cargas de trabajo muy grandes en las que necesitas todo
14:44
Speaker 2: el entorno para ti. Sí es caro, pero si procesas
14:47
Speaker 2: volúmenes masivos de forma constante puede ser más rentable que
14:50
Speaker 2: escalar a un nivel premium. Esto es que impulse al coste.
14:53
Speaker 2: Cuatro cosas. Unidades de rendimiento que es la cantidad de
14:55
Speaker 2: datos que mueves, duración de la retención, cuánto tiempo conserva
14:59
Speaker 2: los eventos, captura, si archivamos en almacenamiento y georeplicación, si
15:02
Speaker 2: copiamos datos entre regiones para la recuperación ante desastres. Y
15:06
Speaker 2: tienes algunos consejos para optimizar los hubs. Empieza con el
15:09
Speaker 2: estándar y ampliálo, solo cuando lo necesites. Usa una retención
15:12
Speaker 2: corta para los datos activos. Manténlo en el hub por
15:14
Speaker 2: un par de días, luego pasa al almacenamiento barato como
15:16
Speaker 2: Blob o Data Lake para análisis a largo plazo. Supervisa
15:19
Speaker 2: el uso y rendimiento, ajusta tus unidades de procesamiento y
15:21
Speaker 2: no sobreprovisiones. Además, usa HTTP para los remitentes en lugar
15:25
Speaker 2: de AMQP, siempre que sea posible porque las conexiones AMQP
15:28
Speaker 2: tienen cargos y HTTP no. Ahora veamos una arquitectura sencilla
15:32
Speaker 2: para ver cómo empezar. Introducción a una arquitectura sencilla. El
15:36
Speaker 2: patrón básico es sencillo. Los productores envían eventos a Event
15:39
Speaker 2: Hubs y los consumidores los leen y los leen. Eso
15:42
Speaker 2: es todo.¿ Y tienes un ejemplo concreto? Imagina que los
15:44
Speaker 2: dispositivos IoT envían datos de temperatura a Event Hubs. Una
15:47
Speaker 2: función de Azure se activa con cada nuevo lote de
15:49
Speaker 2: eventos y posteriormente la función procesa todos los datos. Puede
15:52
Speaker 2: filtrar las lecturas que se encuentren dentro del rango normal,
15:54
Speaker 2: conservar solo las anomalías y a continuación escribir esas anomalías
15:56
Speaker 2: en Cosmos DB para realizar consultar. Se trata de una
15:58
Speaker 2: canalización completa en tres servicios. Lo bueno de las funciones
16:01
Speaker 2: es que se escalan automáticamente con el recuento de particiones.
16:04
Speaker 2: Si tienes ocho particiones, las funciones pueden generar hasta ocho instancias,
16:07
Speaker 2: cada una de las cuales lee.