Se preparó una traducción del artículo específicamente para estudiantes del curso de Ingeniero de datos .
Después de que Cloudera y MapR anunciaron hace semanas que su negocio estaba en un momento difícil, vi una serie de publicaciones en las redes sociales con el tema "Hadoop está muerto". Estas publicaciones no son nuevas, pero en un sector donde los expertos técnicos rara vez producen material de alta calidad para redes sociales, estas exclamaciones son cada vez más fuertes. Me gustaría considerar algunos de los argumentos con respecto al estado de Hadoop.
Competencia con gratis
Cloudera tiene sugerencias que ayudan a Hadoop a ser una solución más completa. Estas herramientas aparecieron antes de que los devops se generalizaran, y la implementación automatizada era rara.
Sus herramientas ofrecen excelentes ofertas para más de 2.600 clientes, pero la mayoría del software que ofrecen es de código abierto y gratuito. Cloudera finalmente compite con el software libre. Para colmo, muchos desarrolladores de ecosistemas de Hadoop han trabajado alguna vez en Cloudera, es decir. al final, de alguna manera subsidiaron las ofertas gratuitas con las que compiten.
A medida que compiten con gratis, Cloudera nunca servirá al 100% de la base de usuarios de Hadoop. No me atrevería a usarlos como un indicador de la salud de Hadoop por esta misma razón.
Otras empresas que ofrecen soluciones llave en mano de Spark y Presto están tratando de distanciarse de la marca Hadoop. Sus ofertas pueden incluir cientos de archivos .jar de varios proyectos de Hadoop, pero, sin embargo, estas empresas quieren hacer todo lo posible para evitar la competencia con las ofertas gratuitas, al tiempo que reducen sus costos de desarrollo mediante el uso de software de código abierto. Las ventas no son tan fáciles cuando su cliente puede descargar legalmente el 80% de su oferta sin pagarla.
Competencia con AWS
En 2012, trabajé en la implementación de Hadoop con otros 25 contratistas. Algunos de mis colegas vinieron de Google, otros continuaron trabajando para Cloudera. Estaba involucrado un presupuesto significativo, el equipo produjo muchas horas pagas, pero una parte muy pequeña del ecosistema Hadoop estaba lista.
En unos pocos años, AWS EMR apareció y comenzó a absorber su cuota de mercado. EMR le permite ejecutar clústeres de Hadoop con una amplia variedad de software instalado en solo un par de clics. Puede funcionar en copias puntuales, lo que reduce los costos de equipo en ~ 80%, y puede almacenar datos en S3, que era y sigue siendo barato y confiable en 99.9999999999%.
De repente, la necesidad de 25 contratistas en el proyecto desapareció. En algunos proyectos, solo yo, un trabajador a tiempo completo y varios otros a tiempo parcial, preparando la infraestructura además de nuestras otras responsabilidades, podría estar involucrado. Todavía es necesario que los consultores de proyectos utilicen AWS EMR, pero el potencial de facturación general para este tipo de trabajo es mucho menor que hace unos años.
¿Qué parte del negocio potencial de Cloudera se perdió a favor de EMR? Cloudera hizo un buen trabajo al configurar y administrar clústeres de metal desnudo, pero hoy en día la mayor parte del mundo de los datos está en la nube. Vale la pena considerar cuán atractivo es Hadoop para su negocio, aunque solo sea porque AWS tiene una oferta administrada con copias puntuales.
¿Qué es el Hadoop?
Si me preguntaras la definición de Hadoop, diría que es una gran colección de software de código abierto que se integra hasta cierto punto y tiene varias bibliotecas comunes. Veo Hadoop como una base de datos particionada, casi como una distribución de datos del sistema operativo.
No todos los proyectos de software patrocinados por Hadoop son proyectos de Apache. Presto es una de esas excepciones. Otros, como ClickHouse, con próxima compatibilidad con HDFS y Parquet, no serán percibidos por muchos como un proyecto de Hadoop, aunque pronto marcarán el gráfico de compatibilidad.
Hasta 2012, no había archivos ORC ni Parquet. Estos formatos contribuyeron a la implementación de análisis rápidos en Hadoop. Antes de estos formatos, las cargas de trabajo estaban orientadas principalmente a la línea. Si necesita convertir terabytes de datos y puede hacerlo en paralelo, Hadoop hará el trabajo perfectamente. MapReduce fue un marco utilizado a menudo para este propósito.
Para lo que se ofreció el almacenamiento de columnas es un análisis de terabytes de datos en cuestión de segundos. Lo que resultó ser una propuesta más valiosa para un mayor número de empresas. Los científicos de datos pueden necesitar solo una pequeña cantidad de datos para hacerse una idea, pero primero necesitarán mirar potencialmente petabytes de datos para elegir los correctos. El análisis de columnas es crucial para ellos en su fluidez en el procesamiento de datos necesarios para comprender lo que se debe seleccionar.
MapReduce tiene dos operadores de procesamiento de datos funcionales, mapear y reducir, y trata los datos como cadenas. Spark lo sigue inmediatamente y tiene operadores más funcionales, como filtro y unión, y percibe los datos estructurados en un gráfico acíclico dirigido (Gráfico acíclico directo - DAG). Estos elementos permitieron a Spark ejecutar cargas de trabajo más complejas, como el aprendizaje automático y el análisis gráfico. Spark todavía puede usar YARN como un planificador de capacidad, al igual que las tareas en MapReduce. Pero el equipo de Spark también comenzó a construir su propio planificador y luego agregó soporte para Kubernetes.
En algún momento, la comunidad Spark intentó distanciarse del ecosistema Hadoop. No querían ser vistos como un complemento sobre el software Legacy o como una especie de "complemento" para Hadoop. Dado el nivel de integración que Spark tiene con el resto del ecosistema de Hadoop y las cientos de bibliotecas de otros proyectos de Hadoop utilizados por Spark, no estoy de acuerdo con la opinión de que Spark es un producto independiente.
MapReduce puede no ser la primera opción para la mayoría de las cargas de trabajo en estos días, pero sigue siendo el entorno base cuando se utiliza hadoop distcp, un paquete de software que puede transferir datos entre AWS S3 y HDFS
más rápido que cualquier otra oferta I probado
¿Todas las herramientas de Hadoop son exitosas?
No, hay algunos proyectos que ya han eclipsado los nuevos elementos.
Por ejemplo, muchas cargas de trabajo que anteriormente estaban automatizadas con Oozie ahora están automatizadas con Airflow. Robert Kanter, el desarrollador principal de Oozie, proporcionó una parte significativa de la base de código que existe hoy en día. Desafortunadamente, Robert ya no tomó una parte tan activa en el proyecto desde que abandonó Cloudera en 2018. Mientras tanto, Airflow tiene más de 800 participantes, cuyo número casi se ha duplicado durante el año pasado. Casi todos los clientes con los que trabajé desde 2015 utilizaron Airflow en al menos un departamento de sus organizaciones.
Hadoop proporciona los diversos elementos básicos y elementos que componen la plataforma de datos. A menudo, varios proyectos compiten por la provisión de la misma funcionalidad. Al final, algunos de estos proyectos se desvanecen mientras que otros toman la delantera.
En 2010, hubo varios proyectos que se posicionaron como la primera opción para diversas cargas de trabajo, en los que solo había unos pocos participantes o, en algunos casos, varios despliegues significativos. El hecho de que estos proyectos vayan y vengan se utilizó como evidencia de que todo el ecosistema de Hadoop está muriendo, pero no extraigo tales conclusiones de esto.
Veo esta débil asociación de proyectos como una forma de desarrollar muchas funciones poderosas que se pueden usar sin tarifas significativas de licencia para el usuario final. Este es el principio de supervivencia del más apto, y demuestra que para cada problema se consideró más de un enfoque.
ACTUALIZACIÓN: Inicialmente dije que Oozie tenía 17 miembros basados en lo que se informa en GitHub. De hecho, Oozie tenía confirmaciones directas y parches enviados por 152 desarrolladores, y no solo 17 que aparecen en el cálculo de GitHub. Robert Kanter me contactó después de la publicación inicial de esta publicación con evidencia de estos 135 autores adicionales, y le agradezco por esta aclaración.
El tráfico de búsqueda no funciona
Uno de los argumentos a favor de la "muerte" de Hadoop es que el tráfico de búsqueda de Google en varias tecnologías de Hadoop no funciona. Cloudera y otros consultores han realizado un buen trabajo de recaudación de fondos en los últimos años y han realizado esfuerzos significativos para avanzar en sus propuestas. Esto, a su vez, despertó un gran interés, y en algún momento una ola de personas que estudiaban estas tecnologías apareció en la comunidad técnica. Esta comunidad es diversa y, en algún momento, la mayoría de las personas, como siempre, se trasladaron a otras cosas.
En toda la historia de Hadoop, no había una variedad tan rica de funcionalidad como la que se ofrece hoy en día, y nunca antes había sido tan estable y probada en la batalla.
Los proyectos de Hadoop consisten en millones de líneas de código escritas por miles de autores. Cada semana, cientos de desarrolladores trabajan en varios proyectos. La mayoría de las ofertas de bases de datos comerciales tienen suerte si al menos un puñado de ingenieros realiza mejoras significativas en sus bases de datos de códigos cada semana.
¿Por qué es especial Hadoop?
Primero, hay clústeres HDFS con una capacidad de más de 600 PB. La naturaleza de los metadatos HDFS en RAM significa que puede procesar fácilmente 60k operaciones por segundo.
AWS S3 ha roto mucho de lo que se puede encontrar en los sistemas de archivos POSIX para lograr escalabilidad. Los cambios rápidos de archivos, como los necesarios al convertir archivos CSV a archivos de Parquet, no son posibles en S3 y requieren algo como HDFS si desea distribuir la carga de trabajo. Si el software de conversión se modificó para hacer la carga de trabajo S3 solo mencionada anteriormente, es probable que las compensaciones con la localidad de datos sean significativas.
En segundo lugar, el proyecto Hadoop Ozone tiene como objetivo crear un sistema compatible con API S3 que pueda almacenar billones de objetos en un clúster sin la necesidad de usar su propio servicio en la nube. El objetivo del proyecto es contar con soporte integrado para Spark y Hive, lo que le brinda una buena integración con el resto del ecosistema Hadoop. Una vez lanzado, este software será una de las primeras ofertas de código abierto que puede almacenar tantos archivos en un clúster.
En tercer lugar, incluso si no trabaja con petabytes de datos, las API disponibles para usted en el ecosistema de Hadoop proporcionan una interfaz consistente para procesar gigabytes de datos. Spark es la solución definitiva para el aprendizaje automático distribuido. Tan pronto como se sienta cómodo con la API, no importa si su carga de trabajo se mide en GB o PB, el código que cree no necesita ser reescrito, solo necesita más máquinas para ejecutarlo. Primero le enseñaría a alguien cómo escribir código SQL y PySpark, y luego le enseñaría cómo distribuir comandos AWK en múltiples máquinas.
Cuarto, muchas de las características del ecosistema Hadoop son líderes para proveedores comerciales. Cada movimiento de marketing fallido para una base de datos patentada lleva al departamento de ventas a descubrir cuántas características faltantes, compensaciones y cuellos de botella hay en su oferta. Cada falla de POC hace que el equipo de ventas descubra qué tan confiables son sus pruebas internas de software.
Esto concluye la primera parte de la traducción. La continuación se puede
leer aquí . Y ahora estamos esperando sus comentarios e invitamos a todos a un seminario web gratuito sobre el tema:
"Principios para construir sistemas de análisis de transmisión" .