Object storage, data lakes y warehouses

El disco de tu computadora guarda archivos en carpetas, con un sistema de archivos. Funciona muy bien para una máquina. Para 3,650 millones de fotos al año, que leen cientos de máquinas a la vez, se usa otra cosa: un object storage (almacenamiento de objetos).

Los más conocidos son de la nube, las computadoras que se rentan por hora o por GB: S3 (Simple Storage Service) de AWS, la nube de Amazon; Cloud Storage (GCS) de Google, y Blob Storage de Microsoft Azure. También hay versiones que una empresa instala en sus propias máquinas, como MinIO o Ceph.

Un objeto: bytes, llave y metadatos

Un objeto tiene tres partes:

• Los bytes: el contenido, sea un JPEG, un Parquet o un archivo de pesos. A S3 le da igual qué son.
• La llave (key): el nombre con el que lo guardas y lo pides, como fotos/2026/11/06/ana-tenis.jpg.
• Los metadatos (metadata): datos sobre el objeto, como su tamaño, su tipo (image/jpeg), la fecha en que se guardó y una huella de su contenido.

No hay que instalar nada para usarlo: se le habla por HTTP, con los métodos que ya conoces. PUT guarda un objeto, GET lo lee, DELETE lo borra y HEAD lee solo sus metadatos. Además hay LIST, que lista llaves. Cada una de esas operaciones es una request, y se cobra aparte de los GB guardados.

Se reemplaza entero

Un objeto no se edita a la mitad. Para cambiar un byte de una foto, la bajas completa, la cambias y la vuelves a subir: un PUT a la misma llave reemplaza al objeto viejo entero. Tampoco se le agregan líneas al final, como a un log en tu disco. Sí se puede leer solo un pedazo, con el header Range de un GET («dame del byte 1,000 al 5,000»): así un lector de Parquet lee solo las columnas que necesita.

¿Por qué tan limitado? Porque esa sencillez es lo que lo deja crecer sin tope. Si nadie edita a la mitad, no hay que coordinar a dos máquinas que escriben el mismo archivo. Cada objeto es independiente, y S3 puede repartir billones de ellos entre miles de discos. A cambio, tú organizas tus datos en objetos que se escriben una vez y se leen muchas.

Si dos programas hacen PUT a la misma llave casi al mismo tiempo, no se mezclan: gana el último, entero, y el otro se pierde sin aviso. Si no quieres que nadie pise una llave, desde agosto de 2024 S3 acepta escrituras condicionales: con el header If-None-Match: * («solo si no hay nada con esa llave»), el PUT falla con el código 412 si la llave ya existe. Y un GET justo después de un PUT ya ve el objeto nuevo: S3 lo garantiza desde diciembre de 2020. Antes, al reemplazar un objeto, un GET podía devolver el viejo durante un rato, la consistencia eventual de la lección de bases de datos.

El bucket

Los objetos viven dentro de un bucket. Ojo: en la lección de percentiles, un bucket era el intervalo de un histograma. Aquí es otra cosa, y en el glosario se llama bucket de objetos: el contenedor donde guardas objetos.

En S3, cada bucket tiene, por omisión, un nombre único en el mundo: si alguien ya usó ml-datos, tú no puedes (desde marzo de 2026 también se puede crear con un sufijo que lleva tu número de cuenta y la región, y ese nombre es solo tuyo). El bucket vive en una región, un grupo de centros de datos en un lugar, como el norte de Virginia, y lleva sus reglas: quién puede leer y escribir (su bucket policy), cuánto dura cada cosa y si guarda versiones viejas.

La dirección completa de un objeto junta las dos cosas: en s3://ml-datos/logs/dt=2026-11-06/part-0001.parquet, el bucket es ml-datos y la llave es todo lo que sigue.

Las carpetas no existen

La llave es solo un texto, de hasta 1,024 bytes, y puede llevar «/». La consola de S3 te enseña «carpetas», pero dentro hay una lista plana de llaves, ordenada. Lo que parece una carpeta es un prefijo (prefix): el principio que varias llaves comparten.

Esto tiene consecuencias. Listar con un prefijo es rápido, porque las llaves están ordenadas, y S3 te las da de 1,000 en 1,000. Pero «renombrar una carpeta» no existe: hay que copiar cada objeto a su llave nueva y borrar el viejo. Con un millón de objetos son dos millones de requests.

El juguete de abajo es un object storage hecho con un diccionario de Python: las llaves son texto y no hay carpetas. Fíjate en cuántas requests cuesta cambiar un byte y mover dos fotos.

from collections import Counter
objetos, requests = {}, Counter()        # un object storage de juguete: llave → bytes

def put(llave, datos):
    requests["PUT"] += 1
    objetos[llave] = bytes(datos)        # si la llave ya existía, lo reemplaza entero
def get(llave):
    requests["GET"] += 1
    return objetos[llave]
def listar(prefijo):
    requests["LIST"] += 1
    return sorted(k for k in objetos if k.startswith(prefijo))

for llave, kb in (("fotos/2026/11/06/ana-tenis.jpg", 200), ("fotos/2026/11/06/beto-bici.jpg", 150),
                  ("fotos/2026/11/07/caro-lampara.jpg", 180)):
    put(llave, b"\xff" * kb * 1000)
