Actualización incremental avanzada con el punto de conexión XMLA

Los conjuntos de datos en una capacidad Premium con el punto de conexión XMLA habilitado para operaciones de lectura y escritura permiten implementaciones más avanzadas de actualización de conjuntos de datos, administración de particiones y metadatos mediante herramientas, scripting y compatibilidad con API. Además, las operaciones de actualización a través del punto de conexión de XMLA no se limitan a 48 actualizaciones al día, y no se impone el tiempo límite de actualización programado.

Particiones

Las particiones de tabla del conjunto de datos no son visibles y no se pueden administrar en el servicio. En el caso de los conjuntos de datos de un área de trabajo asignada a una capacidad Premium, las particiones se pueden administrar a través del punto de conexión XMLA mediante herramientas como SQL Server Management Studio (SSMS), Tabular Editor de código abierto, con scripts con Tabular Model Scripting Language (TMSL) y mediante programación con el Modelo de objetos tabulares (TOM).

La primera vez que publica un modelo en el servicio, cada tabla del conjunto de datos nuevo tiene una partición. En el caso de las tablas que no tienen una directiva de actualización incremental, esa partición única contiene todas las filas de datos para esa tabla (a menos que se hayan aplicado filtros). En el caso de las tablas que tienen una directiva de actualización incremental, esa partición única contendrá solo las filas de datos definidas por el filtro de intervalo de fecha y hora según los parámetros RangeStart y RangeEnd, y cualquier otro filtro aplicado en el Editor de Power Query.

Al realizar la primera operación de actualización del conjunto de datos, las tablas que no tienen una directiva de actualización incremental actualizarán todas las filas contenidas en la partición única predeterminada de esa tabla. En el caso de las tablas que tienen una directiva de actualización incremental, se crean automáticamente particiones históricas y de actualización y las filas se cargan en ellas según la fecha y hora de cada fila.

Esta primera operación de actualización puede tardar bastante tiempo en virtud de la cantidad de datos que se deben cargar desde el origen de datos. La complejidad del modelo también puede ser un factor importante, porque las operaciones de actualización deben realizar un procesamiento y un recálculo adicionales. Esta operación se puede arrancar. Para más información, consulte Prevención de tiempos de espera en la actualización completa inicial que aparece más adelante en este artículo.

Las particiones se crean y nombran por granularidad de período: años, trimestres, meses y días. Las particiones más recientes, las particiones de actualización, contienen filas en el período de actualización que se especifica en la directiva. Las particiones históricas contienen filas por período completo hasta el período de actualización. La granularidad de las particiones históricas y de actualización depende de los períodos de actualización e históricos (almacén) que elige al definir la directiva.

Por ejemplo, si la fecha de hoy es 2 de febrero de 2021 y la tabla FactInternetSales del origen de datos contiene filas hasta hoy, si la directiva especifica las filas de actualización en el último día (período de actualización) y almacena las filas de los últimos tres años (período histórico), con la primera operación de actualización se crea una partición para las filas actuales, una partición histórica para ayer, un período de un día completo (1 de febrero de 2021), una partición histórica para el período anterior de mes completo (enero de 2021), una partición histórica para el período anterior de año completo (2020) y particiones históricas para los períodos de año completo de 2019 y 2018. No se crean particiones de trimestre completo porque todavía no completamos el primer trimestre completo de 2021.

Con cada operación de actualización, solo se actualizan las particiones del período de actualización. Se crea una partición para las filas nuevas con una fecha y hora nueva, y se actualizan las filas existentes con una fecha y hora que ya están dentro de las particiones existentes en el período de actualización. Las filas con fecha y hora anteriores al período de actualización ya no se actualizan.

A medida que se cierran períodos completos, se combinan las particiones. Por ejemplo, si en la directiva se especifica un período de actualización de un día y un período de almacenamiento histórico de tres años, el primer día del mes, todas las particiones de día del mes anterior se combinan en una partición de mes. El primer día de un trimestre nuevo, las tres particiones del mes anterior se combinan en una partición de trimestre. El primer día de un año nuevo, las cuatro particiones del trimestre anterior se combinan en una partición de año.

