1  ¿Por qué Linux domina el mundo del Big Data?

Fundamentos del sistema operativo que sostiene Hadoop, Spark y la nube moderna

big-data
linux
ubuntu
wsl
Autor/a

Wilder Ramírez Delgado

Fecha de publicación

8 de septiembre de 2026

Si mañana te entregan las llaves de un clúster, no empezarás por un dashboard bonito: empezarás por una terminal. En este capítulo entenderás por qué Linux es el cimiento silencioso de Hadoop, Spark, Kafka y casi toda la infraestructura moderna de datos — y dejarás Ubuntu 24.04 LTS listo para trabajar.

Tiempo estimado de lectura: 40 minutos

Nivel: Básico

Requisitos: - Un equipo con Windows 10 u 11 (ruta principal con WSL2), o una máquina con Ubuntu ya instalado - Permisos para instalar software en tu equipo, cuando aplique - Ganas de entender la infraestructura, no solo de memorizar comandos

Tecnologías utilizadas: - Ubuntu 24.04 LTS (ruta principal) - Ubuntu 22.04 LTS (alternativa compatible) - WSL2 - Bash - PowerShell (solo para instalar y gestionar WSL en Windows)

Antes de empezar

Hay muchas formas de “aprender Big Data”. La más común es saltar directo a una herramienta de moda, copiar un tutorial y esperar que el resto se acomode solo. Esa ruta produce demos. Rara vez produce criterio.

Este libro propone otra ruta: cada capítulo se puede leer de corrido, practicarse como laboratorio y consultarse años después, cuando la herramienta de turno ya haya cambiado de nombre.

La promesa no es enseñarte un stack completo en una tarde. La promesa es más ambiciosa y más útil: formar la manera de pensar de quien diseña, opera y diagnostica plataformas de datos.

Empezamos por Linux por una razón incómoda y liberadora a la vez: sin él, el resto del ecosistema es teatro. Hadoop, Spark, Kafka, Airflow, Docker y Kubernetes no “viven en la nube” como abstracción mágica. Viven como procesos, archivos, puertos, usuarios y logs sobre un sistema operativo. Casi siempre, ese sistema operativo es Linux.

Para pensar: si mañana te dan acceso a un clúster y solo puedes usar una herramienta durante la primera hora, ¿abrirías un IDE… o una terminal?

Este capítulo no supone conocimientos previos de Big Data y es la primera pieza del recorrido.

Cómo leer este capítulo

Lee primero. Ejecuta después. Modifica al final.

El ritmo recomendado es simple:

  1. Lee la explicación hasta entender el porqué.
  2. Observa el comando y la consola a la que pertenece.
  3. Ejecuta solo cuando sepas qué debería ocurrir.
  4. Cambia un parámetro y observa el efecto.

PowerShell no es Bash

En este capítulo aparecen dos consolas distintas. No las mezcles:

Consola Dónde Para qué en este capítulo
PowerShell Windows Instalar y gestionar WSL
Bash Ubuntu (dentro de WSL2 o nativo) Todo el trabajo en Linux

Si un bloque dice PowerShell, ábrelo en Windows. Si dice Bash, ábrelo en Ubuntu.

Único laboratorio extenso

Aquí no hay un catálogo interminable de comandos. El único laboratorio largo es la instalación y configuración inicial de Ubuntu 24.04 LTS sobre WSL2. El resto son verificaciones cortas y seguras.

Directorio de práctica

Todo el trabajo práctico de este capítulo ocurre dentro de:

~/bigdata_linux_lab

No borramos archivos del sistema. No tocamos configuraciones críticas. Ningún bloque usa sudo sin avisarte. Si un paso requiere privilegios, lo verás marcado con claridad y lo decidirás tú.

Objetivos de este capítulo

Cuando termines, deberías ser capaz de:

  • explicar por qué Linux domina el ecosistema Big Data
  • instalar Ubuntu 24.04 LTS con WSL2 (o verificar un entorno ya existente)
  • describir la arquitectura Usuario → Shell → Kernel → Hardware
  • orientarte en el sistema de archivos de Linux
  • entender qué es una terminal, un shell y variables como HOME y PATH

Lo que deliberadamente no cubriremos aquí —anatomía profunda de comandos, pipes, filtros y el mini-proyecto de consola— vive en el siguiente capítulo: Dominando la terminal para Big Data.

1. ¿Qué construiremos en este libro?

No empezamos por Spark.

Suena contraintuitivo. Spark es atractivo, rápido de demostrar y luce bien en un portafolio. También es una mala primera piedra si aún no entiendes el sistema donde se ejecuta.

Una plataforma moderna de datos no es una herramienta: es una arquitectura por capas. Cada capa resuelve un problema distinto. Cuando una falla, necesitas saber en qué piso del edificio estás mirando.

En este libro construiremos esa arquitectura de abajo hacia arriba. Linux es el cimiento. Encima aparecerán los contenedores, el sistema de archivos distribuido, el gestor de recursos del clúster y los motores de procesamiento: MapReduce, Spark y PySpark.

En producción… el onboarding de un ingeniero de datos casi nunca empieza por “abre este notebook de ciencia”. Empieza por “entra al nodo, revisa el servicio y dime qué está pasando”.

Si Linux te parece “demasiado básico” para Big Data, conviene leer este capítulo con especial atención: los incendios caros suelen empezar en lo básico.

Diagrama: el mapa completo del libro

Observa el recorrido completo. No necesitas dominarlo hoy. Necesitas ubicarte.

Recorrido del libro: Linux, Docker, Ecosistema Hadoop, HDFS, YARN, Cliente Spark, MapReduce, Spark y PySpark

Estamos aquí: Linux — el sistema operativo sobre el que vive casi toda la infraestructura de datos.

Tema Pregunta que responde Capítulos
Linux ¿Sobre qué corre todo y cómo se opera desde la terminal? 1–2
Docker ¿Cómo empaqueto y levanto la infraestructura igual en cualquier máquina? 3
Ecosistema Hadoop ¿Qué piezas forman una plataforma Big Data? 4
HDFS ¿Dónde viven los datos y cómo sobreviven a un fallo? 5–6
YARN ¿Quién reparte CPU y memoria del clúster? 7–8
Cliente Spark ¿Desde dónde envío trabajos al clúster? 9
MapReduce ¿Cómo se piensa el procesamiento distribuido? 10–11
Spark ¿Cómo se procesa con un motor moderno? 12–13
PySpark ¿Cómo lo programo en Python? 14–15

Dónde encaja este capítulo en el mapa

Este capítulo te deja con territorio y ventana: el sistema de archivos y la terminal, más un Ubuntu usable.

El siguiente capítulo, Dominando la terminal para Big Data, empieza exactamente donde terminamos: el lenguaje cotidiano de la consola, los pipes y un mini-proyecto real dentro de ~/bigdata_linux_lab.

Más adelante, cuando lleguemos a MapReduce, ese puente no será metafórico. Verás que una tubería de shell y un job distribuido comparten la misma idea: transformar, agrupar, reducir.

Reto corto (mental): elige un caso — sensores IoT, transacciones bancarias, clics de un e-commerce o CDR de telecomunicaciones —. Si el equipo no domina Linux, ¿en qué capa del mapa crees que aparecería el primer incendio operativo?

