¿Hadoop MapReduce está muerto y será reemplazado por Apache Spark?

De ningún modo. Tanto Spark como Hadoop se complementan y tienen sus propios casos de uso. Respondí esa pregunta varias veces, pero aquí voy de nuevo. La velocidad no es el único factor a considerar al diseñar la aplicación. Por supuesto, esto es deseable de lograr, pero a veces el costo también tiene sentido. MapReduce es lento cuando varios trabajos se unen o un trabajo se realiza en varias iteraciones. En ese caso, cada resultado intermedio se almacena y recupera del disco, lo que lo hace lento. Spark superó esto utilizando RAM de manera eficiente para resultados intermedios, lo que lo hace adecuado para algoritmos como KMeans u otros algos de IA que pasan por múltiples iteraciones. Pero una mayor RAM viene con el precio. Eche un vistazo a Azure con una máquina de RAM baja y alta para ver la diferencia de precio. En algún momento necesitamos procesar los resultados en lotes y los resultados se necesitan, por ejemplo, 1 día o después de la semana, como un producto que recomienda calcular los productos para sus suscriptores y enviar los resultados cada semana. Para dicha aplicación, Spark será excesivo ya que calculará los resultados en 10 minutos, pero la mayor parte del tiempo restante permanecerá inactivo (más tiempo de clúster significa más costo). Entonces, un maltrato de Hadoop tiene sentido. Si los resultados se calculan en hardware de bajo costo de RAM bajo en aproximadamente 15 horas, pero como los resultados son necesarios en 1 día o 1 semana, tiene sentido reducir el costo.

Software de gestión de casos legales

Sí, MapReduce ya es reemplazado por Spark en proyectos greenfield.

Para los sistemas existentes, una vez que se alcanza el límite de rendimiento de MapReduce, hay dos maneras: agregar más hardware o migrar a Spark. Obviamente, la decisión comercial depende de muchos factores y MapReduce todavía se está utilizando.

El simple hecho de que Spark puede soportar tanto el procesamiento por lotes como en tiempo real con casi el mismo código significa que en los próximos 10 años deberíamos esperar que MapReduce sea obsoleto, ya que considero que MR es una solución de fuerza brutal en primer lugar, pero en última instancia no es una batalla a muerte que solo uno puede ganar, porque obviamente también depende de las habilidades que ya están disponibles para la compañía y los trabajos de MR que ya se han desarrollado y se usan regularmente, el cambio a Spark costaría un gran cantidad de tiempo, habilidades e inversiones financieras.

No hace falta mencionar que la MR a veces es la mejor opción para tantos problemas si se usa correctamente.

No, no reemplazará completamente a Hadoop, ya que ambos tienen una velocidad de procesamiento diferente, pero habrá un cambio de uso.

Hadoop seguirá siendo el procesamiento por lotes “lento”, mientras que la chispa será el procesamiento por lotes “rápido”. Con la transición del hardware a ssd y centrada en la memoria, habrá más chispa de priorización de aplicaciones que el uso de Hadoop.

Creo que es seguro, porque Spark puede hacer todo lo que un Hadoop Map Reduce puede hacer, e incluso en un mínimo de 10 veces menos tiempo y también otorga la tolerancia a fallas. Proporciona APi en 4 idiomas principales como: Java, Scala, Python, R. ¡Por lo tanto, ya se está convirtiendo en un hecho para el procesamiento de grandes datos!