MEJOR PRACTICA: ¿Cuánta limpieza de datos hacer en DAX frente a Power Query?

[ericOnline]

A medida que tengo un poco más de comprensión de cómo trabajar con Power BI, veo que puedo hacer muchas cosas en DAX, así como Power Query.

Pregunta para los profesionales de Power BI:

- ¿Cuánta limpieza (filtrar nulos/en blanco, unir tablas, etc.) hace en DAX frente a Power Query?

- ¿Cómo diferencias el trabajo que haces en DAX frente a Power Query?

Gracias

@ImkeF , @amitchandak , @Greg_Deckler y otros!

[Marounnsader]

Hola a todos

así que ya que mencionamos PQ y transformaciones, ¿cómo se acumula PQ a un lado con otras herramientas ETL, podemos usar o depender de PQ como la solución empresarial para ETL

[ericOnline]

Algunas cosas a considerar:

- La mayoría (¿todo?) se puede hacer en PQ se puede hacer a través de la GUI de PowerBI PQ

- ¿Esto permite una mayor productividad de "desarrollador ciudadano" dentro de su organización?

- ¿Hay experiencia de PowerBI dentro de su organización para mantener informes?

- ¿O su organización ya utiliza un lenguaje ETL MODERNO?

- ¿Es PQ (a través de PowerBI) una posible "actualización" para sus organizaciones existentes (tal vez productos ETL anticuados/esotéricos)?

[Marounnsader]

hi eric

gran pregunta aquí

im tratando de aprovechar la experiencia de PowerBI en mi equipo, he sido asignado recientemente a él, actualmente estamos utilizando ODICS y ADW de ORACLE, el problema es una gran cantidad de proyectos y la limpieza se hace de un equipo muy antiguo y en su mayoría se han ido sin la documentación adecuada, y esto está afectando el rendimiento, pero podemos decir que su limpio con no nulos hasta ahora

im tratando de utilizar más conjuntos de fechas y flujos de datos compartidos para que pueda difundir la cultura bi de autoservicio en la empresa y ahora im en el proceso de contratar a nuevo candidato para manejar más trabajo ETL, pero tener experiencia en ODI está más disponible que PQ, así que me pregunto si es mejor empezar a usar los poderes pq o mantenerlo para casos especiales

[ImkeF]

Muy buenas respuestas!

Mi regla general es:

1) Empuje todo lo que está aguas arriba como sea posible (hacia la fuente de los datos)

2) .... a menos que necesite una medida, entonces use DAX

3) Aprende a saber cuándo necesitas una medida: https://exceleratorbi.com.au/calculated-columns-vs-measures-dax/

[Anonymous]

En general, @Greg_Deckler tiene razón.

Soy de la opinión de que usted debe preparar los datos para el análisis en la herramienta correcta. DAX no es esta herramienta. Después de todo, es un lenguaje de eXpressions de análisis de datos por una razón. Un buen ejemplo: ¿Desea hacer aprendizaje automático en SQL? Bueno, eso es lo que pensé.

Power Query es una herramienta de mashup de datos y gracias al mecanismo de plegado de consultas, es lo suficientemente inteligente como para insertar transformaciones de datos en el origen la mayor parte del tiempo (a veces esto requiere también que el codificador sea inteligente). Power Query es tan potente que puede hacer CUALQUIER transformación de datos que se le ocurra y puede hacerlo muy rápido. Para esto, sin embargo, usted tiene que conocer M (el lenguaje PQ) y saber cómo escribir código optimizado. M es un lenguaje funcional con su propio sistema de tipo, sus propias reglas, sus propias peculiaridades y curiosidades. Tienes que aprenderlos para saber cómo hacer que el código sea rápido y mantenible (documentar pasos individuales, por ejemplo, es una buena práctica). Pero es la misma historia con cualquier idioma, DAX incluido.

Lo último... Si deja espacios en blanco en sus dimensiones, esto no solo será feo para el usuario final. También hará que el código sea más complejo y, por lo tanto, más lento. Por lo tanto, siempre debe asegurarse de no dejar espacios en blanco allí y mostrar algunas etiquetas sensibles para espacios en blanco conceptuales. Las tablas de hechos, por otro lado, pueden tener BLANKS en sus mediciones (no en claves de dimensión, sin embargo) porque estas son tratadas como 0 por las funciones de arith DAX y nunca deben exponerse al usuario final. Todos los cálculos deben hacerse siempre a través de medidas y medidas solamente.

La violación del ideal siempre sucederá, por supuesto, pero es bueno dar buenas razones para tales violaciones para que la próxima persona no te maldiga (y bajo su nariz).

Mejor
D

[ericOnline]

Excelentes @Anonymous de ideas ! Me has dado muchas cosas que considerar, mirar hacia arriba y entender. Gracias.

(como un aparte, y SOLO porque me encontré con el otro día... Sí... "ellos" están haciendo ML con SQL ahora 🙂 )

[Anonymous]

Realmente no lo hacen. Ejecutan scripts de Python o R dentro de SQL Server. Eso no es hacer ML en SQL.

Mejor
D

[Greg_Deckler]

Oh chico, esa es una pregunta cargada. @darlove probablemente querrá hablar de esto.

Así que mi respuesta a esto es que depende. Hay algunas escuelas de pensamiento sobre esto. Una, escuela de pensamiento, tratar de empujar la mayor cantidad de datos de limpieza de la "cadena" como sea posible. Así que si lo piensas, tienes:

1. Fuente

2. Consulta de energía

3. Modelo de datos/DAX

El pensamiento obvio aquí es ¿por qué procesar más datos o almacenar más datos de los que necesita? Por lo tanto, si puede eliminar las cosas en una vista SQL en lugar de conectarse directamente a una tabla, es una buena idea. Realmente puede acelerar las cargas y actualizaciones de datos. Pero, si no tienes acceso a la fuente para hacer cambios, eso está fuera obviamente.

Por lo tanto, eso es limpieza de datos, generalmente mejor hacerlo en el origen o en Power Query. ¿Qué hay de la transformación? Depende, generalmente desea realizar sus transformaciones en Power Query. Dicho esto, he visto datos no pivotantes de una lista de SharePoint tomar excesivamente largo en Power Query. De ahí vino UNPIVOT (solución DAX para despivotar columnas en tablas). Así que eso no es absoluto, pero generalmente una buena idea.

Ahora, ¿qué pasa con la adición de columnas y tal. Bueno, esto entra en una zona más gris en mi opinión. Algunas cosas son muy fáciles de hacer en DAX y un verdadero dolor en Power Query y viceversa. Luego está la pieza de mantenimiento de la misma. Si tiene que hacer ciertos cálculos en DAX, entonces es mejor hacerlos todos en DAX para que tenga una sola base de código? En otras palabras, alguien que viene después de usted no tiene que conocer Power Query y R y Python y DAX para mantener su archivo de informe? Porque puede usartodos todos ellos si lo desea en el mismo archivo de Power BI y ahora necesita saber 4 idiomas en lugar de 1 para mantenerlo.

Por lo tanto, en generalidades muy grandes, es mejor empujar el procesamiento hacia arriba de la cadena hasta el origen y fallar esa consulta de energía. Pero, hay otras cosas a considerar en mi opinión que no lo convierten en un tema absoluto en blanco y negro.

[ericOnline]

GEM de una respuesta! Estoy en este momento en"Entonces está la pieza de mantenimiento de la misma." Como alguien que acaba de heredar un "mi primer panel de Power BI" bastante grande. Reducir la curva de aprendizaje para los nuevos mantenedores es clave. Gracias por compartir su experiencia @Greg_Deckler.