GuíaIntermedio
Guía de Lakehouse e Iceberg
Parquet es un formato de archivo, no un formato de tabla — y esta guía te muestra, con el propio caso Kiosko, las cuatro veces que ese límite ya dolió: el `overwrite-partition` no atómico de las lecciones básicas, las columnas `valid_from`/`valid_to` mantenidas a mano para historizar un producto, la misma técnica automatizada con `dbt snapshot`, y el particionado por carpetas de Spark. Aprendes Apache Iceberg, el formato de tabla que resuelve todo eso desde la capa de almacenamiento: transacciones ACID reales, un snapshot inmutable en cada escritura, time travel (`AS OF` un snapshot, sin declarar una sola columna de historia), evolución de esquema sin reescribir datos, partición oculta y evolución de partición, y `MERGE INTO`/upserts nativos. El vehículo principal es PyIceberg, 100% Python y $0 (catálogo local sobre SQLite); Spark aparece una sola vez, en el módulo de `MERGE INTO`, para correr SQL real contra una tabla Iceberg. Delta Lake se nombra por contraste, sin construir una segunda implementación paralela. El hilo que resuelves de punta a punta es el cambio de precio de un producto de Kiosko, recuperado con time travel puro, sin ninguna columna de historia.
- 64
- lecciones
- 8
- módulos
- Inglés · Español
- disponible en
- Sí
- certificado
- Gratis
- acceso
Resultados
Lo que vas a poder hacer
- Nombrar con precisión la diferencia entre formato de archivo y formato de tabla, y las cuatro veces que Parquet solo ya mostró su techo en el ecosistema de Kiosko
- Instalar PyIceberg, crear un catálogo local (SQLite + filesystem) y cargar la primera tabla Iceberg real a partir de un Parquet existente
- Recorrer la anatomía de una tabla Iceberg: catálogo → archivo de metadata → manifest list → manifest files → archivos de datos
- Usar time travel (`AS OF` un `snapshot-id`) para recuperar el estado anterior de una tabla, sin declarar `valid_from`/`valid_to` en ningún lado
- Evolucionar el esquema de una tabla (agregar, renombrar, borrar columnas) sin reescribir un solo archivo de datos existente
- Contrastar el particionado visible por carpetas (Hive) con la partición oculta de Iceberg, y evolucionar el esquema de partición hacia adelante sin reescribir los datos ya existentes
- Ejecutar `MERGE INTO` nativo con Spark SQL y `table.upsert()` de PyIceberg como alternativa 100% Python para el mismo problema
- Nombrar catálogos de producción (REST, AWS Glue, Unity Catalog, Polaris) y aplicar mantenimiento básico: compactación de archivos pequeños y expiración segura de snapshots
- Decidir con criterio cuándo un lakehouse sobre Iceberg gana frente a un warehouse gestionado clásico o frente a Parquet plano sin más
Antes de empezar
Qué necesitas traer
Es para ti si...
- Data engineers que ya escribieron Parquet o construyeron un warehouse dimensional y quieren resolver versionado/historia desde el formato de tabla, no a mano con columnas
- Devs evaluando si su equipo necesita Iceberg o Delta Lake, y quieren entender la diferencia real (no solo el nombre de moda)
- Cualquiera preparándose para roles donde "Apache Iceberg or Delta Lake" aparece como requisito explícito de la oferta
- Data engineers que completaron `data-modeling-for-analytics-guide`, `dbt-analytics-engineering-guide` y/o `spark-and-distributed-processing-guide` y quieren cerrar el hilo de historia que esas guías dejaron abierto
Requisitos y materiales
- Python intermedio; comodidad leyendo y escribiendo Parquet
- SQL básico (joins, `WHERE`, agregaciones)
- Ideal haber completado `data-modeling-for-analytics-guide` (el problema de `dim_product` historizado a mano) y `spark-and-distributed-processing-guide` (el Parquet particionado que esta guía convierte a Iceberg); Spark + Java 17 solo se necesita para el módulo de `MERGE INTO`
Contenido
El temario, módulo por módulo
Abre cualquiera para ver sus lecciones.
- Presentación del módulo: de un archivo Parquet a una tabla Iceberg real
- Cuatro veces que Parquet solo no fue suficiente
- Formato de archivo vs formato de tabla
- Instalando PyIceberg y un catálogo local
- Creando tu primer namespace y tabla
- Cargando el fact_orders de Kiosko en Iceberg
- Verificando el mismo total de 106.15
- Proyecto: la primera tabla Iceberg de Kiosko
- Presentación del módulo: la anatomía de una tabla Iceberg
- El catálogo: un puntero a la metadata vigente
- El archivo de metadata: esquema, partición, snapshots
- Manifest lists y manifest files
- Los archivos de datos: el Parquet que ya conoces
- Inspeccionando la tabla de Kiosko en disco
- Leyendo snapshots e historia con PyIceberg
- Proyecto: la anatomía de la tabla de Kiosko, mapeada
- Presentación del módulo: snapshots y time travel
- Cada escritura es un snapshot nuevo
- Cambiando P002 con un overwrite normal
- Capturando el snapshot-id, nunca hardcodeándolo
- Time travel: AS OF un snapshot-id
- Recuperando la historia de P002 con cero columnas extra
- Lo que el time travel no reemplaza
- Proyecto: el dim_product de Kiosko viajado en el tiempo
- Presentación del módulo: evolución de esquema sin reescritura
- Por qué overwrite-partition nunca fue atómico
- Agregando una columna sin reescribir datos
- Renombrando y borrando columnas de forma segura
- Poblando country en dim_store
- Leyendo snapshots antiguos después de un cambio de esquema
- Qué garantiza "ACID" en este contexto exacto
- Proyecto: el dim_store de Kiosko evolucionado
- Presentación del módulo: partición oculta y evolución de partición
- Cómo Spark particionó a Kiosko por carpetas
- Partición oculta: la misma consulta, sin saber el layout
- Transforms de partición: `IdentityTransform`, `BucketTransform`, `DayTransform`
- Particionando `fact_orders_at_scale`
- Evolucionando el `PartitionSpec` sin reescribir
- Leyendo esquemas de partición viejos y nuevos, juntos
- Proyecto: el `fact_orders_at_scale` de Kiosko, particionado
- Presentación del módulo: `MERGE INTO` y upserts nativos
- Tres formas en que Kiosko ya resolvió esto
- Configurando Spark con el runtime de Iceberg
- `MERGE INTO` en Spark SQL
- Corriendo el cambio de P002 como un MERGE
- El upsert de PyIceberg: la alternativa Python-nativa
- Eligiendo entre MERGE en SQL y upsert en Python
- Proyecto: el upsert nativo de Kiosko
- Presentación del módulo: catálogos, mantenimiento y Delta Lake por contraste
- Catálogos más allá de lo local: REST, Glue, Unity Catalog, Polaris
- Por qué los snapshots acumulan costo
- Compactando archivos pequeños
- Expirando snapshots viejos, con seguridad
- Eliminando archivos huérfanos
- Delta Lake, por contraste
- Proyecto: la tabla mantenida de Kiosko
- Presentación del módulo: el capstone, el lakehouse completo de Kiosko
- El brief: Kiosko necesita un lakehouse, no siete demos
- Reconstruyendo el star schema como tablas Iceberg
- Reproduciendo la historia de P002 con time travel
- Evolucionando y particionando a escala
- Fusionando actualizaciones a la manera nativa
- Qué le sigue faltando a Kiosko
- Proyecto: el primer lakehouse de Kiosko
Dudas frecuentes
Lo que suele preguntarse
Sin límite. Es una guía gratuita: entras cuando quieras, las veces que quieras.
No. Los módulos están ordenados de menos a más, pero puedes saltar al que necesites. Tu progreso se guarda por lección.
Lo que haga falta está en «Qué necesitas traer», arriba. Si no aparece nada ahí, puedes empezar desde cero.
En el grupo de WhatsApp del Club, y cada quince días hay un live con un instructor donde se resuelven dudas en vivo.
Sí. Al terminar todas las lecciones se emite automáticamente, con un código verificable que puedes compartir en LinkedIn.
Empieza cuando quieras
Lo que dicen los estudiantes
Estas reseñas son de estudiantes inscritos que completaron al menos el 50% del curso. Moderamos las reseñas solo por motivos de contenido (spam, lenguaje ofensivo, datos personales), nunca por ser críticas o negativas.
Aún no hay reseñas aprobadas.
¡Sé el primero en compartir tu experiencia!