La solución de alta cardinalidad de SQLBI no funciona

[Syndicate_Admin]

Hola querida comunidad,

Estoy tratando de implementar la solución de @marcorusso en una columna con alta cardinalidad, pero no obtengo el resultado esperado.

La solución se describe en este gran artículo: https://www.sqlbi.com/articles/optimizing-high-cardinality-columns-in-vertipaq/

Contexto:

• Me estoy conectando a una base de datos de Amazon Redshift con el conector Redshift de Power BI.
• La tabla que quiero consultar es enorme con miles de millones de filas.
• Una columna entera en particular (no una clave principal) tiene alrededor de 100 millones de valores distintos, como un índice, a partir de 1.
• Si creo un conjunto de datos con esa columna en su formato original, el conjunto de datos se está volviendo enorme y esa columna ocupa alrededor del 90% del tamaño total.

Por lo tanto, he creado una vista en la base de datos donde he dividido esa columna con el método descrito en el artículo. El resultado es exactamente lo que debería ser y la columna se divide perfectamente en 2 nuevas columnas. Ahora puedo crear un conjunto de datos sin ningún paso de transformación en Power Query.

Pero... cuando publico el conjunto de datos y lo actualizo, el tamaño del conjunto de datos sigue siendo prácticamente el mismo.

¿Alguien tiene alguna idea de las posibles razones de esto?

Gracias.

[Syndicate_Admin]

Puede probar DirectQuery en lugar de SQL Server, pero será más caro.
El algoritmo DISTINCTCOUNT de SQL Server se escala mejor en varios núcleos, por lo que si tiene un buen hardware, ese cálculo podría ser más rápido. Sin embargo, todo lo demás podría ser más lento. Podría considerar un modelo compuesto, pero entramos en un área en la que realmente depende de los requisitos y las compensaciones.
SQL Server también habilita APPROXIMATEDISTINCTCOUNT, que es mucho más rápido.
Si un cálculo aproximado podría funcionar para usted (dudo que no sea aceptable, por lo general tiene sentido que ese volumen tenga un % de aproximación), también puede considerar esta técnica (que funciona en VertiPaq) de Phil Seamark: DAX : Approx Distinct Count - Phil Seamark en DAX

Phil también habla sobre agregaciones con DISTINCTCOUNT (resuelve el rendimiento, no la memoria): Aceleración de los cálculos de recuento distinto en Power BI mediante agregaciones - Phil Seamark en DAX

[Syndicate_Admin]

Desafortunadamente, no existe tal cosa como un almuerzo gratis.

Lo que describimos en el artículo funciona siempre que los datos sean pequeños y el tamaño del diccionario sea grande.

Cuando se reduce el diccionario, también se aumenta el tamaño de los datos (esto depende de la combinación de diferentes valores en las columnas divididas; es un problema de distribución estadística, pero para simplificarlo, digamos que cuantas más filas, mayor sea el número de combinaciones, menor será la compresión.

Ahora, si tienes un diccionario relativamente grande con un tamaño de datos comprimidos relativamente pequeño, el truco funciona y tienes la misma RAM.

Cuanto más grande sea la tabla, mayor será el tamaño de los datos: en un momento determinado, el guardado en el diccionario ya no sustituye al guardado en el tamaño de los datos. Hay un punto en el que la optimización está empeorando la situación también en el tamaño de los datos.

Parece que estás en el punto óptimo, lo que significa que deberías volver a la columna única.

La buena noticia es que si publica la base de datos en el servicio Power BI con el formato grande, las columnas se cargan en la memoria solo cuando se usa, por lo que no paga el precio completo de la memoria a menos que alguien realmente la use (con suerte, no).

[Syndicate_Admin]

Hola @marcorusso , gracias por su respuesta inmediata y detallada.

Desafortunadamente, en mi caso, el recuento distinto de esa columna es mi principal métrica deseada. Por lo tanto, debe usarse constantemente y eso hace que las imágenes no se carguen y que los límites de uso de la capacidad se estiren y se infrinjan.

Gracias de nuevo por todo su trabajo y apoyo.