Día 4 -- Optimización: compresión Iceberg, particionado y Z-order

### Jueves, 9:00 AM -- El coste del lake

Fernando te pide sentarte con el un momento antes del standup. "Ayer recibi la factura de AWS del mes pasado. El data lake de S3 nos cuesta 3.200 EUR/mes y crece un 8% mensual. A este ritmo, en 6 meses serán 5.000 EUR/mes solo de storage. Kenji me dice que hay margen de optimización pero nunca ha tenido tiempo de hacerlo. Quiero que dediques hoy a esto. Entregable: un plan de optimización con números de antes/después."

Revisas las métricas del lake con Kenji:

• ▹Tamano total: 12.3 TB en S3 (zona raw: 4.1 TB, silver: 5.2 TB, gold: 3.0 TB)
• ▹Crecimiento diario: ~100 GB/día (vibracion domina con 65 GB/día)
• ▹Formato: Parquet con compresión Snappy (default de Spark)
• ▹Particionado: por fecha (dt=YYYY-MM-DD) en todas las tablas
• ▹Archivos: muchos archivos pequeños (problema de "small files") -- promedio 8 MB/archivo
• ▹Queries tipicas de Patricia: filtrar por machine_id + rango de fecha. Full scan actual.
• ▹Queries de BMW export: filtrar por batch_id + fecha. Tambien full scan.
• ▹Retencion: sin politica definida. Datos de hace 18 meses siguen en raw.

Los 3 problemas principales que identificas:

1. 01.COMPRESION SUBOPTIMA: Snappy es rápido pero tiene ratio 2:1. Zstandard consigue 4:1 con datos de sensores (números repetitivos) sin penalización de lectura significativa. Potencial: reducir 12 TB a ~7 TB.
2. 02.SMALL FILES: El streaming escribe un archivo por micro-batch (cada 30 segundos). En un día = 2.880 archivos por particion. Overhead de metadata en Iceberg y latencia de listing en S3. Necesitas compaction.
3. 03.PARTICIONADO INEFICIENTE: Solo por fecha. Cuando Patricia busca "maquina X en los últimos 7 días", Spark escanea TODAS las maquinas de esos 7 días. Con Z-order (sort por machine_id dentro de cada particion), Spark puede saltar bloques irrelevantes (data skipping).

### Solucion 1: Migracion a Zstandard

Zstandard (zstd) nivel 3 ofrece ratio de compresión 2x mejor que Snappy con velocidad de descompresion similar. Para datos de sensores (valores numericos con alta repetitividad), el ratio mejora aun más. El cambio se aplica en la configuración de escritura de Iceberg -- los archivos existentes se pueden reescribir con un job de compaction.

### Solucion 2: Compaction automática

Iceberg tiene una accion de compaction (rewriteDataFiles) que fusiona archivos pequeños en archivos grandes. El objetivo: archivos de 256-512 MB (optimo para S3 y Spark). Un DAG de Airflow ejecuta la compaction cada 6 horas, fusionando los archivos del streaming.

### Solucion 3: Z-order por machine_id

Z-order (también llamado "data clustering") ordena los datos dentro de cada particion por una o más columnas. Cuando Spark busca machine_id = "MACH-L03-047", puede usar los min/max statistics de Iceberg para saltar archivos enteros que no contienen datos de esa maquina. Sin Z-order, Spark debe abrir todos los archivos de la particion.