¡Suscribite al newsletter!
Hoy me voy a poner un poquito técnico, sepan entender.
Un cliente, hace un tiempo, me pidió un relevamiento del estado actual de la plataforma de Power BI que tenían funcionando. Esta instancia de Power BI le pegaba directamente a una base de datos Oracle que tenían en sus servidores. Esto no sería problema, si no fue se porque la base de datos de Oracle se usaba directamente contra los aplicativos finales, sin capas físicas de abstracción mediante.
¿Qué puede causar esto? Bueno, primeramente que todo estalle a la más minima operación de la base de datos.
Los tiempos de actualización de cada reporte rondaban los 30 minutos, e incrementando, por la inmensa carga de datos pedida a un pobre motor transaccional.
Si una tabla era reescrita (cosa que sucedía, fuera del control del entorno del warehouse), Power BI fallaba porque el objeto que tenía que leer “ya no existía”.
Esto, sumado a problemas de todo índole, como claves primarias duplicadas hasta un cable de red que estaba desconectado, llevaron a los usuarios a perder confianza en la herramienta, llamándola inútil.
En concreto, les mandé este resumen, palabras más, palabras menos:
- Limpieza de Objetos: Eliminar medidas y columnas calculadas obsoletas para liberar memoria RAM y facilitar el mantenimiento del código DAX.
- Optimización de Consultas: Restringir la ingesta de datos seleccionando solo las columnas necesarias en el origen para acelerar drásticamente la actualización y compresión.
- Arquitectura DWH: Implementar un Data Warehouse intermedio para desacoplar la carga analítica del sistema transaccional y evitar bloqueos operativos.
- Migración a la Nube: Migrar la base de datos Oracle a una solución Cloud para eliminar cuellos de botella del Gateway y ganar escalabilidad.
- Integridad de Datos: Sanear duplicados en claves primarias antes de la importación para permitir relaciones “Uno a Muchos” limpias y confiables.
- Optimización del Modelo: Desactivar la inteligencia de tiempo automática y trasladar lógica compleja de columnas calculadas al backend para aligerar el procesamiento.
- Redundancia Estructural: Eliminar tablas de hechos duplicadas y dimensiones redundantes para reducir el tamaño del archivo y la confusión.
- Consolidación Geográfica: Fusionar tablas de País y Región en una única dimensión desnormalizada para mejorar el rendimiento de los filtros.
- Simplificación Logística: Absorber dimensiones débiles en la tabla de hechos principal para reducir el ruido y la ambigüedad del modelo.
La checklist tiene cosas que se pueden arrancar sin esfuerzos ni reuniones, pero hay otras, más inherentes a la arquitectura, que requieren un gasto consciente del dinero por alguien que sepa ejecutar.
Esto no es ningún misterio: en toda organización hay líderes que no son técnicos, pero deciden jugando a entender el problema. Esto termina en una iniciativa donde el dinero “se quema”, porque no se han hecho las preguntas correspondientes antes de arrancar a hacer el primer DAX.
La inmediatez es siempre enemiga de soluciones funcionales y constantes. Y una herramienta no es “fit” de todo: Looker era mejor herramienta que Power BI en este caso. Pero como Power BI es “barato” de implementar, decidieron avanzar con ello. Total, si equivocarse era barato no pasaba nada.
Se perdieron años. Que pudiesen haberse usado en otra plataforma.
Reglas para que a vos no te pase
Sprints de arquitectura
Si sos el responsable del proyecto, asegurate de entender las distintas alternativas de arquitectura que hay para el proyecto, tanto tecnológicas como de reporte. Un datamart en una nube analítica es una buena opción, o incluso un servidor on-prem, separado del motor transaccional, con revisión de integridad y alertas para que nada falle.
Si vas a la solución del resultado rápido, si, vas a tener resultados, y un monolito que sólo puede escalar verticalmente, aunque a la mínima zancadilla (un cable desconectado, un proceso de otro programa) las cosas van a dejar de andar.
Construcción responsable
Una buena entrega se asegura que no haya deuda técnica en los archivos entregados. Columnas calculadas sin usar consumen tiempo de procesamiento. Columnas nativas sin usar consumen espacio de archivo y tiempo de carga. Trabajar con bases de datos on prem es muy dificil y la tentación a traer todo existe, pero una vez hecho eso, hay que limpiar después lo que no se use.
Data cleaning
Hay que asegurarse que lo que llegue al “modelo” sea lo que esperamos manejar. Sin claves primarias que de repente se rompan, sin fechas que no sean las de negocio, y que las que existan respondan a una necesidad.
Testear (bien)
“Esto está mal” se repetía durante el proceso, pero la persona responsable de negocio nunca supo decirme por qué, sólo que el reporte original, en otra plataforma, “daba otra cosa”. Si se sabe que el modelo de datos tiene problemas, necesariamente hay que testear varios casos de uso antes de publicar masivamente un reporte a la corporación.
Comunicar los cambios
Es necesario que exista un control de deploy de nuevos cambios a entornos productivos, como comunicación de aquello que ha cambiado a los usuarios finales, para evitar sorpresas.
Avisar que lo barato sale caro
Si, podés pegarle derecho con Power BI a tu base de datos transaccional en un servidor, que usan al menos otras 20 aplicaciones que rompen y crean tablas y paquetes, donde se sabe que hay lógica de negocio viva y que hay registros dependientes que aún no fueron creados. Las posibilidades de que el reporte que armás sea fiable, con data que no es coherente, y que no tengas quejas de los usuarios finales, son muy, muy pocas. Hay que abstraer. Y si, abstraer sale dinero.
Y vos, ¿tenés un tip?
