Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Hay dos fases al implementar una solución de actualización incremental y datos en tiempo real, la primera que configura parámetros, filtra y define una directiva en Power BI Desktop, y 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 crear particiones de 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 ahora funcionan en modo híbrido, lo que significa que funcionan en modo de importación y DirectQuery. Las tablas con relaciones con una tabla híbrida actualizada incrementalmente deben usar el modo Dual para que se puedan usar en el modo de importación y DirectQuery sin penalizaciones de rendimiento. Además, los objetos visuales de informe pueden almacenar en caché los resultados para evitar el envío de consultas al origen de datos, lo que impediría que la tabla recoja las actualizaciones de datos más recientes en tiempo real. En la sección de solución de problemas final se tratan estos problemas de modo híbrido.
Antes de solucionar problemas de actualización incremental y datos en tiempo real, asegúrese de revisar La actualización incremental de los modelos y los datos en tiempo real y la información paso a paso 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. Como se describe en Actualización incremental para los modelos: orígenes de datos admitidos, el origen de datos debe admitir el plegamiento 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 una cantidad excesiva de tiempo y recursos de equipo. Hay varias causas potenciales.
Causa: Error de coincidencia de tipo de datos
Este problema puede deberse a una incompatibilidad de tipo 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 de tipo de datos Date/Time, o viceversa. Tanto el tipo de datos de los parámetros como la columna de datos filtrado deben ser Date/Time de tipo de datos y el formato debe ser el mismo. Si no es así, no se puede plegar la consulta.
Solución: Comprobar el tipo de datos
Compruebe que la columna de fecha y hora de la tabla de actualización incremental es de tipo de datos Date/Time. Si la tabla no contiene una columna de tipo de datos Date/Time, sino que usa un tipo de datos entero, puede crear una función que convierta el valor de fecha y hora en los parámetros RangeStart y RangeEnd para que coincidan con la clave sustituta entera de la tabla del 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
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 están plegando en Power BI Desktop antes de publicarlas en el servicio, donde los problemas de plegado de consultas pueden agravarse significativamente. Este enfoque es especialmente importante cuando se incluyen datos en tiempo real en una directiva de actualización incremental porque la partición de DirectQuery para datos en tiempo real necesita el plegado de consultas.
Solución: Verifique y pruebe las consultas
En la mayoría de los casos, se muestra una advertencia en el cuadro de diálogo de la política 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, en algunos casos podría ser necesario asegurarse de que se pueda realizar el plegado de consultas. Si es posible, monitorea la consulta que se pasa al origen de datos mediante una herramienta como SQL Profiler. Una consulta con filtros basados en RangeStart y RangeEnd debe ejecutarse en una sola consulta.
También puede especificar un breve período de fecha y hora en los RangeStart parámetros y RangeEnd que no incluyan más de mil filas. Si la carga de datos filtrados desde el origen de datos al modelo tarda mucho tiempo y es intensiva en procesamiento, es probable que la consulta no se esté optimizando.
Si determina que la consulta no se está plegando, consulte Instrucciones de plegado de consultas en Power BI Desktop y Plegado de consultas en Power Query para ayudar a identificar lo que podría impedir el plegado de consultas y cómo, o si el origen de datos puede incluso admitir el plegado de consultas.
Actualización del modelo semántico en el servicio
La resolución de problemas de actualización incremental en el servicio difiere en función del tipo de capacidad en la que se haya publicado el modelo. Los modelos semánticos en capacidades Premium admiten el uso de herramientas como SQL Server Management Studio (SSMS) para ver y actualizar de forma selectiva particiones individuales. Por otro lado, los modelos de Power BI Pro no proporcionan acceso a herramientas a través del punto de conexión XMLA, por lo que solucionar problemas de actualización incremental podría requerir un poco más de prueba y error.
Problema: Se agota el tiempo de espera de actualización inicial
La actualización programada para 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 para los modelos en una capacidad Premium. Los sistemas de origen de datos también pueden imponer un límite de tamaño de retorno de la consulta o un tiempo de espera de la consulta.
Causa: Las consultas de origen de datos no se pliegan
Aunque los problemas con el plegado de consultas normalmente se pueden determinar en Power BI Desktop antes de publicar en el servicio, es posible que las consultas de actualización del modelo no se estén plegando, lo que provoca un uso excesivo de los recursos del motor de mashup de consultas y excesivos tiempos de actualización. Esta situación se produce porque se crea una consulta para cada partición del modelo. Si el plegado de las consultas no se realiza y los datos no se filtran en la fuente de datos, el motor intentará filtrar los datos.
Solución: Verifica 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 única consulta que incluye un filtro basado en los parámetros RangeStart y RangeEnd. Si no es así, compruebe que el plegado de consultas se está produciendo en el modelo de Power BI Desktop al cargar una pequeña cantidad filtrada de datos en el modelo. Si no es así, corrígelo primero en el modelo, realiza una actualización solo de metadatos al modelo (mediante el punto de conexión XMLA) o, si es un modelo de Power BI Pro en una capacidad compartida, elimina el modelo incompleto en el servicio, vuelve a publicarlo e intenta nuevamente una operación de actualización inicial.
Si determina que las consultas no se están plegando, consulte Guía de plegado de consultas en Power BI Desktop y plegado de consultas de Power Query para identificar qué podría estar impidiendo el plegado de 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 la cantidad de datos que se deben consultar y cargar en las particiones del modelo supera los límites de tiempo impuestos por la capacidad. Reduzca el tamaño o la complejidad del modelo, o considere la posibilidad de dividir el modelo en partes más pequeñas.
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, puede mejorar el rendimiento de la operación de actualización y asegurarse de que el modelo no alcance el límite de tamaño máximo habilitando el formato de almacenamiento para 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: Actualización inicial de arranque
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 la consulta del origen de datos
Las consultas pueden estar limitadas por un límite de tiempo predeterminado para el origen de datos.
Solución: Invalidación del 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: se produce un error en la actualización debido a valores duplicados
Causa: Las fechas de publicación han cambiado
Con una operación de actualización, solo se actualizan los datos que han cambiado en el origen de datos en el modelo. A medida que los datos se dividen por una fecha, se recomienda que las fechas de las transacciones no se cambien.
Si se cambia una fecha accidentalmente, se pueden producir dos problemas: los usuarios notan que algunos totales han cambiado en los datos históricos (se supone que no se supone que se produzcan), o durante una actualización, se devuelve un error que indica que un valor único no es de hecho único.
Para este último, esta situación puede ocurrir cuando la tabla con actualización incremental configurada se usa en una 1:N relación con otra tabla como el 1 lado y debe tener valores únicos. Cuando se cambian los datos 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 haya una necesidad empresarial de cambiar algunos datos anteriores de las fechas, una posible solución consiste en usar SSMS para actualizar todas las particiones desde el punto donde se encuentra el cambio hasta la partición de actualización actual, manteniendo así el 1 lado de la relación único.
Problema: Los datos se truncan
Causa: Se ha superado 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 (comprimidos) en los datos que se pueden devolver para una consulta externa. Azure Data Explorer puede devolver un error explícito, pero para otros, como Log Analytics y Application Insights, los datos devueltos se truncan.
Solución: especificar períodos de actualización y almacenamiento más pequeños
Especifique períodos de actualización y almacenamiento más pequeños 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. Quiere asegurarse de que las consultas para la partición de actualización actual o para cualquier partición histórica, basadas en los períodos de actualización y almacenamiento, no devuelvan más de 64 MB de datos.
Problema: se produce un error en la actualización debido a conflictos de clave de partición
Causa: Fecha de la columna de fecha en el origen de datos se actualiza
El filtro de la columna de fecha se usa para dividir dinámicamente 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 interpreta como una inserción y una eliminación, no como una actualización real. Si la eliminación se produce en el intervalo histórico y no en el intervalo incremental, no se detecta, lo que puede provocar fallos de actualización de datos debido a conflictos de clave de partición.
Modo híbrido en el servicio
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 en modo import y 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 de DirectQuery tiene implicaciones para las tablas relacionadas y los objetos visuales de informe que consultan esta tabla.
Problema: el rendimiento de las consultas es deficiente
Causa: Las tablas relacionadas no están en modo Dual
Las tablas híbridas que funcionan en el modo import y 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 enviada 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 relaciones limitadas en el origen de datos que requiere Power BI para recuperar más datos de los necesarios. Dado que las tablas duales pueden actuar ya sea como tablas DirectQuery o como tablas de importación, se evita esta situación.
Solución: Convertir tablas relacionadas en modo dual
Al configurar una directiva de actualización incremental, Power BI Desktop le recuerda cambiar las tablas relacionadas al modo Dual al seleccionar Obtener los datos más recientes en tiempo real con DirectQuery (solo Premium). Además, asegúrese de revisar todas las relaciones de tabla existentes en la vista modelo.
Las tablas que funcionan actualmente en 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. Sin embargo, las tablas que funcionan en modo de importación requieren trabajo manual. Las tablas duales tienen las mismas restricciones funcionales que las tablas directQuery. Por lo tanto, Power BI Desktop no puede convertir tablas de importación porque podrían depender de otras funciones que no están disponibles en el modo Dual. Debe volver a crear manualmente estas tablas en modo DirectQuery y, a continuación, convertirlas en modo Dual. Para más información, consulte Administración del modo de almacenamiento en Power BI Desktop.
Problema: los objetos visuales del informe no muestran los datos más recientes
Causa: Power BI almacena en caché los resultados de las consultas para mejorar el rendimiento y reducir la carga de back-end.
De forma predeterminada, Power BI almacena en caché los resultados de la consulta para que las consultas de objetos visuales de informe se puedan procesar rápidamente incluso si se basan en DirectQuery. Evitar consultas de origen de datos innecesarias mejora el rendimiento y reduce la carga del origen de datos, pero también puede 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 recuperar los cambios de datos más recientes del origen, configure la actualización automática de páginas para sus informes en el servicio de 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 objetos visuales en una página detectando cambios en los datos. Este enfoque requiere una medida de detección de cambios que Power BI usa para sondear el origen de datos de los 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.