print(listar("fotos/2026/11/06/"))

foto = bytearray(get("fotos/2026/11/06/ana-tenis.jpg"))   # para cambiar un byte...
foto[10] = 0
put("fotos/2026/11/06/ana-tenis.jpg", foto)                # ...se sube entera otra vez

for k in listar("fotos/2026/11/06/"):                       # «renombrar la carpeta» del día 6
    put(k.replace("/06/", "/06-revisadas/"), get(k))
    del objetos[k]; requests["DELETE"] += 1
print(listar("fotos/"))
print(dict(requests))

['fotos/2026/11/06/ana-tenis.jpg', 'fotos/2026/11/06/beto-bici.jpg']
['fotos/2026/11/06-revisadas/ana-tenis.jpg', 'fotos/2026/11/06-revisadas/beto-bici.jpg', 'fotos/2026/11/07/caro-lampara.jpg']
{'PUT': 6, 'LIST': 3, 'GET': 3, 'DELETE': 2}

Seis PUT para tres fotos guardadas: una para cambiar un byte y dos para «mover» dos fotos. En S3 de verdad, la copia se hace sin bajar los bytes (una request COPY), pero se cobra igual que un PUT.

Ana toca «publicar», y la foto de 200 KB tiene que quedar guardada en un bucket del marketplace, para mostrarla en la publicación. La Ronda no dice cómo la sube la app: lo que sigue es el diseño más común, como supuesto, porque explica bien la idea. Hay dos caminos malos.

• Que pase por tu API. La foto cruza tu balanceador de carga y tus servidores solo para que ellos la vuelvan a subir a S3. A 500 fotos por segundo, eso son ≈ 100 MB/s de bytes que no necesitabas mover.
• Darle a la app las credenciales de S3, la clave secreta que da permiso de entrar al bucket. Cualquiera que abra la app podría sacarlas y leer o borrar todo el bucket. Nunca.

El camino bueno es una URL prefirmada (presigned URL; en Google se llama signed URL, URL firmada).

Quién firma, qué permite y cuánto dura

Tu servidor sí tiene permiso de escribir en el bucket. Con su clave secreta calcula una firma: un número que solo se puede producir con esa clave, y que depende de exactamente qué se permite (la cuenta se llama HMAC, y la verás en la lección de cifrado). Mete la firma en la dirección, en la query (la parte de la URL después del ?, en pares nombre=valor), y se la da a la app. Firmar es una cuenta local: el servidor no tiene que llamar a AWS.

La URL de una subida trae, entre otras, estas partes:

• El bucket y la llave: c01-subidas.s3.amazonaws.com y /fotos/8f3a.jpg.
• X-Amz-Credential: quién firmó, sin su secreto. Puede ser un usuario o un rol (una identidad de AWS con sus permisos, que usa un programa en vez de una persona).
• X-Amz-Date y X-Amz-Expires=900: cuándo se firmó y cuántos segundos vale.
• X-Amz-Signature: la firma.

Cuando llega el PUT, S3 recalcula la firma. Si alguien cambió la llave, el método o la hora, no coincide y responde 403. Si coincide, revisa que no haya vencido y que quien firmó todavía tenga permiso de hacer eso. Como el permiso viaja en la URL, esa request no lleva header Authorization.

Lo que permite una URL prefirmada es una operación (un PUT o un GET) sobre una llave, durante un rato que elige quien firma: en este ejemplo, 15 minutos, igual que en C02 (las cámaras de los centros de distribución). En S3, como mucho 7 días, y menos si se firmó con credenciales temporales (las que caducan solas, como las de un rol), porque vence cuando ellas vencen.

Sirve igual para bajar. En la Ronda, M02 lo usa en los trabajos largos: el resultado (un JSON enorme, una máscara, un PDF) se guarda en el bucket, y el cliente lo baja con una URL prefirmada de GET que vence en minutos.

Guardaste la foto de Ana. ¿Qué tan seguro es que siga ahí dentro de un año?

Once nueves

La durabilidad (durability) es la probabilidad de que un objeto que guardaste siga ahí, intacto, después de un año. S3 está diseñado para 99.999999999 % al año: once nueves. Dicho al revés, la probabilidad de perder un objeto dado en un año es 0.000000001 %, es decir, 10⁻¹¹.

Es un número tan chico que conviene traducirlo a objetos.

¿Cómo se logra? En S3 Standard (y en las demás clases de la tabla de abajo), cada objeto se guarda repartido en muchos discos, en al menos tres zonas de disponibilidad (centros de datos separados por kilómetros) de la región. Cada pedazo lleva una huella para detectar si un bit se dañó. Y cuando un disco muere, el sistema rehace sus pedazos con los demás antes de que muera otro.

Durabilidad no es disponibilidad

En la lección de probabilidad viste la disponibilidad y los los nueves: qué fracción del tiempo un servicio contesta. Son cosas distintas:

• Disponibilidad: ¿S3 me responde ahora? S3 Standard está diseñado para 99.99 % (≈ 53 minutos al año en que una request puede fallar). En su contrato (el SLA), AWS promete menos: 99.9 % cada mes, y si no lo cumple devuelve una parte del cobro.
• Durabilidad: ¿mi objeto sigue existiendo? Once nueves.

