Compartir a través de

Descripción y optimización de la actualización de flujos de datos

  • Artículo

Los flujos de datos de Power BI permiten conectar, transformar, combinar y distribuir datos para un análisis descendente. Un aspecto clave de los flujos de datos es el proceso de actualización, que aplica los pasos de transformación creados en los flujos de datos y actualiza los datos de los propios elementos.

Para comprender los tiempos de ejecución, el rendimiento y si va a aprovechar al máximo el flujo de datos, puede descargar el historial de actualización tras haber actualizado un flujo de datos.

Descripción de las actualizaciones

Hay dos tipos de actualizaciones aplicables a los flujos de datos:

  • Completa, que realiza un vaciado completo y una recarga de los datos.

  • Incremental (solo Premium) , que procesa un subconjunto de los datos en función de las reglas basadas en el tiempo, expresadas como un filtro, que haya configurado. El filtro de la columna de fecha se usa particiona de forma dinámica los datos en intervalos en el servicio Power BI. Una vez configurada la actualización incremental, el flujo de datos modifica automáticamente la consulta para incluir el filtrado por fecha. Puede editar la consulta generada automáticamente mediante el Editor avanzado de Power Query para ajustar o personalizar la actualización. Si aporta su propia instancia de Azure Data Lake Storage, puede ver los intervalos de tiempo de los datos en función de la directiva de actualización que haya establecido.

    Nota

    Para más información sobre la actualización incremental y cómo funciona, consulte Uso de la actualización incremental con flujos de datos.

La actualización incremental permite flujos de datos de gran tamaño en Power BI, lo que ofrece las siguientes ventajas:

  • Las actualizaciones son más rápidas después de la primera actualización debido a los siguientes hechos:

    • Power BI actualiza las últimas N particiones especificadas por el usuario (donde partición es día, semana, mes, etc.), o bien:
    • Power BI solo actualiza los datos que sea necesario actualizar. Por ejemplo, se actualizarán solo los últimos cinco días de un modelo semántico de diez años.
    • Power BI solo actualiza los datos que han cambiado, siempre y cuando especifique la columna cuyos cambios quiere comprobar.

  • Las actualizaciones son más confiables: ya no es necesario mantener conexiones de larga duración a sistemas de origen volátiles.

  • Se reduce el consumo de recursos: al haber menos datos que actualizar, se reduce el consumo total de memoria y de otros recursos.

  • Siempre que sea posible, Power BI emplea el procesamiento paralelo en las particiones, lo que puede dar lugar a actualizaciones más rápidas.

En cualquiera de estos escenarios de actualización, si se produce un error en una actualización, los datos no se actualizan. Los datos pueden estar obsoletos hasta que se complete la actualización más reciente, o bien puede actualizarlos manualmente hasta que la operación finalice sin errores. La actualización se produce en una partición o una entidad, por lo que, si se produce un error en una actualización incremental o una entidad tiene un error, no se producirá la transacción de la actualización completa. Dicho de otro modo, si se produce un error en una partición (directiva de actualización incremental) o en una entidad de un flujo de datos, la operación de actualización completa produce un error y no se actualiza ningún dato.

Descripción y optimización de las actualizaciones

Para comprender mejor cómo funciona una operación de actualización de flujo de datos, revise el historial de actualización de uno de sus flujos de datos. Seleccione Más opciones (...) en el flujo de datos. A continuación, elija Configuración > Historial de actualización. También puede seleccionar el flujo de datos en Área de trabajo. A continuación, elija Más opciones (...) > Historial de actualización.

Screenshot of dataflows refresh history.

El historial de actualización proporciona una visión general de las actualizaciones, incluido el tipo (a petición o programada), la duración y el estado de ejecución. Para ver los detalles en forma de archivo CSV, seleccione el icono de descarga situado en el extremo derecho de la fila de la descripción de la actualización. El CSV descargado incluye los atributos descritos en la tabla siguiente. Las actualizaciones Premium proporcionan más información basada en las capacidades adicionales de proceso y flujo de datos, frente a los flujos de datos basados en Pro que residen en la capacidad compartida. Por tanto, algunas de las siguientes métricas solo están disponibles en la versión Premium.