Si Linux es el cimiento, la siguiente pregunta es inevitable: ¿por qué casi nadie discute alternativas serias para la infraestructura de datos?

2. ¿Por qué Linux domina el mundo del Big Data?

En 2004 Google publicó un artículo breve sobre MapReduce que cambió la forma de procesar información a escala. De esa familia de ideas nacieron sistemas que hoy damos por sentados. Lo que a veces se olvida es más prosaico: esas plataformas no florecieron sobre un escritorio cualquiera. Florecieron sobre servidores Unix-like, y de forma aplastante, sobre Linux.

No es una preferencia estética. Es ingeniería, economía operativa y ecosistema.

Cuando alguien dice “el clúster está caído”, casi nunca está hablando de un botón de Windows. Está hablando de procesos, discos, red, permisos y logs en nodos Linux. Dominar esa capa no te hace administrador de sistemas por accidente: te hace alguien capaz de construir Big Data sin magia.

Pregunta al lector: ¿tu herramienta favorita de datos se instala, opera y depura de forma natural fuera de Linux… o solo “también existe” allí?

¿Qué es Linux realmente?

¿Qué es?
Linux, en sentido estricto, es un kernel: el núcleo del sistema operativo. Administra CPU, memoria, procesos, dispositivos y la comunicación entre el software y el hardware. Lo que la mayoría llama “Linux” en el día a día es en realidad un sistema GNU/Linux: el kernel Linux más herramientas de usuario (shell, compiladores, utilidades) y, encima, una distribución que empaqueta todo eso de forma usable — Ubuntu, Debian, Rocky Linux, Amazon Linux, etc.

¿Por qué existe?
Porque hacía falta un kernel libre, modificable y redistribuible, capaz de correr en hardware real y evolucionar con una comunidad enorme. Linus Torvalds publicó el germen del proyecto a inicios de los años 90; la licencia GPL permitió estudiar, adaptar y compartir mejoras. Eso no es un detalle legal decorativo: es el motor cultural y técnico de su adopción en servidores.

¿Cómo funciona?
Tú no hablas con el disco ni con la red “a pelo”. Hablas con programas. Esos programas piden servicios al kernel mediante llamadas al sistema. El kernel reparte tiempo de CPU, aísla procesos, gestiona memoria y expone dispositivos. La distribución añade el resto: instalador de paquetes, servicios, convenciones de rutas, soporte.

¿Cuándo te importa como ingeniero de datos?
Siempre que instales un motor, leas un log, montes un disco, abras un puerto, lances un contenedor o entres por SSH a un nodo. Si no distingues kernel, distro y shell, terminarás depurando síntomas en el piso equivocado del edificio.

Error común: creer que “saber Linux” es “usar Ubuntu con mouse”. Saber Linux, en datos, es operar el sistema desde la consola con modelo mental.

Línea de tiempo: de Linux a Big Data

La historia importa porque explica el presente: el ecosistema de datos no “eligió Linux” en una reunión de marketing. Creció donde ya había servidores estables, herramientas libres y una cultura de automatización por texto.

Línea de tiempo: del kernel Linux de 1991 a las plataformas modernas de datos

Hito Por qué te importa hoy
Nacimiento del kernel Base técnica común bajo muchas distros
Distros servidor Empaquetado reproducible para máquinas reales
Consolidación en data centers Linux como default operativo
Ecosistema Hadoop/Spark Servicios nativos pensados para Unix/Linux
Contenedores / Kubernetes La unidad de despliegue moderna asume Linux

Curiosidad histórica: el éxito de Linux en infraestructura no vino primero del escritorio. Vino del servidor, donde la estabilidad, la remote-first culture y el costo total de propiedad pesan más que el brillo de una interfaz.

Servidores, supercomputación y nube

Big Data es, antes que un algoritmo, un problema de máquinas coordinadas. Esas máquinas necesitan un sistema operativo predecible, automatizable y observable.

Servidores. En un nodo de clúster instalas paquetes, editas configs, levantas demonios, rotas logs y montas discos. Linux fue adoptado masivamente en ese rol porque combina control fino, scripting y un ecosistema de herramientas de texto que se componen entre sí.

Supercomputación. El cómputo de alto rendimiento históricamente gravitó hacia Unix y, con el tiempo, hacia Linux como plataforma dominante en listados públicos de supercomputadores.

Nube. Las imágenes de máquina, los agentes, los balanceadores y buena parte de los servicios gestionados de datos exponen, debajo de la capa amable, Linux o APIs pensadas a su alrededor. Aunque consumas un servicio “serverless”, alguien está operando Linux por ti.

¿Cuándo te importa?
Cuando eliges una AMI, un nodo de Kubernetes, una imagen Docker o un edge device para ingesta. Tu “stack de datos” hereda las restricciones del SO base.

Sabías que… muchas plataformas comerciales de datos que se venden con interfaz web se administran, en la práctica, con SSH, logs y sistemas de empaquetado Linux cuando algo sale mal de verdad.

Docker, Kubernetes y la estandarización sobre Linux

Si la década anterior consolidó a Linux en servidores, la era de contenedores lo volvió casi inevitable.

¿Qué es un contenedor?
Una forma de empaquetar una aplicación con sus dependencias y ejecutarla de manera aislada sobre el kernel del host. No es una máquina virtual completa; es una unidad de despliegue ligera.

¿Por qué Docker importó tanto?
Porque estandarizó el verbo “correr esto igual en mi laptop y en el servidor”. Y ese verbo se ancló, de forma natural, al mundo Linux.

¿Qué problema resuelve Kubernetes?
Cuando tienes no uno, sino cientos de contenedores, necesitas orquestación: programación, reinicios, escalado, descubrimiento de servicios, límites de recursos. Kubernetes se convirtió en el lenguaje común de esa orquestación en la industria.

¿Cómo se usa en proyectos reales de datos?
Airflow en contenedores, Spark sobre Kubernetes, microservicios de features, consumers de Kafka, jobs de dbt… el patrón se repite: construyes una imagen, la despliegas, observas logs y métricas, y depuras el host cuando el aislamiento no basta.

Para pensar: en el diagrama Usuario → Shell → Kernel → Hardware, ¿dónde ubicarías Docker? (Pista: el contenedor no reemplaza al kernel; lo comparte.)

Linux vs Windows vs macOS para Big Data

Esto no es una guerra de fanáticos. Es una tabla de decisión para quien construye plataformas de datos.

Criterio Linux Windows macOS
Rol dominante en servidores de datos Estándar de facto Marginal para clústeres Hadoop/Spark “clásicos” No es SO de clúster
Hadoop / Spark / Kafka nativos Ecosistema natural Posible con fricción o capas extra Más como cliente de desarrollo que como nodo
Contenedores / Kubernetes Camino principal Mejor vía WSL2/Linux remoto para muchos flujos Buen cliente; producción sigue siendo Linux
Estación de desarrollo Excelente Excelente con WSL2 Excelente como laptop de desarrollo
Automatización por shell / SSH Cultura nativa Existe, distinta Muy buena en local; producción ≠ laptop
Operación de clúster real Cotidiana Poco habitual como SO de nodo de datos No aplica como nodo típico

