Identificadores únicos deterministas

[Syndicate_Admin]

Estoy trabajando con un modelo de datos grande y estoy utilizando cadenas de diferentes tablas de dimensiones en el cálculo de medidas.

Ahora bien, en aras de estos cálculos,

Necesito generar un ID único determinista (la misma entrada siempre genera la misma salida) (que se alimentará más adelante en el cálculo de la medida) sobre la marcha en función de los valores de la cadena.

Actualmente estoy haciendo lo siguiente.

EVALUATE
var base = DATATABLE (
    "Name", STRING ,   
    {
        { "Lorem" },
        { "Ipsum"},
        { "dolor" },
		{ "sit"},
		{"amet"}
    }
)
var cte = ADDCOLUMNS(base, "unique_hash", HASH([Name]))
RETURN cte

Mi pregunta es

1. ¿Es posible que HASH genere valores repetidos (unique_hash) para diferentes cadenas (colisión)? (Estoy trabajando con una gran cantidad de cuerdas provenientes de diferentes tablas de atenuación)
2. en caso afirmativo, ¿cuál es la mejor manera posible de lograr el resultado final deseado con DAX (DAX es la única opción)?
3. Me abstuve de usar ROWNUMBER ya que no se puede utilizar para la tabla derivada.

PICADILLO

Además, hasta donde yo sé (por favor, siéntase libre de corregirme), HASH probablemente usa internamente el principio de encasillamiento (n artículo para poner en m contenedores). Si n>m, se produciría la colisión de hash. Por lo tanto, si llego a conocer m (número total de valores HASH posibles) y si puedo asegurar el número total de n< número total de m, entonces la colisión hah es probablemente evitable. ¿Hay alguna documentación disponible sobre la función HASH de SSAS y cuál es el rango de HASH (por ejemplo, entero con signo de 32 bits; rango 2^32, etc.)?

Gracias de antemano.

@AlexisOlson @jeffrey_wang

[Syndicate_Admin]

1. En el ejemplo, las cadenas son únicas. ¿Es esto cierto en su escenario real?
   • Si no es único, compruebe si las filas duplicadas deben tener valores de ID únicos coincidentes.
   • Si es único, ¿por qué necesita una columna de ID único?
2. El principio del encasillamiento no es realmente parte de un algoritmo hash. Es un teorema matemático que establece que si tiene más de N elementos para poner en N contenedores, al menos un contenedor contendrá varios elementos (es decir, una colisión de hash). Es probable que se produzcan colisiones de hash mucho antes de acercarse al número de posibles salidas de hash. Es solo que si te pasas, tienes matemáticamente garantizados tenerlos.
3. Parece que la función HASH genera valores en el rango de aproximadamente ±9.2 x 10¹⁸. Este es aproximadamente el tamaño de un entero con signo de 64 bits, suponiendo que use ese rango completo.
4. Echa un vistazo a la tabla de probabilidad de colisiones aleatorias en Wikipedia para tener una idea de la probabilidad de una colisión. Por ejemplo, suponiendo que cualquier salida de hash tiene la misma probabilidad, y la función HASH tiene una salida del orden de 64 bits, entonces puede tener hasta alrededor de quinientos millones de valores de entrada con una probabilidad del <1% de tener una colisión de hash aleatoria. O use esta herramienta
   

[Syndicate_Admin]

@AlexisOlson Gracias por esto y disculpas por la demora en la respuesta.

En resumen,

Suponiendo que el hash de DAX es de 64 bits, la probabilidad es directamente proporcional a k (menor probabilidad de k, mayor probabilidad de k)

Probablemente tengo ~ 2500 cadenas para ejecutar a través de HASH, así que debería ser bueno. Me pregunto por qué la EM no tiene literatura al respecto.

Gracias por iluminarme sobre el principio de encasillamiento, pero es el menor de mis problemas ya que DAX HASH no lo sigue.

En el ejemplo, las cadenas son únicas. ¿Es esto cierto en su escenario real? - sí, esta tabla se genera internamente a través de SUMMARIZEDCOLUMNS desde el contexto de filtro

Si es único, ¿por qué necesita una columna de ID único? - Necesito usarlo para un desempate en RANKX

[Syndicate_Admin]

Suponiendo que el hash de DAX es de 64 bits, la probabilidad es directamente proporcional a k (menor probabilidad de k, mayor probabilidad de k)

Echa un vistazo al artículo de Wiki de nuevo. La probabilidad es proporcional a k² en lugar de k.

---

Si todo lo que necesita es un desempate y los valores son únicos, puede usar la cadena en sí en lugar de un hash.

Suponiendo que la columna de cadena es [Nombre], pruebe

ADDCOLUMNS (
    base,
    "rank", RANK ( base, ORDERBY ( [Value], ASC, [Name], ASC ) )
)

Con RANK, puede agregar fácilmente varias condiciones ORDERBY y no es necesario que sean numéricas.

[Syndicate_Admin]

Así es. Pero por si acaso, necesito utilizar cualquier valor derivado sobre la marcha como se muestra a continuación, no se pueden acomodar en RANK.

RANKX es (probablemente) todo clima desde la perspectiva del valor original/derivado (de ahí HASH). De lo contrario, RANK es bastante bueno

var cte_1 = addcolumns(cte_0, "derived", some_dax_callback_that_generate_string)

[Syndicate_Admin]

Yo no sigo. Puede utilizar columnas derivadas en la subfunción ORDERBY de RANK.

Si desea usar RANKX, le recomendaría clasificar de manera única las cadenas (alfabéticamente) en su CTE en lugar de hashearlas y luego usar ese rango en lugar del hash como su desempate.

[Syndicate_Admin]

Arrepentido

Estaba tratando de usar RANK por sí solo (razón por la cual los campos derivados no se mostraban)

var cte1 = ADDCOLUMNS(ALLSELECTED('Table'), "string", switch(TRUE(),'Table'[row]=1,"lorem",'Table'[row]=2,"ipsum",'Table'[row]=3,"dolores"))
var cte2 = RANK()

en lugar de usarlo con el contenedor ADDCOLUMNS.

Con el envoltorio funciona perfectamente y no requiere HASH.

Gracias

[Syndicate_Admin]

Aquí hay un artículo reciente no del todo inconexo, pero divertido.

La universidad pone patas arriba una conjetura de 40 años sobre la ciencia de datos | Revista Quanta