La Data Web

Hace tiempo vengo encontrándome con fallas de modelado en las que las personas rompen la direccionalidad de dos tablas o más por factores que pueden ser resueltos de otro modo. También casos de múltiples tablas de fecha.

Ciertamente una de las reglas de oro al modelar es mantener las direccionalidades "simples", es decir, evitar el "ida y vuelta". Este tipo de dirección podría funcionar en casos muy puntuales de modelos estrella bien definidos, pero si mi modelo tiene copos de nieve o es multi estrella podría complicarse. Aún más si no tenemos un modelo definido con la teoría y solo cargamos tablas. Al igual que el many-to-many no controlado puede ocasionar problemas, la dirección importa y podría provocar ambigüedad en el modelo (cuando las relaciones comienzan a desactivarse porque hay múltiples caminos a un número o el número no se filtra como esperamos porque los filtros direccionados rompen las reglas de negocio).

Otra situación recurrente surge si necesitamos trackear algún valor por una fecha distinta, tenemos soluciones viables más estables que crear muchas tablas fechas. Hablo de la posibilidad de usar una relación inactiva.

En varias oportunidades me crucé con grandes modelos que tienen varias tablas de hecho. Lo cierto es que no siempre esas tablas van a compartir las mismas dimensiones y trabajar al mismo nivel de detalle. El caso más común que puede ocurrirnos es cuando la granularidad de fechas es distinta. Hace tiempo me vengo encontrando con dudas de cómo organizar el modelo cuando sucede eso. Tenemos tablas de hecho a detalle de día, otras a mes y otras a años. El problema es que luego quieren combinar los gráficos comparando valores y con cierto challenge que yo suelo hacer muchas soluciones propuestas no saben cómo resolver esta problemática.

Este artículo va a mostrar lo que NO se debe hacer del punto de vista de data modeling para comparar los valores en un gráfico y lo que SI debemos hacer para relacionar las distintas granularidades en nuestro modelo manteniendo la multi-estrella lo más liviana posible.

Hace no mucho tiempo Power bi ha incorporado soporte para la lectura de archivos Parquet evitando la creación de enormes funciones en power query para intentar llegar a dichos datos. La parte más atractiva de la extensión es leerla desde un Azure Data Lake puesto que sería más probable que los datos estuvieran almacenados allí.

Recientemente un compañero tuvo un inconveniente para conectarlo de forma tradicional y nativa. El "combinar" automático de Power Query no funcionaba. Fue entonces como llegue a una segunda forma de combinar los archivos parquet de una única tabla. 

Éste artículo muestra como conectarnos a archivos parquet de un Azure Data Lake Gen2 en una carpeta que representa una sola tabla en dos formas distintas.

Hace un tiempo que se me viene presentando requerimientos de personas no tan afines a Power Bi pero si al análisis de datos más duro que va directo con lenguajes de programación como Python y R. 

Los pedidos pasan por poder fácilmente llegar a los datos de modelos tabulares completamente funcionales para respuestas o análisis adhoc que se solicitan en el momento. Naturalmente el pedido solía resultar en comentarles que podía correr Python desde el interior de Power Bi Desktop, exportar sus datos, etc. Todo eso puede ser una solución preventiva pero no creo que se compare a la nueva posibilidad de la API que ahora esta disponible (GA) en Power Bi.

Éste artículo relata las restricciones del request y como formarlo desde el lenguaje de programación Python formando un Pandas DataFrame.

¡Hola a todos! En este articulo voy a intentar darles un resumen del paper sobre Lakehouse que publico Databricks en Enero de este año para el evento CIDR. Es un paper muy interesante porque habla de su visión como empresa, enumera problemas con las arquitecturas actuales de datos, justifica porque consideran que este es el enfoque adecuado, aunque también reconoce que tienen cosas para mejorar y que hay otras arquitecturas que pueden aportar mucho valor.

Si bien este no es un artículo de opinión y solo me enfocare en darles un breve resumen del paper y sus puntos más importantes, si agregue en muchos casos algunas definiciones para hacer la lectura más llevadera y no tener que interrumpir la lectura googleando algún termino especifico. Intente que la numeración usada sea la misma que en el paper, aunque no es 100% fiel.

Ojalá les sea de mucha utilidad.