Compartir a través de

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

Los flujos de datos de Power BI permiten conectarse, transformar, combinar y distribuir datos para el análisis posterior. Un elemento clave de los flujos de datos es el proceso de actualización, que aplica los pasos de transformación que creó en los flujos de datos y actualiza los datos de los propios elementos.

Para comprender los tiempos de ejecución, el rendimiento y si obtiene el máximo partido del flujo de datos, puede descargar el historial de actualizaciones después de actualizar un flujo de datos.

Descripción de las actualizaciones

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

  • Lleno, que realiza un vaciado completo y 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 filtro, que configure. El filtro de la columna de fecha divide dinámicamente los datos en intervalos en el servicio Power BI. Después de configurar 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 trae su propio Azure Data Lake Storage, puede ver los fragmentos temporales de sus datos en función de la directiva de actualización que establezca.

    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 grandes flujos de datos en Power BI con 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 particiones N especificadas por el usuario (donde la partición es día,semana/mes, etc.) o
    • Power BI solo actualiza los datos que deben actualizarse. Por ejemplo, actualizando solo los últimos cinco días de un modelo semántico de 10 años.
    • Power BI solo actualiza los datos que han cambiado, siempre y cuando especifique la columna que desea comprobar si hay cambios.

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

  • El consumo de recursos se reduce: menos datos para actualizar reduce el consumo general de memoria y otros recursos.

  • Siempre que sea posible, Power BI emplea procesamiento paralelo en 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 y, después, se pueden completar sin errores. La actualización se produce en una partición o entidad, por lo que si se produce un error en una actualización incremental o una entidad tiene un error, no se produce la transacción de actualización completa. Se ha dicho de otra manera, si se produce un error en una partición (directiva de actualización incremental) o una entidad para un flujo de datos, se produce un error en toda la operación de actualización y no se actualiza ningún dato.

Descripción y optimización de las actualizaciones

Para comprender mejor cómo se realiza una operación de actualización de flujo de datos, revise el Historial de actualizaciones del flujo de datos; para ello, vaya a uno de los flujos de datos. Seleccione Más opciones (...) para el flujo de datos. A continuación, elija Configuración > Actualizar historial. También puede seleccionar el flujo de datos en el área de trabajo. A continuación, elija Más opciones (...) > Historial de actualización.

Captura de pantalla del historial de actualización de flujos de datos.

El historial de actualizaciones proporciona información general sobre las actualizaciones, incluido el tipo , a petición o programado, 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 actualización. El CSV descargado incluye los atributos descritos en la tabla siguiente. Las actualizaciones Premium proporcionan más información en función de las funcionalidades adicionales de proceso y flujos de datos, frente a los flujos de datos basados en Pro que residen en la capacidad compartida. Por lo tanto, algunas de las métricas siguientes solo están disponibles en Premium.

Elemento Description Pro Premium
Solicitado en La actualización de hora se programó o se hizo clic en la actualización ahora, en la hora local. ✔ ✔
Nombre del flujo de datos Nombre del flujo de datos. ✔ ✔
Estado de actualización del flujo de datos Completado, Fallido o Omitido (para una entidad) son posibles estados. Los casos de uso, como las entidades vinculadas, son motivos por los que se podrían ver omitidas. ✔ ✔
Nombre de entidad Nombre de la tabla. ✔ ✔
Nombre de partición Este elemento depende de si el flujo de datos es premium o no, y si Pro se muestra como NA 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 para ese segmento de tiempo de los datos que se actualizan. ✔ ✔
Hora de inicio En Premium, este elemento es el momento en el que el flujo de datos se puso en cola para su procesamiento para la entidad o partición. El tiempo puede diferir si los flujos de datos tienen dependencias y necesitan esperar al resultado de un flujo de datos anterior para comenzar el procesamiento. ✔ ✔
Hora de finalización La hora de finalización es la hora en que se completó la entidad de flujo de datos o la partición, si procede. ✔ ✔
Duración Tiempo total transcurrido para que el flujo de datos se actualice expresado en HH:MM:SS. ✔ ✔
Filas procesadas Para una entidad o partición determinada, el número de filas escaneadas o escritas por el motor de flujos de datos. Es posible que este elemento no contenga siempre 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, los datos escritos por el motor de flujos de datos, expresados en bytes.

