标签：cube process tuning cube处理优化
OALP数据库优化之2 – Cube处理优化
当我们在OLAP数据库的世界中说起Process的时候，它至少可以分为两类：维度的处理跟Cube的处理，本部分只讨论cube的处理及优化，维度的处理优化会在另一部分讨论。
首先我们应该明确所谓处理(Process)这个概念，它可以简单的理解为将数据从一个或多个数据源加载、搬移到分析服务对象中的过程，对Cube处理来说就是加载到度量值组分区中的过程，所以Cube处理的优化其实归根结底是分区的处理优化。
如下图所示，分区的处理过程可以分为两步：
1. 处理事实数据
处理事实数据简单的说就是将数据从数据源搬到分区对象的过程，因为分区中的事实数据需要关联到维度，所以中间还有一步是查找与事实数据对应的已经处理的维度键值。下面三步并行执行已完成事实处理：
发送SQL查询来从源中抽取数据，好像是每次10万行
为上面读入的1万行数据在分析服务的维度对象中查找响应的维度键值，然后填充到处理缓存中
当处理缓存满的时候，将数据写入到磁盘中
2. 构建聚合及位图索引
在事实数据被处理到分区对象之后，处理就开始构建聚合及位图索引。聚合的处理是在内存中进行的，如果内存不足以构建所有的聚合，那么就会一块一块的先写入到磁盘的临时文件，在处理的最后做合并。
在设计OLAP数据库的时候我们应该在聚合上做均衡的考虑，因为大量的聚合肯定会提高查询的效率，但是同时会降低处理的效率。
分区的处理是通过向OLAP数据库发出分区处理命令进行的，主要有以下的分区处理命令：
ProcessFull
全处理会首先删除现有的存储内容(事实数据、聚合及位图索引)，然后首先执行ProcessData过程，紧接着执行ProcessIndexes
ProcessData
处理数据命令也是首先删除现有的存储内容(事实数据、聚合及位图索引)，然后处理事实数据，但是不会构建聚合及位图索引
ProcessIndexes
该命令执行的时候假设事实数据已经存在了，它在事实数据上构建新的聚集及位图索引
ProcessAdd
该命令创建一个临时分区，在其上执行完全执行，最后将临时分区Merge到目标分区中。该命令式一个XMLA命令，在UI上名为ProcessIncremental
ProcessClear
删除分区中现有的存储内容，它是XMLA的命令，在UI上名为UnProcess
ProcessClear Indexes
仅删除分区中的聚合及位图索引
我们可以使用SQL Server自带的Profiler来对OLAP数据库的处理做监控，首先我们需要知道Profiler中哪些Events是用来监控OLAP处理的，其实这个问题比较显而易见，所有与之相关的事件都处于Process Reports这个目录下面，包括：
Process Report Begin
事件ID为5，它表示所有OLAP数据库相关的处理报告的开始事件
Process Report Current
事件ID为7，它表示所有进度报告当前状态事件。例如，在处理期间，当前报表包含有关被处理的对象（维度、分区、多维数据集等）的处理信息
Process Report End
事件ID为6，它表示所有OLAP数据库相关的处理报告的开始事件
Process Report Error
事件ID为8，它表示所有处理报告错误事件
从我个人的使用情况来说，我一般只使用Process ReportEnd事件，因为所有的事件都是以Begin开始，中间经历Current最后以End或Error结束。因为我使用Profiler只是用来调优而不是找错，所以不需要Error事件；而任何出现在ProcessReport Begin的事件肯定最后会反应在Process Report End事件中(应该是这样的吧？)，所以ProcessReport Begin和Process Report End之间我们只需要Process Report End就可以了；对于ProcessReport Current，本人不是太明白这个事件是干什么的，不过它有一个其他事件无法代替的作用：假如度量值组有1千万数据，AS肯定是没办反一次性都读入内存然后处理的，所以它会每次读取比如10万数据来处理，然后再处理10万直至全部处理完，ProcessReport Current能捕获到现在为止处理的数据行数。
接下来我们要知道的是关于Profiler捕获到的数据都有哪些信息，说白了就是有哪些数据列。我们在此只列出最主要的数据列：
EventSubClass– OLAP数据库处理事件类，下面是一些主要的事件
Process
Merge
Delete
DeleteOldAggregations
Rebuild
Commit
Rollback
CreateIndexes
CreateTable
InsertInto
Transaction
Initialize
Discretize
Query
CreateView
WriteData
ReadData
GroupData
GroupDataRecord
BuildIndex
Aggregate
BuildDecode
WriteDecode
BuildDMDecode
ExecuteSQL
NowExecutingSQL
ExecuteModifiedSQL
Connecting
BuildAggsAndIndexes
MergeAggsOnDisk
BuildIndexForRigidAggs
BuildIndexForFlexibleAggs
WriteAggsAndIndexes
WriteSegment
DataMiningProgress
ReadBufferFullReport
ProactiveCacheConversion
Backup
Restore
Synchronize
TextData– 与事件相关的文本数据，大部分情况下是对事件的一种描述。比如对于Process事件在结束时会描述为“Finishedprocessing the XXX partition”
DatabaseName– 事件发生的数据库
ObjectName& ObjectPath 表示事件发生的对象以及该对象的路径
StartTime– 事件开始时间
Duration- 包含所报告的事件开始到结束的时间长度(只存在于ProcessReport End事件中)
EndTime- 包含所报告事件的结束时间(只存在于ProcessReport End事件中)
IntegerData– 包含与发生的事件关联的整形数据，例如已处理行数的当前计数(只存在于ProcessReport End和Process Report Current事件中)
下面我们以实际的例子来描述一下Profiler到底捕获了什么样的处理数据。对一个只有一个度量值组一个分区的Cube进行处理，Profiler捕获的事件如下：
BuildProcessing Schedule
Cube ProcessBegin
Measure Group Process Begin
PartitionProcess Begin
WriteData for Partition Begin
ExecuteSQL to get data from Source
ReadData Begin
ReadData Current – 到现在为止处理的数据行
ReadData Current – 到现在为止处理的数据行
ReadData End
WriteData for Partition End
BuildAggregation and Indexes Begin
BuildIndex
BuildAggregate
BuildAggregation and Indexes End
PartitionProcess End
Measure Group Process End
Cube ProcessEnd
毋庸置疑地有繁多的优化措施可以帮助我们提升Cube的处理效率，比如通过添加索引提升取元数据的速度，提升IO子系统，排除数据库锁等，但是在我们试图应用这些细的优化措施之前，我们应该首先确保我们应用了对Cube处理作用最大的技术：分区+增量处理。
毋庸置疑地有繁多的优化措施可以帮助我们提升Cube的处理效率，比如通过添加索引提升取元数据的速度，提升IO子系统，排除数据库锁等，但是在我们试图应用这些细的优化措施之前，我们应该首先确保我们应用了对Cube处理作用最大的技术：分区+ 分区合并+ 增量处理。
恰当的分区是提升查询机处理效率最有效的方式，假如我们一个销售事实表中包含了近10年的近亿数据，并且还在以每天几万条数据的方式在增长，那如果该度量值组只有一个分区，我们每天不得不对该度量值组做FullProcess，也就是每天都需要处理上亿的数据；但是如果我们是一天一个分区，那么我们每天只需要处理几万数据就可以了。所以分区让我们可以将历史的、固定不变的数据与最近的数据隔离开来，这样就只需要处理最近的少量数据就可以了。
不过实际中每天一个分区会造成管理的混乱，所以有时候我们可以只创建少量的分区，比如只有两个分区，一个表示历史分区，一个表示当前月数据的分区，这样每天我们只在当前月分区上做增量处理(给只处理一天的数据差不多，只是多了Merge的花费)，然后在下月的第一天我们将当前月分区的数据Merge到历史分区中。
如果每天的数据量不是特别大(比如千万甚至上亿)，该方式能够满足绝大部分的处理性能需求。
毋庸置疑地有繁多的优化措施可以帮助我们提升Cube的处理效率，比如通过添加索引提升取元数据的速度，提升IO子系统，排除数据库锁等，但是在我们试图应用这些细的优化措施之前，我们应该首先确保我们应用了对Cube处理作用最大的技术：分区+ 分区合并+ 增量处理。
恰当的分区是提升查询机处理效率最有效的方式，假如我们一个销售事实表中包含了近10年的近亿数据，并且还在以每天几万条数据的方式在增长，那如果该度量值组只有一个分区，我们每天不得不对该度量值组做FullProcess，也就是每天都需要处理上亿的数据；但是如果我们是一天一个分区，那么我们每天只需要处理几万数据就可以了。所以分区让我们可以将历史的、固定不变的数据与最近的数据隔离开来，这样就只需要处理最近的少量数据就可以了。
不过实际中每天一个分区会造成管理的混乱，所以有时候我们可以只创建少量的分区，比如只有两个分区，一个表示历史分区，一个表示当前月数据的分区，这样每天我们只在当前月分区上做增量处理(给只处理一天的数据差不多，只是多了Merge的花费)，然后在下月的第一天我们将当前月分区的数据Merge到历史分区中。
如果每天的数据量不是特别大(比如千万甚至上亿)，该方式能够满足绝大部分的处理性能需求。
如果应用了上面简单的处理方式后还不能满足处理性能的要求，那么我们可能需要参考下面一些比较琐碎的优化方式：
所谓数据源端的优化其实就是关系型数据库的优化以及OLAP分区所对应的数据查询语句的优化，这主要有以下的方式：
如果可能的话为分区查询语句构建恰当的索引，不过我们必须同时考虑到索引对数据插入的负面影响
是每个度量值组的分区对应于至多一个关系型数据库表的分区，这样每个分区的数据查询语句只会访问一个表分区
尽量从分区的数据查询语句中去除JOIN，被JOIN得出的列应该被物理化到事实表中
如果有页面切分，我们可以重构索引来提升填充因子，同时可以采用数据压缩来降低IO
通过使用NOLOCK来降低数据库锁开销
事实表的设计遵循以下的最优设计
| Surrogatekeys | tinyint, smallint, int, bigint |
| Datekey | int inthe format yyyyMMdd |
| Integermeasures | tinyint, smallint, int, bigint |
| Numericmeasures | smallmoney, money, real, float (Note that decimaland vardecimal require more CPUpower to process than money and float types) |
| Distinctcount columns | tinyint, smallint, int, bigint (If your count column is char, consider either hashing or replacing with surrogate key) |
待续….
待续….
标签：cube process tuning cube处理优化
原文地址：http://yubowang.blog.51cto.com/8929119/1562189