Lectura práctica:

  • macOS puede ser una estación de trabajo formidable.
  • Windows deja de ser un obstáculo serio gracias a WSL2.
  • Producción de datos masivos — nodos, brokers, workers, orquestadores — sigue hablando Linux.

Buenas prácticas: desarrolla cerca de producción. Si tu laptop es Windows, WSL2 no es un “apaño”: es la forma correcta de acercar tu entorno al clúster.

Distribuciones relevantes y por qué Ubuntu 24.04 LTS

Un mismo kernel, muchos “sabores”. La distribución decide empaquetado, ciclo de soporte, herramientas por defecto y convenciones.

Distro Perfil Cuándo la verás en datos
Ubuntu Amigable, documentación abundante, LTS predecible Labs, muchos servidores, ciencia de datos, cloud images
Debian Estabilidad y sobriedad Bases sólidas; Ubuntu nace de aquí
RHEL / Rocky / Alma Mundo empresarial y soporte formal Clústeres corporativos, vendors tradicionales
Amazon Linux Optimizada para AWS EMR y cargas cloud en ese ecosistema
SUSE Entornos corporativos específicos Menos “default” en tutorials, presente en enterprise

Ruta principal de este libro: Ubuntu 24.04 LTS.
LTS significa Long Term Support: un ciclo largo de actualizaciones de seguridad y estabilidad. Para aprender y para montar laboratorios serios, eso vale oro.

Alternativa compatible: Ubuntu 22.04 LTS.
Si tu entorno ya la tiene instalada y estable, no necesitas romper nada solo por el número de versión. Los conceptos de este capítulo aplican igual. Cuando instales de cero, prefiere 24.04.

Buenas prácticas: documenta la versión exacta de tu distro en un README del laboratorio. En equipos reales, “funciona en mi Linux” no es una frase útil; “Ubuntu 24.04.x” sí lo es.

# Verificación ligera del entorno
# Consola: Bash (Ubuntu / Linux)
# Seguridad: solo lectura. Sin sudo. Sin borrar nada.

set -euo pipefail

echo "=== Identidad del kernel ==="
uname -a

echo
echo "=== Identidad de la distribución ==="
if [ -f /etc/os-release ]; then
  # shellcheck disable=SC1091
  . /etc/os-release
  echo "NAME=${NAME:-desconocido}"
  echo "VERSION=${VERSION:-desconocida}"
  echo "PRETTY_NAME=${PRETTY_NAME:-desconocido}"
else
  echo "No se encontró /etc/os-release en este entorno."
fi

echo
echo "=== Contexto de sesión ==="
echo "USER=${USER:-}"
echo "HOME=${HOME:-}"
echo "SHELL=${SHELL:-}"
echo "PWD=$(pwd)"

echo
echo "=== ¿Existe el directorio de práctica? ==="
if [ -d "${HOME}/bigdata_linux_lab" ]; then
  echo "bigdata_linux_lab=sí"
else
  echo "bigdata_linux_lab=no (se creará en la sección 5)"
fi

echo
echo "Listo. Interpreta esta salida en la siguiente celda."

Lectura de la verificación y puente a la instalación

Copia el bloque anterior en una terminal Bash dentro de Ubuntu (WSL o nativo). No pegues ese bloque en PowerShell: fallará o mentirá.

Qué mirar en la salida real de tu máquina (sin inventar valores aquí):

  1. uname -a — confirma que hay un kernel Linux.
  2. PRETTY_NAME / VERSION — idealmente Ubuntu 24.04 LTS; 22.04 LTS es alternativa válida.
  3. HOME — tu casa en Linux; ahí vivirá bigdata_linux_lab.
  4. Directorio de práctica — si dice no, es normal: lo creamos pronto.

Escenarios típicos

Situación Qué hacer
Ya tienes Ubuntu 24.04 en WSL2 Puedes leer la sección 3 y saltar al final del laboratorio para verificar
Tienes Ubuntu 22.04 estable Compatible; sigue; anota la versión
Estás en Windows sin WSL La sección 4 es tu camino crítico
El bloque falló con errores de sintaxis Lo pegaste en PowerShell o CMD: ábrelo en una terminal de Ubuntu

Caso real: el primer diagnóstico remoto en un equipo de datos suele ser exactamente este: ¿qué kernel?, ¿qué distro?, ¿quién soy?, ¿dónde estoy?

Convencidos del porqué, toca elegir el cómo instalarlo sin romper tu flujo de trabajo diario.

3. Instalación: el panorama completo

Instalar Linux no es un acto religioso. Es una decisión de ingeniería con trade-offs.

Puedes reemplazar tu sistema, convivir con él, virtualizarlo, probarlo sin instalarlo o —si estás en Windows— integrarlo con WSL2. Todas las rutas son válidas en algún contexto. Para este libro, profundizamos en la que mejor equilibra fricción diaria y fidelidad a producción para quienes trabajan en Windows: WSL2 + Ubuntu 24.04 LTS.

Opciones para tener Linux: nativa, dual boot, máquina virtual, Live USB y WSL2 con Ubuntu 24.04 LTS

Tabla de decisión: qué opción elegir

Opción Qué es Mejor para Evitar cuando
Nativa (bare metal) Linux es el único SO del disco Rendimiento máximo, servidores, labs dedicados No puedes prescindir de Windows en esa máquina
Dual boot Eliges SO al arrancar Usar ambos sistemas “de verdad” No quieres particionar ni reiniciar sin cesar
Máquina virtual Linux dentro de VirtualBox/VMware/Hyper-V Snapshots, experimentos, simular varios nodos Tu RAM/CPU apenas alcanza para el host
Live USB Arrancas Linux sin instalar Probar hardware o rescatar datos Necesitas un entorno persistente de trabajo
WSL2 Kernel Linux real integrado en Windows Desarrollo diario, este libro, baja fricción Necesitas un laboratorio multinodo “clásico” muy aislado

Recomendación de este capítulo

  • Estás en Windows 10/11 y quieres aprender Big Data con seriedad → WSL2 + Ubuntu 24.04 LTS.
  • Quieres practicar administración multinodo con capturas de estado → añade una VM más adelante.
  • Montas un servidor o un lab dedicado → nativa o imagen cloud.

Error común: tratar WSL2 como “un Ubuntu de juguete”. Para desarrollo de datos es un Linux real. Sus límites aparecen en escenarios específicos de red, servicios e I/O — por eso los veremos con honestidad.

Arquitectura conceptual de WSL2

¿Qué es WSL2?
Windows Subsystem for Linux 2 permite ejecutar un entorno Linux genuinamente útil dentro de Windows, con un kernel Linux real gestionado por Microsoft, no una capa de compatibilidad superficial al estilo de las primeras aproximaciones.

¿Por qué existe?
Porque millones de personas desarrollan en Windows y despliegan en Linux. Forzar dual boot solo para compilar, probar scripts o hablar con Docker/Kubernetes añade fricción innecesaria.

¿Cómo funciona (intuición)?
Windows hospeda una máquina virtual ligera. Dentro corre el kernel Linux. Encima instalas una distro (Ubuntu). Desde Windows puedes lanzar distros; desde Ubuntu ves tu disco Windows montado bajo /mnt/c.

Arquitectura de WSL2: Windows, WSL2, kernel Linux, Ubuntu y el disco de Windows en /mnt/c