Un bucket puede no contestar un rato sin perder nada: reintentas y ahí está. Y al revés, con disponibilidad perfecta, un DELETE tuyo borra la foto para siempre. La durabilidad te protege del hardware, no de ti. Para lo segundo hay versionado del bucket (cada PUT o DELETE guarda la versión anterior), Object Lock (una versión que nadie puede borrar antes de una fecha) y copias en otra cuenta o región.

Clases de almacenamiento

No todo se lee igual de seguido. La foto de una publicación activa se ve cientos de veces; la de una que se vendió hace un año, casi nunca. Por eso S3 tiene clases de almacenamiento (storage classes): la misma foto, con la misma durabilidad, guardada más barato a cambio de que leerla cueste más o tarde más. Los nombres son de S3: IA quiere decir Infrequent Access (acceso poco frecuente), y Glacier (glaciar) es la familia de las clases para archivo.

Son precios de lista de la región del norte de Virginia (us-east-1), revisados en noviembre de 2026; cambian por región y con el tiempo. Standard baja un poco con volúmenes muy grandes: US$0.022 pasados los primeros 50 TB y US$0.021 pasados 500 TB.

Fíjate en la columna del mínimo. Si guardas algo en Standard-IA y lo borras a los 10 días, te cobran 30. Un objeto de 10 KB en Standard-IA paga como si pesara 128 KB. En Flexible Retrieval y Deep Archive, cada objeto paga además ≈ 40 KB de metadatos: con millones de objetos chicos, se nota. Y lo que se guarda en Glacier Deep Archive no se puede abrir al momento: primero pides que lo «restauren», y esperas horas. Google tiene la misma escalera con otros nombres: Standard, Nearline (30 días), Coldline (90) y Archive (365).

Elegir clase a mano para millones de objetos es imposible. Para eso existen las reglas de la sección siguiente.

Reglas de ciclo de vida

Una regla de ciclo de vida (lifecycle rule) le dice al bucket qué hacer con los objetos según su edad, sin que ningún programa tuyo lo haga. Tiene dos tipos de acción:

• Mover (transition): «a los 30 días, pasa a Glacier Instant Retrieval».
• Borrar (expiration): «a los 365 días, bórralo».

Cada regla aplica a un prefijo (o a los objetos con cierta etiqueta), así que distintas partes del bucket pueden tener reglas distintas. S3 la revisa por su cuenta, más o menos una vez al día. Así se ve una, en el JSON que recibe S3 (ilustración):

{"Rules": [{"ID": "fotos-viejas", "Status": "Enabled", "Filter": {"Prefix": "fotos/"},
            "Transitions": [{"Days": 30, "StorageClass": "GLACIER_IR"}],
            "Expiration": {"Days": 365}}]}

Retención: cuánto guardar y por qué

Antes de escribir la regla hay que decidir la retención (retention): cuánto tiempo se conserva cada cosa. La deciden tres fuerzas, y casi siempre tiran en direcciones distintas.

• El costo. Cada GB se paga cada mes que sigue ahí. Lo que nunca se borra crece sin parar.
• La ley y la privacidad. Las fotos y los logs traen datos de personas: caras, placas, ubicaciones en el EXIF (los datos que la cámara esconde dentro del JPEG). Las leyes de datos personales piden guardar solo lo necesario y borrar cuando alguien lo pide. Cuanto más guardas, más puedes filtrar.
• El ML. Para reentrenar, buscar drift y comparar modelos de meses distintos hace falta historia.

En C01, la Ronda las reparte así: los logs de predicción duran 90 días; las copias de fotos que van a etiquetar, también 90; los agregados diarios (cuántas predicciones por categoría, por ejemplo) se guardan para siempre, porque no traen datos de nadie. El golden set (las fotos fijas, bien etiquetadas, con las que se examina cada modelo) y los snapshots de entrenamiento (la lista exacta de datos con que se entrenó cada modelo, en la sección 7) no caducan: si el golden set se borrara a los 90 días, ya no podrías comparar el modelo de marzo con el de octubre sobre las mismas fotos. Pero cuando alguien pide que borren su foto, se busca por su huella en todos ellos.

Lo que cuesta: GB-mes y requests

S3 cobra con dos medidores.

• GB-mes: guardar 1 GB durante un mes. En Standard, ≈ US$0.023. Guardar 2 GB durante medio mes también es 1 GB-mes.
• Requests: en Standard, US$0.005 por cada 1,000 PUT (y COPY y LIST), y US$0.0004 por cada 1,000 GET. Los DELETE son gratis. Cuando una regla mueve un objeto de clase, eso también es una request (una transición): US$0.01 por cada 1,000 objetos hacia Standard-IA, US$0.02 hacia Glacier Instant Retrieval y US$0.05 hacia Deep Archive.

Para pasar de días a meses, las cuentas usan 30.4 días por mes (365 ÷ 12).

Una equivalencia para recordar: un PUT cuesta lo mismo que guardar ≈ 217 KB durante un mes (0.000005 ÷ 0.023 GB). Con una foto de 200 KB, subirla cuesta como un mes de guardarla. Con un log de 300 bytes, subirlo cuesta como guardarlo 60 años.