Un conjunto de datos siempre conserva las particiones durante todo el período de almacenamiento histórico más las particiones de período completo hasta el período de actualización actual. Con el ejemplo anterior, se conservan tres años completos de datos históricos en particiones para 2018, 2019, 2020 y también particiones para el período de mes 2021Q101, el período de días 2021Q10201 y la partición del período de actualización del día actual. Dado que elegimos conservar los datos históricos durante tres años, la partición de 2018 se conserva hasta la primera actualización, el 1 de enero de 2022.

Con la actualización incremental de Power BI, el servicio controla automáticamente la administración de particiones en función de la directiva. Si alguna vez trabajó en Analysis Services, sabe que la creación de particiones eficaz implica crear una solución mediante programación, a menudo con miles de líneas de código. Aunque el servicio puede controlar toda la administración de particiones de forma automática, el uso de herramientas mediante el punto de conexión XMLA permite actualizar selectivamente las particiones de manera individual, secuencial o en paralelo.

Actualización de la administración con SQL Server Management Studio (SSMS)

Se puede usar SSMS para ver y administrar las particiones creadas por la aplicación de directivas de actualización incremental. Al usar SSMS puede, por ejemplo, actualizar una partición histórica específica que no se encuentra en el período de actualización incremental para realizar una actualización con fecha en el pasado sin tener que actualizar todos los datos históricos. También se puede usar SSMS en el arranque a fin de cargar datos históricos para conjuntos de datos grandes mediante la incorporación o actualización incremental de particiones históricas en lotes.

Reemplazo del comportamiento de actualización incremental

Con SSMS, también tiene más control sobre cómo invocar las actualizaciones mediante Tabular Model Scripting Language (TMSL) y el Modelo de objetos tabulares (TOM). Por ejemplo, en SSMS, en el Explorador de objetos, haga clic con el botón derecho en una tabla y, a continuación, seleccione la opción de menú Procesar tabla y, luego, haga clic en el botón Script para generar un comando de actualización de TMSL.

Estos parámetros se pueden usar con el comando de actualización de TMSL para invalidar el comportamiento predeterminado de la actualización incremental:

• applyRefreshPolicy: si una tabla tiene definida una directiva de actualización incremental, applyRefreshPolicy determinará si la directiva se aplica o no. Si no se aplica la directiva, una operación de proceso completo dejará las definiciones de partición sin cambios y todas las particiones de la tabla se actualizarán por completo. El valor predeterminado es true.

• effectiveDate: si se está aplicando una directiva de actualización incremental, debe conocer la fecha actual para determinar los intervalos de ventana de desplazamiento para los períodos históricos y de actualización incremental. El parámetro effectiveDate permite invalidar la fecha actual. Este parámetro es útil para pruebas, demostraciones y escenarios empresariales en los que los datos se actualizan incrementalmente hasta una fecha anterior o posterior (por ejemplo, presupuestos futuros). El valor predeterminado es la fecha actual.

{ 
  "refresh": {
    "type": "full",

    "applyRefreshPolicy": true,
    "effectiveDate": "12/31/2013",

    "objects": [
      {
        "database": "IR_AdventureWorks", 
        "table": "FactInternetSales" 
      }
    ]
  }
}

Para obtener más información sobre cómo invalidar el comportamiento predeterminado de la actualización incremental con TMSL, vea comando Refresh.

Garantía de un rendimiento óptimo

Con cada operación de actualización, el servicio Power BI puede enviar consultas de inicialización al origen de datos para cada partición de actualización incremental. Se podrá mejorar el rendimiento de la actualización incremental reduciendo el número de consultas de inicialización, garantizando lo siguiente:

• La tabla para la que configura la actualización incremental debe obtener datos de un único origen de datos. Si la tabla obtiene datos de más de un origen de datos, el número de consultas que envía el servicio para cada operación de actualización se multiplica por el número de orígenes de datos, lo que puede reducir el rendimiento de la actualización. Asegúrese de que la consulta de la tabla de actualización incremental se realiza para un único origen de datos.
• Si los requisitos de seguridad lo permiten, establezca la opción Data source privacy level (Nivel de privacidad del origen de datos) en Organizativo o Público. De forma predeterminada, el nivel de privacidad es Privado; sin embargo, este nivel puede impedir que los datos se intercambien con otros orígenes en la nube. Establezca el nivel de privacidad en Configuración del conjunto de datos > Credenciales del origen de datos > Editar credenciales > Privacy level setting for this datasource (Configuración del nivel de privacidad para este origen de datos). Si se establece el nivel de privacidad en el modelo de Power BI Desktop antes de publicarlo en el servicio, este no se transfiere al servicio cuando se publica. Todavía deberá establecerlo en la configuración del conjunto de datos en el servicio. Para obtener más información, vea Niveles de privacidad.
• Si se usa una puerta de enlace de datos local, asegúrese de que usa la versión 3000.77.3 o una posterior.

Prevención de tiempos de espera en la actualización completa inicial

Después de publicar en el servicio, la operación de actualización completa inicial del conjunto de datos crea particiones para la tabla de actualización incremental, carga y procesa los datos históricos de todo el período definido en la directiva de actualización incremental. Para algunos conjuntos de datos que cargarán y procesarán grandes cantidades de datos, la cantidad de tiempo que tarda la operación de actualización inicial puede superar el límite de tiempo de actualización que impone el servicio o un límite de tiempo de consulta que impone el origen de datos.

El arranque de la operación de actualización inicial permite al servicio crear objetos de partición para la tabla de actualización incremental, pero no cargar ni procesar datos históricos en ninguna de las particiones. Después, se usa SSMS para procesar las particiones de manera selectiva. En función de la cantidad de datos que se carguen para cada partición, puede procesar cada partición de manera secuencial o en lotes pequeños, a fin de reducir la posibilidad de que una o varias de esas particiones causen un tiempo de espera. Los métodos siguientes funcionan para cualquier origen de datos.

Aplicar directiva de actualización

La herramienta Tabular Editor 2 de código abierto proporciona una manera sencilla de arrancar una operación de actualización inicial. Después de publicar en el servicio un modelo con una directiva de actualización incremental definida para él desde Power BI Desktop, conéctese al conjunto de datos mediante el punto de conexión XMLA en modo de lectura y escritura. Ejecute Aplicar directiva de actualización en la tabla de actualización incremental. Con solo la directiva aplicada, se crean particiones, pero no se cargan datos en ellas. Después, conéctese a SSMS para actualizar las particiones de forma secuencial o en lotes para cargar y procesar los datos. Para obtener más información, vea Actualización incremental en la documentación de Tabular Editor.

Filtro de Power Query para particiones vacías

Antes de publicar el modelo en el servicio, en el Editor de Power Query, agregue otro filtro a la columna ProductKey que filtre cualquier valor distinto de 0, de forma eficaz o filtrando todos los datos de la tabla FactInternetSales.

Después de hacer clic en Cerrar y aplicar en el Editor de Power Query, de definir la directiva de actualización incremental y de guardar el modelo, se publicará en el servicio. Desde el servicio, se ejecuta la operación de actualización inicial en el conjunto de datos. Las particiones de la tabla FactInternetSales se crean según la directiva, pero no se cargan ni procesan datos, porque todos se han filtrado.

Una vez que se completa la operación de actualización inicial, de nuevo en el Editor de Power Query, se quita el filtro adicional de la columna ProductKey. Después de hacer clic en Cerrar y aplicar en el Editor de Power Query, y de guardar el modelo, no se vuelve a publicar. Si el modelo se volviera a publicar, sobrescribiría la configuración de la directiva de actualización incremental y forzaría una actualización completa del conjunto de datos cuando se realizara una operación de actualización posterior desde el servicio. En su lugar, se realiza una implementación de solo metadatos mediante ALM Toolkit, que quita el filtro de la columna ProductKey del conjunto de datos. Después, se puede usar SSMS para procesar las particiones de manera selectiva. Una vez que todas las particiones se procesan completamente (lo que debe incluir un recálculo del proceso en todas las particiones) desde SSMS, las operaciones de actualización posteriores en el conjunto de datos desde el servicio solo actualizan las particiones de actualización incremental.