Elemento Descripción Pro Premium
Solicitud realizada el La actualización de tiempo se programó o se hizo clic en Actualizar ahora, en hora local. ✔ ✔
Nombre del flujo de datos Nombre del flujo de datos. ✔ ✔
Estado de actualización de flujo de datos Los estados posibles son Completado, Error u Omitido (para una entidad). Los casos de uso como las entidades vinculadas son los motivos por los que se podrían omitir. ✔ ✔
Nombre de entidad Nombre de la tabla. ✔ ✔
Nombre de la partición Este elemento depende de si el flujo de datos es o no Premium, y si Pro se muestra como N/D porque no admite actualizaciones incrementales. Premium muestra FullRefreshPolicyPartition o IncrementalRefreshPolicyPartition-[DateRange]. ✔
Estado de actualización Estado de actualización de la entidad o partición individual, que proporciona el estado de ese intervalo de tiempo de los datos que se están actualizando. ✔ ✔
Hora de inicio En Premium, este elemento es el momento en el que el flujo de datos se puso en cola para procesarse para la entidad o partición. Este tiempo puede variar si los flujos de datos tienen dependencias y deben esperar a que el conjunto de resultados de un flujo de datos de nivel superior comience a procesarse. ✔ ✔
Hora de finalización El tiempo de finalización es el momento en el que se completa la entidad de flujo de datos o la partición, si procede. ✔ ✔
Duration Tiempo total transcurrido para que se actualice el flujo de datos expresado en HH:MM:SS. ✔ ✔
Filas procesadas Para una entidad o partición determinada, corresponde al número de filas examinadas o escritas por el motor de flujo de datos. Es posible que este elemento no siempre contenga datos en función de la operación que haya realizado. Los datos se pueden omitir cuando no se usa el motor de proceso o cuando se usa una puerta de enlace a medida que los datos se procesan allí. ✔
Bytes procesados Para una entidad o partición determinada, son los datos escritos por el motor de flujo de datos, expresados en bytes.

Si se usa una puerta de enlace en este flujo de datos concreto, no se proporciona esta información.		 ✔
Confirmación máxima (en KB) La confirmación máxima es la memoria de confirmación máxima útil para diagnosticar errores de memoria insuficiente cuando la consulta M no está optimizada.

Si se usa una puerta de enlace en este flujo de datos concreto, no se proporciona esta información.		 ✔
Tiempo de procesador Para una entidad o partición determinada, corresponde al tiempo, expresado en HH:MM:SS, que el motor de flujo de datos dedicó a realizar transformaciones.

Si se usa una puerta de enlace en este flujo de datos concreto, no se proporciona esta información.		 ✔
Tiempo de espera Para una entidad o partición determinada, corresponde al tiempo que dedicó una entidad en estado de espera, según la carga de trabajo de la capacidad Premium. ✔
Motor de proceso Para una entidad o partición determinada, los detalles sobre cómo la operación de actualización usa el motor de proceso. Los valores son:
- N/D
- Plegado
- En caché
- En caché y plegado

Estos elementos se describen con más detalle posteriormente en este artículo.		 ✔
Error Si procede, se describe el mensaje de error detallado por entidad o partición. ✔ ✔

Guía de actualización de flujo de datos

Las estadísticas de actualización proporcionan información valiosa que puede usar para optimizar y acelerar el rendimiento de los flujos de datos. En las secciones siguientes, se describen algunos escenarios, qué se debe supervisar y cómo optimizar en función de la información proporcionada.

Orquestación

El uso de flujos de trabajo en la misma área de trabajo permite una orquestación sencilla. Por ejemplo, podría tener flujos de datos A, B y C en una sola área de trabajo, encadenados como A > B > C. Si actualiza el origen (A), las entidades de nivel inferior también se actualizan. Sin embargo, si actualiza C, tiene que actualizar los otros de manera independiente. Además, si agrega un nuevo origen de datos en el flujo de datos B (que no se incluye en A), los datos no se actualizan como parte de la orquestación.

Es posible que quiera encadenar elementos que no se ajusten a la orquestación administrada que realiza Power BI. En estos escenarios, puede usar las API o Power Automate. Puede consultar la documentación de la API y el script de PowerShell para la actualización mediante programación. Hay un conector para Power Automate que permite este procedimiento sin necesidad de escribir código. Puede ver ejemplos detallados, con tutoriales específicos para las actualizaciones secuenciales.

Supervisión

Con las estadísticas de actualización mejorada descritas anteriormente en este artículo, puede obtener información detallada sobre la actualización de flujo de datos. Pero si quiere ver flujos de datos con información general de todo el inquilino o de toda el área de trabajo de las actualizaciones, quizás para compilar un panel de supervisión, puede usar las API o las plantillas de PowerAutomate. Del mismo modo, para casos de uso como el envío de notificaciones simples o complejas, puede usar el conector de PowerAutomate o crear su propia aplicación personalizada mediante las API.

