Compartir a través de


Solución de problemas de actualización incremental y datos en tiempo real

Hay dos fases al implementar una solución de actualización incremental y datos en tiempo real; la primera es configurar parámetros, filtrar y definir una directiva en Power BI Desktop, mientras que la segunda es la operación de actualización inicial del modelo semántico y las actualizaciones posteriores en el servicio. En este artículo se describe la solución de problemas por separado para cada una de estas fases.

Después de haber particionado la tabla en el servicio Power BI, es importante tener en cuenta que las tablas actualizadas incrementalmente que también obtienen datos en tiempo real con DirectQuery funcionan ahora en modo híbrido, lo que significa que funcionan tanto en el modo de importación como en el modo DirectQuery. Las tablas que tienen relaciones con esta tabla híbrida actualizada incrementalmente deben usar el modo dual para que se puedan usar en el modo de importación y en el modo DirectQuery sin pérdidas de rendimiento. Además, los objetos visuales de informes podrían almacenar en caché los resultados para evitar la devolución de consultas al origen de datos, lo que impediría que la tabla adquiriera las actualizaciones de datos más recientes en tiempo real. En la sección de solución de problemas final se tratan estos problemas en modo híbrido.

Antes de solucionar los problemas de actualización incremental y datos en tiempo real, asegúrese de revisar el artículo Actualización incremental de los modelos y datos en tiempo real y la información paso a paso que se encuentra en Configuración de la actualización incremental y los datos en tiempo real.

Configuración en Power BI Desktop

La mayoría de los problemas que se producen al configurar la actualización incremental y los datos en tiempo real tienen que ver con el plegado de consultas. Tal como se describe en el artículo de Información general de actualización incremental para modelos: orígenes de datos admitidos, el origen de datos debe admitir el plegado de consultas.

Problema: La carga de datos tarda demasiado tiempo

En el Editor de Power Query, después de seleccionar Aplicar, la carga de datos tarda demasiado tiempo y ocupa demasiados recursos del equipo. Hay varias causas posibles.

Causa: Tipo de datos no coincidente

Esta incidencia puede deberse a un error de coincidencia de tipos de datos, donde Date/Time es el tipo de datos necesario para los parámetros RangeStart y RangeEnd, pero la columna de fecha de la tabla en la que se aplican los filtros no es el tipo de datos Date/Time o viceversa. Tanto el tipo de datos de parámetros como la columna de datos filtrados deben ser del tipo de datos Date/Time y el formato debe ser el mismo. Si no es así, la consulta no se puede plegar.

Solución: Compruebe el tipo de datos

Compruebe que la columna de fecha y hora de la tabla de actualización incremental es del tipo Date/Time. Si la tabla no contiene una columna de tipo de datos Date/Time, sino que usa un tipo de datos de entero, puede crear una función que convierta el valor de fecha y hora en los parámetros RangeStart y RangeEnd a fin de coincidir con la clave suplente de entero de la tabla de origen de datos. Para más información, consulte Configuración de la actualización incremental: Conversión de DateTime en entero.

Causa: El origen de datos no admite el plegado de consultas

Tal como se describe en Actualización incremental y datos en tiempo real para modelos: Requisitos, la actualización incremental está diseñada para orígenes de datos que admiten el plegado de consultas. Asegúrese de que las consultas de origen de datos se plegan en Power BI Desktop antes de publicar en el servicio, donde los problemas de plegado de consultas se pueden complicar de manera significativa. Este método es especialmente importante cuando se incluyen datos en tiempo real en una directiva de actualización incremental, ya que la partición DirectQuery en tiempo real requiere el plegado de consultas.

Solución: Comprobación y prueba de consultas

En la mayoría de los casos, se muestra una advertencia en el cuadro de diálogo Directiva de actualización incremental que indica si la consulta que se va a ejecutar en el origen de datos no admite el plegado de consultas. Sin embargo, es posible que en algunos casos sea necesario asegurarse de que el plegado de consultas es posible. Si es posible, supervise la consulta que se pasa al origen de datos mediante una herramienta como SQL Profiler. Una consulta con filtros basados en RangeStart y RangeEnd se debe ejecutar en una sola consulta.

También puede especificar un período breve de fecha y hora en los parámetros RangeStart y RangeEnd que no incluyen más de unos miles de filas. Si la carga de datos filtrados del origen de datos al modelo tarda mucho tiempo y consume muchos procesos, probablemente significa que la consulta no se está plegando.

Si determina que la consulta no se pliega, consulte los artículos Instrucciones de plegado de consultas en Power BI Desktop y Plegado de consultas de Power Query para poder identificar lo que puede estar evitando el plegado de la consulta y cómo el origen de datos puede admitir el plegado de consultas, si es así.

Actualización del modelo semántico en el servicio

La solución de problemas de la actualización incremental en el servicio variará en función del tipo de capacidad en la que se haya publicado el modelo. Los modelos semánticos en las capacidades Premium admiten el uso de herramientas como SQL Server Management Studio (SSMS) para ver y actualizar particiones individuales de manera selectiva. Por otro lado, los modelos de Power BI Pro no proporcionan acceso a las herramientas a través del punto de conexión XMLA, por lo que solucionar los problemas de la actualización incremental puede requerir un poco más de prueba y error.