¿Cuándo usarlo?
Desarrollo local, aprendizaje, clientes cloud, prototipos, pipelines ligeros, preparación de demos.

¿Cuándo no basta?
Cuando necesitas comportamiento idéntico a un servidor bare-metal, redes avanzadas muy específicas, o un clúster multinodo con topología fiel. Ahí entran VM, cloud o metal.

Error común: instalar una distro y quedarte en WSL 1 sin mirar la columna VERSION de wsl -l -v.

Checklist pre-instalación

Antes del laboratorio, confirma esto en voz alta (o en una nota):

Buenas prácticas: cierra trabajo crítico, anota cada error textual y no copies comandos destructivos de foros sin entenderlos. En este capítulo no formateamos discos ni tocamos particiones.

Si ya tienes Ubuntu funcionando en WSL2, igual te recomiendo leer el laboratorio: es tu mapa de diagnóstico cuando algo se rompa dentro de seis meses.

4. Laboratorio: instalando Ubuntu sobre WSL2

Este es el laboratorio extenso del capítulo. Al terminarlo deberías tener:

  1. WSL2 operativo
  2. Ubuntu 24.04 LTS instalado (o 22.04 LTS compatible)
  3. Una sesión Bash usable
  4. Claridad total sobre qué corre en PowerShell y qué corre en Ubuntu

Reglas de seguridad del laboratorio

  • No borramos archivos de Windows.
  • No ejecutamos formateos ni cambios de particiones.
  • Ningún bloque ejecuta sudo sin avisarte.
  • Si un paso pide administrador y no lo tienes, detente y solicita el permiso; no improvises.

Resultado esperado: una sesión Ubuntu usable y la certeza de que tu laboratorio Linux está a un comando de distancia.

Paso 1: habilitar e instalar WSL (PowerShell)

Consola: PowerShell (Windows)
Preferiblemente Ejecutar como administrador si tu política de equipo lo permite.

  1. Abre el menú Inicio.
  2. Escribe PowerShell.
  3. Clic derecho → Ejecutar como administrador (si puedes).
  4. Ejecuta:
wsl --install

En instalaciones recientes, este comando habilita los componentes necesarios e instala una distribución por defecto. Puede solicitar reinicio. Reinicia si Windows lo pide; no es un adorno.

Después del reinicio, abre otra vez PowerShell y revisa el estado:

wsl --status
wsl -l -v

Qué mirar (sin memorizar una salida inventada):

  • Que WSL responda sin error de comando no reconocido.
  • Que exista al menos una distro listada, o que el sistema quede listo para instalar Ubuntu en el paso 2.
  • La columna de versión, cuando aparezca: queremos 2.

Si wsl no se reconoce, Windows está incompleto o la sesión no tiene los componentes. Ve a Solución de problemas.

Error común: ejecutar PowerShell sin privilegios suficientes y leer el mensaje a medias. El texto del error importa: cópialo completo.

Paso 2: instalar Ubuntu 24.04 LTS

Consola: PowerShell (Windows)

Lista distros disponibles:

wsl --list --online

Instala Ubuntu 24.04 LTS de forma explícita:

wsl --install -d Ubuntu-24.04

Si en el catálogo online el nombre aparece con otra etiqueta exacta, usa esa etiqueta; no inventes el identificador. La meta es Ubuntu 24.04 LTS.

Alternativa compatible: si tu organización estandariza 22.04:

wsl --install -d Ubuntu-22.04

También puedes instalar desde Microsoft Store buscando “Ubuntu 24.04 LTS”. El resultado deseado es el mismo: una distro lanzable con wsl.

Verifica:

wsl -l -v

Deberías ver tu Ubuntu en la lista. Aún no interpretemos la columna VERSION a la ligera: eso es el paso 3.

Al primer arranque, Ubuntu pedirá nombre de usuario UNIX y contraseña. Elige un usuario habitual (minúsculas) y una contraseña que recuerdes. Cuando escribas la contraseña, no verás asteriscos: es normal en Linux.

Buenas prácticas: ese usuario será tu identidad diaria. No uses root como cuenta de trabajo.

Paso 3: verificar que estás en WSL 2

Consola: PowerShell (Windows)

wsl -l -v

Busca tu distro (por ejemplo Ubuntu-24.04) y la columna VERSION.

VERSION Significado Acción
2 Correcto para este libro Continúa
1 WSL antiguo para este propósito Migra a 2

Si está en 1, migra (puede tardar; hazlo cuando puedas interrumpir el trabajo):

wsl --set-version Ubuntu-24.04 2

Sustituye Ubuntu-24.04 por el nombre exacto que te mostró wsl -l -v.

Opcional: dejar WSL2 por defecto para futuras distros:

wsl --set-default-version 2

Error común: instalar bien Ubuntu y operar meses en WSL1 por no mirar esa columna. Los síntomas suelen aparecer como rarezas de rendimiento o compatibilidad, no como un cartel rojo.

Paso 4: primer acceso e integración Windows ↔︎ Linux

Abrir Ubuntu

  • Desde el menú Inicio: “Ubuntu 24.04”.
  • O desde PowerShell:
wsl -d Ubuntu-24.04

A partir de aquí, los comandos son Bash (Ubuntu) salvo que indiquemos lo contrario.

pwd
ls /
ls /mnt

Cómo pensar las rutas

Ruta Qué es
/home/tu_usuario o ~ Tu hogar Linux. Aquí debes trabajar.
/mnt/c El disco C: de Windows, visible desde Linux.
/mnt/c/Users/... Tu perfil de Windows, accesible para copiar archivos puntuales.

Puedes leer archivos de Windows desde /mnt/c. Eso no significa que debas clonar repositorios enormes ni guardar datasets pesados allí.

Reto corto: localiza tu carpeta de usuario de Windows desde Ubuntu (/mnt/c/Users/...) usando solo ls y cd. No borres nada. No muevas nada. Solo observa.

Buenas prácticas de rendimiento en WSL2

WSL2 es Linux real, pero el puente con el disco de Windows tiene costo.

Regla de oro: tus proyectos de datos viven en el filesystem Linux:

/home/<usuario>/...

no en:

/mnt/c/Users/<usuario>/...
Ubicación Uso sensato
~/proyectos o ~/bigdata_linux_lab Código, datos de lab, clones git, entornos
/mnt/c/... Intercambio puntual de archivos con Windows

En producción… WSL2 brilla como estación de desarrollo. Un clúster real sigue siendo Linux nativo o instancias cloud. No confundan “puedo aprender aquí” con “esto es el cluster de producción”.

Si alguna vez necesitas apagar WSL por completo desde Windows (mantenimiento), el comando existe en PowerShell (wsl --shutdown). Úsalo solo cuando entiendas que cerrará tus sesiones Linux abiertas.

Solución de problemas (WSL2 + Ubuntu)

Síntoma Causa probable Mitigación segura
wsl no se reconoce Componentes no instalados / PATH / política Reejecutar instalación con admin; actualizar Windows
Error de virtualización BIOS/UEFI sin virtualización Habilitar SVM/VT-x con dueño del equipo; no desactivar antivirus al azar
Distro en VERSION 1 Instalación antigua o default incorrecto wsl --set-version <NombreExacto> 2
No puedes elevar admin Política corporativa Solicitar instalación a TI; no “saltar” seguridad
Fallo descargando distro Red, Store, proxy Reintentar; probar Store; revisar proxy corporativo
Ubuntu pide usuario en bucle Instalación incompleta Cerrar, abrir de nuevo; si persiste, reinstalar la distro, no formatear Windows