Errores de tiempo de espera agotado

Es conveniente optimizar el tiempo necesario para ejecutar escenarios de extracción, transformación y carga (ETL). En Power BI, se aplican los siguientes casos:

  • Algunos conectores tienen valores de tiempo de espera explícitos que se pueden configurar. Para más información, consulte Conectores en Power Query.
  • Cuando se utiliza Power BI Pro, los flujos de datos de Power BI pueden experimentar también tiempos de espera para las consultas de larga duración dentro de una entidad o de los propios flujos de datos. Esta limitación no existe en las áreas de trabajo de Power BI Premium.

Guía de tiempo de espera

Los umbrales de tiempo de espera de los flujos de datos de Power BI Pro son los siguientes:

  • Dos horas en el nivel de entidad individual.
  • Tres horas en el nivel de flujo de datos completo.

Por ejemplo, si tiene un flujo de trabajo con tres tablas, ninguna tabla individual puede tardar más de dos horas, y el flujo de trabajo completo agotará el tiempo de espera si la duración supera las tres horas.

Si experimenta tiempos de espera, considere la posibilidad de optimizar las consultas de flujo de datos y usar el plegado de consultas en los sistemas de origen.

Por otra parte, también podría actualizar a Premium por usuario, que no está sujeto a estos tiempos de espera y ofrece un mayor rendimiento debido a la gran cantidad de características Premium por usuario de Power BI.

Duraciones prolongadas

Los flujos de datos complejos o grandes pueden tardar más tiempo en actualizarse, al igual que los flujos de datos con una optimización deficiente. En las secciones siguientes se proporcionan instrucciones sobre cómo mitigar las duraciones de actualización prolongadas.

Guía para las duraciones de actualización prolongadas

El primer paso para mejorar las duraciones de actualizaciones prolongadas de los flujos de datos es crear flujos de datos siguiendo los procedimientos recomendados. Entre los patrones destacables se incluyen:

Después, puede ayudar a evaluar si se le permite usar la actualización incremental.

El uso de la actualización incremental puede mejorar el rendimiento. Es importante que los filtros de partición se inserten en el sistema de origen cuando las consultas se envían para las operaciones de actualización. El filtrado de inserción descendente indica que el origen de datos debe admitir el plegado de consultas, o bien usted puede expresar la lógica empresarial con una función u otros medios que puedan ayudar a Power Query a eliminar y filtrar archivos o carpetas. La mayoría de los orígenes de datos que admiten consultas SQL admiten el plegado de consultas y algunas fuentes de OData también pueden admitir el filtrado.

Sin embargo, los orígenes de datos, como archivos planos, blobs y API, normalmente no admiten el filtrado. En los casos en los que el back-end del origen de datos no admite el filtro, no se puede insertar. En tales casos, el motor mashup compensa y aplica el filtro localmente, lo que puede requerir la recuperación del modelo semántico completo del origen de datos. Esta operación puede provocar que una actualización incremental sea lenta, y el proceso puede quedarse sin recursos en el servicio Power BI o en la puerta de enlace de datos local, si se usa.

Dados los diversos niveles de compatibilidad con el plegado de consultas para cada origen de datos, debería comprobar que la lógica de filtro se incluye en las consultas de origen. Para facilitar esta tarea, Power BI intenta realizar esta comprobación de forma automática mediante indicadores de plegado de paso para Power Query Online. Muchas de estas optimizaciones son experiencias en tiempo de diseño, pero, tras una actualización, tiene la oportunidad de analizar y optimizar el rendimiento de la actualización.

