Lakehouse o Warehouse? Depende.
Y de qué depende? De eso va esta sesión.
Somos Jimena y Raquel, y elegimos Warehouse cuando teníamos que elegir Lakehouse. 🙋‍♀️🙋‍♀️
La escena seguro que ya la conoces... un caso real encima de la mesa, un cliente que lo quería para ayer y tres personas dándote tres opiniones distintas. 🗣️ Y de fondo, un pipeline que lleva tres horas fallando en silencio, muy educadamente, sin molestar a nadie. 🔕
El problema es que Lakehouse y Warehouse se parecen lo suficiente como para que la decisión acabe tomándose por intuición: los dos guardan en Delta sobre OneLake y los dos responden T-SQL. Así que no se elige leyendo más documentación. Se elige haciéndose las preguntas correctas:
🔧 Spark o T-SQL? La guía de decisión de Microsoft la pone primero, y no es casualidad: cómo quiera desarrollar tu equipo resuelve medio debate.
🔁 Necesitas transacciones multi-tabla? Si es que sí, se acabó la discusión: Warehouse.
🤷‍♀️ Sabes qué forma tienen tus datos? Estructurado y no estructurado, o "ni idea todavía" → Lakehouse. Solo estructurado → Warehouse. Lo dice la doc, no nosotras. 😅
✍️¿Quién va a escribir? El SQL analytics endpoint del Lakehouse es de solo lectura. Esta es la que más disgustos da. 💔
🤝 Y si son los dos? Spoiler: muchas veces lo son. Hablamos de cuándo esa convivencia tiene sentido y cuándo es indecisión con arquitectura encima.
No hay una respuesta universal, pero sí hay un marco mental que convierte el caos de piezas en decisiones que se sostienen. Incluso con tres opiniones distintas encima de la mesa.
Te llevas criterio propio. Nosotras nos quedamos con el trauma. 😌