Esa cuenta es la del bucket del producto, el del marketplace. C01 no guarda su propia copia de cada foto: la foto ya vive ahí, y C01 solo anota su llave. Si la copiara «por si acaso», la Ronda (M12) calcula ≈ 60 TB más cada mes: ≈ US$1,380 el primer mes, US$2,760 el segundo, y así cada mes más, con datos personales y sin dueño.

Con objetos grandes, el costo son los GB. Con millones de objetos chicos, mandan las requests. El log de C01 lo muestra.

Ya tienes dónde guardar. Ahora falta organizar, para que alguien encuentre lo que busca entre millones de archivos.

Un lago de archivos

Un data lake es un object storage donde llega todo el dato de la empresa como archivos: logs, eventos de la app, etiquetas, copias de tablas. Se guarda tal como llegó y también ya procesado, y lo lee cualquier herramienta: Spark (un programa que reparte el trabajo de leer y transformar datos entre muchas máquinas), DuckDB (una base de datos chiquita para analizar, que corre en tu laptop), Athena (consultas SQL directo sobre los archivos de S3) o un script de Python.

La Ronda lo llama la fuente de verdad del camino offline, el que prepara el siguiente modelo sin que nadie espere: todo dataset de entrenamiento y todo recálculo del pasado salen de ahí. Casi siempre se organiza en zonas, cada una con su prefijo:

• Crudo (raw): tal como llegó, por ejemplo JSON lines del log. No se toca: si un paso posterior tenía un bug, se puede rehacer desde aquí.
• Procesado (processed): limpio, con tipos correctos, en Parquet. Es columnar y viene comprimido: los 3 GB diarios de log de C01 quedan en ≈ 0.3 a 0.6 GB.
• Curado (curated): tablas listas para usar, como un dataset de entrenamiento o los agregados diarios.

Así se vería el lake de C01, con un bucket y un prefijo por zona (un ejemplo; cada equipo elige sus nombres):

s3://c01-lake/
  crudo/predicciones/dt=2026-11-06/...        JSON lines, como llegaron
  procesado/predicciones/dt=2026-11-06/...    Parquet, una fila por predicción
  curado/agregados_diarios/dt=2026-11-06/...  conteos por categoría
  curado/datasets/ds-2026-09-01/...           el snapshot de un entrenamiento

Un lago no obliga a nada. Cualquiera puede escribir cualquier archivo, y nadie revisa que cumpla el esquema: las columnas y sus tipos. El esquema lo descubre quien lee, al leer (schema on read). Si el equipo de la app renombró una columna el martes, el job de la noche se entera al fallar, o peor, sin fallar. Por eso los lagos sin reglas se vuelven pantanos, con archivos que nadie sabe qué son. Las capas de la sección siguiente ponen el orden: el warehouse y el lakehouse revisan el esquema al escribir.

Particionar por fecha

Si todo el log de un año estuviera en un solo prefijo, preguntar «¿cuántas fotos de tenis hubo ayer?» obligaría a leer el año entero. La solución es una partición (partition): dividir la tabla en grupos de archivos según el valor de una columna, casi siempre la fecha, y poner ese valor en la llave:

logs/predicciones/dt=2026-11-06/part-0000.parquet

El pedazo dt=2026-11-06 es una convención (columna=valor) que entienden Spark, Athena, DuckDB y los warehouses. dt es solo el nombre de la columna, por date; en la lección de formatos la viste como fecha=2026-11-05/, y funciona igual. Cuando la consulta dice «solo el 6 de noviembre», el motor lista ese prefijo y no abre nada más. Se llama partition pruning: podar las particiones que no sirven.

El lake de juguete de abajo tiene un mes de log: 4 archivos Parquet por día, de ≈ 125 MB cada uno. Leer «un día» es listar su prefijo.

import random
random.seed(7)
lake = {}                                  # llave → bytes del archivo: solo importan las llaves
for dia in range(1, 31):                   # noviembre de 2026, 4 archivos Parquet por día
    for parte in range(4):
        llave = f"logs/predicciones/dt=2026-11-{dia:02d}/part-{parte:04d}.parquet"
        lake[llave] = random.randint(100, 150) * 1_000_000

def leer(prefijos):                        # lo que hace un motor de consultas: listar y leer
    llaves = [k for k in lake if any(k.startswith(p) for p in prefijos)]
    return len(llaves), sum(lake[k] for k in llaves)

semana = [f"logs/predicciones/dt=2026-11-{d:02d}/" for d in range(1, 8)]
for nombre, prefijos in (("un día", ["logs/predicciones/dt=2026-11-06/"]),
                         ("una semana", semana), ("el mes entero", ["logs/predicciones/"])):
    n, b = leer(prefijos)
    print(f"{nombre:>13}: {n:>3} archivos · {b / 1e9:5.2f} GB")

particiones = sorted({k.split("/")[2] for k in lake})   # como un LIST con delimitador «/»
print(len(particiones), "particiones:", particiones[0], "…", particiones[-1])

       un día:   4 archivos ·  0.50 GB
   una semana:  28 archivos ·  3.34 GB
el mes entero: 120 archivos · 14.92 GB
30 particiones: dt=2026-11-01 … dt=2026-11-30

Leer un día abre 4 de los 120 archivos: un trigésimo del mes. La última línea hace lo que un LIST con delimitador «/»: en vez de todas las llaves, S3 devuelve solo los prefijos distintos hasta la siguiente «/», que aquí son las 30 particiones.

