Una escena que se repite en empresas que ya invirtieron en un warehouse: los datos están en Databricks o en Snowflake, hay un equipo que los modela, y aun así el comité discute cuál de dos cifras es la buena. Nadie miente. Las dos salieron del mismo warehouse.

Lo que falla no es el cálculo. Es todo lo que pasa alrededor: quién tomó qué tabla, qué versión, con qué regla, y quién más está leyendo ese resultado desde un tablero que nadie recuerda haber compartido.

Lo que el warehouse resuelve, y lo que no

Un warehouse resuelve dos cosas muy bien: guardar volúmenes grandes y calcular rápido. Databricks y Snowflake son, en eso, de lo mejor que existe.

Lo que un warehouse no resuelve por sí solo son las seis preguntas que separan un dato correcto de un dato confiable:

  1. ¿De dónde proviene esta cifra? El warehouse sabe de qué tabla salió. No sabe de qué exportación del ERP salió esa tabla ni por qué manos pasó antes.
  2. ¿Quién la modificó? Hay historial de cambios en el esquema, pero no un registro de negocio de quién decidió qué.
  3. ¿Qué reglas se le aplicaron? Las que están en el SQL, para quien sepa leerlo.
  4. ¿Qué versión se está usando? Si la tabla se sobrescribió, la versión de febrero ya no existe salvo que alguien haya activado retención y sepa consultarla.
  5. ¿Qué calidad tiene? El warehouse no perfila: un 30 % de vacíos en una columna de costos entra al promedio sin aviso.
  6. ¿Quién puede consumirla? Los permisos del warehouse gobiernan el warehouse. El Excel que alguien descargó y reenvió ya no.

Nada de esto es una crítica al warehouse. Es una descripción de su alcance.

Qué cambia con una capa de gobierno encima

Conectar Databricks o Snowflake a Lorian Analytics no mueve los datos de sitio ni reemplaza el warehouse. Lo que hace es traer las tablas que usted elija a la capa Bronze, de solo lectura, y a partir de ahí tratarlas como cualquier otro origen:

  • Cada sincronización es una versión. La tabla llega como Parquet tipado con una huella; si no cambió, no se crea una versión nueva. La cifra de febrero se puede volver a leer con la tabla de febrero.
  • Las reglas se declaran una vez. Normalizar nombres de ciudad, validar un NIT, ofuscar un correo antes de compartir: reglas guardadas como receta, aplicadas igual cada mes, con la configuración exacta de cada ejecución congelada.
  • La calidad se mide al llegar. Perfilado por columna y un score de 0 a 100 con los mismos pesos para todos los archivos, venga de un Excel o de una tabla de seis millones de filas.
  • El consumo se gobierna con tokens. Power BI, Excel o un notebook leen un modelo con un token que lleva grabado su alcance, vence, se revoca y deja registro de cada lectura con su número de versión.
  • Cada paso queda en una auditoría inmutable. Corrida abierta y cerrada, cada tabla ingerida, cada intento de autenticación fallido: quién, cuándo y desde qué dirección, sin secretos dentro.

El warehouse sigue siendo el warehouse. Lo que se agrega es la capa que responde las seis preguntas.

Cómo se conecta, sin abrir nada

Los dos conectores comparten el mismo contrato:

  • Solo lectura, por contrato. En Databricks se pide CAN USE sobre el SQL Warehouse, USE CATALOG, USE SCHEMA y SELECT sobre las tablas. En Snowflake, el asistente escribe el script: un rol de solo lectura, un usuario de servicio y, si quiere, una política de red.
  • Una IP de salida fija. Lorian Analytics sale siempre por la misma dirección, tanto al probar como al sincronizar. Su lista de permitidos abre exactamente una puerta.
  • Sin agente ni drivers. Databricks se lee por la API oficial de ejecución de sentencias; Snowflake, por su conector oficial. Nada que instalar en su red.
  • Secretos en una bóveda. El token o el par de llaves viven en Azure Key Vault con un nombre por conexión. En Snowflake ni siquiera hay contraseña: la privada la genera la plataforma y nunca sale de la bóveda.

Y una diferencia que vale la pena conocer: en Snowflake, probar la conexión y listar esquemas, tablas y vistas no despierta el warehouse. Cero créditos hasta que decida sincronizar. En Databricks la prueba sí ejecuta una sentencia en el SQL Warehouse. Las dos plataformas lo dicen en el asistente antes de guardar.

Cuándo tiene sentido, y cuándo no

Tiene sentido cuando el warehouse ya existe y lo que duele está fuera de él: los informes que no se reproducen, los Excel que circulan por correo, la conciliación mensual entre áreas, la auditoría que se responde con un proyecto en vez de con una consulta.

No tiene sentido si lo que busca es reemplazar el warehouse, mover petabytes o hacer ingeniería de datos a escala industrial: para eso ya tiene Databricks o Snowflake, y hacen su trabajo. Tampoco tiene sentido esperar carga incremental hoy en estos dos conectores: cada corrida trae la tabla completa y la compara por huella; la incremental por marca de agua está en construcción.

El siguiente paso

Si su empresa ya tiene un warehouse, el primer experimento es barato: conecte un esquema con las tres o cuatro tablas que alimentan el informe que más se discute, déjelas versionar dos o tres semanas y compare lo que puede responder hoy con lo que podía responder antes.

En Lorian Analytics ese experimento se hace desde el plan gratuito, con una conexión y acceso de solo lectura, y no necesita un proyecto de integración. Lo que sí necesita es una decisión: dejar de discutir cifras y empezar a explicarlas.