Diferencia entre Apache NiFi y StreamSets

apache-nifi (4)

Estoy planeando hacer un proyecto de clase y estaba pasando por algunas tecnologías donde puedo automatizar o establecer el flujo de datos entre sistemas y descubrí que hay algunos de ellos, es decir, Apache NiFi y StreamSets (que yo sepa). ¿Qué no pude entender es la diferencia entre ellos y los casos de uso donde se pueden usar? Soy nuevo en esto y si alguien me puede explicar un poco sería muy apreciado. Gracias

Dos de los diferenciadores clave entre los dos IMHO son.

Apache NiFi es un proyecto de Apache de nivel superior, lo que significa que ha pasado por el proceso de incubación descrito aquí, http://incubator.apache.org/policy/process.html , y puede aceptar contribuciones de desarrolladores de todo el mundo que siguen el Apache estándar. Proceso que garantiza la calidad del software. StreamSets, tiene Apache LICENCIADO, lo que significa que cualquiera puede reutilizar el código, etc. Pero el proyecto no se administra como un proyecto de Apache. De hecho, para poder incluso contribuir a Streamsets, SE REQUIERE firmar un contrato. https://streamsets.com/contributing/ . Contrasta esto con la guía de colaboradores de Apache NiFi, que no fue escrita por un abogado. https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide#ContributorGuide-HowtocontributetoApacheNiFi
StreamSets "se ejecuta sobre Spark en YARN / Mesos en su lugar, aprovechando los recursos de clúster existentes que pueda tener". lo que impone un poco de restricción si desea implementar sus flujos de datos más hacia el Edge donde viven los dispositivos que generan los datos. Apache MiniFi, un subproyecto de NiFi puede ejecutarse en una sola Raspberry Pi, aunque estoy bastante seguro de que StreamSets no puede hacerlo, ya que YARN o Mesos requieren más recursos de los que ofrece una Raspberry Pi.

Divulgación: soy un empleado de Hortonworks

Son muy similares para los escenarios de ingesta de datos. Apache NIFI (HDP) es más maduro y StreamSets es más liviano. Ambos son fáciles de usar, ambos tienen una gran capacidad. Y StreamSets fácilmente podría tener empresas detrás, Hortonworks y Cloudera.

Obviamente, hay más colaboradores trabajando en NIFI que StreamSets; por supuesto, NIFI tiene más implementaciones empresariales en producción.

Suraj,

Gran pregunta

Mi respuesta es como miembro del comité de gestión de proyectos de código abierto Apache NiFi y como una persona apasionada por el dominio de administración de flujo de datos.

He estado involucrado en el proyecto NiFi desde que se inició en 2006. Mi conocimiento de Streamsets es relativamente limitado, así que los dejaré hablar como lo han hecho.

La clave a entender es que NiFi fue diseñado para hacer una cosa realmente importante realmente bien y eso es ''Administración de flujo de datos''. Su diseño se basa en un concepto llamado Programación basada en flujo que puede leer y hacer referencia para su proyecto '' https://en.wikipedia.org/wiki/Flow-based_programming ''

Ya hay muchos sistemas que producen datos como sensores y otros. Hay muchos sistemas que se centran en el procesamiento de datos como Apache Storm, Spark, Flink y otros. Y, finalmente, hay muchos sistemas que almacenan datos como HDFS, bases de datos relacionales, etc. NiFi se centra exclusivamente en la tarea de conectar esos sistemas y proporcionar la experiencia de usuario y las funciones básicas necesarias para hacerlo bien.

¿Cuáles son algunas de las funciones clave y las opciones de diseño realizadas para que sea efectivo?

1) Comando y control interactivo

El trabajo de alguien que intenta conectar sistemas es poder interactuar de manera rápida y eficiente con los flujos constantes de datos que ven. La interfaz de usuario de NiFi le permite hacer precisamente eso a medida que fluyen los datos, puede agregar funciones para operar en él, descompone copias de datos para probar nuevos enfoques, ajustar la configuración actual, ver estadísticas recientes e históricas, documentación útil en línea y más. En comparación, casi todos los demás sistemas tienen un modelo que está orientado al diseño y la implementación, lo que significa que realiza una serie de cambios y luego los implementa. Ese modelo está bien y puede ser intuitivo, pero para el trabajo de administración de flujo de datos significa que no obtiene el cambio interactivo por retroalimentación de cambio que es tan vital para generar nuevos flujos rápidamente o para corregir o mejorar el manejo de los flujos de datos existentes de manera segura y eficiente.

2) Procedencia de los datos

Una capacidad muy única de NiFi es su capacidad para generar detalles de trazabilidad detallados y potentes para saber de dónde provienen sus datos, qué se le hace, dónde se envía y cuándo se realiza en el flujo. Esto es esencial para la administración efectiva del flujo de datos por varias razones, pero para alguien en las primeras fases de exploración y para trabajar en un proyecto, lo más importante que esto le brinda es una increíble flexibilidad de depuración. Puede configurar sus flujos y dejar que las cosas corran y luego usar la procedencia para demostrar que realmente hizo exactamente lo que quería. Si algo no sucedió como esperaba, puede arreglar el flujo y reproducir el objeto y luego repetir. De mucha ayuda.

3) Propósito de los repositorios de datos construidos.