Particionar también hace que cada corrida procese una partición. El job de cada noche escribe solo dt=2026-11-06/. Si tenía un bug, se reescribe esa partición y nada más. Lo contrario, una tabla única que se reescribe entera cada noche, obliga a reprocesar todo para arreglar un día.

Se puede particionar por más de una columna, una dentro de otra. El log de predicciones de la Ronda (M12) va por día y por versión del modelo, dt=2026-11-06/model_version=v13/, para que el job que compara la versión nueva con la vieja lea solo las dos que le tocan. La columna que va primero es la que más se filtra.

Tres reglas para que funcione:

• Partir por lo que se filtra. La fecha casi siempre, porque casi toda pregunta empieza por «en estos días». Partir por categoría, si nadie filtra por categoría, solo multiplica archivos.
• Ni muy fino ni muy grueso. Particionar por hora y además por usuario daría millones de archivos diminutos, y ya viste que los objetos chicos se pagan en requests y en tiempo de listar. Se buscan archivos de ≈ 100 MB a 1 GB. Cuando un stream (un flujo de eventos que no para, tema de la lección siguiente) deja muchos archivos chicos, un job de compactación los junta cada noche en pocos grandes.
• ¿Qué fecha? Una predicción de las 23:59 puede llegar al lake a las 00:03. Si la partición usa la hora de llegada, cae en el día siguiente. Para entrenar importa la hora en que pasó, el event time, que verás en la lección de tiempo y hashes.

Dos maneras de usar datos: OLTP y OLAP

La base de datos del marketplace atiende millones de operaciones chiquitas: guardar una publicación, leer el usuario 42, cambiar un precio. Cada una toca pocas filas, completas, y tiene que tardar milisegundos. Eso se llama OLTP (online transaction processing, procesar transacciones en línea, mientras el usuario espera), y es lo que viste en la lección de bases de datos: tablas en una base relacional, con transacciones e índices.

Un analista pregunta otra cosa: «¿cuántas predicciones hubo por categoría en octubre, y cuántas aceptó la gente?». Su consulta toca millones de filas, pero solo dos o tres columnas, y puede tardar segundos. Eso es OLAP (online analytical processing, procesar para analizar).

Son formas tan distintas que piden almacenes distintos. Para OLTP conviene guardar cada fila junta; para OLAP, cada columna junta, como Parquet. La lección de formatos lo explicó: leer dos columnas de treinta en un formato columnar es leer ≈ 2/30 de los bytes (≈ 7 %), y menos con compresión. La diferencia entre OLTP y OLAP es la razón de que existan los warehouses.

Data warehouse

Un data warehouse es una base de datos hecha para OLAP: guarda las tablas por columnas, comprimidas, en su propio almacenamiento, y responde SQL repartiendo cada consulta entre muchas máquinas. Los más usados son BigQuery (Google), Snowflake y Redshift (AWS). Separan el almacenamiento del cálculo: guardas petabytes baratos y rentas máquinas solo mientras corre la consulta.

SELECT categoria, COUNT(*) AS fotos, AVG(CAST(aceptada AS INT64)) AS tasa_aceptacion
FROM c01.predicciones
WHERE dt BETWEEN '2026-10-01' AND '2026-10-31'
GROUP BY categoria
ORDER BY fotos DESC;

Se lee casi en español: de la tabla c01.predicciones, toma las filas de octubre (WHERE), júntalas por categoría (GROUP BY) y, para cada grupo, cuenta las fotos y saca el promedio de aceptada, que vale 1 si la persona aceptó la categoría sugerida y 0 si no: ese promedio es la tasa de aceptación. Toca millones de filas, pero solo tres columnas: categoria, aceptada y dt.

BigQuery, en su modo por consulta, cobra por los bytes que lee: US$6.25 por TiB en su precio de lista de 2026, con el primer TiB de cada mes gratis. Ahí las particiones y las columnas se vuelven dinero. Si la consulta leyera el log crudo, como archivos JSON sin particiones, pagaría el año entero: ≈ 1.1 TB, ≈ US$6 por consulta. En Parquet, las tres columnas que usa esa consulta en las particiones de un mes son unos pocos GB: centavos.

¿Lake o warehouse? El lake es barato, guarda cualquier cosa y lo lee cualquier herramienta, pero no tiene transacciones: si un job muere a la mitad de escribir una partición, quien lea en ese momento ve archivos a medias. El warehouse da tablas con transacciones y SQL rápido, pero cuesta más y hay que cargarle los datos. Muchas empresas usan los dos: el lake guarda todo y el warehouse, las tablas que se consultan a diario.

Lakehouse: tablas encima de los archivos

Un lakehouse junta lo mejor de los dos: deja los datos como archivos Parquet en el lake y les pone encima un formato de tabla que da transacciones. Los tres más usados son Delta Lake (de Databricks), Apache Iceberg (nació en Netflix) y Apache Hudi (nació en Uber).

El truco es un registro aparte, guardado en el mismo bucket, que dice qué archivos forman la tabla en cada versión. Escribir es: subir los Parquet nuevos y, al final, agregar al registro una entrada que diga «la versión 3 son estos archivos». Hasta que esa entrada existe, nadie ve los archivos nuevos. Así cada escritura pasa completa o no pasa, y quien lee nunca ve una tabla a medias.