Al usar una puerta de enlace en este flujo de datos concreto, no se proporciona esta información.		 ✔
Confirmación máxima (KB) Max Commit es la memoria de reserva máxima útil para diagnosticar fallos de memoria insuficiente cuando la consulta M no está optimizada.

Cuando 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, el tiempo, expresado en HH:MM:SS que el motor de flujos de datos ha dedicado a realizar transformaciones.

Cuando 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, el tiempo que una entidad pasó en estado de espera, en función de la carga de trabajo en la capacidad Premium. ✔
Motor de proceso Para una entidad o partición determinada, detalles sobre cómo la operación de actualización usa el motor de proceso. Los valores son:
- N/D
- Doblado
-Caché
- Almacenado en caché + Plegado

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

Guía de actualización del 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é observar y cómo optimizar en función de la información proporcionada.

Orquestación

El uso de flujos de datos 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 y secuenciar como A > B > C. Si actualiza el origen (A), las entidades dependientes también se actualizan. Sin embargo, si actualiza C, tendrá que actualizar otros de forma independiente. Además, si agrega un nuevo origen de datos en el flujo de datos B (que no está incluido en A), esos 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 Power BI realiza. En estos escenarios, puede usar las API o usar 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 de Power Automate que permite realizar este procedimiento sin escribir ningún código. Puede ver ejemplos detallados, con tutoriales específicos para las actualizaciones secuenciales.

Monitorización

Con las estadísticas de actualización mejoradas descritas anteriormente en este artículo, puede obtener información detallada de actualización por flujo de datos. Pero si desea ver flujos de datos con una vista general de las actualizaciones a nivel de inquilino o de espacio de trabajo, tal vez para construir un panel de monitoreo, puede usar las API o las plantillas de Power Automate. Del mismo modo, para casos de uso como el envío de notificaciones simples o complejas, puede usar el conector de Power Automate o crear su propia aplicación personalizada mediante las API.

Errores de tiempo de espera

Optimizar el tiempo necesario para realizar escenarios de extracción, transformación y carga (ETL) es ideal. En Power BI, se aplican los siguientes casos:

  • Algunos conectores tienen valores de tiempo de espera explícitos que puede configurar. Para más información, consulte Conectores en Power Query.
  • Los flujos de datos de Power BI, mediante Power BI Pro, también pueden experimentar tiempos de espera para consultas de larga duración dentro de una entidad o flujos de datos. Esa 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 para los flujos de datos de Power BI Pro son:

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

Por ejemplo, si tiene un flujo de datos con tres tablas, ninguna tabla individual puede tardar más de dos horas y todo el flujo de datos agota 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 considere la posibilidad de usar el plegado de consultas en los sistemas de origen.

Por separado, considere la posibilidad de actualizar a Premium por usuario, que no está sujeto a estos tiempos de espera y ofrece un mayor rendimiento debido a muchas características de Power BI Premium por usuario.

Duraciones largas

Los flujos de datos complejos o grandes pueden tardar más tiempo en actualizarse, ya que pueden optimizarse mal los flujos de datos. En las secciones siguientes se proporcionan instrucciones sobre cómo mitigar las duraciones de actualización prolongada.

Guía para tiempos de actualización prolongados

El primer paso para mejorar las duraciones de actualización largas de los flujos de datos es crear flujos de datos según los procedimientos recomendados. Entre los patrones importantes se incluyen:

Después, puede ayudar a evaluar si es posible utilizar la actualización incremental.

El uso de la actualización incremental puede mejorar el rendimiento. Es importante que los filtros de partición se inserte en el sistema de origen cuando se envían consultas para las operaciones de actualización. Empujar el filtrado hacia abajo significa que el origen de datos debe admitir el plegado de consultas, o puede expresar la lógica empresarial a través de 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 de mash-up compensa y aplica el filtro localmente, lo que podría requerir recuperar el modelo semántico completo del origen de datos. Esta operación puede hacer que la actualización incremental sea lenta y el proceso se puede ejecutar sin recursos en el servicio Power BI o en la puerta de enlace de datos local, si se usa.

