Arquitectura de análisis en tiempo real: capas, patrones y compromisos
Arquitectura de análisis en tiempo real: capas, patrones y compromisos Una arquitectura de análisis en tiempo real mueve los eventos desde el lugar donde ocurren hasta donde alguien puede actuar sobre ellos de forma continua, en vez de esperar a un proceso nocturno.
Arquitectura de análisis en tiempo real: capas, patrones y compromisos
Una arquitectura de análisis en tiempo real mueve los eventos desde el lugar donde ocurren hasta donde alguien puede actuar sobre ellos de forma continua, en vez de esperar a un proceso nocturno. En la práctica, esto implica cuatro capas: ingesta, procesamiento de flujos, un almacén para servir los datos y una capa de consumo, como paneles, API o alertas. La parte difícil rara vez consiste en elegir herramientas. Consiste en decidir con qué rapidez debe estar disponible cada respuesta y pagar solo por ese nivel.
Esta guía explica las capas, los patrones Lambda y Kappa, las decisiones de diseño que causan problemas en producción y una forma de dimensionar correctamente la solución. Está dirigida a líderes empresariales, operativos y tecnológicos que patrocinarán o revisarán este tipo de sistema, no solo a los ingenieros que lo construirán.
Conclusiones clave
- Una arquitectura de streaming tiene cuatro capas: ingesta, procesamiento, servicio y consumo. La latencia se acumula en todas ellas, por lo que debe medirse de extremo a extremo.
- Parta de la decisión, no de la tecnología. Una comprobación de fraude y un panel de inventario necesitan niveles de actualización muy distintos, y la curva de costes es pronunciada.
- Kappa (una única canalización de streaming) encaja en la mayoría de los proyectos nuevos. Lambda (procesamiento por lotes más streaming) solo justifica su coste adicional cuando deben coexistir dos estándares de precisión.
- Los datos tardíos, la contrapresión, los cambios de esquema y la gobernanza son los factores que rompen los sistemas después del lanzamiento. Diseñe teniendo en cuenta estos aspectos desde el primer día.
- El dimensionamiento adecuado es mejor que el máximo. Muchos equipos necesitan minutos, no milisegundos.
Tabla de contenidos
- Qué es una arquitectura de análisis en tiempo real
- Las cuatro capas y cómo circulan los datos entre ellas
- Streaming frente a procesamiento por lotes: qué cambia realmente
- Lambda frente a Kappa: qué patrón encaja mejor
- Decisiones de diseño que determinan si la solución resistirá
- Un camino dimensionado correctamente desde la idea hasta producción
- Cómo ayuda Ridiculous Engineering
- Preguntas frecuentes
- Fuentes
Qué es una arquitectura de análisis en tiempo real
Los sistemas por lotes recopilan datos, esperan a un proceso programado y publican los resultados horas más tarde. Un sistema en tiempo real trata los datos como un flujo continuo: cada evento se captura, se procesa y queda disponible para consultas en cuestión de segundos o menos. La guía de análisis de AWS Well-Architected describe los componentes principales de un diseño de streaming como fuentes de datos, ingesta de flujos y productores (por ejemplo, captura de datos de cambios o Kafka Connect), almacenamiento de flujos (por ejemplo, Kafka o Kinesis), procesamiento de flujos (por ejemplo, Flink o Spark) y destinos posteriores, tal como se expone en su arquitectura de referencia de streaming.
Esta lista es una lista de comprobación útil para una primera sesión de pizarra. Si la propuesta de un proveedor omite alguna de estas casillas, pregunte dónde se asume esa responsabilidad.
«Tiempo real» es un término empresarial antes que técnico
Nadie necesita que todo ocurra en milisegundos. Una comprobación de fraude en un pago puede necesitar una respuesta en bastante menos de un segundo. Una vista del inventario de un almacén puede resultar perfectamente útil si se actualiza cada pocos minutos. Es posible que un informe ejecutivo semanal no necesite streaming en absoluto.
Antes de elaborar cualquier diagrama de arquitectura, anote para cada caso de uso:
- La decisión o acción que respaldan los datos.
- Quién o qué lleva a cabo esa acción (una persona, una aplicación o una regla automatizada).
- Cuánto pueden estar desactualizados los datos antes de que la decisión empeore.
- Cuánto cuesta una respuesta incorrecta o incompleta.
Estas cuatro respuestas establecen su presupuesto de latencia. Todo lo que aparece a continuación está diseñado para cumplirlo, no para superarlo.
Las cuatro capas y cómo circulan los datos entre ellas
1. Ingesta: capturar y almacenar en búfer
Los eventos proceden de bases de datos de aplicaciones, clics de usuarios, sistemas de pago, sensores del Internet de las cosas (IoT), registros y API de terceros. La ingesta los captura de forma fiable y los coloca en un medio duradero. Dos enfoques habituales:
- Publicación de eventos desde las aplicaciones. La aplicación emite un evento de negocio («pedido realizado») a un flujo. La semántica es clara, pero requiere cambios en el código de la aplicación.
- Captura de datos modificados (CDC). Un conector lee el registro de cambios de la base de datos y publica cada inserción o actualización. Es menos invasivo para los sistemas heredados, por eso aparece con tanta frecuencia en proyectos de modernización.
El búfer importa tanto como la captura. Una plataforma de streaming funciona como un registro distribuido de solo anexado, en el que los eventos se conservan durante un periodo configurable, desde horas hasta meses o incluso indefinidamente, y permanecen disponibles para que cualquier consumidor los lea, tal como describe una guía del sector sobre aplicaciones de análisis en tiempo real . Esa retención permite reproducir el historial después de corregir un error o añadir más adelante un consumidor nuevo sin tocar el sistema de origen. Si desea una visión de ingeniería más profunda de esta capa, nuestra guía práctica sobre el streaming de eventos con Kafka abarca los temas, las particiones y las garantías de entrega.
2. Procesamiento: validar, enriquecer y agregar
La capa de procesamiento convierte los eventos sin procesar en algo útil: los valida, los combina con datos de referencia, calcula totales acumulados, detecta patrones o les asigna una puntuación mediante un modelo. La orientación de Microsoft sobre cómo elegir una tecnología de procesamiento de flujos señala que la decisión suele depender de si necesita un procesamiento con estado o sin estado y de si necesita ventanas temporales, ya sean de tipo tumbling (fijas y no superpuestas) o sliding (superpuestas), para las agregaciones basadas en el tiempo.
En términos sencillos:
- Sin estado El trabajo (filtrado, análisis sintáctico y transformaciones simples) es económico y fácil de escalar.
- Con estado El trabajo («número de inicios de sesión fallidos por usuario en los últimos cinco minutos») debe recordar información, lo que afecta a la memoria, la recuperación y el coste.
- Ventanas Definen «los últimos cinco minutos» y es donde se producen la mayoría de las sorpresas relacionadas con la corrección.
3. Servicio: un almacén diseñado para la consulta
Los datos procesados se almacenan en un sistema adaptado a la forma en que se consultarán. No existe una única respuesta correcta:
| Patrón de acceso | Opción habitual para servir los datos | Motivo |
|---|---|---|
| Segmentación ad hoc y paneles sobre datos actualizados | Almacén analítico (OLAP) o tablas de lakehouse | Agregaciones rápidas sobre grandes volúmenes |
| Consultas por cliente o por elemento desde una aplicación | Almacén de clave-valor o de documentos | Lecturas de un solo registro con baja latencia |
| Análisis histórico y reciente combinado | Lakehouse con streaming y procesamiento por lotes sobre las mismas tablas | Una única copia de los datos |
Para el caso de las consultas, la escenario de referencia de lakehouse en tiempo casi real de Microsoft desnormaliza los datos en un almacén NoSQL, como Azure Cosmos DB, para admitir respuestas de API en milisegundos de un solo dígito. Para el caso del lakehouse, el mismo escenario utiliza Delta Lake, que proporciona semántica ACID y un procesamiento unificado de streaming y por lotes sobre un lago de datos.
El principio de diseño: adaptar los datos al lector. Preagregar y desnormalizar en el momento de la escritura es lo que permite acelerar las lecturas.
4. Consumo: paneles, API, alertas y modelos
Aquí es donde la empresa percibe el valor y donde más difieren los requisitos de latencia. Una pantalla de operaciones en directo, una métrica visible para los clientes dentro de su producto, una alerta para un responsable de guardia y un flujo de características para un modelo de aprendizaje automático leen de la capa de servicio de maneras distintas. Planifique primero los consumidores y trabaje hacia atrás.
Un panel en el que nadie confía o que nadie entiende desperdicia todo el trabajo de la canalización. Las personas que consultan datos en directo también necesitan saber interpretarlos, por eso algunas organizaciones acompañan la implementación de una plataforma con un curso de analítica web para los analistas y responsables que trabajarán habitualmente con los paneles. Nuestra guía sobre analítica de autoservicio profundiza en cómo hacer que esa última etapa funcione.
La latencia es la suma de todas las etapas
Es tentador comparar el rendimiento del motor de procesamiento y dar el trabajo por terminado. Sin embargo, la latencia integral es el total de la captura, el tránsito por la red, el almacenamiento en búfer, el procesamiento, la escritura en el almacén, el tiempo de consulta y la actualización del panel. Instrumente cada salto con marcas de tiempo desde el primer día. Cuando una parte interesada diga «el panel parece lento», querrá saber qué etapa consumió esos segundos.
Streaming frente a procesamiento por lotes: qué cambia realmente
Más allá de la frescura de los datos, los dos modelos implican compromisos de ingeniería distintos. Las investigaciones sobre el tema señalan que los motores de streaming afrontan compromisos entre latencia y rendimiento: confirmar los mensajes uno a uno para garantizar la entrega añade sobrecarga y es menos eficiente que procesarlos por lotes, según el análisis de Jimmy Lin sobre las arquitecturas Lambda y Kappa publicado por IEEE.
Esto tiene consecuencias prácticas para la planificación:
- El streaming cuesta más por registro que el procesamiento por lotes cuando se ejecuta las 24 horas. Si una actualización cada hora satisface la decisión, el procesamiento por lotes es la respuesta honesta.
- El streaming obliga a gestionar aspectos que el procesamiento por lotes oculta: eventos desordenados, entregas duplicadas y resultados parciales.
- Las operaciones cambian. Un trabajo nocturno que falla puede volver a ejecutarse por la mañana. Un flujo que se detiene a las 2 de la madrugada es un incidente.
Un enfoque híbrido es lo habitual. Muchas empresas procesan mediante streaming el 10 % de los datos que impulsan decisiones sensibles al tiempo y dejan el resto para el procesamiento por lotes.
Lambda frente a Kappa: qué patrón encaja
Estos dos nombres aparecen en casi todas las revisiones de arquitectura, por lo que conviene ser precisos.
Lambda fue propuesta por Nathan Marz alrededor de 2011. Ejecuta una capa de procesamiento por lotes y una capa transitoria en tiempo real en paralelo, con una capa de combinación que integra sus resultados. La capa de procesamiento por lotes proporciona respuestas precisas y completas con el tiempo. La capa de velocidad proporciona respuestas aproximadas de inmediato.
Kappa fue propuesta por Jay Kreps en una publicación de blog de 2014. Utiliza un único motor de procesamiento de streams para todos los datos y evita la complejidad de la doble canalización de Lambda. Los datos históricos se vuelven a procesar reproduciendo el registro mediante el mismo código. Ambas descripciones proceden del artículo de Lin.
La disyuntiva real
| Lambda | Kappa | |
|---|---|---|
| Canalizaciones que hay que crear y ejecutar | Dos (por lotes y streaming) | Una |
| Lógica de negocio | A menudo se escribe dos veces y debe mantenerse sincronizada | Se escribe una vez |
| Reprocesamiento histórico | Trabajo por lotes | Reproducción desde el registro |
| Carga operativa | Mayor | Más bajo, pero necesita una retención duradera de los registros |
| Es mejor cuando | Distintos estándares de precisión para distintos consumidores | Un estándar coherente para todos los consumidores |
La lógica duplicada es el coste real de Lambda. Cuando dos bases de código calculan los «ingresos», acabarán discrepando y alguien pasará una semana averiguando por qué.
Nuestra recomendación para la mayoría de los sistemas nuevos: empiece adoptando un enfoque Kappa. Mantenga un registro de eventos duradero, escriba la lógica una sola vez y vuelva a reproducirla cuando necesite corregir el historial. Añada una ruta de procesamiento por lotes independiente solo cuando tenga un motivo documentado, como el requisito de que la facturación sea exacta mientras un panel de operaciones tolere pequeños errores. Las tablas modernas de lakehouse que gestionan streaming y procesamiento por lotes sobre los mismos datos reducen aún más la diferencia, porque obtiene una sola capa de almacenamiento con dos formas de leerla.
Decisiones de diseño que determinan si resistirá
El diagrama parece el mismo en todos los proyectos. Las diferencias importantes se indican a continuación.
Datos tardíos y desordenados
Los eventos no llegan en el orden en que ocurrieron. Los dispositivos móviles se desconectan, las redes se ralentizan y los sistemas ascendentes reintentan las operaciones. Los procesadores de streams gestionan esto mediante marcas de agua: una estimación móvil del progreso del tiempo de los eventos, que se utiliza para decidir cuándo una ventana está suficientemente completa para publicarse.
La disyuntiva es directa. Una marca de agua ajustada publica los resultados rápidamente, pero descarta o gestiona incorrectamente los eventos rezagados. Una más holgada espera más tiempo, mejora la integridad, pero aumenta el retraso y el estado que el sistema debe conservar. Elija el valor a partir de la tardanza observada en sus datos reales, no de un valor predeterminado. Después, decida explícitamente qué ocurre con los eventos que llegan una vez cerrada la ventana: descartarlos, dirigirlos a una ruta de corrección o actualizar el resultado.
Control de presión y durabilidad
¿Qué ocurre cuando un almacén de datos descendente se ralentiza? Sin un plan, la respuesta es la pérdida de datos o un fallo en cascada. Una buena canalización almacena temporalmente los datos en el registro duradero, ralentiza a los productores o escala los consumidores y avisa a alguien, en lugar de descartar registros silenciosamente. Pida a su equipo que lo demuestre ralentizando deliberadamente un consumidor en un entorno de pruebas.
Garantías de entrega
«Exactamente una vez» es el objetivo para todo lo relacionado con las finanzas o el inventario, pero es una propiedad de toda la canalización, no de un solo componente. Cuando no se pueda garantizar de extremo a extremo, diseñe las escrituras para que sean idempotentes, de modo que un evento reproducido no se contabilice dos veces.
Cambio de esquema y calidad de los datos
Los productores cambian los formatos de sus eventos, normalmente sin previo aviso. Utilice un registro de esquemas, valide los datos durante la ingesta y envíe los registros incorrectos a un stream de cuarentena con una alerta, en lugar de dejar que contaminen las tablas descendentes. La misma disciplina que aplica a las versiones de la aplicación se aplica aquí: nuestro artículo sobre CI/CD para canalizaciones de datos muestra cómo las comprobaciones de esquemas condicionadas a las solicitudes de incorporación de cambios detectan cambios incompatibles antes de que lleguen a producción.
Seguridad y gobernanza
El streaming no le exime de la gobernanza. De hecho, eleva las exigencias, ya que los datos se mueven más rápido de lo que puede revisarlos una persona manualmente. Considere el control de acceso, el cifrado, la retención, el linaje y la propiedad de los esquemas como parte de la arquitectura, especialmente en entornos regulados como la sanidad, las finanzas y la administración pública, donde la gobernanza debe funcionar al mismo ritmo que los datos. Decida quién es responsable de cada tipo de evento, quién puede leerlo y durante cuánto tiempo se conserva antes de que fluya el primer evento.
Lleve la inteligencia al extremo cuando permita ahorrar dinero
En el caso de cámaras, sensores y máquinas que producen grandes volúmenes de datos, filtre y ejecute la inferencia localmente y envíe aguas arriba solo los agregados o las excepciones. Esto reduce el ancho de banda y el gasto en la nube, y acorta el tiempo de respuesta de las acciones locales.
Una ruta dimensionada adecuadamente desde la idea hasta producción
La mayoría de los proyectos de tiempo real que fracasaron no eligieron la tecnología equivocada. Intentaron transmitirlo todo de una vez. Una secuencia que funciona:
- Elija una decisión. Por ejemplo, marque los pedidos estancados en un plazo de dos minutos o muestre los niveles de existencias en directo por almacén. Defina el presupuesto de latencia y el coste de una respuesta incorrecta.
- Trace las fuentes. ¿Qué sistemas contienen los eventos? ¿Puede publicarlos o necesita CDC? ¿Cuáles de estos sistemas son lo bastante antiguos como para dificultarlo?
- Construya el tramo vertical más reducido posible. Una fuente, un trabajo de procesamiento, un almacén de servicio y un consumidor, con instrumentación del tiempo de extremo a extremo.
- Añada las rutas de fallo. Datos tardíos, reproducción, cuarentena, alertas y un manual de operaciones para el stream detenido.
- Mida el resultado. ¿Mejoró la decisión? ¿Menos roturas de stock, retenciones por fraude más rápidas o tiempos de respuesta más cortos? Si la cifra no cambia, deténgase antes de escalar.
- Amplíe de forma deliberada. Añada fuentes y consumidores de uno en uno, reutilizando la plataforma.
La justificación empresarial se aborda en nuestra visión general de por qué los datos en tiempo real cambian la forma en que operan las empresas. En resumen: el beneficio proviene de tomar decisiones más rápido, no de la tecnología de streaming en sí.
Desarrollar, comprar o combinar
Los servicios en la nube gestionados reducen el trabajo operativo, pero aumentan la dependencia del proveedor y los costes recurrentes. Los motores de código abierto ofrecen control, pero requieren personal que los opere. El código personalizado que se construye alrededor de cualquiera de las dos opciones es donde viven la lógica de su negocio y sus diferencias competitivas. La combinación adecuada depende del tamaño de su equipo, sus necesidades de cumplimiento normativo y cuántos sistemas deben conectarse. Desconfíe de cualquier enfoque que no pueda explicar qué ocurre a las 2:00 cuando algo falla.
Cómo ayuda Ridiculous Engineering
Diseñamos y construimos las piezas que conectan su problema de negocio con un sistema operativo: ingesta de eventos de fuentes heredadas y modernas, canalizaciones de procesamiento, almacenes de datos para servir información y los paneles y las aplicaciones que se apoyan en ellos. Nuestro trabajo de analítica de datos e inteligencia empresarial comienza con la decisión que necesita mejorar y la latencia que realmente requiere; después dimensionamos la arquitectura para adaptarla. Cuando el consumidor es una aplicación o un flujo de trabajo, nuestro equipo de desarrollo de software personalizado construye esa parte con los mismos ingenieros sénior, y nuestro trabajo de desarrollo de IA y automatización abarca los modelos y las acciones automatizadas alimentadas por datos en tiempo real. El precio depende del alcance, por lo que el siguiente paso es conversar sobre su caso de uso y elaborar un presupuesto.
Preguntas frecuentes
¿Cuál es la diferencia entre la analítica en tiempo real y la analítica de streaming?
En el uso cotidiano, los términos se solapan. El streaming describe la técnica: procesar eventos continuamente a medida que llegan. El tiempo real describe el resultado: datos lo bastante recientes como para actuar dentro de un plazo que usted define. Puede transmitir datos y aun así ofrecer resultados cada pocos minutos, lo que suele ser suficiente para las necesidades de la empresa.
¿Debería elegir Lambda o Kappa?
Para la mayoría de los sistemas nuevos, empiece con Kappa: una única canalización de streaming, lógica escrita una sola vez y un historial que se vuelve a procesar reproduciendo un registro duradero. Elija Lambda solo cuando dos consumidores necesiten garantías de precisión diferentes, como cifras exactas de facturación junto con un panel en tiempo real tolerante a cierta imprecisión. Sopese esta opción frente al coste de mantener dos rutas de código.
¿Qué velocidad necesita mi sistema?
Parta de la decisión y trabaje hacia atrás. Una comprobación de fraude puede requerir respuestas en menos de un segundo, mientras que un panel de inventario o ventas puede funcionar bien actualizándose cada pocos minutos. Cada reducción de la latencia aumenta el coste y el esfuerzo operativo, así que establezca el objetivo a partir del valor de la decisión, no de lo que pueden hacer las herramientas.
¿Necesitamos Kafka?
No siempre. Un registro de eventos duradero que pueda reproducirse es la capacidad importante, y Kafka es una forma habitual de obtenerla. Si su volumen es moderado y sus fuentes son pocas, puede bastar con un servicio de streaming gestionado o incluso con microprocesamientos por lotes frecuentes. Nuestra guía de Kafka para ingenieros puede ayudarle a decidir.
¿Qué suele fallar con más frecuencia después del lanzamiento?
Las causas habituales son los cambios de esquema en los sistemas de origen, los eventos tardíos o duplicados y los almacenes de destino lentos que generan contrapresión. La validación durante la ingesta, las escrituras idempotentes, una ruta de cuarentena para los registros incorrectos y las alertas sobre el retraso solucionan la mayoría de estos problemas.
Fuentes
- Arquitectura de referencia, Data Analytics Lens (AWS Well-Architected)
- Elija una tecnología de procesamiento de streams (Microsoft Learn)
- Procesamiento de datos de lakehouse casi en tiempo real (Microsoft Learn)
- Lambda y Kappa (Jimmy Lin, IEEE 2017)
- Creación de aplicaciones de analítica en tiempo real
- Curso de formación en analítica web