Con eso se puede:

• Corregir filas sueltas con un upsert (actualizar la fila si existe, insertarla si no) o borrarlas, algo que con Parquet solo no se puede, porque un objeto no se edita a la mitad. Hace falta, por ejemplo, para borrar los datos de una persona que lo pidió.
• Agregar columnas sin romper a quien lee (la evolución del esquema de la lección de formatos).
• Leer la tabla como estaba en una versión o una fecha: el time travel (viaje en el tiempo).

Snapshot: una foto fija para repetir un entrenamiento

Un snapshot es una foto fija de los datos en un momento: lo que había, y que ya no cambia aunque la tabla siga creciendo. En Iceberg, cada escritura crea uno. Para ML es la pieza que hace repetible un entrenamiento: el modelo de octubre guarda con qué snapshot se entrenó, y dentro de seis meses alguien puede volver a leer exactamente esas filas.

C01 lo hace sin copiar fotos. Su snapshot es un manifest: un archivo Parquet que lista la llave de cada foto, su etiqueta y una huella de su contenido (un hash SHA-256, que cambia si cambia un solo byte). Vive en un prefijo que no se reescribe, como datasets/ds-2026-09-01/, y el modelo guarda la huella del propio manifest. Un manifest pesa megabytes, así que puedes tener uno por mes durante años.

Llevar la cuenta de qué snapshot, qué código y qué contenedor produjeron cada modelo es el versionado de datos y el linaje: los verás a fondo en la estación 2 del Dojo, con DVC y lakeFS.

1. Usar el object storage como si fuera un disco

Abrir un objeto para agregarle una línea, editarlo a la mitad o «renombrar una carpeta» con un millón de fotos como si fuera instantáneo. O dos jobs que escriben la misma llave: gana el último, y el otro se pierde sin aviso.

Cómo evitarlo: diseñar con objetos que se escriben una vez. Llaves que no se repiten (con la fecha, la versión o el id del job), archivos nuevos en vez de editar los viejos y, si hace falta editar filas, un formato de tabla como Delta o Iceberg.

2. Millones de objetos chiquitos

Un objeto por predicción, por evento o por fila. Guardarlos es barato; subirlos, listarlos, moverlos de clase y leerlos, no. El log de C01 así cuesta ≈ US$1,650 al mes en vez de ≈ US$6.

Cómo evitarlo: juntar en archivos de ≈ 100 MB a 1 GB (Parquet, o pedazos de muchas fotos para entrenar). Y antes de una regla de ciclo de vida, contar los objetos, no solo los GB.

3. Creer que once nueves son un respaldo

La durabilidad protege de discos rotos, no de un DELETE, de una regla de ciclo de vida mal escrita o de un script con el prefijo equivocado.

Cómo evitarlo: versionado del bucket en lo que no se puede perder, Object Lock en lo que nadie debe borrar (el golden set, los snapshots de modelos en producción) y permisos que no dejen borrar a quien solo necesita leer.

4. Hacer público un bucket para «compartir rápido»

Un bucket público, o URLs prefirmadas de 7 días pegadas en un chat, con fotos de personas adentro.

Cómo evitarlo: el bucket privado siempre. Para compartir, URLs prefirmadas de una sola llave, de minutos, firmadas por un servicio que revisa quién las pide.

5. Mover a una clase fría lo que se sigue leyendo

Mandar a Standard-IA el dataset que se lee en cada entrenamiento, o a Deep Archive algo que alguien va a necesitar mañana. Pagas el GB leído, el mínimo de días y, en Deep Archive, horas de espera.

Cómo evitarlo: mirar cuántas veces se lee de verdad cada prefijo antes de escribir la regla. Si no lo sabes, Intelligent-Tiering, una clase de S3 que mueve cada objeto sola según su uso, a cambio de una cuota pequeña por objeto.

6. Una retención que nadie cumple

El bucket borra a los 90 días, pero las fotos siguen en snapshots, en copias y en laptops.

Cómo evitarlo: escribir la retención de cada artefacto al crearlo, no después, y que los snapshots se puedan buscar por la huella de cada foto para borrarla de todos.

Resuélvelos con lápiz antes de abrir la solución. Los de costo se pueden comprobar con las calculadoras. Usa los precios de S3 Standard de la lección.

1. 1Fácil

   En s3://ml-datos/logs/dt=2026-11-06/part-0003.parquet, ¿cuál es el bucket y cuál la llave? ¿Qué devuelve un LIST con el prefijo logs/dt=2026-11-0? Alguien quiere «renombrar la carpeta» logs/ a predicciones/ y tiene 50,000 objetos: ¿cuántas requests hace y cuánto cuestan?

   Ver la solución paso a paso

   • Bucket: ml-datos. Llave: logs/dt=2026-11-06/part-0003.parquet, todo lo que sigue.
   • El LIST devuelve las llaves de los días 1 al 9 de noviembre de 2026: un prefijo no tiene que terminar en «/».
   • Renombrar no existe: 50,000 COPY y 50,000 DELETE, más 50 LIST de 1,000 llaves. Son ≈ 100,050 requests.
   • Las COPY y los LIST se cobran como PUT: 50,050 × 0.005 ÷ 1,000 ≈ US$0.25. Los DELETE son gratis. Barato, pero no instantáneo, y quien lea a la mitad ve una parte en cada lado.
