Agentes de mensajes tradicionales y datos de transmisión

7

Según el sitio Kafka :

  

" Kakfa se utiliza para crear canales de datos en tiempo real y aplicaciones de transmisión. "

Al buscar en Internet a lo largo y ancho, he encontrado la siguiente definición generalmente aceptada de lo que " transmisión de datos " es:

  • Los datos de transmisión son datos que fluyen de forma contigua desde un origen a un destino a través de una red; y
  • Los datos de flujo no son no de naturaleza atómica, lo que significa que cualquier parte de un flujo de datos es significativo y procesable, a diferencia de un archivo cuyos bytes no significan nada a menos que los tenga todos ; y
  • Los datos de transmisión pueden iniciarse / detenerse en cualquier momento; y
  • Los consumidores pueden adjuntar y desprenderse de un flujo de datos a voluntad, y procesar solo las partes que deseen

Ahora bien, si algo de lo que dije arriba es incorrecto, incompleto o totalmente incorrecto, ¡por favor comience a corregirme! Suponiendo que estoy más o menos encaminado, entonces ...

Ahora que entiendo qué es la "transmisión de datos", entonces entiendo qué quieren decir Kafka y Kinesis cuando se facturan a sí mismos como middleware de procesamiento / intermediación para aplicaciones con transmisión de datos. Pero ha despertado mi interés: ¿se puede / debería usar "middleware" como Kafka o Kinesis para datos que no se transmiten, como los agentes de mensajes tradicionales? Y viceversa: ¿se pueden / deben usar MQ tradicionales como RabbitMQ, ActiveMQ, Apollo, etc. para transmitir datos?

Tomemos un ejemplo en el que una aplicación enviará un aluvión constante de backend de mensajes JSON que deben procesarse, y el procesamiento es bastante complejo (validación, transformación de los datos, filtrado, agregaciones, etc.):

  • Caso # 1: Los mensajes son cada fotograma de una película; es una mensajería JSON por fotograma de video que contiene los datos de fotograma y algunos metadatos de soporte
  • Caso # 2: Los mensajes son datos de series de tiempo, quizás el latido del corazón de alguien en función del tiempo. Así que el mensaje # 1 se envía representando mi latido en t = 1, el mensaje # 2 contiene mi latido en t = 2, etc.
  • Caso # 3: Los datos son completamente dispares y no están relacionados por tiempo o como parte de cualquier "flujo de datos". Tal vez eventos de auditoría / seguridad que se activan cuando cientos de usuarios navegan por la aplicación haciendo clic en los botones y realizando acciones

En función de cómo se facturan a Kafka / Kinesis y de mi comprensión de qué es la "transmisión de datos", parecen ser candidatos obvios para los Casos # 1 (datos de video contiguos) y # 2 (datos de series de tiempo contiguas). Sin embargo, no veo ninguna razón por la que un intermediario de mensajes tradicional como RabbitMQ no pueda manejar estas dos entradas de manera eficiente.

Y con el Caso # 3, solo se nos proporciona un evento que ha ocurrido y necesitamos procesar una reacción a ese evento. Así que para mí esto significa que se necesita un corredor tradicional como RabbitMQ. Pero tampoco hay razón por la que Kafka o Kinesis no puedan manejar el procesamiento de los datos de eventos.

Básicamente, estoy buscando establecer una rúbrica que diga: Tengo datos X con características Y. Debería usar un procesador de flujo como Kafka / Kinesis para manejarlo. O, a la inversa, uno que me ayude a determinar: Tengo datos W con características Z. Debería usar un intermediario de mensajes tradicional para manejarlo.

Entonces, pregunto: ¿Qué factores sobre los datos (o de otra manera) ayudan a tomar la decisión entre el procesador de flujo o el intermediario de mensajes, ya que ambos pueden manejar datos de transmisión y ambos pueden manejar datos de mensajes (no de transmisión)?

    
pregunta smeeb 07.06.2017 - 05:31

2 respuestas

3

Kafka se ocupa de los registros ordenados de los mensajes atómicos. Puede verlo como el modo pub/sub de los intermediarios de mensajes, pero con un orden estricto y la capacidad de reproducir o buscar en la corriente de mensajes en cualquier momento en el pasado que aún se conserva en el disco (lo que podría ser para siempre) .

El sabor de la transmisión de Kafka se opone a llamada a procedimiento remoto como Thrift o HTTP, y a procesamiento por lotes como en el ecosistema de Hadoop. A diferencia de RPC, los componentes se comunican de forma asíncrona: pueden pasar horas o días entre el momento en que se envía un mensaje y cuando el destinatario se despierta y actúa sobre él. Podría haber muchos destinatarios en diferentes momentos, o tal vez nadie se molestará en consumir un mensaje. Múltiples productores podrían producir el mismo tema sin el conocimiento de los consumidores. Kafka no sabe si está suscrito o si se ha consumido un mensaje. Simplemente se confirma un mensaje en el registro, donde cualquier parte interesada puede leerlo.

