¿Alguien considera que Cascading for Hadoop Map Reduce es útil?
(8)
Creo que el lugar en el que comienzan a mostrarse las ventajas de Cascading son los casos en los que tiene una pila de funciones simples que deben mantenerse separadas en el código fuente, pero que se pueden recopilar en una composición en su asignador o reductor. Ponerlos juntos hace que su código básico de reducción de mapas sea difícil de leer, separarlos hace que el programa sea realmente lento. El optimizador de Cascading puede juntarlos aunque los escriba por separado. Pig y hasta cierto punto Hive también puede hacer esto, pero para programas grandes, creo que Cascading tiene una ventaja de mantenibilidad.
En unos pocos meses, Plume puede ser un competidor de expresividad, pero si tiene programas reales para escribir y ejecutar en un entorno de producción, entonces Cascading es probablemente su mejor opción.
He intentado en cascada, pero no puedo ver ninguna ventaja sobre el enfoque clásico de reducción de mapas para escribir trabajos.
Map Reduce jobs me da más libertad y Cascading parece estar poniendo muchos obstáculos.
Podría hacer un buen trabajo para hacer cosas simples simples, pero complejas. Las encuentro extremadamente difíciles.
Se me escapa algo. ¿Existe una ventaja obvia de la conexión en cascada sobre el enfoque clásico?
¿En qué escenario debería elegir el método clásico en cascada? ¿Alguien lo usa y feliz?
Enseño el curso de Hadoop Boot Camp para Scale Unlimited, y también hago un uso extensivo de Cascading en Bixo y para crear aplicaciones de minería web en Bixo Labs, por lo que creo que aprecio mucho ambos enfoques.
La mayor ventaja que veo en Cascading es que le permite pensar en su flujo de trabajo de procesamiento de datos en términos de operaciones en campos, y para (principalmente) evitar preocuparse por la forma de transponer esta visión del mundo al modelo clave / valor que es Parte intrínseca de cualquier implementación map-reduce.
El mayor desafío con Cascading es que es una forma diferente de pensar acerca de los flujos de trabajo de procesamiento de datos, y hay una correspondiente "joroba" conceptual que debe superar antes de que todo empiece a tener sentido. Además, los mensajes de error pueden recordar a uno de los resultados de lex / yacc ("conflicto en shift / reduce") :)
- Ken
He estado usando Cascading durante un par de años. Me parece extremadamente útil. En última instancia, se trata de ganancias de productividad. Puedo ser mucho más eficiente en la creación y el mantenimiento de trabajos M / R en comparación con el código Java simple. Aquí hay algunas razones por las que:
- Mucho del código de caldera usado para comenzar un trabajo ya está escrito para usted.
- Composabilidad. En general, el código es más fácil de leer y más fácil de reutilizar cuando se escribe como componentes (operaciones) que se unen para realizar un procesamiento más complejo.
- Me parece que las pruebas unitarias son más fáciles. Hay ejemplos en el paquete en cascada que demuestran cómo escribir pruebas unitarias simples para probar directamente la salida de flujos.
- El paradigma Tap (fuente y sumidero) facilita el cambio de entrada y salida de un trabajo, por lo que puede, por ejemplo, comenzar con la salida a STDOUT para desarrollo y depuración y luego cambiar a archivos de secuencia HDFS para trabajos por lotes y luego cambiar a Un toque de HBase para actualizaciones en tiempo pseudo-real.
- Otra gran ventaja de escribir trabajos en cascada es que realmente estás escribiendo más de una fábrica que crea empleos. Esto puede ser una gran ventaja cuando necesita construir algo dinámicamente (es decir, los resultados de un trabajo controlan qué trabajos subsiguientes crea y ejecuta). O, en otro caso, necesitaba crear un trabajo para cada combinación de 6 variables binarias. Se trata de 64 puestos de trabajo que son todos muy similares. Esto sería una molestia con solo hadoop map reduce las clases.
Si bien hay muchos componentes precompilados que puede componer juntos, si parece que una sección particular de su lógica de procesamiento sería más fácil escribir solo en Java directo, siempre puede crear una función en cascada para envolver eso. Esto le permite tener los beneficios de la conexión en cascada, pero las operaciones muy personalizadas pueden escribirse como funciones simples de java (implementando una interfaz en cascada).
La conexión en cascada le permite utilizar nombres de campo y tuplas simples en lugar de los tipos primitivos ofrecidos por Hadoop, que "... tienden a estar en el nivel incorrecto de granularidad para crear código sofisticado y altamente composible que se puede compartir entre diferentes desarrolladores" ( Tom White , Hadoop La Guía Definitiva ). Cascada fue diseñado para resolver esos problemas. Tenga en cuenta que algunas de las aplicaciones como Cascading, Hive, Pig, etc, se desarrollaron en paralelo y algunas veces hacen lo mismo. Si no te gusta la conexión en cascada o te resulta confuso, ¿quizás sería mejor usar otra cosa?
Estoy seguro de que ya tienes esto, pero aquí está la guía del usuario: http://www.cascading.org/1.1/userguide/pdf/userguide.pdf . Proporciona un recorrido decente del flujo de datos en una aplicación en cascada típica.
Teniendo en cuenta que soy el autor de Cascading ...
Mi sugerencia es usar Pig o Hive si tienen sentido para su problema, especialmente Pig.
Pero si usted está en el negocio de los datos, y no solo busca datos en busca de información, encontrará que el enfoque en cascada tiene mucho más sentido para la mayoría de los problemas que MapReduce.
Tu primer obstáculo con MapReduce en bruto estará pensando en MapReduce. Los problemas triviales son simples en MapReduce, pero es mucho más fácil desarrollar aplicaciones complejas si puede trabajar con un modelo que se asigne más fácilmente a su dominio de problemas (filtre esto, analícelo, ordénelo, únase al resto, etc.).
A continuación, se dará cuenta de que una unidad de trabajo normal en Hadoop consiste en varios trabajos de MapReduce. El encadenamiento de trabajos es un problema solucionable, pero no debe filtrarse en el código de nivel de dominio de su aplicación, debe estar oculto y ser transparente.
Además, encontrará que la refactorización y la creación de códigos reutilizables son mucho más difíciles si tiene que mover continuamente las funciones entre los asignadores y los reductores. o desde los mapeadores al reductor anterior para obtener una optimización. Lo que lleva al tema de la fragilidad.
Cascading cree en fallar lo más rápido posible. El planificador intenta resolver y satisfacer las dependencias entre todos esos nombres de campo antes de que el clúster de Hadoop incluso participe en el trabajo. Esto significa que el 90% o más de todos los problemas se encontrarán antes de las horas de espera para que su trabajo lo encuentre durante la ejecución.
Puede aliviar esto en el código de MapReduce sin procesar creando objetos de dominio como Persona o Documento, pero muchas aplicaciones no necesitan todos los campos en el futuro. Considere si necesita la edad promedio de todos los hombres. No desea pagar la multa de IO por pasar a una Persona completa por la red cuando todo lo que necesita es un género binario y una edad numérica.
Con una semántica de falla rápida y un enlace vago de sumideros y fuentes, se vuelve muy fácil construir marcos en cascada que crean flujos en cascada (que se convierten en muchos trabajos de Hadoop MapReduce). Un proyecto en el que actualmente estoy involucrado termina con cientos de trabajos de MapReduce por ejecución, muchos de ellos creados sobre la marcha en función de los comentarios de los datos que se procesan. Busque Cascalog para ver un ejemplo de un marco basado en Clojure para simplemente crear procesos complejos. O Bixo para un conjunto de herramientas y un marco para la minería web que es mucho más fácil de personalizar que Nutch.
Finalmente, Hadoop nunca se usa solo, eso significa que sus datos siempre se extraen de alguna fuente externa y se envían a otra después del procesamiento. El secreto sucio de Hadoop es que es un marco ETL muy efectivo (por lo que es una tontería escuchar a los proveedores de ETL hablar sobre el uso de sus herramientas para insertar / extraer datos en / desde Hadoop). La conexión en cascada alivia este dolor de alguna manera al permitirle escribir sus operaciones, aplicaciones y pruebas unitarias independientemente de los puntos finales de integración. La conexión en cascada se utiliza en la producción para cargar sistemas como Membase, Memcached, Aster Data, Elastic Search, HBase, Hypertable, Cassandra, etc. (Desafortunadamente, no todos los adaptadores han sido liberados por sus autores).
Si lo desea, envíeme una lista de los problemas que está experimentando con la interfaz. Estoy buscando constantemente mejores formas de mejorar la API y la documentación, y la comunidad de usuarios siempre está ahí para ayudar.
Trabajé en cascada durante un par de años y a continuación son útiles las cosas en cascada .
1. code testability
2. easy integration with other tools
3. easily extensibile
4. you will focus only on business logic not on keys and values
5. proven in production and used by even twitter.
Recomiendo que la gente use la mayoría de las veces en cascada.
Usé Cascading with Bixo para escribir el canal completo de clasificación de enlaces anti-spam para una gran red social.
El gasoducto en cascada resultó en 27 trabajos de MR, que habrían sido muy difíciles de mantener en MR simple. He escrito trabajos de MR anteriormente, pero usar algo como en cascada se siente como cambiar de Assembler a Java (insert_fav_language_here).
Una de las grandes ventajas sobre Hive o Pig IMHO es que la conexión en cascada es un solo frasco, que se combina con su trabajo. Pig y Hive tienen más dependencias (por ejemplo, MySQL) o no son tan fáciles de incrustar.
Descargo de responsabilidad: aunque conozco a Chris Wensel personalmente, realmente creo que Cascading es una patada a **. Teniendo en cuenta su complejidad, es extremadamente impresionante que no haya encontrado un solo error al usarlo.
La conexión en cascada es una envoltura alrededor de Hadoop que proporciona grifos y fregaderos hacia y desde Hadoop.
Escribir Mappers y Reducers para todas tus tareas será tedioso. Intente escribir un trabajo en cascada y luego está listo para evitar escribir cualquier mapeador y reductor.
También desea ver Taps y Esquemas en cascada (así es como ingresa datos en su trabajo de procesamiento en cascada).
Con estos dos, es decir, la capacidad de evitar la escritura ad hoc de Hadoop Mappers con reductores y la capacidad de consumir una gran variedad de fuentes de datos, puede resolver gran parte de su procesamiento de datos de manera muy rápida y efectiva.
La conexión en cascada es más que un simple envoltorio alrededor de hadoop, estoy tratando de mantener la respuesta simple. Por ejemplo, he portado una enorme base de datos mysql que contiene terabytes de datos para registrar archivos usando jdbc tap en cascada