2. 2Fácil

   Un equipo guarda mil millones de objetos en S3, con once nueves de durabilidad. ¿Cuántos esperaría perder al año? Y si el servicio tiene 99.99 % de disponibilidad, ¿cuántos minutos al año puede no contestar? ¿Se pierde algo en esos minutos?

   Ver la solución paso a paso

   • Durabilidad: 10⁹ × 10⁻¹¹ = 0.01 objetos al año: uno cada 100 años.
   • Disponibilidad: 0.01 % de 525,600 minutos ≈ 53 minutos al año.
   • En esos minutos no se pierde nada: las requests fallan, se reintenta y los objetos siguen ahí. Son dos medidas distintas.
3. 3Fácil

   Un millón de registros de 1 KB: ¿cuánto cuesta guardarlos un mes y cuánto subirlos, si cada uno es un objeto? ¿Y si los juntas en un solo archivo de 1 GB?

   Ver la solución paso a paso

   • Guardar: 1 GB × 0.023 = US$0.023 en los dos casos.
   • Subir un millón de objetos: 10⁶ × 0.005 ÷ 1,000 = US$5, 217 veces lo que cuesta guardarlos un mes.
   • Un solo archivo: un PUT (en la práctica, unas pocas partes), ≈ US$0.000005.
4. 4Fácil

   La API de C02 firma una URL de PUT para la llave sitio-07/clips/e-31.mp4, válida 15 minutos. ¿Qué puede hacer quien la tenga? ¿Puede leer otros clips, o subir uno a otra llave? ¿Y a los 20 minutos?

   Ver la solución paso a paso

   • Puede subir un archivo a esa llave, una o varias veces, durante 15 minutos (900 segundos). Si sube dos veces, el segundo reemplaza al primero.
   • No puede leer nada (la firma es para PUT), ni escribir en otra llave: cambiar la llave rompe la firma y S3 responde 403.
   • A los 20 minutos ya venció: 403. La caja (la computadora del sitio) pide una URL nueva.
   • Ojo: cualquiera que la copie puede hacer lo mismo durante esos 15 minutos. Por eso no se escribe en los logs.
5. 5Medio

   Guardas 1 TB de datos temporales que vas a borrar a los 10 días. ¿Sale más barato en Standard o en Standard-IA? ¿Y si los guardaras 60 días?

   Ver la solución paso a paso

   • Standard, 10 días: 1,000 GB × 0.023 × 10 ÷ 30.4 ≈ US$7.57.
   • Standard-IA cobra mínimo 30 días: 1,000 × 0.0125 = US$12.50. Sale más caro, aunque su precio por GB es casi la mitad.
   • A 60 días: Standard, 1,000 × 0.023 × 2 ≈ US$46; IA, 1,000 × 0.0125 × 2 = US$25, si no se lee. Leerlo todo una vez sumaría 1,000 × 0.01 = US$10, y todavía gana IA.
6. 6Medio

   El log de C01 en Parquet pesa ≈ 0.5 GB al día. Un analista corre cada mañana una consulta sobre los últimos 7 días. ¿Cuántos GB lee con particiones por día? ¿Y si la tabla no tuviera particiones y guardara un año? ¿Cuántas veces más?

   Ver la solución paso a paso

   • Con particiones: 7 × 0.5 = 3.5 GB.
   • Sin particiones, el motor no sabe dónde está cada fecha y abre todo el año: 365 × 0.5 = 182.5 GB.
   • 182.5 ÷ 3.5 ≈ 52 veces más, cada mañana. En BigQuery, que cobra por bytes leídos, es ≈ 52 veces el precio.
7. 7Medio

   C07 guarda una copia de sus vectores en S3: ≈ 205 GB por versión del modelo. Quiere conservar las últimas 6 versiones. ¿Cuánto cuesta al mes en Standard y en Glacier Instant Retrieval? ¿Cuánto cuesta leer una versión completa desde Glacier IR para reconstruir un índice?

   Ver la solución paso a paso

   • 6 × 205 = 1,230 GB.
   • Standard: 1,230 × 0.023 ≈ US$28 al mes.
   • Glacier IR: 1,230 × 0.004 ≈ US$4.92 al mes.
   • Leer una versión desde Glacier IR: 205 × 0.03 ≈ US$6.15. Si las versiones viejas se leen menos de una vez al mes, conviene: deja la actual en Standard y las otras 5 en Glacier IR.
