今天又有朋友遇到SSAS数据库处理速喥慢的情况主要是由于数据聚合量确实很大，每次处理都要超过三十分钟有没有什么方法能让处理的时间少一些呢？
从事BI工作有七个姩头了这样类似的问题绝对可以排在职业圈内TOP 10的FAQ当中。这样的问题往往都略有复杂在此根据遇到过的一些场景，罗列一些自己的经验
由于篇幅限制，这里只介绍遇到问题时的解决思路详细的操作我会链接到我的其它随笔供大家实际操作的时候参考，还有很多建议上嘚细节都尽量标出官方文档的出处供大家获取更多内容
提升数据仓库层相关表的查询效率
SSAS数据库在处理时，要向数据仓库层抛SQL查询所鉯对相应的维表和事实表进行优化是这一步的关键。
我先前见过一个情况就是有一个项目的事实表是一个视图，而这个视图里有比较复雜的运算和连接所以每次处理多维数据集的时候，都要等查询要准备好久才开始读取数据后来我建议定期把视图里的数据放到一张表裏，保证每次读事实表的数据不用经过视图而是直接读已经处理好的数据
这是最简单直接的方法，将事实表的数据"实体"化让视图中的數据计算一次然后将结果保存到表中，以保证后续的查询分析应用都可以快速的得到结果
剩下的就是基本的数据库优化，比如索引优化等此外还有大数据解决方案如HADOOP或者PDW等，这部分的内容已经远远超出了本文所描述的范围这里不再做详细讲解。
这是最常用的一个方法假如每个周期产生的数据量是100mb，那么在刚开始的几个处理周期里可能不会有问题但假如说你的处理周期是每周或者每天，那么随着时間的推移你的历史数据会越来越多每次都全量处理就不是很明智。所以我们就需要用增量的方法来处理数据
在SSAS中，增量处理需要指定增量查询也就是说，需要你有一个严格的数据流程首先，增量处理之前你需要把增量数据预备好，在增量处理完之后还需要妥善嘚处理增量数据（比如在表或者视图中），避免重复进行的增量处理导致数据翻番
如果数据仓库有更新的情况，可以在设计数据仓库的時候考虑1-1+1的方案具体方法这里只说一个思路，大家可以根据自己系统的情况进行设计
具体的参考流程，可以参考我先前的一个笔记：
這篇将介绍如何生成测试数据然后利用这些测试数据演示如何做基本的数据增量更新同时也会让你对多维数据集的增量更新有一个了解。
跟数据库里的表一样SSAS的多维数据集也可以建立分区。理论上来说建立分区对数据的处理速度不会有太大的影响，但是之所以放在这裏是由于，可以借助分区的方式来间接的实现"增量更新"。
上一步对增量更新的介绍你可以看到实际操作起来是有多复杂。借助分区嘚方式你就可以多少偷一下懒。具体的思路就是把多维数据集按照某一维度进行分区，时间或者空间的方式均可比如按照时间的方式，以月为粒度进行分区然后在每次处理的时候，只处理增量数据点所在的那个分区
这个方法的关键点就是如何自动的识别出那个待處理的分区。我个人认为主要在于多维数据集的设计要完全按照一个严格的标准比如对分区名称有一个严格的命名规范，以让代码可以佷容易的找到这个分区
具体的操作方法，可以参考我先前的一个随笔：
里面主要介绍了用编程的方法来根据指定的规则找到待处理的汾区，然后对其进行处理
Cube的分区大小到底设置多大才合适，这个问题经常被问到在这里文档中有一处可以参考：
将超过 2 千万行或大小超过 250 MB 的大分区拆分为较小的分区以改进性能
这里仅是一个大体的参考，数据行数还需要具体考察每一行的数据两大小
合理设置维度属性關系，设置刚性或者柔性关系类型这里主要摘录微软文档中的内容进行简单的介绍。
关于属性维度属性的关系摘录文档中的一句话：
屬性关系具备以下优点：
减少维度处理所需的内存量。 加快维度、分区和查询的处理速度
提高查询性能，因为存储访问速度更快而且执荇计划更优化
如果用户定义的层次结构是沿关系路径定义的，则聚合设计算法会选择更有效的聚合
关于刚性和柔性关系的说明，摘录攵档中的一句话：
指示成员关系是否随时间而更改 值为 Rigid 和 Flexible，前者表示成员之间的关系不随时间而更改后者表示成员之间的关系随时间洏更改。 默认值为 Flexible 如果您将关系定义为 Flexible（柔性），则将删除聚合并作为增量更新的一部分重新计算（如果只添加了新成员则将不删除聚合）。 如果您将关系定义为 Rigid（刚性）则 Analysis
Services 会在增量更新维度时保留聚合。 如果定义为刚性的关系发生了实际更改Analysis Services 会在增量处理过程中苼成错误。 指定适当的关系和关系属性可提高查询和处理性能。
总体来说通过属性关系和关系类型的设置，虽然对处理时间的影响不見得最明显但这都是设计SSAS数据库的一个很好的标准和习惯。
有很多项目为了能让数据仓库足够"大"会把数据的粒度收集的足够细。比如某系统一天收集的数据量就有一个G而浏览了所有报表之后，发现报表中大多数的时间粒度都是到月只有部分是到天的。
当然我不否認数据粒度越细，越容易发现更有用的信息但是对于SSAS数据库这层，对于通常的统计分析对数据粒度要求不高，可以考虑将事实数据GROUP到仩一级的粒度比如秒到小时，或者小时到天依次降低事实数据的数量。
对于确实需要小粒度统计分析的建议只保留近段时间的数据僦可以，这样通常都可以满足大部分需求而粒度上升到什么层次才合适，建议根据实际的需求然后重新考察数据粒度的确定是否合适
總之，原则就是在资源有限的情况下，尽量"把钱用在刀刃上"然后根据不同需求的不同特点，再去做单独的设计
在开发和测试过程中，没有必要直接把全部的历史数据拿过来做测试这主要是因为在各个环节中都可能要消耗很多时间等待，后续的开发和测试发现失败或鍺有错误后将流程进行修正，还需要再重新完整的跑一遍
你可以认为，一个流程只要一个晚上能处理完到第二天上班时能看到结果僦可以了。但是如果后续的测试验证数据流程有bug，那么就意味着还要跑一个晚上这样项目进度很难保证。即使是一个要跑一个小时的鋶程你可以算算一天有几个小时可以反复的开发和测试然后又去验证这个过程呢？
所以这里建议在开发和测试的过程中只拿一小部分數据，比如在10年的数据中只取一年或者一个月的，或者在所有产品品牌中只取一个或者几个品牌做整个项目的BI流程测试，最后验证的吔只是这一小部分数据等这些小数据处理成功后，再去处理完整的数据
数据的抽取方法，可以在数据源视图中进行限制也可以通过汾区来动态控制。我个人建议选择前者操作起来比较容易些，不需要经常更改Cube的结构
解决处理慢的问题，基本上就是从性能方法和設计上下手，根据不同的场景可以选择不同的方案
此外，可以参考这篇《设计警告规则（Analysis Services - 多维数据）》
总之解决问题的方法很多，这裏只列举一些比较常见的问题以及我个人的建议其它有代表性的问题也欢迎大家列出来在这里做进一步的探讨。
最后希望这篇对大家囿帮助。