Regla de oro de remedios: ninguna solución de este capítulo incluye formatear C:, borrar particiones o desactivar defensas del sistema como primer paso.

Si ya tienes Bash respondiendo, copia en tu terminal de Ubuntu el script de verificación que sigue.

# Script de verificación del laboratorio WSL2 / Ubuntu
# Consola: Bash (Ubuntu)
# Seguridad: solo lectura. Sin sudo. Sin modificar configuraciones.

set -euo pipefail

echo "=== Kernel ==="
uname -a

echo
echo "=== Distro ==="
if [ -f /etc/os-release ]; then
  # shellcheck disable=SC1091
  . /etc/os-release
  echo "PRETTY_NAME=${PRETTY_NAME:-}"
  echo "VERSION_ID=${VERSION_ID:-}"
else
  echo "Sin /etc/os-release"
fi

echo
echo "=== Identidad ==="
echo "hostname=$(hostname)"
echo "whoami=$(whoami)"
echo "HOME=$HOME"
echo "SHELL=${SHELL:-}"

echo
echo "=== Espacio en el home ==="
df -h "$HOME"

echo
echo "=== ¿WSL? (indicador suave) ==="
if grep -qi microsoft /proc/version 2>/dev/null; then
  echo "Indicio de entorno Microsoft WSL en /proc/version"
else
  echo "No se observó firma Microsoft en /proc/version (puede ser Linux nativo o VM)"
fi

echo
echo "=== Directorio de práctica ==="
if [ -d "$HOME/bigdata_linux_lab" ]; then
  echo "bigdata_linux_lab=sí"
  ls -la "$HOME/bigdata_linux_lab"
else
  echo "bigdata_linux_lab=no (se crea en la sección 5)"
fi

echo
echo "Verificación completada."

5. Primer ingreso a Ubuntu

Instalar es el trámite. Configurar con higiene es el oficio.

En esta sección vas a:

  • entender tu identidad en el sistema
  • actualizar paquetes con conciencia
  • instalar un set mínimo de herramientas
  • crear el directorio de práctica ~/bigdata_linux_lab

Consola a partir de aquí: Bash (Ubuntu)
salvo que se indique PowerShell de forma explícita.

Importante: este capítulo no ejecuta sudo por ti. Cuando veas un comando con sudo, léelo, entiéndelo y ejecútalo tú en la terminal si tienes privilegios y estás de acuerdo.

Identidad, prompt y actualización del sistema

Tu prompt suele parecerse a algo como:

usuario@host:ruta$

Eso ya te está diciendo tres cosas: quién eres, en qué máquina estás y en qué carpeta trabajas.

Ejecuta en Bash:

whoami
hostname
pwd

Actualizar el sistema

¿Qué es? Refrescar metadatos de paquetes (update) y aplicar actualizaciones disponibles (upgrade).
¿Por qué existe? Seguridad y estabilidad. Un lab desactualizado acumula sorpresas.
¿Cuándo? Tras instalar la distro y, periódicamente, antes de montar stacks grandes.

En tu terminal Bash — de forma manual — puedes ejecutar:

sudo apt update
sudo apt upgrade

apt update no instala el mundo: actualiza la lista de lo disponible. apt upgrade puede descargar e instalar cambios; toma tiempo y pide confirmación.

Error común: creer que la contraseña está rota porque no aparecen asteriscos al escribirla. En muchos prompts de sudo, el cursor no muestra nada. Escribe con cuidado y pulsa Enter.

Si no tienes permisos sudo, puedes seguir leyendo el capítulo y practicar todo lo que no requiera administración. Pide el privilegio antes de instalar paquetes del sistema.

Herramientas básicas del entorno

No vamos a convertir Ubuntu en un bazar. Solo un set mínimo con justificación de ingeniero de datos:

Paquete Para qué
curl Hablar con APIs y endpoints HTTP desde consola
wget Descargar artefactos
git Versionar código y configs
tree Ver árboles de directorios con claridad
htop Observar procesos de forma interactiva (si está en los repos)
unzip / tar (suele venir) Empaquetar e inspeccionar entregables
ca-certificates Confianza TLS al descargar

Instalación manual en Bash (tú la ejecutas; los bloques del capítulo no elevan privilegios):

sudo apt install -y curl wget git tree htop unzip ca-certificates

Si htop no estuviera disponible en tu mirror, instala el resto y continúa: no es bloqueante para este capítulo.

En producción… los equipos serios no configuran nodos “a mano para siempre”: usan imágenes doradas, Ansible, cloud-init o similares. Aprender el apt manual te enseña el verbo; la madurez operativa es reproducirlo sin click improvisado.

# Crear el directorio de práctica
# Consola: Bash (Ubuntu)
# Escritura SOLO dentro de $HOME/bigdata_linux_lab
# Sin sudo. Sin rm. Sin tocar /etc, /var, /usr ni /mnt/c

set -euo pipefail

LAB="${HOME}/bigdata_linux_lab"

mkdir -p "${LAB}/raw" \
         "${LAB}/clean" \
         "${LAB}/out" \
         "${LAB}/scripts" \
         "${LAB}/logs" \
         "${LAB}/notes"

cat > "${LAB}/notes/README.txt" <<'EOF'
Big Data e Ingeniería de Datos — Capítulo 1
Directorio de práctica: ~/bigdata_linux_lab

raw/     datos crudos de laboratorio
clean/   datos limpios intermedios
out/     salidas y entregables
scripts/ scripts propios
logs/    salidas de verificación
notes/   bitácora personal
EOF

# Bitácora de creación (solo lectura del entorno + eco)
{
  echo "creado=$(date -Iseconds)"
  echo "usuario=$(whoami)"
  echo "host=$(hostname)"
  echo "home=${HOME}"
} > "${LAB}/logs/lab_created.txt"

echo "Laboratorio listo en: ${LAB}"
ls -la "${LAB}"
# Verificación post-configuración inicial
# Consola: Bash (Ubuntu)
# Solo lectura + comprobaciones. Sin sudo. Sin borrados.

set -euo pipefail

LAB="${HOME}/bigdata_linux_lab"

echo "=== SO ==="
uname -a
if [ -f /etc/os-release ]; then
  # shellcheck disable=SC1091
  . /etc/os-release
  echo "PRETTY_NAME=${PRETTY_NAME:-}"
fi

echo
echo "=== Laboratorio ==="
if [ ! -d "$LAB" ]; then
  echo "ERROR: no existe $LAB — ejecuta primero la celda de creación."
  exit 1
fi

ls -la "$LAB"

echo
echo "=== Herramientas (si están instaladas) ==="
for cmd in curl wget git tree; do
  if command -v "$cmd" >/dev/null 2>&1; then
    echo "$cmd=$(command -v "$cmd")"
  else
    echo "$cmd=NO_ENCONTRADO"
  fi
done

echo
echo "=== Espacio del home ==="
df -h "$HOME"

# Guarda un snapshot de verificación para tu bitácora
{
  date -Iseconds
  uname -a
  command -v curl || true
  command -v git || true
} > "${LAB}/logs/post_setup_check.txt"