Por último, considere la posibilidad de optimizar el entorno. Puede optimizar el entorno de Power BI escalando verticalmente la capacidad, ajustando el tamaño de las puertas de enlace de datos y reduciendo la latencia de red con las siguientes optimizaciones:

  • Al usar las capacidades disponibles con Power BI Premium o Premium por usuario, puede mejorar el rendimiento aumentando la instancia Premium o asignando el contenido a otra capacidad.

  • Se precisa una puerta de enlace cuando Power BI necesita acceder a los datos que no están disponibles directamente a través de Internet. Puede instalar la puerta de enlace de datos local en un servidor local o en una máquina virtual.

    • Para comprender las cargas de trabajo de puerta de enlace y las recomendaciones de ajuste de tamaño, vea Ajuste de tamaño de la puerta de enlace de datos local.
    • Valore también incorporar primero los datos en un flujo de datos de almacenamiento provisional y hacer referencia a él mediante entidades vinculadas y calculadas.

  • La latencia de red puede afectar al rendimiento de las actualizaciones si se aumenta el tiempo necesario para que las solicitudes lleguen al servicio Power BI y para la entrega de las respuestas. Los inquilinos de Power BI se asignan a una región específica. Para determinar dónde se encuentra el inquilino, consulte Búsqueda de la región predeterminada de la organización. Cuando los usuarios de un inquilino acceden al servicio Power BI, sus solicitudes siempre se enrutan a dicha región. Cuando las solicitudes llegan al servicio Power BI, el servicio puede enviar solicitudes adicionales (por ejemplo, al origen de datos subyacente o a la puerta de enlace), que también están sujetas a la latencia de red.

    • Las herramientas como Azure Speed Test proporcionan una indicación de la latencia de red entre el cliente y la región de Azure. En general, para minimizar el impacto de la latencia de red, intente mantener los orígenes de datos, las puertas de enlace y el clúster de Power BI lo más cerca posible. Es preferible residir en la misma región. Si la latencia de red es un problema, intente ubicar las puertas de enlace y los orígenes de datos más cerca del clúster de Power BI situándolos dentro de las máquinas virtuales hospedadas en la nube.

Tiempo de procesador elevado

Si observa un tiempo de procesador elevado, es probable que tenga transformaciones costosas que no se pliegan. El tiempo elevado del procesador se debe al número de pasos aplicados que tiene o al tipo de transformaciones que realiza. Cada una de estas posibilidades puede dar lugar a tiempos de actualización mayores.

Guía para el tiempo de procesador elevado

Hay dos opciones para optimizar el tiempo de procesador elevado.

En primer lugar, use el plegado de consultas en el propio origen de datos, lo que debería reducir directamente la carga en el motor de proceso del flujo de datos. El plegado de consultas dentro del origen de datos permite al sistema de origen realizar la mayor parte del trabajo. El flujo de datos puede pasar entonces por las consultas en el lenguaje nativo del origen, en lugar de tener que realizar todos los cálculos en la memoria después de la consulta inicial.

No todos los orígenes de datos son capaces de realizar el plegado de consultas e, incluso en el caso de que sea posible, pueden existir flujos de datos que realicen ciertas transformaciones imposibles de plegar en el origen. En tales casos, el motor de proceso mejorado es una funcionalidad introducida por Power BI que puede mejorar hasta 25 veces el rendimiento, especialmente en las transformaciones.

Uso del motor de proceso para maximizar el rendimiento

Aunque Power Query tiene visibilidad en tiempo de diseño sobre el plegado de consultas, la columna del motor de proceso proporciona detalles sobre si se utiliza el propio motor interno. El motor de proceso resulta útil cuando tiene un flujo de datos complejo y está realizando transformaciones en la memoria. En esta situación es donde las estadísticas de actualización mejorada pueden ser útiles, ya que la columna del motor de proceso proporciona detalles sobre si se ha usado o no el propio motor.

En las secciones siguientes se proporciona una guía sobre el uso del motor de proceso y sus estadísticas.

Advertencia

Durante el tiempo de diseño, el indicador de plegado en el editor puede mostrar que la consulta no se pliega al consumir datos de otro flujo de datos. Compruebe el flujo de datos de origen si está habilitado el proceso mejorado para asegurarse de que el plegado en el flujo de datos de origen está habilitado.

Guía sobre los estados del motor de proceso

Es útil activar el motor de proceso mejorado y comprender los diversos estados. Internamente, el motor de proceso mejorado utiliza una base de datos SQL para leer y almacenar los datos. Es mejor que las transformaciones se ejecuten aquí, en el motor de consultas. A continuación se describen diversas situaciones y una guía sobre qué hacer en cada una de ellas.

N/D: este estado significa que el motor de proceso no se usó por alguna de estas razones:

  • Está usando flujos de datos de Power BI Pro.
  • Desactivó explícitamente el motor de proceso.
  • Está usando el plegado de consultas en el origen de datos.
  • Está realizando transformaciones complejas que no pueden usar el motor SQL que se usa para acelerar las consultas.

Si experimenta duraciones largas y sigue recibiendo el estado N/D, asegúrese de que el motor de proceso esté activado y no se haya desactivado por accidente. Un patrón recomendado es usar flujos de datos de almacenamiento provisional para introducir los datos inicialmente en el servicio Power BI y, luego, crear flujos de datos a partir de estos datos, una vez que se encuentra en un flujo de datos de almacenamiento provisional. Ese patrón puede reducir la carga en los sistemas de origen y, junto con el motor de proceso, proporcionar un aumento de velocidad para las transformaciones y mejorar el rendimiento.

