Description
Todo lo que sabés sobre correr un programa asume que entra en una sola computadora, y en el momento en que los datos no entran, cada una de esas suposiciones se rompe en silencio. Un archivo más grande que cualquier disco. Un job que una laptop terminaría en una semana, que tiene que terminar antes del reporte de la mañana. Una máquina del cluster que se muere a mitad de la corrida, una noche en que ya se murieron otras tres, y se supone que el batch sobrevive eso sin vos despierto. Heredaste un estate de Hadoop de diez años, que guarda los números con los que finanzas cierra el trimestre, y no lo podés entender de tanto leer porque las ideas de abajo no son las que aprendiste en una sola máquina. Qué es un archivo, cuando está partido entre doscientas máquinas y copiado tres veces. Qué es un programa, cuando tiene que correr al lado de los datos en vez de traer los datos hacia él. Quién decide qué máquina hace qué pedazo del trabajo, y qué pasa cuando esa máquina ya está ocupada. Por qué una query de SQL que escribiste en Hive tarda cuarenta minutos cuando la misma query en una base normal tarda un segundo. Nadie te avisó que el big data no es una versión más grande del problema que conocés; es un problema distinto, y las herramientas que reemplazaron a Hadoop, Spark y los cloud warehouses, están todas construidas sobre las mismas ideas que Hadoop te obligó a aprender primero.
Este libro te lleva de alguien que solo corrió programas en una sola máquina a alguien que entiende, en el cuerpo, cómo se guardan y se procesan los datos a una escala que ningún servidor solo puede aguantar. Es honesto sobre dónde está Hadoop en 2026: es un stack maduro, pasó su pico, y para un proyecto nuevo casi siempre irías por Spark o un cloud warehouse en su lugar. Pero las ideas de storage distribuido y compute distribuido que Hadoop inventó no desaparecieron; Spark, BigQuery, Snowflake y todos los lakehouse las heredaron, y no vas a entender de verdad esas herramientas hasta que hayas visto los originales sin vueltas. Y hay una segunda razón para aprenderlo: estates enormes y viejos siguen corriendo sobre Hadoop, en bancos, telcos y gobiernos, guardando los datos de los que esos negocios dependen, y el ingeniero que de verdad puede operar uno es raro y bien pago justamente porque a todos los demás les da miedo. Vas a trabajar un problema real a lo largo de todo el libro, una operadora de celulares que se llama Meridian y que tiene que convertir una manguera de registros de llamadas y clickstream en los números con los que anda el negocio, a un volumen que rompió la base de datos única con la que arrancaron. Vas a ver por qué una máquina deja de alcanzar y dónde está de verdad la pared, cómo HDFS guarda un archivo a lo largo de un cluster y sobrevive a discos que se mueren cada semana manteniendo copias, cómo MapReduce expresa un cómputo como trabajo que corre al lado de los datos y dónde ese modelo choca contra sus límites, cómo YARN decide quién se queda con qué máquina cuando todos quieren el cluster a la vez, cómo Hive te deja escribir SQL sobre archivos que no son una base de datos y por qué esa query es lenta, y cómo los formatos de archivo, el particionado y el storage columnar convierten en silencio a un cluster de Hadoop en el lakehouse moderno que Spark y la nube consultan hoy. Para el final no solo vas a poder mantener vivo el estate de Meridian; vas a entender los fundamentos de los datos distribuidos que sobreviven al propio Hadoop, así la próxima herramienta que aprendas es una variación de ideas que ya tenés. Para el ingeniero que tiene que laburar a una escala que un solo servidor no aguanta, y quiere ser la persona a la que el negocio le confía hacerlo.
¿Este libro es para vos?
Este libro es para: el ingeniero al que acaban de plantar frente a un cluster de Hadoop que nadie quiere administrar, que escribe SQL y Python sin problema pero nunca laburó con datos que no entran en una sola máquina, y que necesita entender qué hacen de verdad HDFS, MapReduce, YARN y Hive antes de poder confiar en un número, arreglar un job lento, o explicarle a un jefe por qué el batch de la noche volvió a no llegar a su ventana.
Lo que lo hace distinto
Los 6 pasos para volverte el ingeniero raro y bien pago al que le confían lo que nadie más se anima a tocar. El método que te lleva de correr programas en una sola máquina a entender cómo se guardan y se procesan los datos a una escala que ningún servidor solo puede aguantar. Cuando los datos dejan de entrar en una máquina, cada suposición que tenés sobre archivos, programas y fallas se rompe en silencio, y necesitás otro modelo mental. Vas a trabajar un problema real de batch de big data de punta a punta y vas a ver sin vueltas cómo un archivo vive a lo largo de un cluster y sobrevive a discos que se mueren, cómo un cómputo corre al lado de los datos en vez de traerlos, quién decide qué máquina hace qué trabajo, y cómo el SQL y los archivos columnares convierten un cluster crudo en el lakehouse que consultan las herramientas modernas. Son los fundamentos de datos distribuidos que heredaron Spark y los cloud warehouses, así la próxima herramienta que aprendas es una variación de ideas que ya tenés.
- Descubrí dónde una máquina deja de alcanzar, y dónde está de verdad la pared
- Guardá un archivo a lo largo de un cluster y sobreviví a discos que se mueren cada semana
- Corré un cómputo al lado de los datos en vez de traer los datos hacia vos
- Decidí quién se queda con qué máquina cuando todos quieren el cluster a la vez
- Escribí SQL sobre archivos que no son una base de datos, y sabé por qué es lento
- Convertí un cluster crudo en el lakehouse que consultan las herramientas modernas
Con qué te vas a quedar
- Capítulo 1: La noche en que el batch no llegó a terminar antes de la mañana
- Capítulo 2: En mi laptop el job terminaría en una semana, pero tiene que estar listo para las seis
- Capítulo 3: Un disco del cluster se muere cada semana. ¿Por qué mi archivo sigue ahí a la mañana?
- Capítulo 4: Mover los datos es la parte lenta. ¿Y si el programa fuera hacia los datos?
- Capítulo 5: Mi job se queda ahí diciendo ACCEPTED. ¿Quién decide cuándo corre de verdad?
- Capítulo 6: Yo ya sé SQL. ¿Por qué la misma query acá tarda cuarenta minutos?
- Capítulo 7: La query lee un terabyte para responder algo de un solo día. ¿Puede leer menos?
- Capítulo 8: El estate que nadie quería, y en qué me convirtió operarlo
