Saltar al contenido

Analizar-luego-tienda: El viaje a la inteligencia continua – Parte 4

1 de septiembre de 2020

Una serie de artículos técnicos para arquitectos de datos

Esta serie de artículos en varias partes está destinada a los arquitectos de datos y a cualquier persona interesada en aprender a diseñar soluciones modernas de análisis de datos en tiempo real. Explora los principios e implicaciones clave de la transmisión de eventos y el análisis de flujo, y concluye que la mayor oportunidad de obtener un valor significativo de los datos -y obtener una inteligencia continua sobre el estado de las cosas- reside en la capacidad de analizar, aprender y predecir a partir de eventos en tiempo real en concierto con datos contextuales, estáticos y dinámicos. Esta serie de artículos sitúa la inteligencia continua en un contexto arquitectónico, con referencia a las tecnologías establecidas y a los casos de uso en vigor hoy en día.

Parte 4: El análisis de la transmisión ayuda

La transmisión de eventos es un útil desacoplador entre el mundo real y las aplicaciones, pero el almacenamiento y las colas introducen retrasos impredecibles. Y si seguimos el típico enfoque de «procesador de flujo» que se basa en instancias de microservicios sin estado, el desarrollador debe usar una base de datos para representar el estado de la aplicación. Esto obviamente introduce más retrasos. Los desarrolladores de aplicaciones quieren entregar resultados significativos – desde el análisis, el aprendizaje y la predicción – a escala, de forma continua, en respuesta a las continuas actualizaciones transmitidas en los eventos. Los retrasos variables en las capas de aplicación e infraestructura son un gran problema.


Recomendado: ¿Qué es el Big data?.


El campo de la analítica de flujo tiene una visión «de arriba hacia abajo» de este desafío y puede servir para casos de uso que no exigen una respuesta en tiempo real. Más conocido por ofrecer vistas de widgets y KPIs, las aplicaciones de análisis de streaming periódicamente (o cuando se les da un empujón a través de una GUI) computan las percepciones y entregan resultados a los usuarios. Muchos En esta categoría existen instrumentos de uso general e integrados verticalmente. En el extremo específico de la escala: el proyecto de código abierto Prometheius proporciona una infraestructura para la gestión del rendimiento de las aplicaciones, en la nube. Un sencillo esquema permite que una base de datos de series cronológicas capte un registro de las métricas de rendimiento para muchos casos y una simple interfaz de usuario en Grafana u otro conjunto de herramientas puede consultar la base de datos y dibujar fantásticos widgets para los administradores. Este caso de uso es un subconjunto simple y muy limitado de los casos de uso de la inteligencia continua: Los widgets de resumen también deben evolucionar en tiempo real.

Los administradores de grandes sistemas, ya sean contenedores en la nube o flotas de camiones, necesitan métricas de rendimiento detalladas y específicas para sus casos de uso. Están centrados en las operaciones y en los resultados – quieren «acercarse» a los problemas para verlos – a menudo en tiempo real. El que significa de datos es fundamental para comprender el rendimiento del sistema. Así, mientras que los sistemas de streaming de eventos no imponen ningún significado a los eventos, en el análisis de streaming el significado de un evento es siempre bien definido: «cuestiones» y «problemas» son abreviaturas de «conocimientos técnicos ganados con esfuerzo y codificados en una aplicación».

Sin embargo, los gerentes no son los únicos usuarios: Las aplicaciones modernas de SaaS deben dar respuestas contextualmente útiles a los usuarios finales. Las respuestas oportunas, granulares, personalizadas y locales son cruciales, incluso para las aplicaciones a escala masiva. Este tipo de capacidad está totalmente fuera del alcance de las aplicaciones de análisis de flujo.

El significado de los datos es crucial tanto para los sistemas que generan eventos («temperatura»: 5″ podría significar que la temperatura es de 5 grados, o que aumentó en 5 grados) y en el contexto de un modelo del sistema en su conjunto (así: «si la temperatura en los sensores cercanos también aumenta, y los niveles de refrigerante son bajos, esto podría causar un incendio»). Por lo general, un modelo de sistema se expresa como un conjunto de relaciones entre entidades (un esquema en una base de datos relacional o un gráfico de relaciones entre entidades en una base de datos gráfica). De cualquier manera, no hay forma de escapar a la necesidad de una riqueza semántica, modelo de estado de la sistema que evoluciona a lo largo del tiempo en respuesta a los cambios de estado comunicados por los acontecimientos, y lógica de aplicación que interpreta esos cambios a medida que se producen.

Tenemos que diferenciar entre datos y estado. El análisis, ya sea lógico o matemático, evalúa / predice / modifica el estado de una o más entidades, dados los datos brutos del evento (un semáforo es simplemente verde, incluso si envía un evento de «Estoy verde» cada 100ms). La confusión entre los datos y el estado está en el corazón de muchos desafíos que los ingenieros de aplicaciones enfrentan hoy en día.

Para abordar este problema, las aplicaciones analíticas de streaming utilizan un esquema o modelo definido del sistema, combinado con la lógica de negocio para traducir los datos del evento en cambios de estado en el modelo del sistema. Un solo evento podría desencadenar cambios de estado para muchas entidades (por ejemplo: el autobús llega, así que muchos pasajeros pueden subir). El significado de los cambios de estado desencadenados por los eventos es la parte de la «lógica empresarial» de una aplicación y tiene una interpretación específica dado el caso de uso. Por este motivo, las aplicaciones de análisis de flujo suelen ser específicas de un dominio (por ejemplo, en la gestión del rendimiento de las aplicaciones), o están diseñadas para un propósito específico de negocio, en el que cambiar el esquema o los casos de uso significa cambiar (mucho) el código.

