Tres lakehouses y ocho cuadernos
Ver las 2 entradas de la serie
- Tres capas y un montón de controles
- Tres lakehouses y ocho cuadernos — estás aquí
Datos · Microsoft Fabric · Segunda parte
Por qué elegí el mismo tipo de almacén para las tres capas, y qué hace exactamente cada pieza del proceso desde que el dato entra por la puerta.
De la entrada anterior me llegaron dos preguntas, y las dos venían de gente que sabe del tema. La primera: ¿por qué los tres almacenes son del mismo tipo? Lo normal es que la última capa sea un almacén de datos clásico. La segunda, más doméstica: vale, muy bonito, pero ¿qué hace exactamente cada pieza?
Van las dos.
Dos formas de guardar lo mismo
En Fabric, cuando tienes que decidir dónde guardas los datos, hay básicamente dos opciones. Y como los nombres no ayudan nada —lakehouse y warehouse, casa del lago y almacén—, lo explico con algo de andar por casa.
Un almacén de datos clásico es una base de datos de toda la vida. Tiene su propio motor, guarda las cosas a su manera, y para hablar con él usas SQL. Es el mostrador de una tienda: tú pides, él te sirve, y lo que hay detrás del mostrador es cosa suya. Funciona estupendamente y lleva treinta años haciéndolo.
Un lakehouse es, literalmente, una carpeta de ficheros con un índice encima. Los datos están ahí, en archivos, en un formato abierto que cualquier herramienta puede leer. Es el almacén con estanterías abiertas: entras, ves las cajas, y puedes cogerlas tú mismo o pedirle a alguien que te las traiga.
La diferencia que importa no es de velocidad ni de capacidad —las dos opciones van sobradas para la mayoría de los proyectos—, sino de quién puede tocar los datos y con qué herramienta.
Por qué elegí estanterías abiertas en las tres
Tres razones, y ninguna es «porque es más moderno».
1. No cambiar de herramienta a mitad del camino
Las dos primeras capas se transforman con una herramienta concreta. Son procesos que leen mucho, limpian, cruzan y escriben: eso se hace con código, no con consultas.
Si la última capa fuera un almacén clásico, tendría que cambiar de herramienta justo en el último paso. Y eso significa tener dos tecnologías conviviendo, dos formas de escribir lo mismo, dos juegos de pruebas y dos sitios donde buscar cuando algo falla.
Es como construir media casa en metros y la otra media en pulgadas. Se puede. Pero cada vez que toques la junta vas a tener que convertir, y cada conversión es un sitio donde meter la pata.
La herramienta más potente no es la mejor elección. La mejor elección es la que no te obliga a cambiar de herramienta.
2. Cómo se escribe de verdad en la última capa
Esta razón es menos obvia y más decisiva.
Mucha gente imagina que una plataforma de datos va añadiendo filas una a una, como quien apunta en una libreta. No es así. Lo que pasa en la práctica es que se reescriben bloques enteros: «vuelve a calcular todo el mes de marzo del hotel de Lisboa», o «el sistema de origen ha corregido una semana entera, rehazla».
Y ahí hay una diferencia real entre las dos opciones. El formato de ficheros del lakehouse está pensado para eso: reemplazar un bloque completo es tirar unos ficheros y poner otros. En un almacén clásico, la misma operación sobre tablas de decenas de millones de filas es bastante menos agradecida y mucho menos predecible en coste.
Dicho en plata: si tu forma de trabajar es «rehaz este cajón entero», te conviene un armario con cajones extraíbles, no uno donde haya que ir sacando los calcetines de uno en uno.
3. Que los informes lean los ficheros directamente
La tercera tiene que ver con lo que pasa al final, cuando alguien abre un informe.
Power BI puede leer directamente los ficheros del lakehouse, sin copiarlos antes a ningún sitio. Eso significa que cuando termina la carga de la noche, el informe ya tiene los datos nuevos: no hay que esperar a que se refresque nada, porque no hay una segunda copia que refrescar.
Sobre un almacén clásico también se puede hacer, pero con una capa de traducción en medio. Y esa capa, en este caso, no aportaba nada: nadie iba a sentarse a consultar la última capa con SQL a mano. El consumo es por informes. Si la capa de traducción no la usa nadie, es mantenimiento gratis.
«¿Y si mañana alguien quiere consultar esto con SQL?»
Pues lo hace. Un lakehouse trae de serie un punto de conexión que habla SQL para lectura, así que quien quiera lanzar una consulta puede hacerlo sin que nadie mueva nada. No se pierde esa puerta: simplemente no se paga por tenerla abierta todo el rato.
Y ahora, las piezas
La segunda pregunta era qué hace cada cosa. El proceso son ocho cuadernos —ocho programas que se ejecutan en orden— y lo más interesante es cómo se reparten el trabajo:
El preparador
El primero no toca ni un dato. Lo único que hace es dejar la casa lista: crear las carpetas donde va a aterrizar cada cosa y, sobre todo, las tablas donde el proceso se apunta a sí mismo lo que va haciendo.
Esas tablas de registro son las que nadie valora hasta el día que hacen falta. Son el cuaderno de bitácora: qué entidades existen, cuándo se cargó cada una por última vez, cuántas filas trajo, si fue bien o mal. Sin eso, cuando una cifra no cuadre, lo único que tienes es un «pues yo creo que cargó anoche».
La ingesta
Aquí es donde el dato entra por la puerta.
En este caso, como es un laboratorio, el dato lo fabrica un generador que simula catorce sistemas distintos: el programa que gestiona las reservas, el de facturación, el de recursos humanos, las valoraciones de los clientes… En un proyecto real este hueco lo ocupan las conexiones contra esos sistemas, pero el resto del proceso es idéntico: a partir de aquí, nada sabe ni le importa de dónde vino el fichero.
Y hay una decisión importante en este punto: el fichero se deja tal cual en una zona de aterrizaje antes de convertirlo en nada. Organizada por sistema, por entidad y por fecha.
¿Por qué no cargarlo directamente? Por una razón muy práctica: los sistemas de origen sobrescriben. Si mañana necesitas recargar lo de hoy y no guardaste el fichero, puede que ese dato ya no exista en ningún sitio del mundo. La zona de aterrizaje es la fotocopia que te guardas antes de entregar el original.
El aterrizaje
El tercero convierte esos ficheros en tablas de verdad. Y hace dos cosas que merecen mención.
La primera: a cada fila le añade de dónde vino y cuándo. Cuatro columnas que no le interesan a ningún usuario y que resuelven el noventa por ciento de las investigaciones.
La segunda es más sutil. Hay dos formas de traer datos, y el proceso distingue entre ellas:
El conformado
Este es el cuaderno más largo de todos, y es donde ocurre la mayor parte del trabajo de verdad.
Aquí se limpia, se tipa, se quitan duplicados y se resuelve el lío de que la misma persona aparezca tres veces con tres grafías distintas en tres sistemas. Se convierten las monedas. Se reparten los paquetes —cuando alguien paga una tarifa que incluye habitación y cena, hay que decidir qué parte es cada cosa—. Y se aplica una por una cada regla de negocio que se acordó en aquella reunión del principio.
Hay dos detalles que me gusta contar de esta parte.
El primero es el día de negocio. Parece trivial y no lo es: una reserva que entra a las once de la noche en Lisboa y una que entra a la misma hora en Ciudad de México no pertenecen al mismo día, y si usas un horario común para todos, los hoteles lejanos nunca van a cuadrar con su propio sistema. Se normaliza al huso de cada hotel, no a uno central.
El segundo es la cuarentena. Lo que no pasa una regla no se tira: se aparta y se cuenta. Es una diferencia pequeña con una consecuencia grande, porque lo que se tira desaparece y nadie lo echa de menos, mientras que lo que está apartado aparece como una cifra en un informe, con el nombre del sistema que lo mandó al lado. Y esa cifra, enseñada en una reunión, consigue en diez minutos lo que tres correos no habían conseguido en un mes.
La estrella
El penúltimo cuaderno coge todo eso y le da la forma final.
Se llama «modelo en estrella» porque si lo dibujas queda así: en el centro los hechos —cada noche vendida, cada factura, cada valoración— y alrededor las tablas que los describen: el hotel, la fecha, el cliente, el canal por el que reservó.
¿Por qué esta forma y no una más ordenada? Porque es la que entienden rápido tanto el motor que calcula como la persona que arrastra campos a un informe. Hay formas de modelar más elegantes sobre el papel, impecables técnicamente, y que no las sabe usar nadie sin un manual.
Dos decisiones de aquí, en cristiano:
- Las claves propias. Cada hotel, cada cliente, recibe un identificador interno que no es el del sistema de origen. Da trabajo y alguien siempre pregunta para qué. Para el día —que llega siempre— en que el sistema de origen migre y cambie sus códigos: entonces cambias una tabla de equivalencias y no se entera nadie.
- Las filas para lo desconocido. Cuando una venta no sabe a qué cliente corresponde, no se deja en blanco: se apunta a una fila que literalmente se llama «desconocido». Suena absurdo y evita el problema más feo de todos, que es que los importes huérfanos desaparezcan de los totales sin que nadie lo note.
Los tres que no hacen nada
Y quedan tres cuadernos que no transforman ni una fila. Uno al final de cada capa.
Lo único que hacen es mirar lo que acaba de quedar escrito y compararlo con lo que tenía que haber quedado. Si algo importante no cuadra, el proceso se detiene ahí y la capa siguiente no empieza.
De esto hablé largo en la entrada anterior, así que solo repito la idea: son tres de ocho. Tres piezas de un proceso de ocho cuya única función es desconfiar del resto.
Y hay un detalle de construcción que sí merece contarse aquí: estos tres cuadernos vuelven a leer los datos desde el almacén, no reaprovechan nada de lo que acaba de calcular el cuaderno anterior. Si comprobaras usando lo que ya tienes en memoria, heredarías sus errores: si la transformación se dejó la mitad de las filas por un filtro mal puesto, tu comprobación se deja exactamente la misma mitad y te dice que todo está perfecto.
Un control que corre dentro del proceso que valida no es un control: es el mismo proceso dándose la razón.
Lo que me llevo
Si tuviera que resumir las dos decisiones de este post en una frase cada una:
La del almacén: no elegí lo más potente, elegí lo que no me obligaba a cambiar de herramienta a mitad del camino. Y la elección habría sido distinta con otro patrón de escritura o con otro tipo de consumo. Cuando alguien te diga que una opción es siempre mejor que la otra, desconfía: lo que hay que preguntar es cómo se escribe y quién lee.
La de las piezas: el proceso no es una tubería, son ocho piezas pequeñas con un trabajo cada una, de las que tres existen solo para comprobar que las otras hicieron bien el suyo. Y eso no es desconfianza: es lo que permite que a las tres de la mañana algo se pare solo en vez de llegar al informe de la mañana siguiente convertido en una cifra que nadie sabe explicar.
Novara Hospitality Group no existe: es un caso de laboratorio que construí para recorrer el método completo sin depender de los tiempos ni de los permisos de un cliente real. Las decisiones, en cambio, son las mismas que tomaría en un proyecto de verdad — y si tú las tomas de otra manera, me interesa mucho saber por qué.
Comentarios
Deja un comentario