用SQL Server 2005构建高性能数据仓库(一)
用SQL Server 2005构建高性能数据仓库(二)
【IT168 专稿】
从索引策略、索引的分片以及快速载入与查询性能的等方面对表的设计进行阐述后后，接下的此篇将讲述怎么样优化数据仓库环境方面的知识。
四．优化数据仓库环境
1．聚合策略
观察那些允许SQL Server直接的、特别的查询的客户通常对临时总结表非常有用处。分析服务怎么样获得性能也不是一件值得惊讶的事情。这个问题在于用户（通常被成为“超级用户”）常常是那些做总结，并且是常常对相同的信息一次一次做总结的人，因此他们没有注意到另外的用户也在做这些操作。然而这对系统资源产生了很大的影响。前聚合在某些地方被存储，或者是在源数据库中，或者是在tempdb中。如果这些信息被重复的存储，磁盘消耗将会是很巨大的。当这些东西在高峰期被构建时，存储需求能够变得非常巨大，因为所有用来支持摘要的详细数据必须读入到内存中。
（1） 设计摘要性的表
一个策略性和高效率的目标是设计和实现永久摘要表的少部分，以便包含前聚合的信息。
下面是设计摘要表的一个实例过程：
l 收集一个好的查询取样；
l 分析维度层次级别的、维度属性和实际表测量；
l 识别与每一个表现出来的维度级别相关的行数；
l 平衡最常见的查询维度级别和在结果摘要表中的行数。
（2） 分析服务
那些对SQL Server的分析服务（SSAS）已经习惯的人可能已经注意到在这份白皮书中的很多推荐都是用的SSAS中的默认值。SSAS中的性能的优化直接来自于它的内在的决定对于空间数据的最好的前聚合算法和动态的导航能力。
它的优点如下：
l 在这份白皮书中提及到的很多手工的进程，特别是考虑到前聚合的那些，都被构建到分析服务中；
l 将分析查询提交给服务器以及允许管理员制定一个基于这些查询的聚合设计是一个半自动的过程；
l 很多第三方的应用程序被设计来读取SSAS的元数据以及用户友好的特定的查询界面；
l 没有显式的报告模型被设计，报告构建器能够从SSAS中直接的产生一个模型；
l 聚合设计更加方便；
l 查询性能变得更加好。
缺点如下：
l SSAS的节目化的接入必须使用MDX（Multidimensional Extensions）；
l 在SQL Server和分析服务中技能集有很少有交替；
l 维度处理比起显式的维护摘要表不太方便；
l 并不是所有的数据都在立方体中有空间；
l 在很大的实际表中查询必须接触每一个实体。
（3） 设计摘要表的一个过程
设计摘要表并不是一个简单的工作，并且需要从报表和特别的查询所载入的数据的期望和观察到的查询的一个相当大的数量。记住你想要设计尽可能少的摘要表来满足最大数量的查询。
（4） 索引化的视图与摘要表
所有摘要表的维护的自动化是非常有用的。通过使用索引化的视图（SQL Server的特性，表示前聚合的数据）来使得其更大的便利化。这由于索引视图的特征看起来是逻辑性的一步。
这里有一些索引视图必须遵循的一些需求，但是，作为一个摘要实际表的实现来说是比较困难的。下面的需求是与之相关的：
l 不允许进行外连接。如果不止一个实际表被摘要并且行的交集没有保证，外连接将会
l 被需要。一个很好的例子是在用来分析销量和投资的数据仓库中，销量和投资相关的实际表将可能既包括满足键联合的行，迫使进行一个全外连接（FULL OUTER JOIN）；
l 在一个分离实际表上的一个SWITCH操作需要任何的索引化视图基于那些被舍弃和重建的表中；
l 索引化的视图需要一个独特的、集群的索引作为第一索引。这可能需要附加的行加到索引中。如果在索引视图上有一些额外的索引，既然一个很长的集群索引key将会永存在非集群中的索引中；
l 为了一个自动的在一个指定的表的指定的查询中使用索引视图，查询的条件必须以特定的顺序存在。
索引视图的一个明显的好处是它们自动的由SQL Server维护。这种好处是非常巨大的，因此索引视图必须明确的被考虑。你能够使用NOEXPAND提示直接的查询索引视图，为了获得索引视图的益处以便进行过程性能改进，需要联合自动的摘要维护的连接。
就像前面所描述的，一个可替换的索引视图是很清楚的摘要表。这些表必须手动的维护并且直接的在查询中使用。前面的问题是一个很大的问题。
为了更好的揭示摘要表的价值，让我们看一个相对简单，但是很现实的查询例子：
SELECT Subject, SUM(Sales.Sales_Qty) AS Sales_Qty
FROM Tbl_Fact_Store_Sales as Sales JOIN Tbl_Dim_Store Store ON Sales.SK_Store_ID = Store.SK_Store_ID
JOIN Tbl_Dim_Date Date ON Sales.SK_Date_ID = Date.SK_Date_ID
JOIN Tbl_Dim_Item Item ON Sales.SK_Item_ID = Item.SK_Item_ID
WHERE Date.Fiscal_Period_Desc IN ('F04 P5 (JUN)') AND Store.Region = 'West'
GROUP BY Subject
ORDER BY Sales_Qty DESC
Avg response time: 1 minute 43 seconds
这个查询直接的引用了详细的实际表。不仅仅使得它运行，而且每一个相关的细节记录被读入到缓冲缓存中，在下面的语句中，查询被重写，为了对我们的摘要表而不是细节进行引用。它改善了87%的查询时间，语句如下：
SELECT Subject, SUM(Sales_Qty) AS Sales_Qty
FROM Tbl_Fact_Summary as summary JOIN (SELECT DISTINCT Region, District_Num FROM Tbl_Dim_Store) Tbl_Dim_Store ON summary.Store_District_Num = Tbl_Dim_Store.District_Num
JOIN (SELECT DISTINCT Subject, Category_Code FROM Tbl_Dim_Item) Tbl_Dim_Item
ON summary.Item_Category_Code = Tbl_Dim_Item.Category_Code
JOIN Tbl_Dim_Date ON summary.Date_Summary_Key = Tbl_Dim_Date.SK_Date_ID
WHERE Tbl_Dim_Date.Fiscal_Period_Desc IN ('F04 P5 (JUN)')
AND Tbl_Dim_Store.Region = 'West'
GROUP BY Subject
ORDER BY Sales_Qty DESC
Avg response time: 13 seconds
维护摘要表的花费应该得到小心的控制。ETL进程能够被修改以便能明了更新的日期。这些信息能够被使用来仅仅更新在摘要表中影响的行中的聚合。保证更新的环境被紧紧的控制以便使得摘要表中的数量常常是正确的。它怎么样进行控制取决于ETL过程是如何的被执行。
（5） 改善摘要表的性能
创建的摘要表必须处于一个连接维度表的大部分的情况下。例如，如果详细的实际数据在一个日期维度的天的级别上，摘要的日期可能是周、月等级别。在这个点上，你或者需要为那些级别携带相关的属性，或者对维度连接回去以便获取这些信息。你将常常选择后续的选项，特别是如果这里有一些属性必须的时候。如果这些维度表改变或者也改善了构建和维护的摘要表性能的时候，这些结果将更加便利。如果维度表设计师摘要表的基础，这是用的雪花的方式，这是相当容易的。
（6） 表和报表构造器的总结
我们已经展示了摘要表怎样能够为大部分查询提供强大的便利。写Transact-SQL查询并且能够懂得摘要表的内容，以及怎样使用它们的“超级用户”能够将它们合并到日常的查询工作中来加强性能。典型的商业用户将具有更少的技能集来构建查询代码，并且没有时间或没有意向来学习这项技能。
SQL Server 2005报表服务发布了一个组件来便利特别的查询，它叫做报表构建器，它是为特定类型的用户准备的。为了报表构建器来报告SQL Server相关的数据库，一个或者更多的报表模型必须被定义。一个报表模型能够构建在DSV（data source view）上，并且这两个概念加起来，能够提供工具来插入摘要表到查询中去。
有两种常用的方法来将摘要表合成到报表模型中。第一种方法是为每一个或者大多数摘要表创建一个单独的报表模型，接着为细节化的视图创建一到多个。关键在于报表模型的正确命名以便对那些当创建一个报表的时候需要的用户更加明显。这种方法的最大的问题是：如果用户选择了一个不正确的报表模型，他们将必须重新开始一个新的报表。
另一种方法是将摘要表合并到单个的报表模型中，这些报表模型常常包括细节化的实际的信息。这个将会呈现对于终端用户的数据的多个视图。当在报表模型中使用一个基于摘要的层次时，用户将会自动的接近在摘要表中剩下的维度级别信息。
在这两种方法中，与摘要级别信息相关的维度表能够来源于前面所提及的索引视图，或者在源DSV中创建的命名的查询。
五. 结论
一个可升级的、高性能的数据仓库能够不顾它下面的数据库的大小来开发。更新和查询者两个操作窗口能够通过如下的可靠的基础来构建：
l 创建一个基于健壮的硬件平台和正确配置的SQL Server环境的基础；
l 重新思考认识到的表的实践的非常好的实践。仔细的计划你的索引策略，并且使用表和索引分离来使得你的数据仓库更加的易于管理；
l 学习在你的服务器上载入的查询并且构建策略性的前聚合的策略来便利很好的查询性能。
通过开发一个深思熟虑的数据仓库策略，并且不断的监视你的批量维护和查询环境，你能够传送数据市场，这些数据市场提供了高性能和高实用性以便你的用户能够聚焦于商业智能。