Dados los distintos niveles de compatibilidad con el plegado de consultas para cada origen de datos, debe realizar la comprobación para asegurarse de que la lógica de filtro se incluye en las consultas de origen. Para facilitar esto, Power BI intenta realizar esta comprobación automáticamente, con indicadores de plegado de pasos para Power Query Online. Muchas de estas optimizaciones son experiencias en tiempo de diseño, pero después de que se produzca 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 mediante el escalado de la capacidad, el dimensionamiento adecuado de las puertas de enlace de datos y la reducción de la latencia de red con las siguientes optimizaciones:

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

  • Se requiere una puerta de enlace siempre que Power BI necesite 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 del gateway y las recomendaciones de dimensionamiento, consulte Dimensionamiento del gateway de datos local.
    • Evalúe también traer los datos primero a un flujo de datos intermedio y referenciándolos en pasos posteriores mediante entidades vinculadas y calculadas.

  • La latencia de red puede afectar al rendimiento de la actualización aumentando el tiempo necesario para que las solicitudes lleguen al servicio Power BI y para que se entreguen 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 cliente acceden al servicio Power BI, sus solicitudes siempre se dirigen a esa región. A medida que las solicitudes llegan al servicio Power BI, el servicio podría enviar solicitudes adicionales, por ejemplo, al origen de datos subyacente o a una puerta de enlace de datos, que también están sujetas a 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 localizar puertas de enlace y orígenes de datos más cerca del clúster de Power BI colocándolos dentro de máquinas virtuales hospedadas en la nube.

Tiempo elevado de procesador

Si observa un uso elevado del tiempo del procesador, es probable que tenga transformaciones costosas que no se optimizan. El tiempo de procesador elevado se debe al número de pasos aplicados que tiene o al tipo de transformaciones que está realizando. Cada una de estas posibilidades puede dar lugar a tiempos de actualización más altos.

Guía para un alto tiempo de procesador

Hay dos opciones para optimizar el tiempo de procesador elevado.

En primer lugar, use el plegado de consultas dentro del propio origen de datos, lo cual debería reducir directamente la carga en el motor de procesamiento de flujo de datos. El plegado de consultas dentro del origen de datos permite al sistema de origen realizar la mayor parte del trabajo. A continuación, el flujo de datos puede pasar por consultas en el idioma 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 pueden realizar el plegado de consultas, e incluso cuando el plegado de consultas es posible que haya flujos de datos que realicen determinadas transformaciones que no se pueden plegar al origen. En tales casos, el motor de proceso mejorado es una funcionalidad introducida por Power BI para mejorar potencialmente el rendimiento hasta 25 veces, para las transformaciones específicamente.

Uso del motor de proceso para maximizar el rendimiento

Aunque Power Query tiene visibilidad en tiempo de diseño en el plegado de consultas, la columna del motor de proceso proporciona detalles sobre si se usa el propio motor interno. El motor de proceso es útil cuando tiene un flujo de datos complejo y realiza transformaciones en memoria. Esta situación es en la que las estadísticas de actualización mejoradas pueden ser útiles, ya que la columna del motor de cálculo proporciona detalles sobre si se utilizó el motor en sí.

En las secciones siguientes se proporcionan instrucciones 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 podría mostrar que la consulta no se plega al consumir datos de otro flujo de datos. Compruebe el flujo de datos de origen si el proceso mejorado está habilitado para asegurarse de que el plegado en el flujo de datos de origen está habilitado.

Guía sobre los estados del motor de cálculo

Activar el motor de proceso mejorado y comprender los distintos estados es útil. Internamente, el motor de proceso mejorado usa una base de datos SQL para leer y almacenar datos. Es mejor que las transformaciones se ejecuten en el motor de consultas aquí. Los párrafos siguientes proporcionan varias situaciones e instrucciones sobre qué hacer para cada uno.