En caché: si ve el estado En caché, los datos de flujo de datos se almacenaron en el motor de proceso y están disponibles para hacer referencia a ellos como parte de otra consulta. Esta situación es conveniente si los usa como entidad vinculada, ya que el motor de proceso almacena en caché esos datos para su uso en un nivel inferior. Los datos almacenados en caché no necesitan actualizarse varias veces en el mismo flujo de datos. Esta situación también podría ser conveniente si quiere usarlos en DirectQuery.

Cuando se almacenan en caché, el efecto sobre el rendimiento de la ingesta inicial se amortiza más adelante, en el mismo flujo de datos o en un flujo de datos diferente de la misma área de trabajo.

Si la duración de la entidad es muy larga, considere la posibilidad de desactivar el motor de proceso. Para almacenar en caché la entidad, Power BI la escribe en el almacenamiento y en SQL. Si se trata de una entidad de un solo uso, la ventaja de rendimiento para los usuarios podría no merecer la pena de la ingesta doble.

Plegado: este estado significa que el flujo de datos pudo usar el proceso de SQL para leer los datos. La entidad calculada usó la tabla de SQL para leer los datos, y el SQL utilizado está relacionado con las construcciones de su consulta.

El estado Plegado aparece si, cuando se usan orígenes de datos locales o en la nube, se cargan primero los datos en un flujo de datos de almacenamiento provisional y se hace referencia a ellos en este flujo de datos. Este estado solo se aplica a las entidades que hacen referencia a otra entidad. Significa que las consultas se ejecutaron sobre el motor de SQL y, por tanto, tienen la posibilidad de mejorar con el proceso de SQL. Para asegurarse de que el motor de SQL procesa las transformaciones, use transformaciones que admitan el plegado de SQL, como las acciones de fusionar mediante combinación (combinar), agrupar por (agregación) y anexar (unión) en el Editor de consultas.

En caché y plegado: cuando vea el estado En caché y plegado, es probable que se haya optimizado la actualización de datos, ya que tiene una entidad que hace referencia a otra y a la que se hace referencia mediante otra entidad de nivel superior. Esta operación también se ejecuta sobre SQL y, de ese modo, también tiene la posibilidad de mejorar con el proceso de SQL. Para asegurarse de que está obteniendo el mejor rendimiento posible, utilice las transformaciones que admiten el plegado de SQL, como las acciones de mezclar (combinación), agrupar por (agregación) y anexar (unión) en el Editor de consultas.

Guía para la optimización del rendimiento del motor de proceso

Los pasos siguientes permiten que las cargas de trabajo desencadenen el motor de proceso y, por tanto, mejoren siempre el rendimiento:

Entidades calculadas y vinculadas en la misma área de trabajo:

Para la ingesta, céntrese en introducir los datos en el almacenamiento lo más rápido posible, y use filtros únicamente si reducen el tamaño total del modelo semántico. Mantenga la lógica de transformación independiente de este paso. A continuación, separe la lógica de transformación y de negocios en un flujo de datos aparte de la misma área de trabajo. Use entidades vinculadas o calculadas. Al hacerlo, el motor puede activar y acelerar los cálculos. Haciendo una simple comparación, sería como la preparación de los alimentos en la cocina: normalmente es un paso independiente y distinto de la recolección de las materias primas y un requisito previo para poner los alimentos en el horno. Del mismo modo, la lógica debe prepararse por separado para poder aprovechar el motor de proceso.

Asegúrese de realizar las operaciones que doblan, como combinaciones, conversiones y otras.

Además, cree flujos de datos dentro de las instrucciones y limitaciones publicadas.

Cuando el motor de proceso está activado, pero el rendimiento es lento:

Siga estos pasos al investigar escenarios en los que el motor de proceso está activado, pero observa un rendimiento deficiente:

  • Limite las entidades calculadas y vinculadas que existen en toda el área de trabajo.
  • Si la actualización inicial es con el motor de proceso activado, los datos se escriben en el lago y en la caché. Esta doble escritura da lugar a que las actualizaciones sean más lentas.
  • Si tiene un flujo de datos vinculado a varios flujos de datos, asegúrese de programar las actualizaciones de los flujos de datos de origen para que no se realicen todas al mismo tiempo.

Consideraciones y limitaciones

Una licencia de Power BI Pro tiene un límite de actualización de flujos de datos de 8 actualizaciones al día.

Contenido relacionado