Consultas sobre tablas de datos grandes

Tenemos un gran conjunto de datos de datos no estructurados (Azure Blob) y hemos comenzado a notar que la actualización de nuestro modelo se vuelve bastante lenta después de que se cargan unos pocos miles de registros.

Nuestra estructura de consulta actual es:

#"Load Data"
    Loads data from the Azure Blob, ~1000 files
    Parses the files into a table with 3 columns (of list/record types which can be further expanded), ~700k rows

#"Sessions"
    Reference #"Load Data"
    Expand all 'Session' related columns

#"Users"
    Reference #"Load Data"
    Expand all 'User' related columns

#"Events"
    Reference #"Load Data"
    Expand all 'Event' related columns

#"Events By Name"
    Reference #"Events"
    Groups by 'event.name'- generates a column of tables to each event type's events and properties (these vary between events)

#"Event Name1" (2, 3, etc. one table per event type)
    Reference #"Events by Name"
    Expands that event name's Table, and generates a table with event.id and each of the properties for that event type

Mientras se ejecuta esto y se observa el monitor de recursos, el uso de la memoria se dispara y, finalmente, hay toneladas de fallas graves que conducen al uso del disco. Al mirar la ventana emergente de ejecución de consultas, parece que un montón de consultas se inician y se ejecutan en paralelo.

Si cargo los datos de una carpeta local, parece que todos están obteniendo datos, revisando los archivos y cargando las consultas comunes a las que se hace referencia en paralelo. Creo que esto es lo que hace que el uso de la memoria se vuelva loco, que el disco se active y que las consultas tarden horas en ejecutarse.

Supuse que las consultas referenciadas se ejecutarían una vez primero, y luego las consultas individuales harían referencia a sus tablas resultantes, pero ese no parece ser el caso. También intenté usar Table.Buffer como último paso de # «Cargar datos» y # «Eventos», en un intento de hacer que esas consultas se calculen una vez y luego se compartan entre los dependientes, pero eso solo pareció empeorar las cosas. ¿Hay formas de:

* Hacer que una consulta solo se ejecute una vez y que su resultado se transfiera a cualquier consulta que haga referencia a ella

* Evite que las consultas se ejecuten en paralelo y, en su lugar, ejecute secuencialmente

¿Estoy viendo esto de la manera incorrecta? Muchos artículos de «rendimiento» que encontré solo mencionan la estructuración de sus consultas para permitir el plegado de consultas. Sin embargo, esta no es una posibilidad para nuestro caso actual, ya que Azure Blob Storage realmente solo almacena archivos ‘blob’ que deben cargarse y analizarse localmente.

Es una verdadera lucha hacer que estas consultas se ejecuten en nuestros eventos de prueba actuales de 700k, y esperamos que aumenten a millones en el entorno real. ¿Nuestra única opción es tratar los blobs y enviar los datos a una base de datos SQL y vincular nuestro modelo a eso en su lugar?

@jPinhao Creo que en el último SU activamos la carga paralela de consultas. De lo que no nos dimos cuenta es que, en algún contexto, en realidad daña la actuación. Creo que podemos agregar una opción de interfaz de usuario para volver a la carga secuencial. Haré un seguimiento con el equipo de BI internamente sobre esto.

Gracias por la información @pqian. Por lo que vale, estaba teniendo problemas de rendimiento similares con la versión anterior (actualización de febrero).

Podría ser bueno tener ese control sobre la carga lineal / paralela, otra opción sería que Power BI pueda predecir el uso de la memoria y administrar mejor el modo de ejecución y el uso de recursos (aunque esto sin duda sería más complejo, si es posible en algunos casos ).

Teniendo en cuenta las consultas referenciadas que aparentemente se ejecutan repetidamente como parte de sus usuarios, ¿puede confirmar si este es el caso? ¿Sería esto un subproducto de la evaluación paralela o siempre ha sido el caso de Power BI? ¿Hay alguna forma de evitar que eso suceda?

@jPinhao Las consultas referenciadas se ejecutarán una vez por cada consulta cargada, por lo que es posible que lleguen a la fuente de datos varias veces; en los casos de carga paralela ciertamente lo harán. Es una función de cómo cada consulta de referencia terminó plegándose a la fuente y cómo se almacenaron en caché los datos.

Para obtener una explicación más detallada, consulte esta publicación:

http: //community.powerbi.com/t5/Desktop/How-to-Improve-Query-Reference-performance-for-large-tables / …

@jPinhao

Mientras discutimos opciones para desactivar el procesamiento paralelo con los equipos involucrados, existe una solución para su escenario. Puede establecer una variable de entorno en el proceso PBIDesktop.exe para volver a la carga secuencial.

Por ejemplo, en el símbolo del sistema, puede:

> SET PBI_EnableMultithreadedDataLoad = 0

> PBIDesktop.exe

¡Gracias pqian!

Esto fue bastante útil para seguir mejor la orden de ejecución, e incluso nos ayudó a identificar algunas deficiencias en nuestras consultas. 🙂 Tal como está, no creo que lo que estamos tratando de hacer con Power BI sea posible, ¡pero ayuda saber que necesitamos una capa adicional para procesar nuestros datos!

Entradas relacionadas

Deja un comentario Cancelar respuesta