El Problema con las Tablas de Datos Tradicionales
Desliza para mostrar el menú
Las tablas de datos tradicionales almacenadas como archivos sin procesar (como CSV o Parquet) son "no gestionadas". Carecen de los mecanismos necesarios para prevenir la corrupción de datos, manejar usuarios simultáneos o deshacer errores, lo que conduce a lo que a menudo se denomina un "Data Swamp".
1. Falta de atomicidad (escrituras parciales)
Imagina que tu clúster está a mitad de escribir 50,000 nuevos registros de diamantes en un archivo cuando se va la energía o falla la red.
El resultado: Terminas con un archivo "corrupto". La mitad de los datos está presente, la otra mitad falta, y tu análisis ahora es permanentemente incorrecto. Los archivos tradicionales no tienen una regla de "todo o nada".
2. Sin validación de esquema
En una configuración tradicional, nada impide que un usuario suba accidentalmente un registro de diamante donde el "Price" sea un texto (como "Expensive") en lugar de un número.
El resultado: La próxima vez que intentes ejecutar una suma o promedio, toda tu canalización falla porque las "operaciones matemáticas" no pueden manejar el texto. Los archivos sin procesar son "fallos silenciosos": aceptan datos erróneos sin advertir.
3. El problema de los "dos cocineros" (concurrencia)
¿Qué sucede si dos ingenieros de datos diferentes intentan actualizar la tabla Diamonds en el mismo segundo exacto?
El resultado: Es probable que los cambios de una persona sobrescriban los de la otra, o que el archivo quede bloqueado e inutilizable. Los sistemas de archivos tradicionales no están diseñados para que varias personas lean y escriban en los mismos datos simultáneamente.
4. Sin botón de "deshacer"
Si por accidente ejecutas un comando que elimina todos los diamantes de corte "Premium" de tu conjunto de datos, esos datos se pierden. En un sistema de archivos estándar, no existe un "historial" o botón de "deshacer" incorporado para ver cómo era la tabla hace cinco minutos.
La evolución: por qué necesitamos Delta Lake
Estos problemas son la razón por la que las empresas migran de los Data Lakes (solo carpetas de archivos) hacia el Lakehouse.
Para resolver estos problemas, Databricks creó Delta Lake. Añade un "registro de transacciones" a tus archivos, actuando como un contador sofisticado que:
- Registra cada cambio;
- Garantiza que no ingrese información incorrecta;
- Permite "viajar en el tiempo" a versiones anteriores si ocurre un error.
1. ¿Qué es la "escritura parcial" o "corrupción de datos" en un sistema de datos tradicional?
2. ¿Por qué es importante la "validación de esquema" para un conjunto de datos como nuestra tabla Diamonds?
¡Gracias por tus comentarios!
Pregunte a AI
Pregunte a AI
Pregunte lo que quiera o pruebe una de las preguntas sugeridas para comenzar nuestra charla
