Compartir a través de

Actualización incremental y datos en tiempo real para modelos semánticos

  • Artículo

La actualización incremental y los datos en tiempo real para los modelos semánticos en Power BI proporcionan formas eficaces de controlar los datos dinámicos y mejorar el rendimiento de la actualización del modelo. Al automatizar la creación y administración de particiones, la actualización incremental reduce la cantidad de datos que se deben actualizar y permite la inclusión de datos en tiempo real. En este artículo explica cómo configurar y usar características de actualización incremental en Power BI para capturar datos de movimiento rápido y rendimiento mejorado.

La actualización incremental amplía las operaciones de actualización programada proporcionando la creación y administración automatizadas de particiones para las tablas de modelo semántico que cargan datos nuevos y actualizados con frecuencia. Para la mayoría de los modelos, se trata de una o varias tablas que contienen datos de transacción que cambian con frecuencia y pueden crecer exponencialmente, como una tabla de hechos en un esquema de base de datos relacional o de estrella. Una directiva de actualización incremental para crear particiones de la tabla y actualizar solo las particiones de importación más recientes y, opcionalmente, utilizar otra partición DirectQuery para los datos en tiempo real, puede reducir significativamente la cantidad de datos que hay que actualizar. Al mismo tiempo, esta directiva garantiza que los cambios más recientes en el origen de datos se incluyan en los resultados de la consulta.

Con actualización incremental y datos en tiempo real:

  • Menos ciclos de actualización para los datos que cambian rápidamente El modo DirectQuery obtiene las actualizaciones de datos más recientes a medida que se procesan las consultas sin necesidad de una cadencia de actualización alta.
  • Las actualizaciones son más rápidas. Solo hay que actualizar los datos más recientes que se han modificado.
  • Las actualizaciones son más confiables. No se necesitan conexiones de larga duración a orígenes de datos volátiles. Las consultas a los datos de origen se ejecutan más rápido, lo que reduce la posibilidad de que los problemas de red interfieran en el funcionamiento.
  • El consumo de recursos es menor. Al haber menos datos que actualizar, se reduce el consumo total de memoria y de otros recursos tanto en Power BI como en sistemas de origen de datos.
  • Se habilitan modelos semánticos de gran tamaño. Los modelos semánticos con potencialmente miles de millones de filas pueden crecer sin necesidad de actualizar completamente todo el modelo con cada operación de actualización.
  • La instalación es fácil. Las directivas de actualización incremental se definen en Power BI Desktop con solo algunas tareas. Cuando Power BI Desktop publica el informe, el servicio aplica automáticamente esas directivas con cada actualización.

Al publicar un modelo de Power BI Desktop en el servicio, cada tabla del modelo nuevo tiene una sola partición. Esa partición única contiene todas las filas de esa tabla. Si la tabla es grande, por ejemplo, con decenas de millones de filas o incluso más, una actualización de esa tabla puede tardar mucho tiempo y consumir una cantidad excesiva de recursos.

Con la actualización incremental, el servicio crea particiones de manera dinámica y separa los datos que se deben actualizar con frecuencia de los datos que se pueden actualizar con menos frecuencia. Los datos de tabla se filtran mediante los parámetros de fecha y hora de Power Query con los nombres reservados RangeStart y RangeEnd, que distinguen mayúsculas de minúsculas. Al configurar inicialmente la actualización incremental en Power BI Desktop, los parámetros se usan para filtrar solo un período de datos breve que se va a cargar en el modelo. Cuando Power BI Desktop publica el informe en el servicio Power BI, con la primera operación de actualización, el servicio crea particiones incrementales e históricas y, opcionalmente, una partición DirectQuery en tiempo real basada en la configuración de la directiva de actualización incremental. A continuación, el servicio anula los valores de los parámetros para filtrar y consultar los datos de cada partición basándose en los valores de fecha y hora de cada fila.

