ericOnline
A medida que comprendo un poco más cómo trabajar con Power BI, veo que puedo hacer muchas cosas en DAX además de en Power Query.
Pregunta para sus profesionales de Power BI:
– ¿Cuánta limpieza (filtrar nulos / espacios en blanco, unir tablas, etc.) hace en DAX frente a Power Query?
– ¿Cómo diferencia el trabajo que hace en DAX frente a Power Query?
Gracias
¡@ImkeF, @amitchandak, @Greg_Deckler y otros!
Marounnsader
Hola a todos
Entonces, dado que mencionamos PQ y transformaciones, ¿cómo se compara PQ con otras herramientas ETL? ¿Podemos usar o depender de PQ como la solución empresarial para ETL?
ericOnline
En respuesta a Marounnsader
Algunas cosas a considerar:
– La mayoría (¿todo?) Que 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?
– ¿Existe experiencia en PowerBI dentro de su organización para mantener informes?
– ¿O su organización ya usa un lenguaje ETL MODERNO?
– ¿Es PQ (a través de PowerBI) una posible «actualización» para sus productos ETL existentes (quizás anticuados / esotéricos)?
Marounnsader
En respuesta a ericOnline
Hola Eric
gran pregunta aquí
Estoy tratando de aprovechar la experiencia de PowerBI en mi equipo, me han asignado recientemente, actualmente estamos usando ODICS y ADW de ORACLE, el problema son muchos proyectos y la limpieza se realiza con un equipo muy antiguo y la mayoría se ha ido sin la documentación adecuada. , y esto está afectando el rendimiento, pero podemos decir que está limpio sin nulos hasta ahora
Estoy tratando de usar más conjuntos de fechas y flujos de datos compartidos para poder difundir la cultura de BI de autoservicio en la empresa y ahora estoy en el proceso de contratar un 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 comenzar a usar los poderes PQ o guardarlo para casos especiales
ImkeF
¡Muy buenas respuestas!
Mi regla general es:
1) Empuje todo lo posible en sentido ascendente (hacia la fuente de los datos)
2) …. a menos que necesite una medida, use DAX
3) Aprenda a saber cuándo necesita una medida: https://exceleratorbi.com.au/calculated-columns-vs-measures-dax/
Anónimo
Generalmente, @Greg_Deckler tiene razón.
Soy de la opinión de que debería preparar los datos para su análisis con la herramienta adecuada. DAX no es esta herramienta. Después de todo, es un lenguaje de expresiones de análisis de datos por una razón. Un buen ejemplo: ¿le gustaría 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 impulsar las transformaciones de datos a la fuente la mayor parte del tiempo (a veces esto requiere que el codificador también sea inteligente). Power Query es TAN poderoso que puede realizar CUALQUIER transformación de datos que se le ocurra y puede hacerlo realmente rápido. Para esto, sin embargo, debe conocer M (el lenguaje PQ) y saber cómo escribir código optimizado. M es un lenguaje funcional con su propio sistema de tipos, sus propias reglas, sus propias peculiaridades y curiosidades. Tienes que aprenderlos para saber cómo hacer que el código sea increíblemente rápido y fácil de mantener (documentar los pasos individuales, por ejemplo, es una buena práctica). Pero es la misma historia con cualquier idioma, incluido DAX.
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 y mostrar algunas etiquetas sensibles para los espacios en blanco conceptuales. Las tablas de hechos, por otro lado, pueden tener ESPACIOS EN BLANCO en sus medidas (aunque no en las claves de dimensión) porque las funciones arit de DAX las tratan como 0 y nunca deben exponerse al usuario final. Todos los cálculos deben realizarse siempre a través de medidas y medidas únicamente.
La violación del ideal siempre ocurrirá, por supuesto, pero es bueno dar buenas razones para tales violaciones para que la próxima persona no lo maldiga (y ante sus narices).
Mejor
D
ericOnline
En respuesta a Anónimo
Grandes conocimientos @Anónimo! Me has dado muchas cosas para considerar, buscar y comprender. Gracias.
(aparte, y SOLO porque me lo encontré el otro día … sí … «ellos» están haciendo ML con SQL ahora 🙂 )
Anónimo
En respuesta a ericOnline
Realmente no lo hacen. Ejecutan scripts Python o R dentro de SQL Server. Eso no es ML en SQL.
Mejor
D
Greg_Deckler
Vaya, esa es una pregunta complicada. @Anonymous probablemente querrá intervenir en esto.
Entonces, mi respuesta a esto es que depende. Hay algunas escuelas de pensamiento sobre esto. Una, la escuela de pensamiento, trata de impulsar la mayor cantidad de limpieza de datos en la «cadena» como sea posible. Entonces, si lo piensas, tienes:
1. Fuente
2. Power Query
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? Entonces, si puede eliminar las cosas en una Vista SQL en lugar de conectarse directamente a una tabla, es una buena idea. Realmente puede acelerar la carga y actualización de datos. Pero, si no tiene acceso a la fuente para realizar cambios, obviamente está descartado.
Así que esa es la limpieza de datos, generalmente es mejor hacerlo en el origen o en Power Query. ¿Qué pasa con la transformación? Depende, generalmente desea hacer sus transformaciones en Power Query. Dicho esto, he visto que los datos de desvinculación de una lista de SharePoint tardan excesivamente en Power Query. De ahí es de donde vino UNPIVOT (solución DAX para desvincular columnas en tablas). Entonces eso no es absoluto, pero en general es una buena idea.
Ahora, ¿qué hay de agregar columnas y demás? Bueno, esto entra en un área más gris en mi opinión. Algunas cosas son muy fáciles de hacer en DAX y un verdadero problema en Power Query y viceversa. Luego está la parte de la mantenibilidad. Si tiene que hacer ciertos cálculos en DAX, ¿es mejor hacerlos todos en DAX para que tenga una única 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 usarlos todos 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 llevar el procesamiento hacia arriba en la cadena hasta la fuente y, en caso de falla, Power Query. Pero, en mi opinión, hay otras cosas a considerar que no lo convierten en un problema absoluto en blanco y negro.
ericOnline
En respuesta a Greg_Deckler
JOYA de una respuesta! Estoy tecleando ahora mismo «Luego está la parte de la mantenibilidad.. «Como alguien que acaba de heredar un» mi primer panel de Power BI «bastante grande. Disminuir la curva de aprendizaje para los nuevos mantenedores es clave. Gracias por compartir su experiencia @Greg_Deckler.