Problema: Se agotó el tiempo de espera de la actualización inicial

La actualización programada de los modelos de Power BI Pro en una capacidad compartida tiene un límite de tiempo de dos horas. Este límite de tiempo aumenta a cinco horas en el caso de los modelos en una capacidad Premium. Los sistemas de origen de datos también pueden imponer un límite de tamaño de devolución de consulta o un tiempo de espera de consulta.

Causa: No se están plegando las consultas de origen de datos

Si bien los problemas con el plegado de consultas habitualmente se pueden determinar en Power BI Desktop antes de la publicación en el servicio, es posible que las consultas de actualización del modelo no se plieguen, lo que genera tiempos de actualización excesivos y el uso de recursos del motor de mashup de consultas. Esta situación se debe a que se crea una consulta para cada partición del modelo. Si las consultas no se están plegando y los datos no se filtran en el origen de datos, el motor intentará filtrar los datos.

Solución: Comprobar el plegado de consultas

Use una herramienta de seguimiento en el origen de datos para determinar que la consulta que se pasa para cada partición es una consulta única que incluye un filtro basado en los parámetros RangeStart y RangeEnd. Si no es así, compruebe que el plegado de consultas ocurre en el modelo de Power BI Desktop al cargar una cantidad filtrada de datos pequeña en el modelo. Si no es así, primero debe solucionarlo en el modelo, realizar una actualización solo de metadatos en el modelo (mediante el punto de conexión XMLA) o, si se trata de un modelo de Power BI Pro en una capacidad compartida, eliminar el modelo incompleto en el servicio, volver a realizar la publicación e intentar nuevamente una operación de actualización inicial.

Si determina que las consultas no se pliegan, consulte los artículos Instrucciones de plegado de consultas en Power BI Desktop y Plegado de consultas de Power Query para poder identificar lo que puede estar evitando el plegado de las consultas.

Causa: Los datos cargados en particiones son demasiado grandes

Solución: Reducir el tamaño del modelo

En muchos casos, el tiempo de espera se debe a que la cantidad de datos que se deben consultar y cargar en las particiones del modelo supera los límites de tiempo que impone la capacidad. Reduzca el tamaño o la complejidad del modelo, o bien considere la posibilidad de dividirlo en conjuntos más pequeños.

Solución: Habilitar formato de almacenamiento de modelos grandes

En el caso de los modelos publicados en capacidades Premium, si el modelo crece a más de 1 GB o más, puede mejorar el rendimiento de la operación de actualización y asegurarse de que el modelo no supere los límites de tamaño si habilita el formato de almacenamiento de modelos grandes antes de realizar la primera operación de actualización en el servicio. Para obtener más información, consulte Modelos grandes en Power BI Premium.

Solución: Arrancar la actualización inicial

En el caso de los modelos publicados en capacidades Premium, puede arrancar la operación de actualización inicial. El arranque permite al servicio crear objetos de tabla y partición para el modelo, pero no cargar ni procesar datos históricos en ninguna de las particiones. Para más información, consulte Actualización incremental avanzada: Prevención de tiempos de espera en la actualización completa inicial.

Causa: Tiempo de espera de consulta del origen de datos

Las consultas pueden verse limitadas por el límite de tiempo predeterminado del origen de datos.

Solución: Invalidar el límite de tiempo en la expresión de consulta

Muchos orígenes de datos permiten invalidar el límite de tiempo en la expresión de consulta. Para más información, consulte Actualización incremental para modelos: Límites de tiempo.

Problema: Error en la actualización debido a valores duplicados

Causa: Las fechas posteriores cambiaron

Con una operación de actualización, solo los datos que han cambiado en el origen de datos se actualizan en el modelo. Como los datos se dividen por una fecha, se recomienda que las fechas posteriores (transacción) no cambien.

Si se cambia una fecha de manera accidental, pueden ocurrir dos problemas: los usuarios observan que algunos totales han cambiado en los datos históricos (esto no debería pasar), o bien que durante una actualización se devuelve un error que indica que un valor único no es único en realidad. En este último caso, esta situación puede ocurrir cuando la tabla que tiene configurada la actualización incremental se usa en una relación 1:N con otra tabla como el lado 1 y debe tener valores únicos. Cuando los datos cambian (para un identificador específico), ese identificador aparece en otra partición y el motor detecta que el valor no es único.

Solución: Actualizar particiones específicas

Cuando para una empresa es necesario cambiar algunos datos anteriores a partir de las fechas, una solución posible es usar SSMS para actualizar todas las particiones desde el punto en que se encuentra el cambio hasta la partición de actualización actual, lo que hace que el lado 1 de la relación siga siendo único.

Problema: Se truncan los datos

Causa: Se superó el límite de consultas del origen de datos

