Procesamiento de flujos

En el paradigma secuencial estándar, la operación se ejecuta de forma iterativa utilizando un único bucle:

for ( int i = 0 ; i < 400 ; i ++ ) { result [ i ] = source0 [ i ] + source1 [ i ]; }

Si bien existen variaciones estructurales, como el uso de bucles internos anidados o diseños de datos basados ​​en matrices de estructuras, el cálculo subyacente se basa fundamentalmente en este modelo de ejecución lineal.

// para cada vector for ( int elem = 0 ; elem < 100 ; elem ++ ) { vectorSum ( result [ elem ], source0 [ elem ], source1 [ elem ]); }

Este modelo ilustra de forma abstracta el paradigma asumiendo una vector_suminstrucción genérica. Si bien esta abstracción refleja cómo funcionan las instrucciones intrínsecas en la práctica, omite detalles de la implementación del hardware subyacente, como formatos de datos explícitos y anchos de bits de los componentes, para mayor claridad.

Al operar con estructuras de datos empaquetadas, este método reduce la cantidad de instrucciones aritméticas individuales necesarias para procesar los componentes del array. El control de bucles y la sobrecarga de saltos también se reducen debido al menor número de iteraciones. Estas mejoras en la eficiencia son el resultado directo de ejecutar múltiples operaciones aritméticas simultáneamente dentro de un único paso de ejecución de instrucciones. ^{[ 10 ]}

Sin embargo, debido a que un registro SIMD empaquetado tiene una capacidad de ancho de bits fija, la escalabilidad está inherentemente limitada por el tamaño máximo del registro. En este escenario, la aceleración por hardware está limitada por el ancho del vector de cuatro operaciones paralelas, una configuración estándar en arquitecturas como AltiVec y Streaming SIMD Extensions (SSE) . ^{[ 11 ]}

// Este es un lenguaje ficticio con fines demostrativos. elements = array streamElement ([ number , number ])[ 100 ] kernel = instance streamKernel ( "@arg0[@iter]" ) result = kernel . invoke ( elements )

En el paradigma de procesamiento de flujos, los datos se tratan como una secuencia continua e ilimitada de elementos, en lugar de un conjunto de datos estático. En vez de gestionar la iteración explícitamente, el programa define una secuencia de flujo de datos, lo que permite que el entorno de ejecución aplique automáticamente la función del núcleo de cálculo a medida que llegan nuevos elementos de datos. Si bien se suele utilizar una correspondencia uno a uno entre los datos de entrada y salida por simplicidad, no es un requisito arquitectónico inherente; los núcleos pueden realizar transformaciones complejas, ventanas de agregación o modificaciones con estado. ^{[ 12 ]}

Los compiladores optimizados para este paradigma pueden realizar transformaciones de código automatizadas extensas, como el desenrollado de bucles . Esta abstracción permite que el rendimiento se ajuste de forma transparente a la capacidad del hardware, lo que posibilita la utilización de cientos de unidades aritmético-lógicas (ALU). ^{[ 13 ] [ 14 ]} Minimizar los patrones de acceso a datos complejos e impredecibles garantiza que se pueda acceder a un mayor porcentaje de la capacidad máxima de ejecución del hardware.

Aunque el procesamiento de flujo comparte características con las arquitecturas SIMD y MIMD más amplias, los conceptos siguen siendo distintos. ^{[ 12 ]} Si bien el hardware SIMD suele ejecutar operaciones de forma segmentada o en flujo continuo, las características de rendimiento estándar de SIMD difieren; el modelo de procesamiento de flujo impone un flujo de datos estructurado y una gestión de memoria explícita que permite una eficiencia de ejecución significativamente mayor. ^{[ 15 ]}

Cuando se implementaban en arquitecturas de propósito general, como las CPU estándar, las abstracciones de procesamiento de flujos a menudo producían ganancias de rendimiento limitadas, y algunos estudios históricos señalaban una aceleración de ejecución de tan solo aproximadamente 1,5x. ^{[ 16 ]} En contraste, los primeros procesadores de flujos dedicados lograron aumentos de rendimiento superiores a 10x, principalmente debido a archivos de registro especializados gestionados por hardware y niveles más altos de unidades de ejecución paralela. ^{[ 17 ]}