Con cada actualización posterior, los filtros de la consulta solo devuelven las filas que se encuentran dentro del período de actualización que los parámetros definen de manera dinámica. Esas filas con fecha y hora dentro del período de actualización se actualizan. Las filas con fecha y hora que ya no se encuentran dentro del período de actualización se convierten en parte del período histórico, el que no se actualiza. Si en la directiva de actualización incremental se incluye una partición DirectQuery en tiempo real, su filtro también se actualizará para que resalte los cambios que se produjeron después del período de actualización. Se ponen al día tanto los períodos de actualización como los períodos históricos. A medida que se crean particiones de actualización incremental nuevas, las particiones de actualización que dejan de estar dentro del período de actualización se convierten en particiones históricas. Con el tiempo, las particiones históricas se vuelven menos pormenorizadas a medida que se combinan. Cuando una partición histórica deja de estar dentro del período histórico definido por la directiva, se quita completamente del modelo. Este comportamiento se conoce como un patrón de ventana con desplazamiento.

Gráfico que representa un patrón de ventana con desplazamiento.

La belleza de la actualización incremental es que el servicio controla todo esto automáticamente en función de las directivas de actualización incremental que el usuario define. De hecho, el proceso y las particiones que se crean a partir de él ni siquiera son visibles en el servicio. En la mayoría de los casos, una directiva de actualización incremental bien definida es todo lo que se necesita para mejorar significativamente el rendimiento de la actualización del modelo. Sin embargo, la partición DirectQuery en tiempo real solo se admite para modelos en las capacidades Premium. Power BI Premium también permite escenarios de partición y actualización más avanzados a través del punto de conexión XML for Analysis (XMLA).

Requisitos

En las secciones siguientes se describen los planes y orígenes de datos admitidos.

Planes admitidos

La actualización incremental es compatible con modelos Power BI Premium, Premium por usuario, Power BI Pro y Power BI Embedded.

La obtención de los datos más recientes en tiempo real con DirectQuery solo es compatible con modelos de Power BI Premium, Premium por usuario y Power BI Embedded.

Orígenes de datos admitidos

La actualización incremental y los datos en tiempo real funcionan mejor para orígenes de datos relacionales estructurados, como SQL Database y Azure Synapse, pero también pueden funcionar para otros orígenes de datos. En cualquier caso, el origen de datos debe admitir lo siguiente:

Filtrado de fechas: el origen de datos debe admitir algún mecanismo para filtrar los datos por fecha. Para un origen relacional, suele ser una columna de fecha de tipo de datos de fecha y hora o entero en la tabla de destino. Los parámetros RangeStart y RangeEnd, que deben ser de tipo de datos de fecha y hora, filtran los datos de la tabla en función de la columna de fecha. En el caso de las columnas de fecha de claves suplentes de enteros con formato yyyymmdd, puede crear una función que convierta el valor de fecha y hora en los parámetros RangeStart y RangeEnd para que coincida con la clave suplente de enteros de la columna de fecha. Para más información, consulte Configuración de la actualización incremental y datos en tiempo real: Conversión de DateTime en entero.

Para otros orígenes de datos, los parámetros RangeStart y RangeEnd deben pasarse al origen de datos de alguna manera que permita el filtrado. En el caso de los orígenes de datos basados en archivos donde los archivos y carpetas se organizan por fecha, los parámetros RangeStart y RangeEnd se pueden usar para filtrar los archivos y carpetas para seleccionar los archivos que se van a cargar. En el caso de los orígenes de datos basados en web, los parámetros RangeStart y RangeEnd se pueden integrar en la solicitud HTTP. Por ejemplo, la siguiente consulta se puede usar para la actualización incremental de los seguimientos desde una instancia de AppInsights:

let 
    strRangeStart = DateTime.ToText(RangeStart,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    strRangeEnd = DateTime.ToText(RangeEnd,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    Source = Json.Document(Web.Contents("https://api.applicationinsights.io/v1/apps/<app-guid>/query", 
    [Query=[#"query"="traces 
    | where timestamp >= datetime(" & strRangeStart &") 
    | where timestamp < datetime("& strRangeEnd &")
    ",#"x-ms-app"="AAPBI",#"prefer"="ai.response-thinning=true"],Timeout=#duration(0,0,4,0)])),
    TypeMap = #table(
    { "AnalyticsTypes", "Type" }, 
    { 
    { "string",   Text.Type },
    { "int",      Int32.Type },
    { "long",     Int64.Type },
    { "real",     Double.Type },
    { "timespan", Duration.Type },
    { "datetime", DateTimeZone.Type },
    { "bool",     Logical.Type },
    { "guid",     Text.Type },
    { "dynamic",  Text.Type }
    }),
    DataTable = Source[tables]{0},
    Columns = Table.FromRecords(DataTable[columns]),
    ColumnsWithType = Table.Join(Columns, {"type"}, TypeMap , {"AnalyticsTypes"}),
    Rows = Table.FromRows(DataTable[rows], Columns[name]), 
    Table = Table.TransformColumnTypes(Rows, Table.ToList(ColumnsWithType, (c) => { c{0}, c{3}}))
in
Table

Cuando se configura la actualización incremental, se ejecuta una expresión Power Query que incluye un filtro de fecha y hora basado en los parámetros RangeStart y RangeEnd en el origen de datos. Si el filtro se especifica en un paso de consulta después de la consulta de origen inicial, es importante que el plegamiento de consultas combine el paso de consulta inicial con los pasos que hacen referencia a los parámetros RangeStart y RangeEnd. Por ejemplo, en la siguiente expresión de consulta, Table.SelectRows se plegará porque sigue inmediatamente el paso Sql.Database y SQL Server admite el plegamiento:

let
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data  = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
  #"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
  #"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))
  
in
  #"Filtered Rows1"

No es necesario que la consulta final admita el plegamiento. Por ejemplo, en la expresión siguiente, usamos NativeQuery sin plegar, pero integramos los parámetros RangeStart y RangeEnd directamente en SQL:

let
  Query = "select * from dbo.FactInternetSales where OrderDateKey >= '"& Text.From(Int32.From( DateTime.ToText(RangeStart,"yyyyMMdd") )) &"' and OrderDateKey < '"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ",
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false])
in
  Data

Sin embargo, si la directiva de actualización incremental incluye la obtención de datos en tiempo real con DirectQuery, no se pueden usar transformaciones no plegadas. Si se trata de una directiva de modo de importación pura sin datos en tiempo real, el motor de mashup de consultas podría compensar y aplicar el filtro localmente, lo que requiere recuperar todas las filas de la tabla desde el origen de datos. Esto puede hacer que la actualización incremental sea lenta y el proceso puede quedarse sin recursos en el servicio Power BI o en una puerta de enlace de datos local, lo que podría eliminar el propósito de la actualización incremental de manera eficaz.

Dado que la compatibilidad con el plegamiento de consultas es diferente para los distintos tipos de orígenes de datos, se debe realizar la comprobación para asegurarse de que la lógica de filtro esté incluida en las consultas que se ejecutan en el origen de datos. En la mayoría de los casos, Power BI Desktop intenta realizar esta comprobación automáticamente al definir la directiva de actualización incremental. En el caso de los orígenes de datos basados en SQL, como SQL Database, Azure Synapse, Oracle y Teradata, esta comprobación es confiable. Sin embargo, es posible que otros orígenes de datos no puedan ejecutar la comprobación sin realizar el seguimiento de las consultas. Si Power BI Desktop no puede confirmar las consultas, se muestra una advertencia en el cuadro de diálogo Configuración de directiva de actualización incremental.

Captura de pantalla de la advertencia de plegamiento de consultas

Si ve esta advertencia y desea comprobar que se realiza el plegamiento de consultas necesario, use la característica de diagnóstico de Power Query o haga un seguimiento de las consultas mediante una herramienta compatible con el origen de datos, como SQL Profiler. Si no se produce el plegamiento de consultas, compruebe que la lógica de filtro esté incluida en la consulta que se pasa al origen de datos. Si no es así, es probable que la consulta incluya una transformación que impide el plegado.

Antes de configurar la solución de actualización incremental, asegúrese de leer cuidadosamente y comprender los artículos Instrucciones de plegado de consultas en Power BI Desktop y Plegado de consultas de Power Query. Estos artículos pueden ayudarlo a determinar si el origen de datos y las consultas admiten el plegamiento de consultas.

Origen de datos único

Al configurar la actualización incremental y los datos en tiempo real mediante Power BI Desktop o al configurar una solución avanzada mediante Tabular Model Scripting Language (TMSL) o Tabular Object Model (TOM) a través del punto de conexión XMLA, todas las particiones, ya sean de importación o de DirectQuery, deben consultar datos de un único origen.

Otros tipos de origen de datos

Mediante el uso de más funciones de consulta personalizadas y lógica de consulta, la actualización incremental se puede usar con otros tipos de orígenes de datos si los filtros basados en RangeStart y RangeEnd se pueden pasar en una sola consulta, como con orígenes de datos como archivos de libro de Excel almacenados en una carpeta, archivos en SharePoint y fuentes RSS. Tenga en cuenta que se trata de escenarios avanzados que requieren una personalización adicional y pruebas que van más allá de lo que se describe en este artículo. Asegúrese de consultar la sección Comunidad que aparece más adelante en este artículo para obtener sugerencias sobre cómo puede encontrar más información acerca del uso de la actualización incremental para escenarios únicos.

Límites de tiempo

Independientemente de la actualización incremental, los modelos de Power BI Pro tienen un límite de tiempo de actualización de dos horas y no admiten la obtención de datos en tiempo real con DirectQuery. En el caso de los modelos en una capacidad Premium, el límite de tiempo es de cinco horas. Las operaciones de actualización consumen muchos procesos y memoria. Una operación de actualización completa puede usar hasta el doble de memoria que necesita solo el modelo, porque el servicio mantiene una instantánea del modelo en memoria hasta que se completa la operación de actualización. Las operaciones de actualización también pueden consumir muchos procesos, utilizando una cantidad significativa de recursos de CPU disponibles. Las operaciones de actualización también deben basarse en conexiones volátiles a orígenes de datos y en la capacidad que tienen esos sistemas de origen de datos para devolver rápidamente la salida de la consulta. El límite de tiempo es una medida de seguridad que permite limitar el consumo excesivo de los recursos disponibles.

Nota

Con las capacidades Premium, las operaciones de actualización realizadas a través del punto de conexión XMLA no tienen ningún límite de tiempo. Para más información, consulte Actualización incremental avanzada con el punto de conexión XMLA.

Dado que la actualización incremental optimiza las operaciones de actualización en el nivel de partición del modelo, el consumo de recursos puede disminuir significativamente. Al mismo tiempo, incluso con la actualización incremental, a menos que se realicen a través del punto de conexión XMLA, las operaciones de actualización están enlazadas por esos mismos límites de dos y cinco horas. Una directiva de actualización incremental eficaz no solo reduce la cantidad de datos procesados con una operación de actualización, sino que también disminuye la cantidad de datos históricos innecesarios que se almacenan en el modelo.

Las consultas también pueden verse limitadas por el límite de tiempo predeterminado del origen de datos. La mayoría de los orígenes de datos relacionales permiten invalidar los límites de tiempo en la expresión M de Power Query. Por ejemplo, en la expresión siguiente se usa la función de acceso a datos de SQL Server para establecer CommandTimeout en dos horas. Cada período definido por los intervalos de directiva envía una consulta que respeta el valor de tiempo de espera del comando.

let
    Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
    dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    #"Filtered Rows"

En el caso de modelos muy grandes en capacidades Premium que probablemente contengan miles de millones de filas, se 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 en ninguna de las particiones. Mediante el uso de SQL Server Management Studio, puede establecer las particiones para procesarse de manera individual, en secuencia o en paralelo, lo que puede reducir la cantidad de datos que devuelve una consulta única y también omitir el límite de tiempo de cinco horas. Para más información, consulte Actualización incremental avanzada: Prevención de tiempos de espera en la actualización completa inicial.

Fecha y hora actual

De forma predeterminada, la fecha y hora actuales se determinan en función de la hora universal coordinada (UTC) en el momento de la actualización. En el caso de las actualizaciones bajo demanda, programadas y de la API REST, puede configurar una zona horaria diferente en "Zona Horaria" que se tendrá en cuenta al determinar la fecha y hora actuales. Por ejemplo, en una actualización que se produce a las 20:00 con Hora del Pacífico (EE. UU. y Canadá) configurada como zona horaria, la fecha y hora actual se determinará según la hora del Pacífico, y no UTC, que, de otro modo, sería el día siguiente.

Captura de pantalla del cuadro de diálogo Actualización programada que muestra el campo de entrada zona horaria

Las operaciones de actualización no invocadas a través del servicio Power BI, como el comando de actualización de XMLA TMSL, no tienen en cuenta la configuración de zona horaria y el valor predeterminado es UTC.

Configuración de la actualización incremental y los datos en tiempo real

En esta sección se describen los conceptos importantes de configuración de la actualización incremental y los datos en tiempo real. Cuando tenga todo listo para obtener instrucciones paso a paso más detalladas, asegúrese de consultar Configuración de la actualización incremental y los datos en tiempo real.

La configuración de la actualización incremental se realiza en Power BI Desktop. Para la mayoría de los modelos, solo se requieren algunas tareas. Sin embargo, tenga presente los siguientes puntos:

  • Después de publicar en el servicio Power BI, no puede volver a publicar el mismo modelo desde Power BI Desktop. Volver a publicarlo quita las particiones y los datos existentes que ya están en el modelo. Si va a publicar en una capacidad Premium, se pueden realizar cambios posteriores en el esquema de metadatos con herramientas como ALM Toolkit de código abierto o mediante TMSL. Para más información, consulte Actualización incremental avanzada: Implementación de solo metadatos.
  • Después de publicar en el servicio Power BI, no se puede volver a descargar el modelo como .pbix en Power BI Desktop. Como los modelos del servicio pueden crecer tanto, no resulta práctico descargarlos y abrirlos en un equipo de escritorio típico.
  • Al obtener datos en tiempo real con DirectQuery, no puede publicar el modelo en un área de trabajo que no sea Premium. La actualización incremental con datos en tiempo real solo se admite con Power BI Premium.

Creación de parámetros

Al configurar la actualización incremental en Power BI Desktop, primero debe crear dos parámetros de fecha y hora de Power Query con los nombres reservados RangeStart y RangeEnd, que distinguen mayúsculas de minúsculas. Estos parámetros, que se definen en el cuadro de diálogo Administrar parámetros del Editor de Power Query, se usan inicialmente para filtrar los datos cargados en la tabla del modelo de Power BI Desktop a fin de incluir solo las filas con una fecha y hora dentro de ese período. RangeStart representa la fecha y hora más antiguas o tempranas, y RangeEnd representa la fecha y hora más recientes o tardías. Una vez que se publica el modelo en el servicio, el servicio reemplaza automáticamente los valores de RangeStart y RangeEnd para consultar los datos definidos por el período de actualización que se especifica en la configuración de la directiva de actualización incremental.

Por ejemplo, la tabla de origen de datos FactInternetSales promedia 10 000 filas nuevas al día. Para limitar el número de filas cargadas inicialmente en el modelo en Power BI Desktop, se especifica un período de dos días entre RangeStart y RangeEnd.

Captura de pantalla del cuadro de diálogo Administrar parámetros que muestra los parámetros RangeStart y RangeEnd

Filtrado de los datos

Con los parámetros RangeStart y RangeEnd definidos, se aplican filtros de fecha personalizados en la columna de fecha de la tabla. Los filtros que aplica seleccionan un subconjunto de datos que se cargarán en el modelo cuando seleccione Aplicar.

Captura de pantalla del menú contextual de columna con filtro personalizado seleccionado

Con nuestro ejemplo de FactInternetSales, después de crear filtros basados en los parámetros y aplicar los pasos correspondientes, se cargan dos días de datos (aproximadamente 20 000 filas) en el modelo.

Definición de directiva

Una vez que se aplican los filtros y se carga un subconjunto de datos en el modelo, se define una directiva de actualización incremental para la tabla. Una vez que se publica el modelo en el servicio, el servicio usa la directiva para crear y administrar particiones de tabla y realizar operaciones de actualización. Para definir la directiva, use el cuadro de diálogo Actualización incremental y datos en tiempo real para especificar la configuración necesaria y la configuración opcional.

Captura de pantalla del cuadro de diálogo Actualización incremental y datos en tiempo real en el que se muestra la opción Actualizar incrementalmente esta tabla

Tabla

El cuadro de lista Seleccionar tabla tiene como valor predeterminado la tabla que seleccionaste en la vista Tabla. Habilite la actualización incremental para la tabla con el control deslizante. Si la expresión de Power Query para la tabla no incluye un filtro basado en los parámetros RangeStart y RangeEnd significa que el botón de alternancia no está disponible.

Configuración requerida

La configuración Archivar datos a partir de antes de la actualización determina el período histórico en el que se incluyen en el modelo las filas con fecha y hora dentro de ese período, más las filas del período histórico incompleto actual, además de las filas del período de actualización hasta la fecha y hora actuales.

Por ejemplo, si especifica cinco años, la tabla almacena los últimos cinco años enteros de datos históricos en particiones de año. La tabla también incluirá filas para el año actual en particiones trimestrales, mes o día, hasta e incluido el período de actualización.

En el caso de los modelos en las capacidades Premium, las particiones históricas con fecha en el pasado se pueden actualizar selectivamente según una granularidad determinada por esta configuración. Para más información, consulte Actualización incremental avanzada: Particiones.

La configuración Actualizar los datos incrementalmente a partir de antes de la fecha de actualización determina el período de actualización incremental en el que todas las filas con una fecha y hora en ese período se incluyen en las particiones de actualización y se actualizan con cada operación de actualización.

Por ejemplo, si especificamos un período de actualización de 3 días, con cada operación de actualización, el servicio invalida los parámetros RangeStart y RangeEnd para crear una consulta para filas con una fecha y hora dentro de un período de tres días, con inicio y finalización según la fecha y hora actuales. Se actualizan las filas con una fecha y hora en los últimos tres días hasta la hora de la operación de actualización actual. Con este tipo de directiva, podemos esperar que nuestra tabla de modelo FactInternetSales del servicio, que promedia 10 000 filas nuevas al día, actualice aproximadamente 30 000 filas con cada operación de actualización.

Especifique un período que incluya solo el número mínimo de filas necesarias para garantizar la precisión de los informes. Cuando se definen directivas para más de una tabla, se deben usar los mismos parámetros RangeStart y RangeEnd, aunque se definan distintos períodos de almacenamiento y actualización para cada tabla.

Configuración opcional

La opción Obtenga los datos más recientes en tiempo real con DirectQuery (sólo Premium) permite capturar los cambios más recientes de la tabla seleccionada en el origen de datos más allá del período de actualización incremental mediante DirectQuery. Todas las filas con una fecha y hora posteriores al período de actualización incremental se incluyen en una partición de DirectQuery y se capturan del origen de datos con cada consulta del modelo.

Por ejemplo, si esta configuración está habilitada, con cada operación de actualización, el servicio sigue invalidando los parámetros RangeStart y RangeEnd para crear una consulta para filas con una fecha y hora posteriores al período de actualización, con el inicio dependiendo de la fecha y hora actuales. También se incluyen las filas con una fecha y hora después de la hora actual de la operación de actualización. Con este tipo de directiva, la tabla de modelo FactInternetSales del servicio incluye las actualizaciones de datos más recientes.

La opción Actualizar solo días completos garantiza que todas las filas de todo el día se incluyan en la operación de actualización. Esta opción es opcional a menos que habilite la opción Obtenga los datos más recientes en tiempo real con DirectQuery (sólo Premium). Por ejemplo, supongamos nuestra actualización está programada para ejecutarse todas las mañanas a las 4:00 h. Si aparecen filas de datos nuevas en la tabla de origen de datos durante esas cuatro horas entre la medianoche y las 04:00 a.m., no tendrá en cuenta estas filas. Algunas métricas empresariales (como, por ejemplo, los barriles por día en el sector petrolífero) no tienen sentido en días parciales. Pensemos en otro ejemplo en el que hay que actualizar los datos de un sistema financiero donde los datos del mes anterior se aprueban el día doce del mes en curso. Puede establecer el período de actualización en un mes y programar la actualización para que se ejecute el día doce del mes. Así, con esta opción activada, los datos de enero se actualizarían el 12 de febrero.

Tenga en cuenta que, a menos que la zona horaria de "Actualizar" esté configurada para una no UTC, las operaciones de actualización en el servicio se ejecutan en hora UTC, lo que puede determinar la fecha efectiva y los períodos completos.

La opción Detectar cambios de datos permite una actualización aún más selectiva. Puede seleccionar una columna de fecha y hora y usarla para actualizar solo los días en que los datos han cambiado. Esta configuración da por hecho que esta columna existe en el origen de datos, que se suele usar con fines de auditoría. Esta columna no debe ser la misma que se usa para particionar los datos con los parámetros RangeStart y RangeEnd. El valor máximo de esta columna se evalúa para cada uno de los períodos en la frecuencia incremental. Si no ha cambiado desde la última actualización, no es necesario actualizar el período, lo que podría reducir aún más los días actualizado incrementalmente de tres a uno.

El diseño actual requiere que la columna que detecta los cambios de datos sea persistente y esté almacenada en la memoria caché. Se pueden usar las técnicas siguientes para reducir la cardinalidad y el consumo de memoria:

  • Durante la actualización, solo debe persistir el valor máximo de la columna, posiblemente usando una función de Power Query.
  • Reduzca la precisión a un nivel que sea aceptable en virtud de sus requisitos de frecuencia de actualización.
  • Defina una consulta personalizada para detectar los cambios en los datos mediante el punto de conexión de XMLA y evitar que el valor de la columna se conserve por completo.

En algunos casos, se puede mejorar aún más la habilitación de la opción Detectar cambios de datos. Por ejemplo, es posible que quiera evitar que se conserve la columna de última actualización en la caché en memoria, o bien habilitar escenarios en los que los procesos de Extracción, transformación y carga de datos (ETL) preparan una tabla de configuración o instrucción para así marcar solo las particiones que se deben actualizar. En este tipo de casos, para las capacidades Premium, use TMSL o TOM para invalidar el comportamiento de detección de cambios de datos. Para más información, consulte Actualización incremental avanzada: Consultas personalizadas para detectar cambios de datos.

Publicar

Después de configurar la directiva de actualización incremental, puede publicar el modelo en el servicio. Una vez que se completa la publicación, puede realizar la operación de actualización inicial en el modelo.

Nota

Los modelos semánticos que tengan una directiva de actualización incremental para obtener los datos más recientes en tiempo real con DirectQuery solo se pueden publicar en un área de trabajo Premium.

En el caso de los modelos publicados en áreas de trabajo asignadas a capacidades Premium, si cree que el modelo crecerá a más de 1 GB, 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 al habilitar la configuración de formato de almacenamiento de modelos semánticos 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.

Importante

Después de Power BI Desktop publique el modelo en el servicio, no se puede volver a descargar .pbix.

Actualizar

Después de publicar en el servicio, se debe realizar una operación de actualización inicial en el modelo. Esta actualización debe ser una actualización individual (manual) para que pueda supervisar el progreso. La operación de actualización inicial puede tardar bastante tiempo en completarse. Se deben crear particiones, cargar datos históricos, crear o volver a crear objetos como relaciones y jerarquías, y volver a calcular los objetos calculados.

Las operaciones de actualización posteriores, ya sean individuales o programadas, son mucho más rápidas porque solo se actualizan las particiones de actualización incremental. De todos modos deben producirse otras operaciones de procesamiento, como la combinación de particiones y el recálculo, pero suele tardar mucho menos tiempo en comparación con la actualización inicial.

Actualización automática de informes

En el caso de los informes que usan un modelo con una directiva de actualización incremental para obtener los datos más recientes en tiempo real con DirectQuery, es una buena idea habilitar la actualización automática de páginas a un intervalo fijo o en función de la detección de cambios para que los informes incluyan los datos más recientes sin retraso. Para más información, consulte Actualización automática de páginas en Power BI.

Actualización incremental avanzada

Si el modelo está en una capacidad Premium con el punto de conexión XMLA habilitado, la actualización incremental se puede ampliar aún más para escenarios avanzados. Por ejemplo, puede usar SQL Server Management Studio para ver y administrar particiones, arrancar la operación de actualización inicial o actualizar particiones históricas con fecha en el pasado. Para más información, consulte Actualización incremental avanzada con el punto de conexión XMLA.

Comunidad

Power BI tiene una comunidad dinámica donde MVP, profesionales de BI y colegas comparten sus experiencias en grupos de debate, vídeos, blogs, entre otros. Cuando esté aprendiendo sobre la actualización incremental, consulte estos recursos adicionales:

Contenido relacionado