8. 8Reto

   Diseña el almacenamiento del log de C01 para un año, con la Ronda: filas crudas 90 días, agregados para siempre. Compara: (a) un objeto por predicción, en Standard; (b) un archivo por minuto. Para cada uno: GB guardados, costo de guardar, de los PUT y de leerlo una vez al mes. ¿Qué regla de ciclo de vida escribes?

   Ver la solución paso a paso

   • Guardado en los dos: 3 GB × 90 = 270 GB, ≈ US$6.2 al mes.
   • (a) PUT: 10 M × 30.4 × 0.005 ÷ 1,000 ≈ US$1,520 al mes. Leer un mes: 304 M × 0.0004 ÷ 1,000 ≈ US$122. Total ≈ US$1,650.
   • (b) PUT: 1,440 × 30.4 = 43,776 al mes, ≈ US$0.22. Leer un mes, 43,776 GET: ≈ US$0.02. Total ≈ US$6.4.
   • La regla: borrar a los 90 días el prefijo de las filas crudas (Expiration, 90 días) y ninguna regla sobre el de los agregados. No vale la pena mover el log a una clase fría: pesa poco y se lee para cada reentrenamiento.
   • En Parquet serían ≈ 0.3–0.6 GB al día: el guardado bajaría a ≈ 27–54 GB, ≈ US$1 al mes.
9. 9Reto

   El backfill del catálogo de C01: 200 millones de fotos, partidas en 2,000 pedazos iguales. Cada GPU T4 clasifica ≈ 1,000 fotos por segundo, y hay 4. (a) ¿Cuántas fotos lleva cada pedazo? (b) ¿Cuánto tarda todo? (c) ¿Cuánto cuestan los GET? (d) El pedazo 1,234 se cae a la mitad: ¿qué se repite, y qué tiene que cumplir cada pedazo para que repetirlo no haga daño?

   Ver la solución paso a paso

   • (a) 200,000,000 ÷ 2,000 = 100,000 fotos por pedazo.
   • (b) 200 M ÷ (4 × 1,000 por segundo) = 50,000 s ≈ 14 horas.
   • (c) 200 M × 0.0004 ÷ 1,000 = US$80.
   • (d) Solo el pedazo 1,234: el job ve que no tiene archivo de salida y lo vuelve a correr. Para que eso sea seguro, cada pedazo escribe su salida en una llave fija, como .../shard-01234.parquet, y solo al terminar: si se repite, reescribe el mismo objeto con lo mismo. Es idempotente.

En la Ronda:

• M09 · Datos es esta lección hecha diseño: el data lake en Parquet particionado por dt=, cada corrida sobre una partición, los backfills de 180 días, los snapshots con manifest y prefijos que no se pisan, Delta e Iceberg con su time travel, y el feature store con sus dos almacenes.
• M13 · Nube recorre los bytes para encontrar los costos ocultos: S3 por GB y por request, objetos chicos contra Parquet, las equivalencias entre AWS, Google y Azure (S3, Cloud Storage, Blob; EBS, Persistent Disk; Redshift, BigQuery) y por qué los pesos se leen de S3 por un camino privado y no por internet.
• M12 · Monitoreo guarda el log de predicciones con retención escalonada (filas 90 días, agregados para siempre) y advierte la trampa de loguear la imagen «por si acaso».
• M02 · Patrones usa la URL prefirmada en los trabajos asíncronos y los pedazos con salida fija en el batch.

En el Dojo: la estación 1, «Datos y etiquetas», ya copia de S3 las fotos que hay que etiquetar, sin EXIF, a un bucket restringido. La estación 2, «Versionado y linaje», cuando abra, va a armar los snapshots con manifest y a versionarlos con DVC o lakeFS.

En Sensei: la siguiente lección, «Colas y streams», cuenta cómo llegan los eventos al lake, y «Tiempo, hashes e identificadores» explica las huellas de los manifests, el event time y el point-in-time join. Más adelante, las lecciones de regiones y redes en la nube explican por qué cuesta sacar datos de una región.

Estos son los conceptos que presentó esta lección. Cada uno tiene su tarjeta con la definición completa.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿Por qué no se puede «editar a la mitad» un objeto de S3, y qué haces si necesitas cambiarlo?Ver respuesta

   Porque solo guarda objetos enteros: un PUT a la misma llave reemplaza todo, y esa sencillez le deja repartir billones de objetos sin coordinar escrituras. Lo bajas, lo cambias y lo subes entero; para editar filas, Delta o Iceberg.

2. 2¿Qué permite una URL prefirmada y quién la firma?Ver respuesta

   Una operación (PUT o GET) sobre una llave, por un rato. La firma con su clave secreta un servidor con permiso, y quien tenga la URL la usa hasta que vence.

3. 3Once nueves de durabilidad, ¿quieren decir que tus datos están a salvo?Ver respuesta

   De los discos rotos, sí: perderías uno de 10 millones cada 10,000 años. De un DELETE, una regla mal escrita o un prefijo equivocado, no: para eso, versionado, Object Lock y permisos.

4. 4¿Por qué un ciclo de vida que mueve millones de fotos chicas a una clase fría puede ahorrar poco?Ver respuesta

   Porque cada transición se cobra por objeto: mover 304 millones de fotos al mes a Glacier IR cuesta ≈ US$6,080, casi la mitad del ahorro en GB; a Deep Archive, más que todo el ahorro.

5. 5¿Para qué sirve particionar un log por dt=?Ver respuesta

   Para leer solo los días necesarios: una semana son 3.5 GB en vez de los 182.5 del año. Y para que cada corrida reescriba solo su día si algo sale mal.

6. 6¿Qué le agrega un lakehouse a un data lake?Ver respuesta

   Un registro de qué archivos forman la tabla en cada versión. Con él, cada escritura pasa completa o no pasa, se corrigen filas y se lee una versión vieja (time travel), sin copiar datos.