A pesar de las variaciones en la flexibilidad entre los modelos de implementación, el hardware de procesamiento de flujos generalmente impone restricciones estrictas tanto en la complejidad del núcleo como en el tamaño de las dimensiones del flujo. Por ejemplo, el hardware de procesamiento gráfico de consumo históricamente carecía de soporte para aritmética de alta precisión, carecía de capacidades complejas de indirección de punteros e imponía límites estrictos en el número máximo de instrucciones. ^{[ 18 ]}

Un desafío principal en la computación paralela es la complejidad de mapear algoritmos a arquitecturas de hardware manteniendo la velocidad de desarrollo de software y el rendimiento en tiempo de ejecución. El hardware de transmisión inicial, como el prototipo Stanford Imagine, mitigó esto al utilizar un modelo de programación de un solo hilo que abstraía la asignación de memoria, las dependencias de datos y la planificación del acceso directo a memoria (DMA) . ^{[ 21 ]} Esta división de tareas surgió de la investigación en el Instituto Tecnológico de Massachusetts (MIT) y la Universidad de Stanford, que demostró que los programadores humanos son altamente efectivos en la partición algorítmica de alto nivel, mientras que las herramientas de compilación automatizadas sobresalen en la optimización de rutinas complejas de asignación y planificación de memoria. ^{[ 22 ] [ 23 ]} En contraste, las arquitecturas multinúcleo asimétricas, como Cell Broadband Engine , transfieren la partición estructural, la sincronización de procesos y la sobrecarga del equilibrio de carga directamente al desarrollador de software. ^{[ 24 ]}

La disposición de la estructura de datos impacta significativamente la eficiencia de ejecución de los paradigmas paralelos, requiriendo típicamente una elección entre una matriz de estructuras (AoS) y una estructura de matrices (SoA) . En la ingeniería de software de propósito general, los desarrolladores convencionalmente representan entidades de datos en memoria —por ejemplo, la ubicación de una partícula en el espacio 3D, el color de una pelota y su tamaño— como se muestra a continuación: ^{[ 25 ]}

// Una partícula en un espacio tridimensional. struct Particle { double x ; double y ; double z ;// 8 bits por canal, digamos que solo nos interesa RGB unsigned byte color [ 3 ]; float size ; // ... y muchos otros atributos pueden seguir... };

Cuando existen múltiples entidades en secuencia, se asignan de extremo a extremo, formando una topología de matriz de estructuras (AoS) . Si un algoritmo procesa solo un atributo en todos los elementos, como modificar únicamente las coordenadas 3D, el motor de ejecución debe omitir los atributos no utilizados en la memoria. Dado que las líneas de caché convencionales acceden a la memoria en bloques contiguos, la carga de atributos innecesarios resulta en una utilización ineficiente de la caché y un desperdicio de ancho de banda de memoria . Además, las operaciones SIMD estándar requieren que los elementos de entrada sean contiguos y estén correctamente alineados en la memoria para llenar eficientemente los carriles vectoriales. ^{[ 25 ]}

Para optimizar la transmisión de datos y la ejecución vectorial, los atributos se pueden separar en bloques paralelos distintos mediante una estructura de matrices (SoA) . Una representación SoA aísla los campos idénticos en matrices individuales y contiguas, como se muestra a continuación:

struct Particle { double * x ; double * y ; double * z ;byte sin signo * colorRojo ; byte sin signo * colorAzul ; byte sin signo * colorVerde ;flotar * tamaño ; };

Si bien la estructura de arreglos (SoA) optimiza las rutas de datos uniformes, introduce desventajas arquitectónicas importantes. Si una rutina debe operar simultáneamente en múltiples atributos distintos de una sola entidad, estos atributos pueden residir muy separados en la memoria virtual , lo que provoca fallos de caché graves y una mayor sobrecarga en la traducción de direcciones. Además, garantizar que cada arreglo independiente cumpla con los límites de alineación de memoria del hardware puede requerir relleno de datos, lo que aumenta el consumo total de memoria. La gestión dinámica de la memoria también se vuelve muy compleja cuando se deben agregar o eliminar elementos, ya que las modificaciones requieren el desplazamiento síncrono de elementos a través de múltiples arreglos desconectados. ^{[ 26 ]}