Pero los usuarios quieren una inteligencia continua

Las empresas quieren rastrear, analizar, aprender y predecir en base a datos de eventos en vivo de todos sus sistemas y en cada momento. Quieren desarrollar, desplegar y operar fácilmente aplicaciones que ofrezcan respuestas contextuales y en tiempo real a eventos en vivo. Y a medida que sus sistemas crecen, debe garantizarse la capacidad de una aplicación para ofrecer respuestas en tiempo real a la transmisión continua de datos a escala. Necesitan entregar respuestas en tiempo real y conducir la automatización a nivel local, a cualquier usuario o sistema, en cualquier momento.

Es difícil construir una aplicación que proporcione continuamente información en tiempo real a partir de datos de flujo y contextuales. Hay dos desafíos principales:

  • Las arquitecturas de las aplicaciones de microservicios sin estado y respaldadas por bases de datos hacen imposible dar respuestas en tiempo real.
  • El análisis de los datos de transmisión sobre la marcha exige cambios en los algoritmos analíticos tradicionales que funcionan con conjuntos de datos completos.
  • Las cosas se ponen aún más difíciles cuando se procesan datos de flujo en conjunto con datos contextuales de fuentes de datos estáticos. Con un volumen de datos suficiente, las bases de datos no podrán seguir el ritmo.

El análisis, el aprendizaje, la predicción y otras percepciones dependen de poderosos operadores como uniones, mapas, reducciones, uniones, intersecciones y productos cartesianos, y una gran cantidad de funciones matemáticas y otros algoritmos como el aprendizaje de la máquina. Una evaluación de algún predicado debe ocurrir para cada evento que pueda cambiar de estado, en cada contexto relevante. Eso parece pesado, así que tomémoslo con calma.

Cada evento que llega debe ser analizado en el contexto del estado de la entidad que lo generó, y los estados de todas las demás entidades que están relacionadas con él y su contexto. El contexto cambia rápidamente: Un autobús puede estar «cerca» de una parada de autobús pero luego se aleja rápidamente. No tiene sentido decirle a un pasajero que el autobús se está acercando a una parada cuando ya ha partido, por lo que el análisis tiene que ser oportuno para ser útil. El análisis (por ejemplo: «cerca» – un cálculo afín de geo-cercas) debe ser reevaluado para cada nuevo evento de relevancia en el contexto del pasajero, la parada de autobús y el autobús, y potencialmente todos los demás vehículos y peatones en la vecindad, para cada autobús, simultáneamente. Cada acontecimiento podría afectar no sólo a la entidad prevista, sino a cualquier otra entidad en su vecindad.

Para una respuesta en tiempo real, el análisis debe ser ejecutado al menos tan rápido como llegan los nuevos eventos. Si el análisis es más lento que en tiempo real, los resultados serán inútiles y la aplicación se retrasará rápidamente – los eventos podrían ser dejados de lado o retrasados, y las inexactitudes se multiplicarán. Es fácil ver cómo en un modelo con millones de entidades, cada una en su contexto, el significado contextual de los eventos puede causar retrasos en cascada e impactos en el rendimiento que no pueden ser resueltos con más hardware.

Hay un último desafío: Un evento que se analiza en el contexto inmediato en el que se generó también afectará a todos los demás contextos con un grado de detalle menor (a medida que nos alejamos). Por ejemplo: Un pasajero que sube a un autobús afecta al autobús y al pasajero (el número de asientos libres disminuye en el autobús, y la velocidad y la ruta del pasajero cambian) pero también afecta a un KPI a un nivel más alto, aumentando el número de pasajeros actualmente en todos los autobuses de la ciudad. Por lo tanto, los casos de uso del análisis de flujo son un subconjunto de la inteligencia continua en la medida en que se requiere una visión en tiempo real del sistema. Pero lo más importante es que cada evento causa naturalmente una cascada de reevaluaciones a través del modelo del sistema.

Swim reimagina toda la pila de software para resolver los problemas que requieren aplicaciones basadas en datos a escala para ofrecer respuestas en tiempo real, de forma continua y en contexto.

Para leer las partes 1 a 3 de esta serie de artículos de invitados, por favor visite el blog Swim.

Sobre el autor

Simon Crosby es CTO en Swim. Swim ofrece el primer núcleo abierto, plataforma de grado empresarial para la inteligencia continua a escala, proporcionando a las empresas una completa conciencia de la situación y apoyo a la decisión operativa en todo momento. Simon cofundó Bromium (ahora HP SureClick) en 2010 y actualmente se desempeña como asesor estratégico. Anteriormente, fue el CTO de la División de Centro de Datos y Nube de Citrix Systems; fundador, CTO y vicepresidente de estrategia y desarrollo corporativo de XenSource; y un ingeniero principal de Intel, así como miembro de la facultad de la Universidad de Cambridge, donde dirigió la investigación sobre el rendimiento y control de la red y los sistemas operativos multimedia.

Simon es un socio de capital en DCVC, es miembro de la junta de Cambridge en América, y es un inversor y asesor de numerosas empresas de nueva creación. Es autor de 35 trabajos de investigación y patentes sobre varios temas de centros de datos y redes, incluyendo seguridad, virtualización de redes y servidores, y optimización de recursos y rendimiento. Tiene un doctorado en informática de la Universidad de Cambridge, una maestría de la Universidad de Stellenbosch, Sudáfrica, y una licenciatura (con honores) en informática y matemáticas de la Universidad de Ciudad del Cabo, Sudáfrica.