Performance PowerBi. Que es lo mas optimo?

[Alexx95]

Buenas tardes comunidad.

Tengo algunas dudas con respecto a la performance con 3 custiones.

1- Cual es la mejor performance con respecto a la parte de ETL?
Tengo entendido que para hacer la limpieza de datos en powerBi conviene hacerla desde powerQuery y no con funciones DAX.
Pero suponiendo que tengo una base de datos de SQL server y una tabla de 50 millones de registros, de los cuales 10 millones haya que filtrarlos porque no son utiles.
Conviene hacer una vista en SQL, limpiar todos los datos (hacer el proceso ETL) y luego desde PowerBi tomo esa vista con los datos que me son utiles?
O tomo la tabla directamente desde powerBi y hago ETL desde powerQuery?

2-  Es conveniente armar un flujo de datos "masivo" del cual despues puedas conectarte desde diferentes reportes?
Suponiendo que este flujo se conectara a una base de datos de SQL server y tardara 1 hora en actualizar. Suponiendo una super consulta.
O acaso es mejor hacer en cada reporte una consulta a la base de datos directamente?
De una forma veo que es mejor para no pegar a la base de datos muchas veces por la misma informacion, pero de la otra manera creo que es mas eficiente.
A mi entender es mas eficaz tirar 100 consultas pequeñas a la base de datos, que una sola consulta que contenga las 100.

3- Cual seria la mejor forma de "relacionar" o solucionar este problema.
Tengo 3 tablas. Formulario A / Formulario B / Usuarios.
Formulario A y B estan relacionados. Y ambos tienen un codigo de usuario que se relaciona con la tabla usuarios.
PERO, el usuario del Formulario A y B no necesariamente son el mismo.
Conviene duplicar la tabla Usuario y relacionar cada una a cada Formulario? O conviene tener la tabla suelta y buscar desde ambos formularios con una columna calculada su usuario?
O si hay otra alternativa me serviria.
Este ejemplo se me aparece tambien en caso de que en una misma tabla tenga mas de 1 forma de relacionarse a otra.
Ejemplo si Formulario tuviera un cod_usuario_creador / cod_usuario_aprobador / cod_usuario_modifica.

Muchas gracias!

[Syndicate_Admin]

Tal vez esto pueda ayudar para la pregunta 3.

El Formulario A tiene un asociado del Formulario B. Relación 1 a 1.
Ambos tienen un usuario. PERO los usuarios entre ellos pueden ser diferentes.
En mi experiencia puedo hacer esto de 3 maneras.
1- Con una tabla suelta, entonces en las tablas de Formularios puedo usar una columna de cálculo, con algo como esto: Caculate(users_table(user_name), user_table(id) = FormA/B(user_id))
2- Con la tabla duplicada, entonces el usuarioA está relacionado con FormA. Y userB está relacionado con FormB.
3- Con una tabla de usuario y relacionada con ambas entonces, PERO una de las relaciones debe estar inactiva.

Si entiendo correctamente @AllisonKennedy dijiste que si necesito 2 filtros en mis visuales que son para usuarios (en este caso necesitamos eso) la forma correcta duplicará la tabla.
Entiendo que la tabla de usuario generalmente es "pequeña", esta opción tiene sentido.

@Migasuke No sé si entiendo correctamente, pero ¿dijiste que la forma en que mi fuente es una base de datos SQL literalmente es "casi" lo mismo porque el plegado de consultas está optimizado para esta fuente?
Entiendo que si podemos usar la fuente para el proceso ETL, deberíamos usar eso, pero ¿es irrelevante en este caso?

Muchas gracias a ambos.

[Syndicate_Admin]

@Alexx95

Sí, entendiste correctamente. La mejor opción en este caso sería duplicar la tabla User para que pueda filtrar por creador y luego filtrar por aprobador.

[Syndicate_Admin]

Hola @Alexx95 ,

Me temo que no le ayudaré con su tercera pregunta, sin embargo, puedo aclararle una pregunta adicional hacia mí.
Te doy ejemplo de dos escenarios diferentes:

1. Quiero extraer 100K filas de Excel y necesito seleccionar solo las filas de 10K principales.
En Power Query me veo obligado a extraer todas las filas de 100K y luego quitar las 90K restantes de filas.

2. En caso de plegado de consultas, que es posible en Azure SQL, y otro escenario de SQL es diferente.
En Power Query quiero mantener los 10K superiores de 100K. Power Query envía el comando SQL a la base de datos y no descargaré todos los 100K, sino solo 10K. La razón es que la base de datos devolverá datos ya procesados con solo 10K, por lo que la operación se realiza en el lado de la base de datos y no en el lado de Power BI.

Así que el resultado es:
Haga su transformación en la fuente si puede, sin embargo, con las fuentes de plegado de consultas (bases de datos) realmente no importa.

[Syndicate_Admin]

Hola @Syndicate_Admin ,

1. Si puede, prepare los datos en la fuente. Si el origen de datos es una base de datos, también puede aprovechar el plegado de consultas: básicamente realiza todos los pasos en Power Query, pero se filtran automáticamente en el lateral de la base de datos. Consulta más aquí:
https://learn.microsoft.com/en-us/power-query/power-query-folding

2. Pregunta difícil. Si sabe que puede consultar los mismos datos varias veces en diferentes informes, podría tener sentido preparar algún flujo de datos, que almacene todos sus datos y no sobrepase su base de datos. Si las consultas SQL extraen datos diferentes, omitiría Dataflow.


3. ¿Puede proporcionar algunas impresiones del modelo o resultado deseado?

[Syndicate_Admin · Accepted solution]

@Syndicate_Admin @Alexx95

¡Uau! Muchas preguntas geniales. Puede obtener una mejor respuesta si las publica como 3 preguntas separadas, ya que son lo suficientemente diferentes como para que se requiera que diferentes personas las respondan. No tengo todas las respuestas, pero lo intentaré.

1) En mi experiencia, es mejor empujar las transformaciones lo más cerca posible de la fuente. Por lo tanto, crear vistas en SQL y extraerlas en Power BI es lo mejor.

2) Esto es complicado y depende. ¿Qué parte del flujo de datos se utiliza en cada informe? ¿Cuánta superposición hay entre los informes? Tenga en cuenta que cuando se actualiza un flujo de datos, todo debe actualizarse o, si una parte falla, todo falla, por lo que puede ser mejor dividir el flujo de datos en "dimensiones centrales" que se utilizan en la mayoría de los informes, y luego colocar las otras tablas en otro flujo de datos o flujos de datos.

3) ¿Cómo se relaciona el formulario A con el formulario B? Al no conocer los formularios, supongo que el Usuario se relaciona con el Formulario A y el Usuario se relaciona con el Formulario B, pero ese formulario A no se relaciona directamente con el Formulario B. Sin embargo, necesito más detalles sobre los formularios para confirmarlo.

Para los diferentes usuarios (creados por, modificados por, aprobados por, etc.) puede usar la dimensión de juego de roles y las relaciones inactivas, o puede tener una tabla de usuario 'aprobadores' y una tabla de usuarios 'creadores'. Esto también depende del resultado final deseado -

¿quieres ver cuántos formularios creó y aprobó Jorge en el mismo objeto visual? Luego usa las dimensiones de juego de roles

¿O desea filtrar por Jorge como aprobador, y luego filtrar por los creadores en un filtro / visual separado, luego use aprobadores y tablas de usuario separadas de creadores?