Por el contrario, las arquitecturas de procesamiento de flujo dedicadas utilizan ampliamente abstracciones estructuradas para unificar estos diseños. En las canalizaciones de vértices de las unidades de procesamiento gráfico (GPU) contemporáneas, el hardware proporciona un número fijo de ranuras de atributos, estandarizándose históricamente en torno a 16 líneas de entrada. ^{[ 27 ]} La aplicación especifica el número de componentes y el formato del tipo de datos para cada flujo de entrada, aunque la compatibilidad del hardware suele estar restringida a tipos de datos numéricos primitivos. Estos atributos independientes están vinculados a un bloque de memoria cohesivo mediante un parámetro de paso explícito. Al ajustar el paso de bytes entre elementos consecutivos de la matriz, los desarrolladores pueden formatear el flujo de datos como matrices intercaladas de estructuras (AoS) o estructuras separadas de matrices (SoA). En la etapa de ejecución, el hardware de la GPU reúne automáticamente estos atributos dispares en un paquete de parámetros unificado, como una estructura de kernel explícita o registros globales integrados, ejecuta las operaciones en paralelo y dispersa los resultados de salida a un búfer de salida para las etapas posteriores de la canalización de procesamiento. ^{[ 28 ]}

Los marcos de procesamiento de flujos modernos introducen abstracciones de primero en entrar, primero en salir (FIFO) para representar las canalizaciones de ejecución de datos como topologías direccionales desacopladas. Este diseño permite a los desarrolladores definir dependencias de paralelismo de datos explícitas, al tiempo que posibilita que el entorno de ejecución coordine de forma transparente la asignación de memoria, los límites de subprocesos y la planificación de tareas entre núcleos. ^{[ 29 ]}

Una implementación de este modelo de transmisión en C++ es RaftLib , una biblioteca de plantillas de código abierto que permite a los desarrolladores encadenar núcleos computacionales independientes en un grafo de flujo de datos utilizando operadores de flujo de C++ sobrecargados. ^{[ 30 ]} Para demostrar este paradigma, el siguiente código inicializa un flujo de generación de texto asíncrono vinculado a un núcleo de salida estándar:

import < raft > ; import < raftio > ;importar std ;usando String = std :: string ;using RaftKernel = raft :: kernel ; using RaftKernelStatus = raft :: kstatus ; using RaftMap = raft :: map ; using RaftPrint = raft :: print ;clase HelloWorld : public RaftKernel { public : HelloWorld () { output . addPort < String > ( "0" ); }virtual RaftKernelStatus run () { output [ "0" ]. push ( "Hola Mundo \n " ); return raft :: stop ; } };int main ( int argc , char * argv []) { // instanciar el kernel de impresión RaftPrint < String > p ;// instanciar el kernel hello world HelloWorld hello ;// crea un objeto de mapa RaftMap m ;// agregar kernels al mapa, tanto hello como p se ejecutan simultáneamente m += hello >> p ;// ejecutar el mapa m . exe ();devolver 0 ; }

Más allá de los lenguajes de programación procedimentales de alto nivel , las aplicaciones de procesamiento de flujos se estructuran formalmente mediante distintos modelos de computación (MoC) . Estos incluyen modelos de flujo de datos estructurados y marcos concurrentes basados ​​en procesos (como las redes de procesos de Kahn ), que representan matemáticamente las dependencias computacionales y las etapas de ejecución en paralelo. ^{[ 31 ]}

Históricamente, las unidades centrales de procesamiento (CPU) de propósito general implementaron jerarquías de acceso a memoria de múltiples niveles cada vez más complejas para mitigar la creciente discrepancia de rendimiento entre las velocidades de ejecución brutas del núcleo y el ancho de banda de la memoria externa. Para enmascarar estas latencias de memoria, un porcentaje sustancial del área del chip de la CPU convencional se asigna al seguimiento automático de la caché, la predicción de bifurcaciones y la lógica de ejecución especulativa. En consecuencia, solo una pequeña fracción del espacio físico del hardware —históricamente estimada en menos del 10 %— se dedica directamente a las unidades aritmético-lógicas (ALU). ^{[ 32 ]}

Las estructuras de hardware de procesamiento de flujo minimizan esta sobrecarga de gestión aprovechando las restricciones explícitas del flujo de datos. ^{[ 32 ]} Estructuralmente, los procesadores de flujo suelen operar dentro de un entorno de coprocesamiento; una CPU principal del host sigue siendo responsable de ejecutar el sistema operativo, orquestar las asignaciones de recursos del sistema y gestionar los límites de los subprocesos a nivel de aplicación, mientras que el procesador de flujo se centra por completo en la aceleración aritmética de alto rendimiento. ^{[ 33 ]}

Para mantener el máximo rendimiento, los procesadores de flujo utilizan buses de memoria amplios y dedicados. Los primeros diseños empleaban barras cruzadas multisegmento con diferentes anchos de bus (como topologías de 128 o 256 bits), priorizando el ancho de banda de la memoria sobre la latencia. Esto contrasta con las plataformas de computación escalar históricas, que tradicionalmente dependían de canales de memoria de un solo canal más estrechos. Además, las rutas de acceso a la memoria dentro de un motor de flujo siguen siendo altamente predecibles; los límites de dimensión de los datos de flujo se fijan explícitamente al invocar el kernel, transformando indirecciones arbitrarias de múltiples punteros en cadenas de indirecciones limitadas que se resuelven en regiones de memoria de flujo explícitas. ^{[ 32 ]}

Debido a que las unidades de ejecución están organizadas en densos clústeres aritméticos paralelos gestionados por paradigmas de control convergentes VLIW y SIMD , las operaciones de lectura y escritura se procesan mediante transferencias de flujo masivo. Estos sistemas desacoplan los datos de aplicación intermedios, completando la gran mayoría de las tareas de cálculo directamente en el chip a través de una jerarquía explícita de ancho de banda de datos de tres niveles. ^{[ 33 ]}

Aunque las arquitecturas de transmisión paralela pueden lograr una aceleración de un orden de magnitud, no todas las cargas de trabajo se benefician de este modelo. La latencia de la comunicación entre procesadores representa un cuello de botella significativo. Si bien los buses de sistema modernos, como PCI Express, proporcionan canales de comunicación dúplex completo de alto ancho de banda, la sobrecarga de latencia de la transferencia de datos entre la memoria del host y el espacio de memoria discreta del procesador de flujo sigue siendo considerable. En consecuencia, utilizar un coprocesador de flujo para conjuntos de datos pequeños suele ser ineficiente. Debido a que la reconfiguración del estado de ejecución o la compilación de un nuevo kernel introduce una latencia significativa, la arquitectura también conlleva graves penalizaciones de rendimiento al procesar dimensiones de flujo pequeñas, un fenómeno conocido como el efecto de flujo corto. ^{[ 34 ]}

El hardware gráfico programable inicial dependía en gran medida de profundas y especializadas canalizaciones de ejecución para maximizar el rendimiento. Sin embargo, los frecuentes cambios de estado, como el cambio de programas de sombreado o la actualización de enlaces de memoria, interrumpían la eficiencia de la canalización e introducían una gran sobrecarga de validación del controlador. Para mitigar estas desventajas en las canalizaciones de renderizado en tiempo real, los desarrolladores introdujeron patrones de optimización a nivel de software, como los "supersombreadores" (grandes núcleos monolíticos que manejan múltiples tipos de materiales mediante bifurcaciones condicionales) y los "atlas de texturas" (que consolidan recursos de textura independientes en una única disposición de memoria contigua para evitar cambios de enlace). Si bien estas técnicas se originaron en los motores de videojuegos reales, los principios subyacentes se aplican ampliamente al procesamiento de flujo genérico para maximizar el tiempo de ejecución del núcleo y evitar estados de bloqueo del hardware. ^{[ 35 ]}

• Commodore Amiga Blitter (1985): Una implementación temprana de hardware para la manipulación de datos tipo flujo. El Amiga blitter funcionaba como un coprocesador gráfico dedicado, capaz de combinar hasta tres fuentes de flujo de bits de memoria distintas mediante operaciones lógicas bit a bit para generar un único flujo de salida. Esta canalización movía datos a un ancho de banda de entrada máximo de 42 megabits por segundo, evitando la CPU principal para acelerar la renderización de gráficos 2D. ^{[ 36 ]}

• Proyecto Stanford Imagine (1996-2002): Financiado por DARPA , Intel y Texas Instruments , este proyecto de investigación académica fue pionero en la arquitectura de flujo moderna. El proyecto desarrolló un prototipo de chip flexible que combinaba una matriz de unidades aritmético-lógicas (ALU) con un archivo de registro de flujo (SRF) centralizado y gestionado por software para maximizar la eficiencia energética y el rendimiento computacional.

• Stanford Merrimac (2004): Una iniciativa académica posterior que extendió la arquitectura de transmisión Imagine al dominio de la supercomputación. Utilizó redes de interconexión especializadas para ofrecer altas relaciones rendimiento-precio para cargas de trabajo de computación científica en comparación con los clústeres de computadoras estándar de su época. ^{[ 37 ]}

• Stream Processors, Inc. Storm-1 (2007): Un producto derivado del proyecto Stanford Imagine. La arquitectura Storm-1 estaba dirigida a mercados de procesamiento de señales digitales (DSP) de alta gama, como videoconferencias y vigilancia digital. Mejoró el rendimiento de 30 a 220 mil millones de operaciones por segundo (GOPS) mediante la agrupación de unidades aritmético-lógicas (ALU) de transmisión en un solo chip.

Las unidades de procesamiento gráfico (GPU) modernas representan la evolución comercial más extendida del procesamiento de flujos. Su progresión arquitectónica transformó el hardware de tuberías rígidas y de función fija a motores de flujo de propósito general: ^{[ 38 ]}

• Era de funciones fijas (anterior a 2001): El hardware gráfico inicial no ofrecía acceso explícito para que los desarrolladores procesaran flujos de datos. Las operaciones de transmisión estaban completamente abstraídas dentro de las interfaces de programación de aplicaciones (API) gráficas, lo que limitaba la personalización del hardware.
• Programabilidad temprana de vértices (2001-2002): Microarquitecturas como la ATI R200 y la Nvidia NV20 introdujeron el control explícito del programador, pero exclusivamente para las canalizaciones de procesamiento de vértices. El procesamiento de fragmentos/píxeles siguió ligado a paradigmas más antiguos. La total ausencia de ejecución condicional (compatibilidad con ramificaciones) limitó estos primeros chips a modelos matemáticos lineales simples, como simulaciones básicas de dinámica de fluidos.
• Flujo de control dinámico (2003-2004): Arquitecturas como la ATI R300 y la Nvidia NV40 introdujeron un flujo de control y ramificación flexibles. Si bien estaban limitadas por el número máximo de instrucciones y la profundidad de anidamiento de bucles, estos chips permitían que los flujos de datos divergieran según los estados de cálculo en tiempo de ejecución.
• Arquitecturas de flujo unificadas (2006-presente): Las generaciones posteriores unificaron las canalizaciones independientes de vértices y píxeles en matrices homogéneas de núcleos de flujo programables. Las iteraciones de hardware introdujeron mecánicas de flujo especializadas, como operaciones atómicas a nivel de hardware y búferes dinámicos de adición/consumo, lo que permitió la computación GPU compleja de propósito general (GPGPU). Esta evolución dio lugar a líneas de productos dedicadas a centros de datos para computación de alto rendimiento (HPC), incluidas las marcas Nvidia Tesla y AMD FireStream.

Desarrollado por una alianza de Sony, Toshiba e IBM (STI), el procesador Cell funciona como una arquitectura de transmisión híbrida cuando se combina con cadenas de herramientas de software especializadas. El chip cuenta con un procesador de control principal —el Elemento de Procesamiento de Potencia (PPE)— y una matriz de coprocesadores vectoriales denominados Elementos de Procesamiento Sinérgico (SPE). Dado que cada SPE posee un espacio de memoria de instrucciones y un contador de programa independientes, el chip se comporta como un entorno de instrucciones múltiples, datos múltiples (MIMD). Sin embargo, debido a las severas restricciones de memoria local, el software debe utilizar comandos explícitos de acceso directo a memoria (DMA) para transmitir datos secuencialmente a través de los SPE. Cuando los algoritmos de software se reestructuran por completo para adherirse estrictamente a este modelo de programación de transmisión, la eficiencia de ejecución del hardware iguala la de los procesadores de transmisión dedicados. ^{[ 24 ]}

• Modelo de programación ACOTES: Un marco de programación estructurada desarrollado por la Universidad Politécnica de Cataluña , que aprovecha las directivas OpenMP para optimizar los flujos de datos en paralelo.
• Ateji PX (Edición Gratuita): Una extensión para la máquina virtual de Java (JVM) diseñada para expresar la programación de flujos, el modelo de actores y las abstracciones de MapReduce .

• Auto-Pipe: Desarrollado por el Laboratorio de Supercomputación Basada en Flujos (SBS) de la Universidad de Washington en St. Louis . Proporciona un entorno de desarrollo heterogéneo que coordina flujos de trabajo entre CPU (a través de C/C++ o Java), FPGA (a través de Verilog/VHDL ) y GPU (a través de CUDA ).
• BeepBeep: Una biblioteca ligera de procesamiento de flujos de eventos basada en Java, desarrollada por el Laboratorio de Ciencias de la Computación Formal de la Universidad de Quebec en Chicoutimi .
• Brook: Una extensión fundamental del lenguaje de transmisión de datos en paralelo desarrollada por la Universidad de Stanford para abstraer la programación de GPU.
• Lenguaje de actores CAL : Un lenguaje de programación de flujo de datos de alto nivel diseñado para crear operadores con estado (actores) que transforman flujos de tokens entrantes en flujos de salida deterministas.
• Cal2Many: Un marco de compilación de la Universidad de Halmstad que traduce el código de alto nivel de los actores CAL a código fuente de bajo nivel específico para cada plataforma, incluyendo C paralelo y modelos de descripción de hardware.
• Lenguaje de programación DUP : Un lenguaje de programación de flujos desarrollado simultáneamente por la Universidad Técnica de Múnich y la Universidad de Denver .
• HSTREAM: Una extensión de compilador de código fuente a código fuente basada en directivas, diseñada para facilitar el procesamiento de flujos de datos a través de recursos de ejecución heterogéneos de CPU y GPU, de forma similar a los patrones de compilación de OpenMP.
• RaftLib : Una biblioteca de plantillas C++ de código abierto que utiliza operadores de flujo nativos de C++ (>>) para ensamblar núcleos computacionales concurrentes en topologías de flujo de datos unificadas. ^{[ 30 ]}
• Sh : Una biblioteca de metaprogramación fundamental desarrollada en la Universidad de Waterloo para ejecutar programas de flujo en GPU, que sirvió como base de código para RapidMind .
• S-Net: Un lenguaje de coordinación desarrollado en la Universidad de Hertfordshire que desacopla por completo la lógica de orquestación de flujos de los algoritmos estructurales.
• SPar: Un lenguaje específico de dominio en C++ diseñado por el Grupo de Modelado de Aplicaciones (GMAP) de la Pontificia Universidad Católica de Rio Grande do Sul para expresar el paralelismo de flujos mediante anotaciones de atributos.
• StreamIt: Un lenguaje especializado y una infraestructura de compilación desarrollada en el MIT, diseñada específicamente para optimizar las arquitecturas de procesamiento paralelo de flujos de datos.
• WaveScript: Un lenguaje funcional de procesamiento de flujos de datos desarrollado en el MIT y optimizado para el manejo de flujos de sensores de alta velocidad y redes de señales distribuidas.

• Embiot (Telchemy) : Un agente ligero e integrado de análisis de datos en tiempo real, diseñado para procesar flujos de sensores directamente en entornos de computación perimetral con recursos limitados.
• Floodgate: Un motor de procesamiento de flujo que históricamente se incluía con el motor Gamebryo para gestionar la distribución de tareas multinúcleo en las consolas de videojuegos de consumo.
• Jacket (AccelerEyes) : Un motor comercial diseñado para compilar y acelerar estructuras de cálculo de MATLAB directamente sobre unidades de flujo de GPU.
• OpenHMPP : Un modelo de programación basado en directivas diseñado para simplificar el despliegue de kernels de streaming en aceleradores multinúcleo heterogéneos .
• PeakStream : Una empresa derivada comercial del proyecto Stanford Brook, adquirida posteriormente por Google en 2007.
• RapidMind : Una plataforma de software comercial que evolucionó a partir de la biblioteca Sh de la Universidad de Waterloo, posteriormente adquirida por Intel en 2009.
• SPADE (IBM): El motor declarativo de aplicaciones de procesamiento de flujos, que sirve como lenguaje de transmisión declarativo fundamental para la plataforma empresarial System S de IBM. ^{[ 40 ]}
• TStreams : Un entorno de ejecución declarativo para la transmisión de tareas desarrollado en el Laboratorio de Investigación de Hewlett-Packard en Cambridge para aprovechar la concurrencia multinúcleo.

• Brook+: Una implementación comercial del marco de lenguaje Stanford Brook , optimizada por AMD y acelerada por hardware .
• CUDA (Compute Unified Device Architecture) : plataforma de computación paralela y modelo API propiedad de Nvidia para ejecutar kernels de transmisión en hardware gráfico.
• Intel Ct : Extensión histórica del lenguaje C/C++ de Intel diseñada para vectorizar y transmitir automáticamente bucles de datos a través de procesadores multinúcleo.
• StreamC: Un lenguaje de procesamiento de flujos desarrollado por Stream Processors, Inc. , basado directamente en la microarquitectura del procesador Stanford Imagine.

• Apache NiFi : Un sistema integrado de logística de datos diseñado para automatizar y gestionar el flujo continuo de datos en forma de grafos dirigidos entre sistemas de software.
• Apama: Un motor de análisis y procesamiento de eventos complejos de alto rendimiento y baja latencia, desarrollado por Software AG.
• Wallaroo: Un marco de procesamiento de flujos elásticos distribuidos de código abierto diseñado para el manejo de métricas de baja latencia.
• WSO2 Stream Processor / Siddhi: Un motor de procesamiento de eventos complejos y de transmisión de código abierto, nativo de la nube, que ingiere, analiza y reacciona a flujos en tiempo real mediante consultas similares a SQL.

La infraestructura de datos moderna a escala de clúster clasifica las arquitecturas de flujo en función de sus modelos de ejecución:

• Procesamiento nativo de flujo continuo: Marcos de trabajo que procesan los elementos individualmente a medida que llegan, optimizando para latencias en tiempo real inferiores a un segundo:
  • Apache Storm : Un sistema de computación distribuida en tiempo real, nativo y de baja latencia.
  • Apache Flink : Un verdadero motor de ejecución de flujos de datos que trata la computación por lotes estrictamente como un subconjunto especializado del procesamiento continuo de flujos de datos.
  • Apache Samza : Un motor de procesamiento de flujos distribuidos con estado, construido sobre Apache Kafka.
• Procesamiento de flujos por micro-lotes: Marcos de trabajo que logran una semántica de flujo de alto rendimiento mediante la recopilación automática de elementos entrantes en ventanas de tiempo muy restringidas o lotes en miniatura:
  • Apache Spark Streaming : Una extensión de la API principal de Apache Spark que ingiere flujos de datos en tiempo real y los procesa en pequeños fragmentos discretos (microlotes).
• Arquitecturas de registro distribuido: Infraestructura que sirve como capa de transporte persistente y de solo adición para arquitecturas de flujo continuo:
  • Apache Kafka : Una plataforma de transmisión de eventos distribuida y altamente escalable que se utiliza para ingerir y almacenar flujos de registros tolerantes a fallos.

• Amazon Web Services (AWS) Kinesis : Un servicio en la nube gestionado para el procesamiento en tiempo real de flujos de datos distribuidos a gran escala.
• Google Cloud Dataflow : Un servicio en la nube totalmente administrado que ejecuta canalizaciones unificadas de procesamiento por lotes y en tiempo real basadas en la arquitectura Apache Beam.
• IBM Streams / Streaming Analytics: Entornos de ejecución en la nube y locales para aplicaciones de streaming de baja latencia escritas en SPL .
• Microsoft Azure Stream Analytics : Un motor de procesamiento de eventos complejos en tiempo real administrado, diseñado para evaluar flujos de datos provenientes de aplicaciones y dispositivos IoT.
• Procesamiento de flujos de MongoDB Atlas: Un motor de enrutamiento de flujos de bases de datos gestionadas, diseñado para procesar y agregar continuamente los cambios activos en los documentos.
• SQLStreamBuilder (Eventador): Una interfaz gestionada que permite la detección continua de patrones complejos en estructuras de Kafka mediante consultas SQL declarativas estándar.