Solución:
Sería útil si pudiera ampliar un poco sus casos de uso específicos. ¿Qué está tratando de lograr en relación con el “análisis de Bigdata”? La respuesta corta … depende 🙂
A continuación, se muestran algunos puntos arquitectónicos clave a considerar en relación con Google Cloud Dataflow v. Spark y Hadoop MR.
-
Gestión de recursos: Cloud Dataflow es un entorno de ejecución completamente bajo demanda. Específicamente, cuando ejecuta un trabajo en Dataflow, los recursos se asignan a pedido solo para ese trabajo. No hay intercambio / contención de recursos entre trabajos. En comparación con un clúster de Spark o MapReduce, normalmente implementaría un clúster de nodos X y luego enviaría trabajos y luego ajustaría los recursos de los nodos en todos los trabajos. Por supuesto, puede construir y derribar estos clústeres, pero el modelo de Dataflow está orientado a las operaciones de desarrollo de manos libres en relación con la gestión de recursos. Si desea optimizar el uso de recursos según las demandas del trabajo, Dataflow es un modelo sólido para controlar los costos y casi olvidarse del ajuste de recursos. Si prefiere un clúster de estilo multiinquilino, le sugiero que mire Google Cloud Dataproc, ya que proporciona los aspectos de administración de clústeres bajo demanda como Dataflow, pero se centra en cargas de trabajo de clase Hadoop como MR, Spark, Pig, …
-
Interactividad: En la actualidad Cloud Dataflow no proporciona un modo interactivo. Lo que significa que una vez que envía un trabajo, los recursos de trabajo están vinculados al gráfico que se envió Y la mayoría de los datos se cargan en los recursos según sea necesario. Spark puede ser un modelo mejor si desea cargar datos en el clúster a través de RDD en la memoria y luego ejecutar consultas dinámicamente. El desafío es que a medida que aumenta el tamaño de los datos y la complejidad de las consultas, tendrá que manejar devOps. Ahora bien, si la mayoría de sus consultas se pueden expresar en sintaxis SQL, es posible que desee ver BigQuery. BigQuery proporciona los aspectos “a pedido” de Dataflow y te permite ejecutar consultas de forma interactiva en cantidades masivas de datos, por ejemplo, petabytes. En mi opinión, la mayor ventaja de BigQuery es que no tiene que pensar / preocuparse por la asignación de hardware para lidiar con el tamaño de sus datos. Lo que significa que a medida que aumenta el tamaño de los datos, no tiene que pensar en la configuración del hardware (tamaño de la memoria y del disco).
-
Modelo de programación: el modelo de programación de Dataflow tiene un sesgo funcional en comparación con un modelo clásico de MapReduce. Hay muchas similitudes entre Spark y Dataflow en términos de primitivas de API. Cosas a considerar: 1) El lenguaje de programación principal de Dataflow es Java. Hay un SDK de Python en proceso. El SDK de Dataflow Java es de código abierto y se ha adaptado a Scala. Actualmente, Spark tiene más opciones de superficies de SDK con GraphX, Streaming, Spark SQL y ML. 2) Dataflow es un modelo de programación unificado para el desarrollo de DAG basado en streaming y por lotes. El objetivo era eliminar la complejidad y el cambio de costos al moverse entre modelos por lotes y de transmisión. El mismo gráfico se puede ejecutar sin problemas en cualquier modo. 3) En la actualidad, Cloud Dataflow no admite la ejecución de gráficos convergentes / iterativos. Si necesita el poder de algo como MLib, Spark es el camino a seguir. Tenga en cuenta que este es el estado actual de las cosas.
-
Streaming y Windowing: Dataflow (basado en el modelo de programación unificado) se diseñó para ser un entorno de ejecución altamente confiable, duradero y escalable para el streaming. Una de las diferencias clave entre Dataflow y Spark es que Dataflow le permite procesar datos fácilmente en términos de su tiempo real del evento en lugar de procesarlos únicamente en su momento de llegada al gráfico. Puede crear ventanas de datos en ventanas fijas, deslizantes, de sesión o personalizadas según la hora del evento o la hora de llegada. Dataflow también proporciona activadores (aplicados a Windows) que le permiten controlar cómo desea manejar los datos que llegan tarde. Net-net marca el nivel de control de corrección para satisfacer las necesidades de su análisis. Por ejemplo, digamos que tiene un juego móvil que interactúa con 100 nodos de borde. Estos nodos crean eventos de 10000 en segundo lugar relacionados con el juego. Digamos que un grupo de nodos no puede comunicarse con su sistema de análisis de transmisión de back-end. En el caso de Dataflow, una vez que llegan los datos, puede controlar cómo le gustaría manejar los datos en relación con las necesidades de corrección de su consulta. Dataflow también brinda la capacidad de actualizar sus trabajos de transmisión mientras están en proceso. Por ejemplo, digamos que descubre un error lógico en una transformación. Puede actualizar su trabajo en vuelo sin perder su estado existente de ventana. Net-net puede mantener su negocio en funcionamiento.
Net-net: – si realmente está haciendo principalmente trabajo de estilo ETL (filtrado, modelado, unión, …) o estilo por lotes, MapReduce Dataflow es un excelente camino si desea un mínimo de devOps.
– si necesita implementar gráficos de estilo ML, siga el camino de Spark y pruebe Dataproc – si está haciendo ML y primero necesita hacer ETL para limpiar sus datos de entrenamiento, implemente un híbrido con Dataflow y Dataproc – si necesita interactividad Spark es una opción sólida, pero también lo es BigQuery si puede expresar sus consultas en SQL; si necesita procesar sus trabajos ETL o MR a través de transmisiones, Dataflow es una opción sólida.
Entonces … ¿cuáles son sus escenarios?
Probé ambos:
Dataflow es todavía muy joven, no hay una solución “lista para usar” para hacer ML con él (aunque podría implementar algoritmos en transformaciones), podría enviar los datos de los procesos al almacenamiento en la nube y leerlos más tarde con otro herramienta.
Se recomendaría Spark, pero tendría que administrar su clúster usted mismo. Sin embargo, existe una buena alternativa: Google Dataproc
Puede desarrollar herramientas de análisis con Spark e implementarlas con un comando en su clúster, dataproc administrará el clúster en sí sin tener que modificar la configuración.
He creado código usando Spark, DataFlow. Déjame poner mis pensamientos.
Spark / DataProc: he usado mucho Spark (Pyspark) para ETL. Puede utilizar SQL y cualquier lenguaje de programación de su elección. Hay muchas funciones disponibles (incluidas las funciones de ventana). Cree su marco de datos y escriba su transformación y puede ser súper rápido. Una vez que los datos se almacenan en caché, cualquier operación en el marco de datos será rápida.
Simplemente puede crear una tabla externa de colmena en el GCS. Luego, puede usar Spark para ETL y cargar datos en Big Query. Esto es para el procesamiento por lotes.
Para la transmisión, puede usar Spark Streaming y cargar datos en Big query.
Ahora, si ya tiene un clúster, debe pensar si debe pasar a la nube de Google o no. Encontré que la oferta de Data proc (Google Cloud Hadoop / Spark) es mejor ya que no tiene que preocuparse por muchas administraciones de clústeres.
DataFlow: se conoce como haz de apache. Aquí puede escribir su código en Java / Python o en cualquier otro idioma. Puede ejecutar el código en cualquier marco (Spark / MR / Flink). Este es un modelo unificado. Aquí puede realizar tanto el procesamiento por lotes como el procesamiento de Stream Data.