cómo diseñar el entorno de desarrollador para cargas de datos rápidas en Desktop

[Anonymous]

En primer lugar, esto no es estrictamente una pregunta de escritorio. Pero, no sé dónde más hacer esta pregunta. Así que tendrás que perdonarme si este no es el foro correcto.

Tengo desarrolladores de PBI repartidos por todo el país (EE.UU.). La mayoría de los datos que cargamos en PBI provienen de una única ubicación en el país (es decir, no tengo centros de datos distribuidos en todo el país). La mayoría de nuestros informes de PBI tienen muchas transformaciones complicadas de carga de datos, pero los volúmenes de datos no son gigantescos (2 millones de filas para nuestra tabla más grande). Hemos estado descubriendo que, en el trabajo del desarrollador en Escritorio (no informar de actualizaciones en el servicio):

1) cuando las transformaciones se escriben en M (en lugar de directamente en el idioma de origen de datos), las cargas de datos son muy lentas (a veces tardan unos 45 minutos)

2) los desarrolladores que están físicamente cerca de nuestro centro de datos experimentan cargas de datos mucho más rápidas que las que están más lejos (exacerbada por el hecho de que todos estamos trabajando desde casa ahora debido al virus, es decir, estamos usando VPN)

Para resolver problemas #1, hemos implementado un estándar de diseño para escribir las transformaciones en el lenguaje del origen de datos, no en M / Power Query. Para resolver problemas #2, hemos comenzado a poner de pie las máquinas cerca de nuestro centro de datos para los desarrolladores que están lejos del centro de datos a RDP en.

Entiendo que nuestra solución para el problema #1 no se recomienda en general (por ejemplo, porque impide todo el plegado de consultas posterior, si alguna vez queremos hacer transformaciones M después del paso de origen). Además, entiendo que el rendimiento de la carga de datos en Desktop puede ser muy diferente al del Servicio. (Por ejemplo, una consulta SQL en Desktop se ejecuta dos veces, mientras que solo se ejecuta una vez en el servicio.) Sin embargo, estoy muy incómodo con nuestro estándar de diseño para la #1 de problemas. ¿Es típica la lentitud de la carga de datos en Desktop para transformaciones M complejas? Si no, ¿cuál es la mejor solución para esto?

Además, ¿es típico que las empresas de pie máquinas cerca de centros de datos para los desarrolladores de PBI RDP para superar los desafíos de rendimiento de carga de escritorio? Si no es así, ¿cómo se resuelve este problema?

[Greg_Deckler]

@qubit813 Bueno, poner en Vistas en el sistema de datos de origen es la forma más rápida recomendada de cargar datos. Es cuando se coloca el código SQL en una instrucción de consulta que puede causar problemas. @edhans tiene opiniones específicas sobre esto si la memoria sirve. Si las transformaciones de consulta M se pueden plegar en la base de datos que es la 2a mejor opción más allá de colocar las vistas en la propia base de datos.

[Anonymous]

@Greg_Deckler

Consideraré la posibilidad de mover la lógica de transformación pesada a SQL Server como vistas.

¿Qué tal para mi segunda pregunta? Para superar los desafíos de la velocidad de los datos, ¿es típico poner máquinas "desarrolladoras" cerca de los centros de datos y tener a los desarrolladores de PBI RDP en ellas para el desarrollo de PBI? Si es así, ¿hay alguna gotcha o mejores prácticas? Por ejemplo, ¿debo asignar 1 máquina por desarrollador (ya que PBI guarda las credenciales en el perfil de Windows)?

[Greg_Deckler]

@qubit813 Sí, la distancia crea latencia, no hay duda si usted podría sentar a sus desarrolladores en la parte superior de los servidores que sería óptimo! :D. No veo por qué los desarrolladores no pudieron compartir cajas de salto, eso es bastante común, pero estoy seguro de que sería mucho más feliz no tener que compartir, quiero decir, son desarrolladores después de todo!!