echo
echo "Verificación guardada en ${LAB}/logs/post_setup_check.txt"

Buenas prácticas del primer día (y errores comunes)

Buenas prácticas

  • Trabaja como usuario normal, no como root.
  • Mantén código y datos de aprendizaje dentro de ~/bigdata_linux_lab.
  • Anota tu PRETTY_NAME en notes/.
  • Lee cualquier comando con sudo antes de pulsar Enter.
  • Actualiza con criterio; no pegues pipelines opacos de internet.

Errores comunes

Error Por qué duele Antídoto
Guardar el lab en /mnt/c I/O lento y dolores raros Todo bajo ~
Ignorar fallos de apt Bases rotas después Leer el error; no “forzar” a ciegas
Trabajar siempre con sudo Permisos imposibles de depurar sudo solo cuando hace falta
No documentar la versión “En mi máquina funciona” Bitácora en notes/

En producción… el primer día bien hecho se parece más a una checklist que a una improvisación heroica.

El sistema ya responde. Ahora viene la pregunta de arquitecto: cuando escribes un comando, ¿quién habla con quién?

6. Arquitectura de Linux

Un sistema operativo existe para una promesa: que muchas aplicaciones compartan un hardware sin el caos. Esa promesa se cumple por capas.

En Linux, la imagen mental que te acompañará el resto del libro es esta:

Usuario / aplicaciones → Shell → Kernel → Hardware

Tú casi nunca “hablas con el disco”. Hablas con un programa. El programa habla con el shell o hace llamadas al sistema. El kernel arbitra. El hardware obedece.

Pregunta al lector: cuando lanzas un job de Spark, ¿con qué capa interactúas tú directamente en el día a día?

Diagrama de capas de Linux

Capas de Linux: usuario y aplicaciones, shell, kernel y hardware

Capa ¿Qué es? ¿Por qué existe? ¿Qué ves tú?
Usuario / apps Programas: Python, Spark, editores, navegadores Resolver problemas de negocio Procesos, puertos, logs de app
Shell Intérprete de comandos (Bash, Zsh…) Traducir tu intención en ejecución Prompt, scripts, pipes
Kernel Núcleo del SO Administrar recursos y dispositivos /proc, /sys, syscalls (indirectas)
Hardware CPU, RAM, disco, red Ejecutar de verdad Fallos físicos, capacidad, latencia

Si depuras en la capa equivocada, puedes pasar horas “optimizando Spark” cuando el disco está lleno, o culpando a la red cuando el proceso simplemente no arrancó.

Analogía, procesos y demonios en Big Data

Imagina un restaurante de alta rotación.

  • Tú eres el cliente (usuario).
  • El mesero toma tu pedido (shell).
  • La cocina coordina fuegos, tiempos e inventario (kernel).
  • Los fogones, neveras y cables son el hardware.

No entras a la cocina a abrir el gas cada vez que quieres un plato. Pides. El sistema organiza.

En Big Data, Hadoop, Spark o Kafka no son “la nube”. Son procesos — a menudo demonios: servicios de larga vida que corren en segundo plano — sobre Linux.

Un comando o servicio pasa por el shell o supervisor, el kernel y los recursos de hardware

Componente típico Se ve en Linux como
NameNode / DataNode Procesos de larga vida + logs + puertos
Spark worker / driver Procesos JVM con CPU y memoria visibles
Broker Kafka Demonio con logs y almacenamiento en disco
Scheduler (Airflow) Procesos + base + logs

Espacio de usuario vs. espacio de kernel (intuición): tus apps viven “arriba”, con restricciones. El kernel vive “abajo”, con privilegio real sobre el hardware. Por eso un bug de app suele matar un proceso, y un panic de kernel tumba la máquina.

Para pensar: si Spark “se queda sin memoria”, ¿estás ante un problema de aplicación, de límites del sistema, o de hardware insuficiente? A veces son los tres. La arquitectura te obliga a preguntar en orden.

# Inspección práctica ligera de la arquitectura
# Consola: Bash (Ubuntu)
# Solo lectura. Sin sudo. Sin matar procesos. Sin escribir en /proc.

set -euo pipefail

LAB="${HOME}/bigdata_linux_lab/logs"
mkdir -p "$LAB"

echo "=== Proceso de esta shell ==="
ps -p $$ -o pid,ppid,cmd

echo
echo "=== Una mirada a /proc del proceso actual ==="
ls "/proc/$$" | head -n 20

echo
echo "=== Memoria (primeras líneas) ==="
head -n 5 /proc/meminfo

echo
echo "=== CPU (primeras líneas) ==="
head -n 5 /proc/cpuinfo

{
  echo "timestamp=$(date -Iseconds)"
  ps -p $$ -o pid,ppid,cmd
  head -n 5 /proc/meminfo
} > "${LAB}/architecture_probe.txt"

echo
echo "Nota guardada en ${LAB}/architecture_probe.txt"
echo "Idea clave: el kernel expone información del sistema como si fueran archivos."

Cierre de arquitectura y puente al sistema de archivos

Acabas de ver una idea que atraviesa todo Unix: el kernel habla en archivos y descriptores. /proc no es una carpeta de documentos personales; es una interfaz viva.

Síntesis mínima:

  • Tú operas desde el espacio de usuario.
  • El shell es tu volante cotidiano.
  • El kernel reparte recursos.
  • El hardware impone límites físicos.

El kernel administra. Tú, además, navegas un territorio: directorios, permisos, logs y datos. Ese territorio tiene mapa. Se llama sistema de archivos.

7. Sistema de archivos

En Linux todo cuelga de un único árbol cuya raíz es /.

No hay C: y D: como lenguajes distintos del sistema. Un disco nuevo no “aparece como letra mágica”: se monta en algún punto del árbol. Esa decisión de diseño —heredada de Unix— es una de las razones por las que automatizar infraestructura con texto funciona tan bien.

¿Qué es el sistema de archivos (para ti, ingeniero de datos)?
El mapa donde viven configuraciones, binarios, logs, datos y dispositivos.

¿Por qué existe esta jerarquía?
Para que cualquier persona (y cualquier script) sepa dónde mirar sin adivinar.

Sabías que… la frase clásica “todo es un archivo” no es poesía: dispositivos, sockets e incluso información del kernel se exponen con metáforas de archivo. Por eso ls /proc se siente raro… y poderoso.

Directorios esenciales del árbol

Árbol de directorios desde la raíz: /home, /etc, /var, /usr, /opt y /tmp

Ruta ¿Qué es? ¿Por qué existe? Ejemplo en datos
/ Raíz del árbol Origen único de rutas absolutas Punto de partida de cualquier path
/home Hogares de usuarios Aislar el trabajo de cada persona ~/bigdata_linux_lab
/etc Configuración del sistema y servicios Separar config de código configs de red, servicios, a veces apps
/var Datos variables Logs, colas, estado que cambia /var/log, colas, cachés
/usr Programas y recursos compartidos de usuario Organizar software “del sistema” binarios en /usr/bin
/opt Software opcional / de terceros Instalar stacks sin mezclarlos del todo Hadoop, Spark, herramientas vendor
/tmp Temporal Espacio de paso; no archivo eterno dumps temporales de jobs