NA : este estado significa que el motor de proceso no se usó, ya sea porque:

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

Si tienes duraciones largas y sigue recibiendo un estado de NA, asegúrate de que está activado y no esté desactivado por accidente. ** Un patrón recomendado es usar flujos de datos de almacenamiento provisional para obtener inicialmente los datos en el servicio Power BI y, a continuación, crear flujos de datos basados en estos datos, una vez que estén 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.

Almacenado en caché: si ve el estado almacenado en caché , los datos del flujo de datos se almacenaron en el motor de proceso y están disponibles para que se haga referencia a ellos como parte de otra consulta. Esta situación es ideal si la usa como una entidad vinculada, ya que el motor de computación almacena esos datos en caché para su uso posterior. Los datos almacenados en caché no necesitan actualizarse varias veces en el mismo flujo de datos. Esta situación también es posiblemente ideal si quiere usarla para DirectQuery.

Cuando se almacena en caché, el impacto sobre el rendimiento durante la ingesta inicial compensa más adelante, ya sea en el mismo flujo de datos o en un flujo de datos diferente dentro de la misma área de trabajo.

Si tiene una larga duración para la entidad, considere desactivar el motor de cálculo. Para almacenar en caché la entidad, Power BI la escribe en el almacenamiento y en el sistema SQL. Si se trata de una entidad de uso único, es posible que la ventaja de rendimiento para los usuarios no valga la pena de la ingesta doble.

Plegado - El término plegado significa que el flujo de datos pudo usar la computación SQL para leer los datos. La entidad calculada usó la tabla de SQL para leer datos, y el SQL utilizado está relacionado con las estructuras de su consulta.

El estado plegado aparece si, cuando se usan orígenes de datos locales o en la nube, primero se cargan datos en un flujo de datos 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 utilizando el motor de SQL, y tienen el potencial de mejorarse mediante las capacidades de cálculo de SQL. Para asegurarse de que el motor SQL procese sus transformaciones, use transformaciones que admitan el plegado de SQL, como las acciones de combinar (combinación), agrupar por (agregación) y anexar (unión) en el Editor de Consultas.

Almacenado en caché y combinado: cuando veas almacenado en caché y combinado, es probable que la actualización de datos esté optimizada, ya que tienes una entidad que hace referencia a otra entidad y a la que hace referencia otra entidad ascendente. Esta operación también se ejecuta sobre SQL y, como tal, también tiene el potencial de mejora con el cómputo de SQL. Para asegurarse de obtener el mejor rendimiento posible, use transformaciones que tengan compatibilidad con SQL folding, como combinar (combinación), agrupar por (agregación) y acciones de anexar (unión) en el Editor de consultas.

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

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

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

Para la ingesta, céntrese en obtener los datos en el almacenamiento lo más rápido posible, use filtros solo si reducen el tamaño general del modelo semántico. Mantenga la lógica de transformación independiente de este paso. A continuación, separe la transformación y la lógica de negocios en un flujo de datos independiente en la misma área de trabajo. Use entidades vinculadas o calculadas. Esto permite que el motor active y acelere los cálculos. Para una simple analogía, es como la preparación de alimentos en una cocina: la preparación de alimentos suele ser un paso independiente y distinto de la recopilación de sus ingredientes sin procesar, y un requisito previo para poner la comida en el horno. Del mismo modo, debe preparar la lógica por separado antes de poder aprovechar el motor de cómputo.

Asegúrese de realizar las operaciones de combinación, como fusiones, uniones, conversión y otras.

Además, cree flujos de datos dentro de las directrices 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 computación está encendido, pero experimenta un rendimiento deficiente:

  • Limite las entidades calculadas y vinculadas que existen en el área de trabajo.
  • Si la actualización inicial se realiza con el motor de cálculo activado, los datos se escriben en el lago de datos y en la memoria caché. Esta escritura doble da como resultado que las actualizaciones sean más lentas.
  • Si tiene un flujo de datos vinculado a varios flujos de datos, asegúrese de programar actualizaciones de los flujos de datos de origen para que no se actualicen 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

  • Last updated on