A diferencia del procesamiento por lotes, le interesan los mensajes individuales, no solo las colecciones gigantes de mensajes. (Aunque no es infrecuente archivar mensajes de Kafka en archivos de Parquet en HDFS y consultarlos como tablas de Hive).

Caso 1 : Kafka no conserva ninguna relación temporal particular entre el productor y el consumidor. Es un mal ajuste para la transmisión de video porque Kafka puede disminuir la velocidad, acelerar, adaptarse y comenzar, etc. Para los medios de transmisión, queremos intercambiar el rendimiento general a cambio de bajo y, lo que es más importante, estable latencia (también conocida como baja fluctuación de fase). Kafka también hace grandes esfuerzos para no perder nunca un mensaje. Con la transmisión de video, usualmente usamos UDP y estamos contentos de soltar un cuadro aquí y allá para mantener el video en funcionamiento. El SLA en un proceso respaldado por Kafka suele ser de segundos a minutos cuando está sano, de horas a días cuando está sano. El SLA en transmisión de medios está en decenas de milisegundos.

Netflix podría usar Kafka para mover fotogramas en un sistema interno que transcodifica terabytes de video por hora y los guarda en el disco, pero no para enviarlos a su pantalla.

Caso 2 : Absolutamente. Usamos Kafka de esta manera en mi empleador.

Caso 3 : puede usar Kafka para este tipo de cosas, y nosotros lo hacemos, pero está pagando algunos gastos generales innecesarios para conservar el pedido. Como no le importa el orden, probablemente podría exprimir un poco más el rendimiento de otro sistema. Sin embargo, si su compañía ya mantiene un clúster Kafka, probablemente sea mejor reutilizarlo en lugar de asumir la carga de mantenimiento de otro sistema de mensajería.

    
respondido por el closeparen 07.06.2017 - 06:46
3

Kafka / Kinesis se modela como una secuencia. Una secuencia tiene propiedades diferentes a las de los mensajes.

  • Las corrientes tienen contexto para ellos. Tienen orden. Puede aplicar funciones de ventana en secuencias. Aunque cada elemento en una secuencia es significativo, puede ser más significativo con el contexto que lo rodea
  • Debido a que las secuencias tienen orden, puede usar eso para hacer ciertas afirmaciones sobre la semántica del procesamiento. P.ej. Supuestamente, Apache Trident tiene una sola semántica cuando se consume de un flujo Kafka.
  • Puede aplicar funciones a las secuencias. Puedes transformar una corriente sin consumirla realmente. Usted puede consumir perezosamente una corriente. Puede omitir partes de un flujo.
  • Puede reproducir secuencias de forma inherente en Kafka, pero no puede (sin software adicional) reproducir las colas de mensajes. Esto es útil cuando aún no sabe qué quiere hacer con los datos todavía. También es útil para entrenar a la IA.

En general, use Kafka para el procesamiento de la transmisión sin conexión, use colas de mensajes para los mensajes del cliente-servidor en tiempo real.

Ejemplos de casos de uso de pivotal :

  

Kafka:   Seguimiento de actividad del sitio web, Métricas, Agregación de registros, Procesamiento de flujos, Fuentes de eventos y Registros de compromiso

     

RabbitMQ:   mensajería de propósito general ..., que se usa a menudo para permitir que los servidores web respondan a las solicitudes rápidamente en lugar de ser forzados a realizar procedimientos con muchos recursos mientras el usuario espera el resultado. Úselo cuando necesite usar protocolos existentes como AMQP 0-9-1, STOMP, MQTT, AMQP 1.0

¡A veces puede ser útil usar ambos! Por ejemplo, en el caso de uso n. ° 2, si se tratara de un flujo de datos de un creador de marcapasos, me gustaría que el creador de ritmo transmita datos de latido a una cola de mensajes de RabbitMQ (utilizando un protocolo fresco como MQTT) donde se procesa de inmediato. A ver si el corazón de la fuente sigue latiendo. Esto podría alimentar un tablero de instrumentos y un sistema de respuesta de emergencia. La cola de mensajes también depositaría los datos de la serie de tiempo en Kafka para que pudiéramos analizar los datos de los latidos del corazón con el tiempo. Por ejemplo, podríamos implementar un algoritmo para detectar enfermedades del corazón al observar las tendencias en el flujo de latidos del corazón.

    
respondido por el Samuel 07.06.2017 - 06:20

Lea otras preguntas en las etiquetas