Partekatu honen bidez:


Técnicas de reducción de datos para modelos de importación

Este artículo está dirigido a los modeladores de datos de Power BI Desktop que desarrollan y publican modelos semánticos de Power BI. En concreto, describe varias técnicas para ayudar a reducir los datos cargados en Importar modelos.

Los modelos de importación se cargan con datos comprimidos y optimizados y, a continuación, se almacenan en el disco mediante el motor de almacenamiento VertiPaq. Cuando los datos de origen se cargan en la memoria, es posible lograr una compresión de 10x, por lo que es razonable esperar que 10 GB de datos de origen pueda comprimirse a unos 1 GB de tamaño. Además, cuando se guardan en el disco, se puede lograr una reducción adicional del 20 %.

A pesar de las eficiencias que se han logrado con el motor de almacenamiento VertiPaq, debería esforzarse por minimizar la cantidad de datos que se cargan en sus modelos. Esto es especialmente cierto para los modelos grandes, o los modelos que se prevé que crecerán hasta volverse grandes a lo largo del tiempo. Los cuatro motivos de peso incluyen:

  • Es posible que la capacidad no admita tamaños de modelo más grandes. La capacidad compartida puede hospedar modelos de hasta 1 GB de tamaño, mientras que las capacidades Premium pueden hospedar modelos más grandes en función del SKU. Para obtener más información, consulte Modelos semánticos grandes en Power BI Premium.
  • Los tamaños de modelo más pequeños reducen la contención de los recursos de capacidad, en particular, memoria. Es posible cargar simultáneamente muchos modelos más pequeños dentro de una cierta capacidad durante períodos de tiempo más prolongados, lo que resulta en tasas de expulsión más bajas.
  • Los tamaños de modelo más pequeños logran una actualización de datos más rápida, lo que da lugar a informes de menor latencia, mayor rendimiento de actualización del modelo semántico y menor presión en los recursos de capacidad y sistema de origen.
  • Los recuentos de filas de tabla más pequeños pueden dar lugar a evaluaciones de cálculo más rápidas, lo que da lugar a un mejor rendimiento general de las consultas.

Importante

En ocasiones, este artículo hace referencia a Power BI Premium o a sus suscripciones de capacidad (SKU P). Tenga en cuenta que Microsoft está consolidando actualmente las opciones de compra y retirando las SKU de Power BI Premium por capacidad. Los clientes nuevos y existentes deben considerar la posibilidad de comprar suscripciones de capacidad de Fabric (SKU F) en su lugar.

Para obtener más información, consulte Actualización importante sobre las licencias de Power BI Premium y Preguntas más frecuentes sobre Power BI Premium.

Quitar columnas innecesarias

Las columnas de las tablas del modelo tienen dos propósitos principales:

  • Creación de informes, para lograr diseños de informe que filtren, agrupan y resumen los datos del modelo adecuadamente.
  • Estructura del modelo, al admitir relaciones del modelo, cálculos del modelo, roles de seguridad e incluso formato de colores de datos

Probablemente puede quitar cualquier columna que no sirva ninguno de estos propósitos. La eliminación de una columna de una tabla se conoce a veces como filtrado vertical.

Se recomienda diseñar modelos con exactamente el número correcto de columnas en función de los requisitos de informes conocidos. Los requisitos pueden cambiar con el tiempo, pero tenga en cuenta que es más fácil agregar columnas más adelante que quitarlas más adelante. La eliminación de columnas puede interrumpir los informes o la estructura del modelo.

Quitar filas innecesarias

Debe cargar tablas de modelo con la menor cantidad de filas posible. Puede lograrlo cargando conjuntos de filas filtrados en tablas de modelo por dos razones diferentes: filtrar por tiempo o por entidad. La eliminación de filas a veces se conoce como filtrado horizontal.

  • El filtrado por tiempo implica limitar la cantidad de historial de datos cargados en tablas de hechos (y limitar las filas de fecha cargadas en las tablas de fechas del modelo). Se recomienda no cargar todo el historial disponible de forma predeterminada, a menos que sea un requisito de informes conocido. Puede implementar filtros de Power Query basados en tiempo con parámetros e incluso establecerlos para que usen períodos de tiempo relativos (relativos a la fecha de actualización, por ejemplo, los últimos cinco años). Además, tenga en cuenta que un cambio retroactivo en los filtros de tiempo no afectará los informes; simplemente resultará en menos (o más) historial de datos disponible en los informes.
  • El filtrado por entidad implica cargar un subconjunto de datos de origen en el modelo. Por ejemplo, en lugar de cargar datos de ventas de todas las regiones de ventas, solo se cargan los de una región. Este enfoque de diseño da como resultado muchos modelos más pequeños y también puede eliminar la necesidad de definir seguridad de nivel de fila (RLS), pero requiere conceder permisos de modelo semántico específicos en el servicio Power BI y crear informes duplicados que se conectan a cada modelo semántico. Puede usar parámetros de Power Query y archivos de plantilla de Power BI para simplificar la administración y la publicación. Para obtener más información, consulte Creación y uso de plantillas de informe en Power BI Desktop.

Agrupar y resumir

Quizás la técnica más eficaz para reducir el tamaño de un modelo es cargar datos resumidos previamente. Puede usar esta técnica para aumentar el detalle de las tablas de hechos. La desventaja es la pérdida de detalle.