Algunos orígenes de datos, como Azure Data Explorer, Log Analytics y Application Insights, tienen un límite de 64 MB (comprimido) en los datos que se pueden devolver para una consulta externa. Azure Data Explorer puede devolver un error explícito, pero en el caso de otros como Log Analytics y Application Insights, los datos devueltos se truncan.

Solución: Especificar períodos de actualización y almacenamiento más breves

Especifique períodos de actualización y almacenamiento más breves en la directiva. Por ejemplo, si especificó un período de actualización de un año y se devuelve un error de consulta o se truncan los datos devueltos, pruebe un período de actualización de 12 meses. Querrá asegurarse de que las consultas para la partición de actualización actual o cualquier partición histórica basada en los períodos de actualización y almacenamiento no devuelvan más de 64 MB de datos.

Problema: Error en la actualización debido a conflictos de clave de partición

Causa: Se actualiza la fecha de la columna de fecha en el origen de datos

El filtro de la columna de fecha se usa para particionar de manera dinámica los datos en intervalos de períodos en el servicio Power BI. La actualización incremental no está diseñada para admitir casos en los que la columna de fecha filtrada se actualiza en el sistema de origen. Una actualización se interpretará como una inserción y una eliminación, no como una actualización real. Si la eliminación ocurre en el intervalo histórico y no en el intervalo incremental, no se seleccionará, lo que puede provocar errores en la actualización de los datos debido a conflictos de clave de partición.

Modo híbrido en el servicio (versión preliminar)

Cuando Power BI aplica una directiva de actualización incremental con datos en tiempo real, convierte la tabla actualizada incrementalmente en una tabla híbrida que funciona tanto en el modo de importación como en el modo DirectQuery. Observe la partición DirectQuery al final de la siguiente lista de particiones de una tabla de ejemplo. La presencia de una partición DirectQuery tiene implicaciones para las tablas relacionadas y para los objetos visuales de informes que consultan esta tabla.

Captura de pantalla de la tabla híbrida.

Problema: el rendimiento de las consultas es deficiente

Las tablas híbridas que funcionan tanto en el modo de importación como en el modo DirectQuery requieren que las tablas relacionadas funcionen en modo dual para que puedan actuar como almacenadas en caché o no almacenadas en caché, en función del contexto de la consulta que se envía al modelo de Power BI. El modo dual permite a Power BI reducir el número de relaciones limitadas en el modelo y generar consultas de origen de datos eficaces para garantizar un buen rendimiento. No se pueden insertar las relaciones limitadas en el origen de datos que requiere que Power BI recupere más datos de los necesarios. Como las tablas duales pueden actuar como tablas de DirectQuery o Importación, se evita esta situación.

Al configurar una directiva de actualización incremental, Power BI Desktop le recuerda que cambie las tablas relacionadas al modo dual al seleccionar Obtenga los datos más recientes en tiempo real con DirectQuery (solo Premium). Además, asegúrese de revisar todas las relaciones entre tablas existentes en la vista Modelo.

Captura de pantalla que muestra la conversión de tablas relacionadas al modo dual.

Las tablas que actualmente funcionan en el modo DirectQuery se cambian fácilmente al modo dual. En las propiedades de la tabla, en Opciones avanzadas, seleccione Dual en el cuadro de lista Modo de almacenamiento. Las tablas que actualmente funcionan en modo de importación, sin embargo, requieren trabajo manual. Las tablas duales tienen las mismas restricciones funcionales que las tablas de DirectQuery. Por tanto, Power BI Desktop no puede convertir las tablas de importación porque podrían basarse en otras funcionalidades no disponibles en modo dual. Debe volver a crear manualmente estas tablas en modo DirectQuery y, a continuación, convertirlas al modo dual. Para más información, consulte Administración del modo de almacenamiento en Power BI Desktop.

Problema: los objetos visuales de informes no muestran los datos más recientes

Causa: Power BI almacena en caché los resultados de la consulta, mejora el rendimiento y reduce la carga de back-end

De forma predeterminada, Power BI almacena en caché los resultados de la consulta, por lo que las consultas de objetos visuales de informes se pueden procesar rápidamente incluso si se basan en DirectQuery. Evitar las consultas de origen de datos innecesarias mejora el rendimiento y reduce la carga del origen de datos, pero esto también podría significar que los cambios de datos más recientes en el origen no se incluyen en los resultados.

Solución: configurar la actualización automática de páginas

Para seguir capturando los cambios de datos más recientes del origen, configure la actualización automática de páginas para los informes en el servicio Power BI. La actualización automática de páginas se puede realizar en intervalos fijos, como cinco segundos o diez minutos. Cuando se alcanza ese intervalo concreto, todos los objetos visuales de esa página envían una consulta de actualización al origen de datos y se actualizan según corresponda. Como alternativa, puede actualizar los objetos visuales de una página en función de la detección de cambios en los datos. Este método requiere una medida de detección de cambios que Power BI usa a continuación para sondear el origen de datos en busca de cambios. La detección de cambios solo se admite en áreas de trabajo que forman parte de una capacidad Premium. Para más información, consulte Actualización automática de páginas en Power BI.