¿Cuáles son las mejores soluciones de procesamiento de flujo por ahí?

Como trabajo en Alooma, me resulta fácil recomendar nuestra herramienta. Sin embargo, existen muchas herramientas, así que intentaré enumerar algunas de las características más importantes.

Primero, puede separar el mercado de herramientas de procesamiento de flujo en dos categorías generales:

  1. Componentes de procesamiento de flujo : estos son productos que las empresas pueden usar para crear sus propias soluciones completas. Estos incluyen corredores de mensajes, motores de procesamiento de flujo, herramientas de extracción de datos y más.
    1. En realidad, la mayoría de las empresas (especialmente las pequeñas y medianas empresas) encontrarán que estos componentes, si bien proporcionan una parte de la lógica de procesamiento de flujo necesaria, aún requieren una gran cantidad de infraestructura para construir a su alrededor, es decir, crear un software para extraer los datos de las fuentes de datos. Por eso existe la segunda categoría.
  2. Soluciones de extremo a extremo : generalmente hay soluciones administradas, le costarán dinero, pero manejarán el procesamiento de su flujo de datos desde extraer datos de sus fuentes hasta hacer que sus datos sean procesables (es decir, cargarlos en un almacén / crear disparadores para eventos) , etc.)

Hay muchas páginas en Internet que comparan componentes para el procesamiento de flujo (es decir, vea esto, esto o aquello), así que me enfocaré en la categoría # 2, estas son algunas consideraciones al elegir su solución de procesamiento de flujo / flujo de datos:

  1. Facilidad de uso : a menudo se subestima, pero el aspecto más importante es la existencia de características autoexplicables y discernibles que se ofrecen a través de una buena interfaz de usuario. Ninguna cantidad de funciones poderosas ayudará si no puede encontrar la manera de encontrarlas.
  2. Control de flujo: un buen motor de procesamiento de flujo le permitirá manejar los errores en el flujo de una manera que tenga sentido para su uso: ¿desea que el flujo se detenga cuando se encuentre un error? ¿necesita tratar diferentes tipos de datos de diferentes maneras? ¿Quizás necesite dividir o fusionar ciertos eventos para extraer el significado de los datos en la transmisión? Estas son todas preguntas importantes.
  3. Escalabilidad: intente evaluar el volumen de datos que introducirá en la solución. Piense en el umbral de latencia por encima del cual la solución será demasiado lenta. Cambiar una infraestructura a la que está acostumbrado porque su empresa creció, casi siempre es un proceso largo y costoso. Asegúrese de que su solución pueda crecer con usted para evitar costos innecesarios.

Hay otras cosas a tener en cuenta, pero cuando se presenta una solución para el procesamiento de flujo, tener en cuenta estas consideraciones lo colocará en una posición mucho mejor para tomar la decisión correcta. ¡Buena suerte!

Hay muchas opciones basadas en lo que está buscando hacer.

¿Cómo quieres escribir la lógica?

Si está buscando escribir código para su lógica (y no está buscando un SQL como lenguaje declarativo), puede usar uno de los motores de procesamiento de flujo: Apache Storm, Apache Spark, Apache Fink, Apache Samza o Kafka Streams. La buena noticia es que todos ellos son de código abierto.

Entre ellos, mi apuesta es Fink. Tiene una arquitectura bastante agradable que maneja muchas trampas en las que otros se metieron. Especialmente, si quieres hacer exactamente una vez el procesamiento, Fink es la mejor apuesta.

Sin embargo, escribir código java para hacer esto está bien si hace un conteo simple, pero es una pesadilla si desea hacer cosas serias como ventanas de tiempo, patrones de secuencia de eventos temporales y de unión, etc. (consulte Patrones para Streaming Realtime Analytics para obtener detalles sobre este argumento ) Si quiere expresar la lógica usando un lenguaje declarativo, entonces querrá usar “Streaming SQL” , que le permite escribir consultas SQL y hacer cosas complejas. (vea Lenguaje de consulta similar a SQL para análisis de transmisión en tiempo real para una discusión sobre este argumento). Específicamente, este tipo de consultas admiten operadores temporales como ventanas deslizantes, uniones, patrones de secuencia temporal, etc.

Si está buscando una solución de código abierto, entre las opciones están el Procesador de flujo WSO2 (WSO2 SP) formalmente conocido como WSO2 CEP (Licencia Apache) y Esper (GPL). (Descargo de responsabilidad, trabajo para WSO2).

Si puede pagar, entonces está Tibco Stream Base, IBM Infosphere Streams y SQLStreams. Tanto “Streaming SQL” como Esper tienen soporte comercial si lo necesita. Paul Vincent ha mantenido una encuesta de mercado CEP que proporciona una descripción histórica de casi todos los motores CEP.

Un informe reciente de Forrester encuestó las opciones y puede encontrar los detalles de 15 plataformas de análisis de transmisión “verdaderas” para todo en tiempo real .

Los motores de procesamiento de flujo anteriores están agregando soporte para lenguajes de consulta similares a SQL (consulte el segundo acto de Realtime Analytics: los procesadores de flujo y los motores CEP se están fusionando para obtener más detalles). Sin embargo, todavía se quedan atrás con las características (por ejemplo, patrones de secuencia temporal). Como discutí aquí, los motores de procesamiento de flujo versus procesamiento de eventos complejos, CEP y procesamiento de flujo se están fusionando.

Despliegue mínimo de HA

Según el tamaño de la implementación que está buscando, debe verificar la implementación mínima admitida por la herramienta que elija. Por ejemplo, cualquier solución basada en Kafka necesita 6 nodos. Algunas herramientas pueden admitir una implementación de dos nodos.

Escalabilidad

Si planea procesar millones de eventos por segundo, debe configurar un gráfico complejo de procesamiento distribuido. En este tema, el procesamiento de flujo tiene una ventaja donde se construyen históricamente a escala. Sin embargo, como mencioné, estos dos modelos se están fusionando.

IoT Analytics

Si está realizando un análisis de IoT, los datos crean una serie temporal. En ese caso, a menudo necesita realizar operaciones temporales como ventanas deslizantes. En ese caso de uso, está mejor con un lenguaje similar a SQL, por lo tanto, recomiendo ir a CEP.

Streaming + Lote

El giro final es si desea hacer lotes (procesamiento de estilo MapReduce) también. En caso afirmativo, lea sobre la arquitectura Lambda y la arquitectura Kappa. Apache Fink y WSO2 SP son compatibles con este escenario. (y puede haber otros).

Hay tantos marcos de transmisión abiertos disponibles que necesitamos comprender las fortalezas, debilidades y casos de uso de cada uno.
También debemos conocer algunos términos y conceptos relacionados con la transmisión antes de comparar los marcos.
He intentado cubrir las cosas anteriores en detalle en mi publicación:
Spark Streaming vs Flink vs Storm vs Kafka Streams vs Samza: elija su marco de procesamiento de flujo

Como siempre, no existe una solución de procesamiento de flujo única para todos. Hay muchas consideraciones, como compilar o comprar, en las instalaciones o en la nube, vinculadas al proveedor de la nube o independientes, etc. Si el código abierto puede ser la opción correcta para usted, puede estar interesado en un plan de procesamiento In-Stream, basado en Apache Kafka, Spark Streaming y Cassandra, que mis colegas y yo publicamos recientemente:

https://blog.griddynamics.com/wh

Introducción al procesamiento de transmisiones: la próxima gran cosa en el mundo de Big Data: esta publicación de blog puede ayudarlo a comprender el procesamiento de transmisiones