¿Cuándo usar cada uno (criterio)?

  • Tu trabajo diario de aprendizaje → /home (nuestro lab).
  • “¿Por qué el servicio no arranca?” → mira configs en /etc y logs en /var.
  • “¿Dónde dejaron el Spark de la empresa?” → a menudo /opt o rutas documentadas del equipo.

Directorios del sistema vivo

Estos directorios confunden al principio porque no se comportan como carpetas de documentos.

Ruta ¿Qué es? ¿Se edita a mano? Cómo se usa en la práctica
/dev Interfaces a dispositivos Casi nunca Discos, terminales, dispositivos lógicos
/proc Interfaz al kernel (procesos, memoria, etc.) No como archivos normales Diagnóstico: meminfo, PIDs, uptime
/sys Interfaz a dispositivos/buses vía sysfs No como playground Inventario y atributos de hardware lógico
/run Estado volátil de tiempo de ejecución No PIDs de servicios, sockets temporales
/srv Datos de servicios servidos por este host Según diseño del equipo Contenidos servidos; menos común en laptops

Error común: intentar “limpiar disco” borrando cosas dentro de /proc o /sys. No son datasets. Son ventanas al sistema.

¿Cuándo te importan en Big Data?
Cuando un nodo “no tiene memoria”, “no ve el disco”, “el servicio no deja PID” o necesitas evidencia antes de reiniciar nada.

Dónde vive el stack Big Data en el disco

No hay una ley universal única —cada instalación documenta sus rutas— pero el patrón se repite:

Tipo de artefacto Dónde suele vivir Por qué
Configuración /etc/... o conf/ de la app Debe sobrevivir a redeploys con control
Logs /var/log/... o volumen dedicado Crece sin aviso; hay que rotarlo
Binarios / stacks /opt/..., /usr/local/... Separar producto del SO
Datos discos montados (/data, /mnt/...) No ahogar la raíz /
Trabajo personal / labs /home/... Exactamente nuestro caso

Rutas absolutas vs relativas (mínimo vital)

Notación Significado
/home/ana/lab Absoluta: desde la raíz
./out Relativa: desde el directorio actual
../raw Un nivel arriba, luego raw
~ Atajo a tu $HOME

En este libro, la convención es férrea:

~/bigdata_linux_lab

En producción… separar disco del sistema operativo y discos de datos no es capricho: es la diferencia entre “se llenó un volumen de datos” y “el nodo no puede ni escribir logs porque / está al 100%”.

# Exploración guiada del árbol
# Consola: Bash (Ubuntu)
# Lectura del sistema + notas SOLO en ~/bigdata_linux_lab

set -euo pipefail

LAB="${HOME}/bigdata_linux_lab"
NOTES="${LAB}/notes"
LOGS="${LAB}/logs"
mkdir -p "$NOTES" "$LOGS"

echo "=== Raíz (ls /) ==="
ls /

echo
echo "=== Home ==="
ls -la "$HOME"

echo
echo "=== Laboratorio ==="
ls -la "$LAB"

# Guardar un listado de la raíz para estudio (no modifica el sistema)
ls / > "${LOGS}/root_listing.txt"

cat > "${NOTES}/filesystem_map.txt" <<'EOF'
Mapa personal — Capítulo 1
/           raíz
/home       usuarios
/etc        configuración
/var        logs y datos variables
/opt        software opcional (stacks)
/tmp        temporal
/proc /sys  interfaces del kernel (no "limpiar")
EOF

echo
echo "Notas escritas en:"
echo "  ${LOGS}/root_listing.txt"
echo "  ${NOTES}/filesystem_map.txt"
# Mirar /proc, /sys y /dev sin miedo
# Consola: Bash (Ubuntu)
# Solo lectura. Sin sudo. Sin escritura en /proc ni /sys.

set -euo pipefail

LAB="${HOME}/bigdata_linux_lab/notes"
mkdir -p "$LAB"

echo "=== Entradas en /proc (muestra) ==="
ls /proc | head -n 15

echo
echo "=== Uptime (vía /proc) ==="
head -n 1 /proc/uptime

echo
echo "=== Entradas en /sys (muestra) ==="
ls /sys | head -n 15

echo
echo "=== Entradas en /dev (muestra) ==="
ls /dev | head -n 15

{
  echo "timestamp=$(date -Iseconds)"
  echo "--- /proc/uptime ---"
  cat /proc/uptime
  echo "--- head /proc/meminfo ---"
  head -n 8 /proc/meminfo
} > "${LAB}/proc_sys_observations.txt"

echo
echo "Observaciones guardadas en ${LAB}/proc_sys_observations.txt"
echo "Recuerda: esto se observa, no se 'limpia'."

Orientación en el disco: errores comunes y checklist

Errores comunes

Error Consecuencia Antídoto
Confundir / con ~ Comandos en el lugar equivocado Mira el prompt; usa pwd
Llenar / sin mirar /var Nodo inestable Monitorear logs y volúmenes
Datasets pesados en /mnt/c (WSL) Lentitud y rarezas Datos en el home Linux
Editar a ciegas en /etc Servicio roto Backup + cambio mínimo + lectura

Checklist de orientación

Reto corto: escribe en ~/bigdata_linux_lab/notes/ una línea: dónde pondrías logs de un scheduler y dónde binarios de un motor de cómputo en un servidor serio. No hay una sola respuesta correcta; hay respuestas defendibles.

Ya conoces el territorio. Falta la ventana desde la que lo operas cada día.

8. La terminal

La terminal no es “lo negro raro para gente antigua”. Es el IDE de la infraestructura.

Desambiguemos de una vez:

Término ¿Qué es?
Terminal (o emulador de terminal) La ventana/programa que recibe tu teclado y muestra texto
Shell El programa que interpreta lo que escribes (bash, zsh…)
TTY La abstracción de terminal del sistema; de ahí vienen ideas como “sesión de terminal”
Bash Bourne Again Shell: el shell más común en Ubuntu por defecto
Zsh Shell popular, muy usable con buen autocompletado; alternativa frecuente

Del teclado y la terminal al shell, el kernel y el hardware

¿Por qué existe esta separación?
Porque puedes cambiar de shell sin cambiar de sistema, y puedes automatizar sin interfaz gráfica.

¿Cuándo usar la terminal en proyectos reales?
SSH a un nodo, inspeccionar logs, lanzar jobs, copiar artefactos, depurar contenedores, leer df a las 3 a.m. cuando el dashboard miente por omisión.

En este capítulo priorizamos Bash. Zsh puede esperar; los conceptos se transfieren.

Prompt, HOME, PATH y variables de entorno

Una variable de entorno es un valor con nombre que procesos heredan. Configura comportamiento sin recompilar el mundo.

Variable ¿Qué es? ¿Por qué importa?
HOME Tu directorio home Ancla de ~ y de configs de usuario
USER Tu nombre de usuario Identidad en scripts y prompts
SHELL Shell por defecto Qué intérprete te atiende
PATH Lista de directorios donde buscar programas Decide si comando se encuentra o no

¿Cómo funciona PATH?
Cuando escribes ls, el shell no “se inventa” ls. Busca un ejecutable llamado ls en los directorios listados en PATH, en orden. Si no está, respondes al famoso:

command not found

Cómo busca el shell un comando en el PATH: si lo encuentra lo ejecuta; si no, command not found