Considere un ejemplo en el que una tabla de hechos de ventas de origen almacena una fila por línea de pedido. Se puede lograr una reducción significativa de los datos mediante el resumen de todas las métricas de ventas, la agrupación por fecha, cliente y producto. Se puede lograr una reducción de datos aún más significativa mediante la agrupación por fecha en el nivel de mes. Aunque se podría lograr una reducción posible de hasta un 99%% en el tamaño del modelo, ya no es posible la generación de informes a nivel diario o a nivel de línea de pedido individual. Decidir resumir los datos de hechos siempre implica desventajas. El equilibrio podría mitigarse mediante un diseño de modelo que incluye algunas tablas en el modo de almacenamiento de DirectQuery, que se describe más adelante en este artículo.

Optimizar tipos de datos de columna

El motor de almacenamiento VertiPaq usa estructuras de datos internas independientes para cada columna. Por diseño, estas estructuras de datos logran las optimizaciones más altas para los datos de columnas numéricas, que utilizan la codificación de valores . Pero los datos de texto y otros no numéricos usan codificación hash. La codificación hash requiere que el motor de almacenamiento asigne un identificador numérico a cada valor único contenido en la columna. Así, es el identificador numérico el que se almacena en la estructura de datos, lo que exige una búsqueda hash durante el almacenamiento y la consulta.

En algunas instancias específicas, puede convertir los datos de texto de origen en valores numéricos. Por ejemplo, un número de pedido de venta podría tener consistentemente un prefijo con un valor de texto (por ejemplo, SO123456). En este caso, se podría quitar el prefijo SO y el valor del número de pedido convertido en un número entero. En el caso de las tablas grandes, esta modificación puede dar lugar a una reducción significativa de los datos, especialmente cuando la columna contiene valores de cardinalidad únicos o altos.

En este ejemplo, se recomienda establecer la propiedad de resumen predeterminado de columna en Do Not Summarize. Ayuda a evitar resúmenes inadecuados de los valores de número de pedido.

Preferencia de columnas personalizadas

El motor de almacenamiento VertiPaq almacena las columnas calculadas del modelo (definidas en DAX) de la misma manera que las columnas normales derivadas de Power Query. Sin embargo, las estructuras de datos internas se almacenan ligeramente de forma diferente y normalmente logran una compresión menos eficaz. Además, las estructuras de datos se crean una vez que se cargan todas las tablas de Power Query, lo que puede dar lugar a tiempos de actualización de datos extendidos. Por lo tanto, resulta menos eficaz agregar columnas de tabla como columnas calculadas que como columnas calculadas de Power Query (definidas en M).

Siempre que sea posible, prefiera crear columnas personalizadas en Power Query. Cuando el origen es una base de datos, puede lograr una mayor eficacia de carga de dos maneras: el cálculo se puede definir en la instrucción SQL (mediante el lenguaje de consulta nativo del proveedor) o se puede materializar como una columna en el origen de datos.

Sin embargo, en algunos casos, las columnas calculadas del modelo podrían ser la mejor opción. Esto es cierto cuando la fórmula implica evaluar las medidas o requiere una funcionalidad de modelado específica que solo se admite en las funciones DAX. Para obtener información sobre un ejemplo de este tipo, consulte Descripción de las funciones para jerarquías de elemento primario y secundario en DAX.

Deshabilitar la carga de consultas de Power Query

Las consultas de Power Query destinadas a admitir la integración de datos con otras consultas no deben cargarse en el modelo. Para evitar cargar estas consultas en el modelo, asegúrese de deshabilitar la carga de consultas en estas instancias.

Captura de pantalla de Power Query que muestra la opción Habilitar carga.

Deshabilitar fecha y hora automáticas

Power BI Desktop incluye una opción llamada Fecha y hora automáticas. Cuando se habilita, crea tablas ocultas de fecha y hora automáticas para cada columna de fecha del modelo. Esta opción asiste a los autores de informes al configurar filtros, agrupación y acciones detalladas para los períodos de tiempo del calendario. Las tablas ocultas son de hecho tablas calculadas que aumentan el tamaño del modelo.

Para más información, vea Guía sobre la fecha y hora automáticas en Power BI Desktop.

Uso del modo de almacenamiento directQuery

El modo de almacenamiento directQuery es una alternativa al modo de almacenamiento de importación. Las tablas del modelo de DirectQuery no importan datos. En su lugar, solo constan de metadatos que definen la estructura de la tabla. Cuando se consulta la tabla, las consultas nativas se usan para recuperar datos del origen de datos subyacente. Al combinar tablas del modo de almacenamiento Import y DirectQuery en un solo modelo, se conoce como modelo compuesto de .

Una técnica eficaz para reducir el tamaño del modelo es establecer el modo de almacenamiento para tablas de hechos más grandes en DirectQuery. Tenga en cuenta que este enfoque de diseño a menudo funciona bien con la técnica Agrupar por y resumir introducida anteriormente. Por ejemplo, los datos de ventas resumidos se pueden usar para lograr informes de resumen de alto rendimiento. Una página de obtención de detalles podría mostrar las ventas pormenorizadas de un contexto de filtrado (y delimitación) específico y mostrar todos los pedidos de ventas en contexto. En este ejemplo, la página de obtención de detalles podría incluir objetos visuales basados en una tabla modelo DirectQuery para recuperar los datos de pedidos de ventas.

Sin embargo, hay muchas implicaciones de seguridad y rendimiento relacionadas con el modo de almacenamiento directQuery y los modelos compuestos. Para obtener más información, consulte Uso de modelos compuestos en Power BI Desktop.

Para obtener más información relacionada con este artículo, consulte los siguientes artículos: