PowerBI. Configurar el personal gateway para actualizar automáticamente datos en PowerBI

Algunos conceptos fundamentales del refresco de datos parecen obvios a los técnicos pero no son tan obvios para las personas que su formación es de negocio. En concreto en PowerBI para refrescar los datos, es posible que te plantees abrir PowerBI desktock refrescar los datos y volver a subir el fichero, un proceso totalmente manual y tedioso, que además hace depender de ti que todos los usuarios vean la información

¿Que ha diseñado Microsoft PowerBI para evitar esa tortura?

Lo que ha diseñado es un mecanismo por el cual PowerBI ( la nube) se conecta a tus orígenes de datos de forma segura, lee la información y actualiza su contenido.  No cuento en el vídeo todos estos conceptos, lo haré en algún otro espero :).

Y ¿como funciona ese Gateway?

Básicamente es una aplicación –funcionando en modo servicio– que se encarga de frente a una petición de PowerBI en la nube (y solo de PowerBI) enviar la información fresca del DataSet a la versión del Dataset que tenemos en PowerBI.com. Es decir, permite que se actualicen los datos sin tener que desplegar de nuevo todo el fichero .pibx.

¿se puede agendar?

Se puede agendar con distintas frecuencias de actualización según tu suscripción.. También puedes ir al dataset que quieras refrescar y forzar su refresco. Para mas información puedes consultar este link (en inglés).

Demostración sencilla

Para que veáis una introducción muy sencilla a esta funcionalidad he grabado un vídeo en mi canal de Youtube, espero que os guste y os sirva de ayuda.

 

 

Miguel Egea

Introducción a SQL Server en Linux con Docker

Mini tutorial de 15 minutos sobre como instalar, configurar, y ejecutar contenedores Docker para usar SQL Server en Linux.

Si quieres descargar el código te dejo el enlace del github donde está todo esto. https://github.com/MegeaPortalSQL/Docker-01

Suscribete al canal y estate atento para la siguiente entrega.
Creando un Always On con contenedores.

Traducciones en modelos tabulares

Cuando tenemos proyectos multi-idioma en los que dependiendo del usuario que se conecta, o de cualquier otro criterio hemos de mostrar los datos en un idioma u otro necesitamos traducciones. Este era uno de los gaps iniciales que existía entre las versiones Tabular y Multidimensional. Desde hace tiempo esto ya no es ningún problema. Para gestionar esas traducciones necesitamos diferencias dos escenarios, el primero de ellos es la traducción de los literales en si mismos, la segunda es la traducción de los datos. En la siguiente demostración puedes ver como se hacen ambas cosas.

 

Opinión: ¿Sigue siendo necesario crear DataWarehouses en 2019?

El pasado 18 de Mayo de 2019 tuve la oportunidad de debatir con el amigo Cesar Oviedo, responsable del canal Bi Latam y estuvimos charlando  sobre la necesidad (o no) de crear DataWarehouses a estas alturas de madurez de la tecnología relacionada con el análisis de datos.

Si te interesa el tema.. aquí te dejo el video


 

PowerBI Analysis Services 2019. Calculation groups y Many to many

El pasado día 7 de mayo del 19 tuve el honor de participar en un evento virtual de las PowerCommunities y explicar las nuevas funcionalidades como los calculation measure groups y las relaciones many to many .
Personalmente estoy encantado con estas nuevas funcionalidades, usemoslas con precaución y siempre midiendo el impacto en el rendimiento de nuestros sistemas (nada es gratis en terminos de recursos ya se sabe)
En el siguiente link podeis ver el video que he grabado con la sesión y la demostración

También a nivel de pruebas y por si quieres ampliar lo que yo hago en la demostración aquí te dejo el link en el que Christian Wade nos habla de esas funcionalidades.

y aquí algunos de los ejemplos dax con los que usar SELECTEDMEASURE()

Calculation Item Expression

 

La democratización de la inteligencia artificial en Power BI

Las revoluciones en el mundo de la ingeniería cambian el suelo bajo nuestros pies, si fuesemos unos plácidos artesanos de principio del siglo XX y nos dijeran que nos subiéramos en ese artefacto con 4 ruedas que es capaz de ponerse a 40 kms/h sin saber como funciona quizá pensaríamos que nuestro interlocutor ha perdido por completo la cabeza. Ahora, simplemente funciona, y ni nos percatamos de que no es necesario conocer la configuración de un coche para conducirlo. Otro ejemplo es el de los televisores, en la mitad de los 70 recuerdo que mi abuela tenía un televisor en blanco y negro que tenía un mónton de botones por delante y otro montón por detrás, ruedecitas, potenciometros, el día que tocabas aquello dejaba de verse bien la televisión para siempre.. lo recuerdo bien :).

Con la democratización del BI o lo que Microsoft llamó el Self-Service BI hice como los antiguos, resistirme, regañar, enfadarme, he de reconocer mi profundo error. No entendía como siendo líderes en el mercado con Analisis Services Multidimensional y mi amado MDX nos íbamos a una aventura extraña in-memory, mis disculpas por todas las tontadas que llegué a decir, resistiéndome como usuario al cambio que era imparable y que a la postre ha resultado en esta maravilla que hoy conocemos como PowerBI. No quiero caer en la misma tentación en lo que yo percibo como la siguiente revolución. La democratización de la inteligencia artificial. Gartnert decía hace unos años  el montón de científicos de datos  que iban a  hacer falta, pero también decía -2017- que para este año, 2019, el número de «citizen data scientics» iba a superar al de los cientificos de datos tradicionales y que el impacto en la industria iba a ser mayor que el de los propios científicos de datos.

Que Microsoft y el equipo de Powerbi se tomaron en serio esta predicción está claro cristalino, muchas pistas nos cuentan eso, forecasting automático en gráficos, analisis de key influencers, explicaciones automáticas a gráficos, todo eso está en PowerBI hoy. Si quieres saber los detalles, no dejes de ver este video.

La presentación que hice el día 4-4-19 en #BigDataAlcoy las puedes descargar de Congreso Big Data Alcoy

 

Espero que lo disfrutes

Truco Rápido. Obtener los paquetes agendados que están tardando mas con un query

A veces escribimos ese script  que no es que sea complicado ni nada parecido pero si que es útil. Analizando los paquetes a los que prestar atención en los tiempos que ejecutan yo suelo usar el log que le dejo a los propios paquetes, pero en una instalación de un cliente ese log no existe, digamos que son paquetes «legacy», de forma que hay que recurrir a la información que quede en la historia de los jobs para ver esos tiempos. Esta historia es corta generalmente, pero menos es nada.

Aqui os dejo el script que sirve para ver esa información que al menos a mí, hoy, me ha resultado muy util.

Curiosamente este script tiene errores, porque SQL server está informando el campo run_duration como un entero si, pero no representa el número de segundos ni nada por el estilo sino que representa la hora, tal cual la escribirías, así pues si el valor es 3554 quiere decir que ha tardado 35 minutos y 54 segundos. No se porqué es así, pero si que es una manera bastante poco eficiente de guardar la informacion :). en cualquier caso, lo que es lo que es..

Esta correción NO CORRIGE todos los problemas, no tengo paquetes que duren varios dias para comprobar que pasaría con el tema horas así que dejo la aproximación que con  paquetes que duran menos de horas me funciona.

 

SQL Server 2019 CTP 2.3 Big Data containers e inteligencia artificial todo en uno

Puedes ver un webcast sobre este tema en https://info.microsoft.com/ww-landing-intro-sql-server-2019.html

Hace tiempo (entendiendo esta antigüedad en el contexto de lo que es la informatica) que Spark con su Scala me parece un lenguaje que hay que empezar a dominar , ahora más aún, en SQL 2019 ,  se puede poner todo junto, SQL Server y Spark y puede usarse todos los lenguajes de inteligencia artificial, Python, R, etc para consultar datos, no solo en los tradicionales SQL servers sino también en clusters de bigdata.

En el webcast podreis ver como nos hablan de uno de los retos que más horas nos han hecho invertir en nuestros proyectos, los métodos para integración de datos, tanto los procesos ELT o ETL como lo que llaman Data virtualization, básicamente dos aproximaciones a tener los datos todos en un solo lugar, ya sea real copiando datos, o virtual  dejando los datos en su situación y virtualizando su acceso sin replicar o mover datos aunque es un poco tendencioso, porque cuenta todas las maldades del ETL ELT  pero no los relacionados con la virtualizacion  y son unos cuantos. Aún así es interesantisimo de ver, en este caso PolyBase  es quien acude al rescate puesto que utiliza su potencia para consultar cualquier origen de datos.

Siguiendo con esa virtualizacion podrás ver como con la misma estructura, se pueden consultar no solamente datos de otros gestores de base de datos como teradata u oracle, sino también clusters de spark o ficheros alojados en un hdfs. También veras como pueden funcionar varios SQL Servers en paralelo o con spark. También veras el concepto scale-out data pool para poder crear caches intermedias de estos datos, y el concepto de compute pool, paralelizando y creando clusters de SQL SErver al mas puro estilo hadoop pero con un lenguaje conocido y un interfaz amable para hacerlo.

De lo mas destacable, la promesa de que con Microsoft, todos los componentes que están dentro del cluster big data, van a ser compatibles en los cambios de versión , esto a los que estamos en el mundo Microsoft nos parece natural, pero  en mis propias carnes he sufrido lo poco natural que es en el mundo del big data.

La tecnología Kubernetes al rescate, algo que también podras ver el video, como a través de esta tecnología se puede desplegar un cluster no importa si es en  Azure ya sea en IaaS o en servicio como Azure Kubernetes o es On-premisses.

Los logs de todas los nodos acaban en una base de datos elastic search para poder ser administradas y consultadas. Muy interesante.

Seguridad y mantenimiento, unificado a traves de un single sing-on con directorio activo.

El dibujo de como Microsoft ve la plataforma de Inteligencia Artificial también es muy ilustrativa, puedes usar  Spark STreaming, SSIS,  para leer datos y llevarlos a una instancia de SQL SErver o a HDFS o a unos data pools… entonces puedes empezar a preparar y entrenar tus modelos con Spark Machine Learing o con SQL Server Machine Learning SErvices, y a traves de un modelo  servir esos datos a las herramientas de BI o aplicaciones, también pudes usar notebooks en Azure data Studio, los notebooks son una de las herramientas prefereidas para AI.

 

Disfrutad el webcast

 

 

 

Conceptos Básicos. Common Table Expressions o CTE’s

Una de las funcionalidades que vienen bien tanto a desarrolladores como a administradores de bases de datos son las CTE’s. Una definición , poco rigurosa, pero muy ilustrativa sería describirlas como vistas temporales en el ámbito de una consulta, es decir, a un query mas o menos complejo se le puede poner un alias y usarlo varias veces. Si te has enfrentado a los dialectos SQL y te ha tocado hacer subqueries complejas por ejemplo para sacar las ventas de este año y las del año pasado, haciéndolo con subconsultas da queries muy largas (la complejidad depende más de lo que se busque) en el que hay repetidas varias veces la misma premisa.

Vamos a ver lo que decimos a través de un ejemplo, vamos a calcular las ventas por año de nuestra base de datos adventure works. Para eso lo primero es tomar la cabecera de ventas y las lineas de venta, en la cabecera tenemos el año, en las lineas el importe, para comenzar haríamos algo como esto
<preclass=»lang:tsql decode:true » title=»cabecera y lineas de venta»>SELECT * FROM Sales.SalesOrderHeader soh INNER JOIN Sales.SalesOrderDetail sod ON soh.SalesOrderID = sod.SalesOrderID;

Obviamente ahí no hay ningún cálculo, solo hemos puesto el join inicial que nos permite unir tablas y obtener los datos  que necesitamos -fecha e importe- en la misma consulta.

El valor por años de las ventas sería algo como esto

Ahora vamos a volver la premisa inicial, vamos a obtener en la misma fila las ventas de un año y las del año anterior, para eso hemos de hacer dos subqueries y unirlos

El resultado sin CTES sería algo así

Si usamos CTE’s la idea es poder ponerle un alias al primero de los conjuntos y volver a usarlo cuantas veces sea necesario, por ejemplo así

Mucho mas limpio, pero no solo eso sino que mucho más versátil para peticiones y cambios, por ejemplo si en lugar de agrupar por año queremos año y mes el cambio sería solamente en el query de la CTE no en toda la parte de abajo, con subqueries habría que cambiarlo en las dos y eso es bastante más lioso

Otro ejemplo imaginemos que queremos un año atras y dos años atras…

 

 

Aunque solamente esta funcionalidad ya sería más que suficiente para resaltar las cualidades de las CTE’s, aún tienen muchas más, ya que pueden ser Recursivas, y de esa forma nos ayudan a recorrer árboles, o a crear datos, dimensiones, en breve publicaré el siguiente apunte de la serie de cte’s en el que veremos esas funciones recursivas con algunos ejemplos y su utilidad.