¿Qué problema resuelven formatos de tabla como Iceberg y Delta Lake que Parquet a secas sobre almacenamiento de objetos no resuelve?

Ficheros Parquet sueltos en un bucket no te dan transacciones, así que un lector puede ver un directorio escrito a medias y un job fallido deja datos parciales. Los formatos de tabla añaden una capa de metadatos con commits atómicos y aislamiento por snapshot, de modo que las escrituras aparecen todas de golpe. También aportan evolución de esquema, actualizaciones y borrados a nivel de fila, viaje en el tiempo a snapshots previos, y poda de ficheros mediante estadísticas en lugar de listar directorios.

Con Parquet a secas la tabla es en realidad una convención de directorios, así que no hay atomicidad. Si un job muere a mitad, los lectores ven datos parciales, y no hay forma de actualizar o borrar una sola fila sin reescribir particiones enteras a mano. Los formatos de tabla arreglan eso con una capa de metadatos. Un commit intercambia de forma atómica un puntero a un snapshot nuevo, así que los lectores ven o el estado antiguo o el nuevo, nunca una mezcla, y obtienes viaje en el tiempo casi gratis porque los snapshots antiguos siguen existiendo. Esa última parte nos salvó una vez, cuando una transformación mala sobrescribió un mart y recuperamos consultando el snapshot anterior en lugar de restaurar desde backups. La otra cosa que me gusta de Iceberg en concreto es el particionado oculto, donde la tabla rastrea ella misma la transformación de partición, así que un analista que filtra por un timestamp obtiene poda sin conocer la disposición. El coste es mantenimiento: necesitas compactación programada de ficheros pequeños y caducidad de snapshots, o los metadatos crecen sin límite.