Anónimo
Hola,
He estado cargando datos de Excel almacenados en SharePoint en PBI Desktop durante un par de meses y ha estado más o menos bien, aunque siento que es un poco lento, pero lo atribuyo a que necesito autenticarme cada vez. (El recuento de filas de hechos es solo 500k, aunque ~30 columnas más algunas tablas de dimensiones pequeñas)
Sin embargo, recientemente agregué un par de archivos más a SharePoint y construí nuevas consultas para ellos que requieren agregar consultas existentes o unirlas para hacer nuevas consultas y esto ha causado que PBI Desktop se ralentice significativamente y con bastante frecuencia obtengo una fórmula. Error de firewall y tengo que intentar actualizar la vista previa nuevamente. A menudo, esto hace que otras consultas tengan un «error» (es decir, tienen el signo de exclamación junto a su nombre) y tengo que actualizar cada vista previa para que funcione la nueva). Pero esto es muy LENTO y realmente hace que el desarrollo sea casi imposible.
Probé las sugerencias en la publicación de blog a continuación sobre cómo separar la extracción de Excel y los pasos de transformación, lo que parece haber ayudado, pero acabo de cargar otro bloque de datos de hechos (nueva región) y no puedo aplicar los cambios de consulta o haga una actualización completa ya que solo se evalúa durante mucho tiempo (ha estado evaluando durante más de 20 minutos ahora…)
https://www.excelguru.ca/blog/2015/03/11/power-query-errors-please-rebuild-this-data-combination/
¿Alguien sabe si esto se debe a la carga de todos estos datos de SharePoint? ¿Hay problemas conocidos y debería comenzar a pensar en almacenar los datos de una manera diferente?
Muchas gracias,
Tomás
Anónimo
En respuesta a marclelijveld
Hola @marclelijveld,
Gracias por los consejos útiles, naturalmente tiende a agrupar los pasos de la consulta, pero no lo había considerado conscientemente antes, probablemente hay una pequeña cantidad de orden que puedo hacer.
En cuanto a mi problema, me di cuenta de que estaba creando una nueva tabla que agregaba el gasto total para cada una de las 3 regiones, lo que, por supuesto, para cargar la vista previa tendría que pasar por todas las filas de datos de ~ 1 millón. Habiendo eliminado esto y movido el requisito a una tabla DAX, esto solucionó los problemas que enfrentaba más o menos. Sin embargo, habiendo dicho eso, cargar desde Excel localmente fue significativamente más rápido que cargar desde Excel almacenado en SharePoint, por lo que es algo a considerar en el futuro.
¡Muchas gracias!
Tomás
marclelijveld
hola @anonimo
Probablemente esté limitado por el conector de SharePoint. Desafortunadamente, este es simplemente un conector muy lento.
Cuando estoy trabajando con varios archivos en SharePoint, lo que normalmente hago es crear 1 tabla (por estructura de archivo/columna) que incluye todos los datos, y luego creo tablas adicionales que hacen referencia a la tabla que contiene todo. En este caso, solo habrá una tabla que consulte la fuente de datos y todas las demás harán referencia a esa tabla. Para hacer esto, puede hacer clic con el botón derecho en una tabla y una referencia, ¡así que no duplique!
Funcionara para ti?
– Marc
Anónimo
En respuesta a marclelijveld
Hola Marc,
¡Gracias por la rápida respuesta!
Los datos almacenados en Sharepoint son actualmente 3 archivos principales de Excel que contienen datos de hechos para 3 regiones diferentes, así como algunos archivos de dimensiones muy pequeñas.
Los datos de hechos se desglosan de la siguiente manera:
Región 1 = 100k filas
Región 2 = 250k filas
(Región 3 = 700k filas)
Anteriormente había cargado en 1 y 2 bien, agregándolos juntos en una consulta, pero agregar el tercero hizo que la carga no funcionara.
Para cada región, divido las consultas en 1. Cargar hoja de Excel, entonces una nueva consulta para 2. realizar cualquier transformación para obtener los datos en el formato correcto, 3. Agregar datos a la consulta principal esa es la tabla de hechos que debe usar el front-end. Cada uno de estos pasos hace referencia a la consulta anterior para cada región.
Todavía no he probado si el rendimiento mejora al cargar desde copias locales de Excel, pero supongo que ese es el siguiente paso lógico y luego, si eso soluciona el problema, necesito pensar en cómo podemos almacenar los datos en el futuro, como estos archivos regionales son actualizados diariamente por un equipo extranjero.
Gracias,
Tomás
marclelijveld
En respuesta a Anónimo
Hola Tom,
Hmm… La forma en que creaste tus consultas se ve bien. Los archivos de Excel son un poco grandes, pero supongo que ese no es el problema. Sin embargo, también depende de la cantidad de columnas y el tipo de datos que esté importando en la consulta. Mientras los archivos sean simples archivos planos, esto aún debería funcionar, aunque hay mejores fuentes para esta cantidad de datos.
Dijiste que hay una consulta donde haces todas las transformaciones. ¿Qué tipo de transformaciones estás haciendo? Lo que puede tener un gran impacto es repetir pasos. La mejor práctica es agrupar los pasos de consulta tanto como sea posible. Así que intente cambiar todos sus tipos de datos a la vez, cambie el nombre de las columnas a la vez, etc. Sé que esto no siempre es posible, pero intente hacerlo tanto como sea posible.
Como usted mismo sugiere, intente ejecutar esta consulta refiriéndose a los archivos locales en su máquina. De modo que puede probar si el problema se está acelerando en el conector de SharePoint, su consulta o la cantidad de datos.
– Marc
Anónimo
En respuesta a marclelijveld
Hola @marclelijveld,
Gracias por los consejos útiles, naturalmente tiende a agrupar los pasos de la consulta, pero no lo había considerado conscientemente antes, probablemente hay una pequeña cantidad de orden que puedo hacer.
En cuanto a mi problema, me di cuenta de que estaba creando una nueva tabla que agregaba el gasto total para cada una de las 3 regiones, lo que, por supuesto, para cargar la vista previa tendría que pasar por todas las filas de datos de ~ 1 millón. Habiendo eliminado esto y movido el requisito a una tabla DAX, esto solucionó los problemas que enfrentaba más o menos. Sin embargo, habiendo dicho eso, cargar desde Excel localmente fue significativamente más rápido que cargar desde Excel almacenado en SharePoint, por lo que es algo a considerar en el futuro.
¡Muchas gracias!
Tomás