La experiencia lista para usar de NiFi ofrece un rendimiento muy potente incluso en hardware o entornos virtuales realmente modestos. Esto se debe al diseño de repositorio de contenido y archivo de flujo que nos proporciona el alto rendimiento, pero la semántica transaccional que queremos como datos se abre paso a través del flujo. El repositorio de archivos de flujo es una implementación de registro de escritura anticipada simple y el repositorio de contenido proporciona un almacén de contenido versionable inmutable. Eso, a su vez, significa que podemos "copiar" los datos agregando solo un nuevo puntero (en lugar de copiar bytes) o podemos transformar los datos simplemente leyendo el original y escribiendo una nueva versión. De nuevo muy eficiente. Combina eso con lo de la procedencia que mencioné hace un momento y solo proporciona una plataforma realmente poderosa. Otra cosa realmente importante que hay que entender aquí es que en el negocio de la conexión de sistemas no siempre se puede dictar cosas como el tamaño de los datos involucrados. La API de NiFi fue creada para honrar ese hecho y así nuestra API permite a los procesadores hacer cosas como recibir, transformar y enviar datos sin tener que cargar los objetos completos en la memoria. Estos repositorios también significan que en la mayoría de los flujos, la mayoría de los procesadores ni siquiera tocan el contenido. Sin embargo, puede ver fácilmente desde la interfaz de usuario de NiFi exactamente cuántos bytes realmente se leen o escriben, de modo que nuevamente obtendrá información realmente útil para establecer y observar sus flujos. Este diseño también significa que NiFi puede soportar la contrapresión y la liberación de presión naturalmente, y estas son características realmente críticas para un sistema de gestión de flujo de datos.

Las personas de la compañía Streamsets mencionaron anteriormente que NiFi está orientado a archivos. No estoy realmente seguro de cuál es la diferencia entre un archivo o un registro o una tupla o un objeto o un mensaje en términos genéricos, pero la realidad es que cuando los datos están en el flujo, es ''una cosa que se debe administrar y entregado''. Eso es lo que hace NiFi. Ya sea que tengas muchas cosas pequeñas de muy alta velocidad o cosas grandes y que provengan de una transmisión de audio en vivo de Internet o de un archivo que se encuentra en tu disco duro, no importa. Una vez que está en el flujo, es hora de administrarlo y entregarlo. Eso es lo que hace NiFi.

La compañía Streamsets también mencionó que NiFi no tiene esquemas. Es preciso que NiFi no fuerce la conversión de datos de lo que sea originalmente a algún formato especial de NiFi ni que tengamos que reconvertirlos a algún formato para su entrega posterior. Sería bastante desafortunado si lo hiciéramos porque lo que esto significa es que incluso los casos más triviales tendrían implicaciones problemáticas en el rendimiento y, por suerte, NiFi no tiene ese problema. Además, si hubiéramos recorrido ese camino, significaría que manejar diversos conjuntos de datos como medios (imágenes, video, audio y más) sería difícil, pero estamos en el camino correcto y NiFi se usa para cosas así todo el tiempo.

Finalmente, a medida que continúe con su proyecto y encuentre que hay cosas que le gustaría ver mejoradas o que le gustaría contribuir con un código, nos encantaría contar con su ayuda. Desde https://nifi.apache.org puede encontrar rápidamente información sobre cómo presentar boletos, enviar parches, enviar correos electrónicos a la lista de correo y más.

Aquí hay un par de divertidos proyectos recientes de NiFi para realizar el pago: https://www.linkedin.com/pulse/nifi-ocr-using-apache-read-childrens-books-jeremy-dyer https://twitter.com/KayLerch/status/721455415456882689

Buena suerte en el proyecto de clase! Si tiene alguna pregunta, a la lista de correo de [email protected] le encantaría ayudar.

Gracias joe

Tanto Apache NiFi como StreamSets Data Collector son herramientas de código abierto con licencia de Apache.

Hortonworks tiene una variante compatible comercialmente llamada Hortonworks DataFlow (HDF).

Si bien ambos tienen muchas similitudes, como una interfaz de usuario basada en la web, ambos se utilizan para ingerir datos, existen algunas diferencias clave. Ambos también constan de procesadores conectados entre sí para realizar transformaciones, serialización, etc.

Los procesadores NiFi están orientados a archivos y no tienen esquemas. Esto significa que una parte de los datos está representada por un FlowFile (esto podría ser un archivo real en el disco, o algún blob de datos adquiridos en otro lugar). Cada procesador es responsable de comprender el contenido de los datos para poder operar en él. Por lo tanto, si un procesador entiende el formato A y otro solo entiende el formato B, es posible que deba realizar una conversión de formato de datos entre esos dos procesadores.

NiFi se puede ejecutar de forma independiente, o como un clúster utilizando su propio sistema integrado de agrupación en clústeres.

Sin embargo, StreamSets Data Collector (SDC) adopta un enfoque basado en registros. Lo que esto significa es que a medida que los datos ingresan a su canalización (ya sea JSON, CSV, etc.) se analizan en un formato común para que la responsabilidad de comprender el formato de los datos ya no se coloque en cada procesador individual y se pueda conectar cualquier procesador. a cualquier otro procesador.

SDC también se ejecuta en modo autónomo, y también en modo agrupado, pero se ejecuta sobre Spark en YARN / Mesos en su lugar, aprovechando los recursos de clúster existentes que pueda tener.

NiFi ha existido durante los últimos 10 años (pero menos de 2 años en la comunidad de código abierto).

StreamSets se lanzó a la comunidad de código abierto un poco más tarde en 2015. Es independiente del proveedor, y en lo que respecta a Hadoop, Hortonworks, Cloudera y MapR son compatibles.

Revelación completa: soy un ingeniero que trabaja en StreamSets.