Para más información sobre el procesamiento de tablas y particiones de SSMS, consulte Procesamiento de bases de datos, tablas o particiones (Analysis Services). Para más información sobre el procesamiento de conjuntos de datos, tablas y particiones mediante TMSL, consulte Comando de actualización (TMSL).

Personalización de consultas para detectar cambios de datos

Se puede usar TMSL o TOM para invalidar el comportamiento de los cambios de datos detectados. Este método se puede usar no solo para evitar que se conserve la columna de última actualización en caché, sino que puede habilitar escenarios en los que los procesos de ETL preparan una tabla de configuración o instrucción con el fin de marcar solo las particiones que se deben actualizar. Este método puede crear un proceso de actualización incremental más eficaz donde solo se actualicen los períodos necesarios, con independencia del tiempo transcurrido desde las actualizaciones de datos.

La expresión pollingExpression está diseñada para ser una expresión M ligera o el nombre de otra consulta M. Debe devolver un valor escalar y se ejecutará para cada partición. Si el valor devuelto es diferente al de la última vez que se produjo una actualización incremental, la partición se marca para su procesamiento completo.

En el ejemplo siguiente se abarcan los 120 meses del período histórico para los cambios con fecha en el pasado. Si se especifican 120 meses en lugar de 10 años, es posible que la compresión de los datos no sea tan eficaz, pero se evita tener que actualizar un año histórico completo (lo que sería más caro cuando fuera suficiente un mes para un cambio con fecha en el pasado).

"refreshPolicy": {
    "policyType": "basic",
    "rollingWindowGranularity": "month",
    "rollingWindowPeriods": 120,
    "incrementalGranularity": "month",
    "incrementalPeriods": 120,
    "pollingExpression": "<M expression or name of custom polling query>",
    "sourceExpression": [
    "let ..."
    ]
}

Implementación de solo metadatos

Al publicar una versión nueva de un archivo PBIX desde Power BI Desktop en un área de trabajo, si ya existe un conjunto de datos con el mismo nombre, se le pedirá que reemplace el conjunto de datos existente.

En algunos casos, es posible que no quiera reemplazar el conjunto de datos, especialmente con la actualización incremental. El conjunto de datos de Power BI Desktop podría ser mucho menor que el del servicio. Si el conjunto de datos del servicio tiene aplicada una directiva de actualización incremental, puede tener varios años de datos históricos que se perderán si el conjunto de datos se reemplaza. La actualización de todos los datos históricos podría tardar horas y provocar un tiempo de inactividad del sistema para los usuarios.

En su lugar, es mejor realizar una implementación solo de metadatos, lo que permite la implementación de nuevos objetos sin perder los datos históricos. Por ejemplo, si agregó algunas medidas, puede implementar solo las medidas nuevas sin necesidad de actualizar los datos, lo que ahorra mucho tiempo.

En el caso de las áreas de trabajo asignadas a una capacidad Premium configurada para lectura y escritura de puntos de conexión XMLA, las herramientas compatibles permiten la implementación de solo metadatos. Por ejemplo, ALM Toolkit es una herramienta de comparación de esquemas para los conjuntos de datos de Power BI y se puede usar para realizar la implementación solo de metadatos.

Descargue e instale la versión más reciente de ALM Toolkit desde el repositorio de Git de Analysis Services. La guía paso a paso sobre el uso de ALM Toolkit no está incluida en la documentación de Microsoft. Los vínculos de documentación de ALM Toolkit y la información sobre la compatibilidad están disponibles a través de la cinta de opciones de ayuda. Para realizar una implementación de solo metadatos, realice una comparación y seleccione la instancia de Power BI Desktop en ejecución como origen y el conjunto de datos existente en el servicio como destino. Tenga en cuenta las diferencias que se muestran y omita la actualización de la tabla con particiones de actualización incremental, o use el cuadro de diálogo Opciones para conservar las particiones para las actualizaciones de la tabla. Valide la selección para garantizar la integridad del modelo de destino y, a continuación, actualice.

Vea también

Particiones en modelos tabulares
Herramientas externas para Power BI
Configuración de actualización programada
Solución e problemas de la actualización incremental