Autocompletado e historial (preview)
Tab completa nombres. Flecha arriba recorre historial. En el siguiente capítulo los usaremos como músculo, no como anécdota.

Buenas prácticas: no ensucies PATH con rutas aleatorias pegadas de foros. En entornos serios, los cambios son deliberados y documentados.

# Laboratorio corto — inspeccionar el entorno
# Consola: Bash (Ubuntu)
# Sin sudo. Sin modificar PATH de forma persistente.

set -euo pipefail

LAB="${HOME}/bigdata_linux_lab/notes"
mkdir -p "$LAB"

echo "HOME=$HOME"
echo "USER=${USER:-}"
echo "SHELL=${SHELL:-}"
echo "PWD=$(pwd)"
echo
echo "PATH (una entrada por línea):"
echo "$PATH" | tr ':' '\n'

{
  echo "timestamp=$(date -Iseconds)"
  echo "HOME=$HOME"
  echo "USER=${USER:-}"
  echo "SHELL=${SHELL:-}"
  echo "PATH=$PATH"
} > "${LAB}/environment.txt"

echo
echo "Bitácora: ${LAB}/environment.txt"
# Laboratorio corto — localizar ejecutables
# Consola: Bash (Ubuntu)
# Adelanto del siguiente capítulo. Sin instalar paquetes. Sin sudo.

set -euo pipefail

LAB="${HOME}/bigdata_linux_lab/notes"
mkdir -p "$LAB"

echo "=== command -v (preferido y portable) ==="
command -v bash
command -v ls
command -v pwd

echo
echo "=== type (builtin vs externo) ==="
type ls
type pwd
type command

{
  echo "timestamp=$(date -Iseconds)"
  echo -n "bash="
  command -v bash
  echo -n "ls="
  command -v ls
} > "${LAB}/executables.txt"

echo
echo "Bitácora: ${LAB}/executables.txt"
echo "Si algo esencial falta, vuelve a la sección de herramientas básicas."

Errores comunes del primer contacto con la terminal

Error Qué está pasando Qué hacer
command not found No está instalado o no está en PATH command -v; instalar con criterio; no adivinar
Rutas con espacios mal citadas El shell parte argumentos Usa comillas
Pegar bloques con sudo sin leer Riesgo real Leer línea a línea
Mezclar PowerShell y Bash Sintaxis y comandos distintos Mirar la etiqueta de consola
Miedo al prompt vacío tras contraseña Feedback oculto normal Confiar el mecanismo; reintentar con cuidado

En producción… entras por SSH a un nodo y el modelo mental es el mismo: identidad, pwd, PATH, logs, procesos. La laptop fue el ensayo; el clúster es la función.

Puente al siguiente capítulo

Ya tienes el territorio (sistema de archivos) y la ventana (terminal + entorno).
Falta el lenguaje con el que se opera un clúster de verdad: anatomía de comandos, filtros, pipes y un proyecto pequeño de punta a punta.

Eso es Dominando la Terminal para Big Data.

9. Lo que acabas de aprender

Hace un capítulo, Linux podía parecerte un requisito borroso en las ofertas laborales. Ahora tienes un mapa.

Puedes explicar por qué la industria de datos habla Linux.
Puedes instalar Ubuntu 24.04 LTS sobre WSL2 con método.
Puedes dibujar de memoria —o casi— la cadena Usuario → Shell → Kernel → Hardware.
Puedes caminar el árbol de archivos sin sentir que estás en un bosque aleatorio.
Puedes mirar HOME y PATH como lo que son: configuración del entorno, no magia.

Eso no es “saber de todo”. Es mejor: es dejar de estar perdido.

Para pensar: si mañana entras a un nodo remoto, ¿qué mirarías primero — /, los procesos o tu PATH? No hay una única respuesta correcta. Hay un orden defendible según el síntoma.

Mapa conceptual del capítulo

Mapa conceptual del capítulo: de por qué Linux hasta la terminal, listo para dominarla

Si puedes narrar este diagrama en voz alta en dos minutos, sin mirar el texto, este capítulo cumplió su trabajo.

Autoevaluación de criterio

Responde honestamente con sí/no. No es un examen: es un espejo.

  1. ¿Puedo explicar la diferencia entre kernel y distribución?
  2. ¿Sé por qué Ubuntu 24.04 LTS es la ruta principal de este laboratorio?
  3. ¿Diferencio con claridad PowerShell (Windows) de Bash (Ubuntu)?
  4. ¿Verifiqué WSL 2 (wsl -l -v) si mi ruta fue Windows?
  5. ¿Puedo describir Usuario → Shell → Kernel → Hardware con una analogía propia?
  6. ¿Sé para qué sirven, a grandes rasgos, /etc, /var, /home y /opt?
  7. ¿Entiendo por qué /proc no se “limpia” como una carpeta de descargas?
  8. ¿Puedo explicar qué problema resuelve PATH?
  9. ¿Mi trabajo práctico está en ~/bigdata_linux_lab?
  10. ¿Sé qué queda deliberadamente para el siguiente capítulo?

Lo que aún no cubrimos (a propósito):

  • anatomía profunda de un comando (flags, comodines, expansiones)
  • laboratorio amplio de herramientas de consola
  • pipes, redirecciones, tee, xargs
  • mini-proyecto de logs de punta a punta

Eso no falta por olvido. Está diseñado para el siguiente capítulo, Dominando la terminal para Big Data, cuando ya no estás sobreviviendo al SO, sino usándolo.

10. Próximo capítulo

Dominando la Terminal para Big Data

Ya tienes el territorio y la ventana.
En el siguiente capítulo aprendemos el lenguaje con el que se opera un clúster de verdad.

Trabajaremos dentro del mismo hogar de práctica:

~/bigdata_linux_lab

Allí construiremos músculo real: navegar, filtrar, encadenar comandos, entender pipes como idea hermana de MapReduce, y cerrar con un mini-proyecto que se sienta a trabajo — no a ejercicio ornamental.

Del capítulo de fundamentos de Linux al de la terminal y luego a Docker

Reto de continuidad: antes de pasar al siguiente capítulo, deja Ubuntu actualizado a tu criterio y verifica que ~/bigdata_linux_lab existe con sus subcarpetas.

Resumen

En este capítulo aprendimos:

  • por qué Linux es el cimiento del ecosistema Big Data — servidores, nube, contenedores y clústeres
  • cómo instalar y verificar Ubuntu 24.04 LTS sobre WSL2, distinguiendo PowerShell de Bash
  • cómo pensar la arquitectura Usuario → Shell → Kernel → Hardware
  • cómo orientarse en el sistema de archivos, incluyendo /proc, /sys, /dev, /run y /srv
  • cómo funciona la terminal y el entorno del shell (HOME, PATH, prompt)

Ahora comprendes el suelo sobre el que se construyen Hadoop, Spark y el resto de una plataforma moderna de datos.

En el siguiente capítulo, Dominando la terminal para Big Data, bajaremos las manos al teclado de verdad: comandos, pipes y un flujo de trabajo reproducible.

Recursos opcionales

Pocos enlaces. Alta señal. Verifica siempre la fecha de lo que leas.

Este capítulo debe sostenerse solo. Los recursos son ampliaciones, no muletas.