这是两个非常常见的SSAS处理异常，网上也能找到很多文章讲解决办法，但很少见关于异常原因的分析，先来看看第一个" OLAP 存储引擎中存在错误: 处理时找到重复的属性键"，一个维度表的关键字段，也就是通常讲的主键，是必须具有唯一性的，如果因为维度主键字段出现重复键，真没什么好说的了，太不应该犯这种错误，所以通常大家看到这个处理异常信息都是因为一个非主键属性，例如[Dim Customer]维度里的[Education]属性，和主键[Customer Key]是一对多的关系，Education教育程度的条目是有限的，相同教育程度的顾客会有很多，因此某种意义上来说[Dim Customer]维度的[Education]属性是要允许重复的。
为了演示说明，我先对AW库的Customer表的English Education字段做一些update，再做一个简单的demo cube，只有一个[Dim Customer]维度，一个[English Education]属性，其它设置都默认不做修改。
一个[Fact Customer]事实，数据源映射到一个sql查询，这里只查出维度表主键CustomerKey，因此对应的事实度量值就只有一个[Fact Customer Count]顾客人次了。
然后部署这个项目，收到下图所示的异常信息，EnglishEducation里的Bachelors出现重复属性键，具有Bachelors学士学位的Customer有很多人，这个太正常不过了，出了什么状况呢？我们展开下图高亮所示的Processing English Education日志，找到具体的sql脚本复制出来看看
复制出来的脚本是个distinct查询，执行后如下图所示，问题来了，不难发现第2行和第6行都是Bachelors，的确是重复了（实际生产环境可能无法肉眼识别重复项），那么为什么distinct没起作用呢？
我们对脚本做个简单的修改，看下Bachelors的两条记录有什么不同，下图看到第一行的Bachelors里多了个ascii码9，也就是tab键
在这之前我做的update更新正是对其中一条customer的education内容追加了几个特殊字符，脚本如下：
update DimCustomer set EnglishEducation = 'Bachelors'+char(9)+char(13) where CustomerKey=11001
那么问题又来了，既然这已经是两个不同的Education了，为什么SSAS会报找到重复键的异常呢？我们把上图的查询结果复制到Excel里
然后进行去重操作
，会发现excel去重成功了，也就是说excel是先对这两项都进行trim操作，去除一些特殊字符(例如空格、换行符、Tab键等) 
不难料见，SSAS在处理维度数据时也是做了同样的数据清洗工作，而数据库的distinct不能如此简单暴力的做这种清洗工作，SSAS之所以会报找到重复键的异常，简单理解就是SSAS向数据库请求distinct去重的Education列表，数据库查询出来并给到SSAS后，SSAS又自作主张进行了一些清洗工作，然后发现有重复项，总之这个问题是由于MSSQL和SSAS对字符串的处理不一致造成的。这个异常警告是没什么影响的，在ErrorConfiguration里设置KeyDuplicate为Ignore即可，当然，如果你有洁癖强迫症，也可以在etl过程中做手工清洗去除这些特殊字符。。。
至于另一个处理异常" 处理时找不到以下属性键"，这个通常是由于数据库的字符集和排序规则引起的，转载下面一篇文章讲解的很透彻
全半角空格导致的Sql Server Analysis Services处理错误
比如说对Customer维度表做以下update更新，分别为两个Customer追加全角和半角空格，那么SSAS在处理11000这个Customer时，发现数据库里对应的Education(有全角空格)在SSAS的数据结构里找不到，结合上面综合理解，SSAS的数据结构里存储的是自己清洗后的结果，这个问题同样也是由于MSSQL和SSAS对字符串的处理不一致造成的。
update DimCustomer set EnglishEducation = 'Bachelors'+N' ' where CustomerKey=11000 update DimCustomer set EnglishEducation = 'Bachelors'+' ' where CustomerKey=11001
另外需要补充的是这个处理异常也是可以设置为ignore忽略的，但是请注意后果很严重，例如执行上面的两个update更新后，并设置KeyNotFound为Ignore
这时候如果对[Dim Customer]维度单独进行process update，的确可以成功处理，但是处理之前和之后的对比图如下，这种数据异常在某些场合还不容易被发现
而如果是对整个cube进行process full，还是会报以下错误信息，奇怪的是报错的CustomerKey是完全不相干的11918，不清楚具体原因了
既然这个异常如此重要，不能简单暴力的Ignore忽略，那么如何定位到具体的错误记录呢，请参考下面的文章：
设置KeyNotFound为ReportAndContinue后利用错误提示信息中的记录号可以定位到具体的错误数据，也可以用前面介绍的sql like定位。
