实际业务场景中，除了各类条件计算、同环比计算以外，排名也是比较常见的问题，我们经常需要使用Rankx函数来进行某些TopN计算等。

微软新推出的开窗函数Rank，可以说是对排名问题的一次优化，也解决了一些之前Rankx函数的坑点。

Rank函数基本语法

参数介绍：

ties：可选项，DENSE或SKIP，相同值的排名处理。

relation：可选项，排名依据的表或表表达式。

orderBy：可选项，排序依据，如果省略，第2参数需绑定。

blanks：可选项，处理空值排名位置使用。

partitionBy：可选项，分区定义，参照SQL的开窗分区即可。

matchby：可选项，定义匹配数据和标识当前行的列的语句。

PS：

看起来参数很多，实际上我们日常中用到第2参数和第3参数的频率较高，其他参数一般是为了处理某些特殊场景时使用。

先来看看本期的案例数据：

案例数据共计3张表，产品表、分店表以及事实表，将其导入到PowerBI中，模型关系如下：

添加基础度量值：

销售金额：

销售成本：

销售利润：

销售单价：

销售单位成本：

到这里，我们的准备工作完成，接下来我们来看看在不同的场景中，Rank函数的表现。

①.浮点运算

浮点运算指的是因为数值小数位过长，而导致排名发生错乱的情况，比如，我们添加如下代码：

其结果如下图：

可以看到有很多依据值不同的维度，排名却是相同的，之前我们的处理方式如下：

解决的思路是利用ROUND函数将依据值处理成固定位数，来避免浮点计算差。

而有了Rank函数之后，我们无需考虑这种情况。

结果如下：

②.并列排名

实际场景中，经常会出现并列排名的情况，一般情况的处理办法是发现并列排名，则进行加权处理。

例如，我们现在根据销售价格，对产品进行排序。

结果如下：

为了解决并列排名，我们选择将产品单位成本进行加权。

结果如下：

写法上对性能是有损耗的，有了Rank函数后，我们可以换一种写法。

结果如下：

写法上对比Rankx的处理方式，无疑是简洁了很多。

PS：

擅长SQL的小伙伴不难发现，微软就是将SQL中的Rank函数移植到了DAX中，写法上有差异，其内核基本相同。

③.性能方面

我们来分别比较一下两个场景中，Rankx函数和Rank函数的执行性能。

肉眼上可见，在处理浮点运算问题上，二者的差异并不大。

在处理并列排名的问题上，Rank函数的性能是高于Rankx函数的。

除了上述的3个问题之外，还有相关的绝对排名、相对排名以及组内排名等，白茶这里就不赘述了，感兴趣的小伙伴可以自己动手测试。