版权声明：该系列文章（DW2.0下一代数据仓库架构）内容系作者学习用笔记，
欢迎共同学习，所载内容版权归原书作（译）者所有，请勿转载商用。
好的性能对于一个有效的DW2.0数据仓库至关重要，并且在整个DW2.0环境中都很有必要。
在DW2.0中，有很多适用的性能。交互区有在线响应性能或者OLTP性能，OLTP是以秒来度量的。在整合区有分析性能，对于
不同的分析活动，相应时间可能以秒或者分钟来度量。在归档区，相应时间则是以天来度量的。相应时间是相对的。响应时间的
度量单位和期望值随着人物的内容和地点不同而不同。但是在整个DW2.0环境下响应时间都是很重要的。
在线响应时间
在线响应时间的正常期望值是2-3秒，通常又常被称为实时响应时间，它是在交互区中完成的。
在线响应时间：从用户按下向计算机发送事务的键开始到返回用户的第一个响应之间的时间。
在线响应过程：
1、事务被传输至网络，到应用系统；
2、事务在系统队列中等待，直到执行该事务的系统资源可用；
3、应用服务器处理事务的应用部分；
4、应用服务器调用DBMS完成数据的操作；
5、事务执行完成，离开应用；
6、结果通过网络传输至用户；
为了达到好的响应时间，这些操作必须在几秒之内完成。
影响事务性能的因素包括：
1、冗长的活动，比如网络传输；
2、数据库的输入和输出；
3、在队列或其他地方的等待；
4、事务本身大的的任务量；
分析响应时间
分析响应时间问题涉及到整合区、归档区，偶尔也和近线区相关。分析响应时间的期望值一般在10秒和一小时之间。
分析环境相较于事务处理环境：
1、做出的决策的战略性要强于战术性；
2、分析型处理所需的数据量要远多于事务型处理所需的数据量；
3、在整天中可预知的数据流动相对较少；
数据的流动
整个系统中的数据流大体和事务处理中所描述的相同。两者数据流关键的不同在于：
1、分析性处理所需的数据量要显著多于事务型处理所需的数据量。收集大量的数据用于分析需要大量的数据输入和输出，而
这样的输入和输出操作会明显减慢计算机的速度。
2、分析型事务的排队等待时间取决于在队列中等待被执行的其他分析活动。对于分析活动，在队列中的时间是不可预知的，
并且时间会很长。
因此对于分析活动，响应时间一般相较于事务型的事务不可预知。
当事务型处理的性能变差时，将会在公司于客户交互的地方队公司的业务产生影响，如队列等待。真正对事务响应时间产生
消极影响的不是已给事务的执行，而是等待队列中等待执行的事务的积累效应。事务处理性能较差以及长时间的队列等待时间所
带来的最坏的问题就是这种影响已经被公司的用户直接感知。
在分析型环境中，低下的性能表现同样也会产生消极影响，它影响分析者为管理层准备消息的效率。
启发式处理
分析型事务较差的性能对于分析团队的消极影响主要是因为分析型处理的实现方式是启发式进行的。这种方式使得分析活动
几乎没有任何计划安排。因为启发式分析中的每个步骤都需要完全依赖上一步骤的完成效果。所以，在启发式处理时，分析过程
是没有组织、没有计划路径。
分析的生产率和响应时间
启发式分析完成的速率完全取决于分析型处理完成的快慢。分析型处理完成的越快，就能越快的得到最终结果。
事务处理性能差可以直接被公司的顾客直接感受到；而分析型事务性能差会在公司内部本分析人员感受到，对于公司而言，事务型
响应时间差在短期内更具有破坏性。
上面分析了数据仓库的事务型响应时间和分析型响应时间差对公司的影响，下面注重讲如何提高DW2.0数据仓库的响应时间
一、索引
针对数据仓库性能的一个最简单的设计方法是创建索引。如果创建了索引，系统就不用为了定位和获取所需信息而对所有数据进行
顺序查找。
对于已经创建了索引的数据库，当一个人在数据库中查询某些数据记录时，它首先会查阅索引。如果在索引中可以直接查找到
对应的数据信息，就可以直接访问它，这样就极大地减少了数据库的访问时间。
对数据库中的所有数据建立索引是件好事，但是这是由代价的，索引需要空间，并且当数据库的数据在不断更新，维护索引的代价也
相当大。因此索引的建立也要折中。
二、移除休眠数据
休眠数据是指那些不再被访问或者访问概率很低的数据，它由于妨碍整个系统的运行而严重影响系统性能。
每个计算机系统都有一定量的休眠数据，只有在存在非常大量的休眠数据时，系统的性能才会收到损坏。
把休眠数据从数据仓库环境中移除是一个不从的手段。虽然移除休眠数据对交互区已经是很可行的，但与整合区更是非常相关。
三、终端用户培训
在终端用户开始使用数据仓库之前要对他们进行培训，告诉用户：
1、数据库中有什么数据，这些数据的结构和格式又是怎样的？
2、怎么创建高效的数据查询？
终端用户培训在整个DW2.0环境下都是适用的，尤其是在整合区和归档区。
四、监控环境
很多人都没有对重要的数据库和技术基础设施进行监控，当问题放生时，性能监控是一个极好的用于检测和诊断问题的工具，而
当问题不能诊断时，必要的补救措施也只是猜测。与DW2.0环境相关的监控：交互区的事务监控和整合区的数据仓库监控。事务监控
监测事务处理的速度，事务处理中所用的资源和事务在等待队列中等待的时间。数据仓库监控查看休眠数据以及用户正在访问的数据。
五、容量规划
容量规划的目的是主动预测可能出现系统性能变差的时间，这样就可以在其发生之前采取补救措施。如果没有容量规划，直到
容量耗尽前系统性能可能一直很好，但是一旦资源耗尽，由于获得新设备以及技术升级不可能很快完成，整个组织都要遭受损失，直到
获取并实现了更大的容量。
虽然容量规划在整个DW2.0环境下都很重要，但与交互区尤为相关。
容量规划涉及软硬件很多方面的升级
硬件：
1、更大的主存
2、更大的缓存
3、更快的内部速度
4、存储管理的并行化
5、额外的数据存储
软件：
1、更新更快的操作系统的支持
2、并行软件的支持
3、最新软件的软件新特性的支持
六、元数据
一个可靠的元数据基础结构是好的数据仓库性能必不可少的组成部分。元数据和性能之间也许没有明显的关系，单事实上元数据
和系统性能有着实际且积极的联系。元数据是可重用性的关键。从元数据中可以清楚的直到那些分析已经完成，避免重复的分析。
七、批处理的并行
处理过程的并行化是一个真正提高性能的好方法。并行处理一个作业会减少完成该作业所需的时间，这种减少是与处理器的数量成比例。
必须注意的是，虽然很多作业时可以被并行处理，但是有些作业时不能够并行处理的。作业的并行化最为提高性能的一种方法被应用于
整个DW2.0环境。
事务处理的并行，当事务处理中发生并行时，事务被合并且集中管理，但是数据和用来操作处理的处理能力是分开管理的，这种类型的
操作系统被称为“无共享环境”，在这种无共享环境中，每个处理器拥有并且管理数据自己的数据，每个事务被完全和其他事务的执行分开
，这样就产生了极高的吞吐率。
八、工作负荷的管理
事务的类型，大小，共享相同处理程序的事务数量都对整个数据仓库所能达到的速度有直接的影响。交互区只允许少量的事务，因此速
度更快，整合区允许不同大小的事务混合在一起，一般期望得到一个综合响应时间。在归档区事务一般都很大，响应时间性能较差。从战略
的角度来看，数据朝向数据集市移动极大地提高数据仓库的性能。
九、数据集市
数据集市是用于满足一组用户的分析需求的数据集合。一般情况下，数据集市是依据不同的组织建立起来的。数据集市一般适用于适用
于适用相同的方法查看数据。通过创建一个数据集市，分析处理就从一个环境转移到下一个环境。即当数据集市被创建后，针对DW2.0环境的
处理的数据就会减少，其中的一些处理就转移到数据集市。把数据集市中的处理转移到几个物理上相互分离的处理器可以显著减少公司数据
仓库中处理成本。数据集市几乎应用于DW2.0的整合区。
十、探索工具
探索工具以和数据集市非常相似的方式来提高DW2.0的性能。
十一、将事务分为不同的类
将事务分为不同的类是提高数据仓库性能的另外一个号方法。一个组织如何决定一个事务将会是快还是慢？通常，事务需要访问的数据
越多，速度就会越慢。如果事务将访问整个数据仓库，那么速度将会非常慢，而如果事务只访问一部分数据，通常需要较短的时间。
十二、服务标准协议
一旦事务的执行速度被确定后，管理该事务执行的一种方法就是创建所谓的“服务标准协议”。“服务标准协议”是对于服务的所
期望的标准的一种声明。一般情况下，“服务标准协议”是针对事务响应时间和系统可用性的。DW2.0不同的部分有着不同的服务标准协议
例如：交互区有OLTP的响应时间；整合区有多个标准，对于近线区，有数据传输的服务标准协议。这样就有一套可度量的操作参数来概括
终端用户对于性能和可用性的期望值。服务标准协议定义了IT组织和终端用户之间的操作边界。
十三、保护交互区
直到确定数据不会被访问之前，交互区的数据不会被移动到整合区。如果过早移入到整合区，对于数据的请求会被转移到整合区，
而整合区的在线响应时间是不能保障的，这样在整合区寻找数据会消耗更长的时间，因此如果还有访问交互区数据的可能，就应该把这些
数据保留在交互区。
十四、数据分割
数据分割需要在存储数据时，将数据在物理上分割为多个离散的部分。数据分割保证了不同的数据集可以分开处理，这样极大地增强了
数据的灵活性。分割方法使用于DW2.0环境下任何存储着大量数据的部分。
十五、选择合适的硬件
在DW2.0环境下，选择合适的软硬件对性能有很大的影响。
十六、区分“农民”和“探索者”
基于数据不同的使用方式来区分处理工作也是优化性能的一个方法。“农民”是指从事的分析活动有着规律性和可预见性的终端用户。
他们在开始查找数据之前就知道他们想得到什么。而探索者的活动则很难预测，探测者可能在6个月之内不会做任何分析活动，但突然在一周
之内需要做大量的分析型处理，他们在开始之前并不确切地知道他们想要什么。农民和探索者都是DW2.0的合法用户，他们都应该得到资源，
并且都为公司的决策过程做出了颇有价值的贡献。但是需要区分这两者是因为这两种类型的数据仓库使用者进行分析活动是完全不同的，当
将这两种不同类型的用户群体的分析活动分开时，整个数据仓库环境的性能就提高了。
十七、数据的物理分组
为提高数据仓库性能，另一个应该完成的基本活动是：当大多数用户对数据进行分组使用时，将这些数据在物理上也进行分组。如果
分析者认为95%的情况下这些数据都是一起被访问的，那对于数据库设计者来说，将这些数据已其最常见的访问方式物理地组合起来就很有
意义，以这种方式将数据组合起来，系统就可以有效的获取数据。像这样根据数据被访问和使用的形式来组合数据被认为是数据的非正规化
。通常，数据的非正规化对于公司数据仓库来说并不是好的数据架构，不推荐使用，除非确定一个极其有必要的、一致的和持久的数据子集
访问方式。
十八、检查自动产生的代码
检查由分析工具产生的代码是提高数据仓库性能一个好的实践。我们 通常假设分析工具可以并总是自动产生高效且有用的代码，
但这并不是一个安全的假设，因为分析工具经常产生低效的代码。因此，对于分析者来说有必要确保正在产生的代码的效率至少是符合最低
要求的。
企业用户的职责是，在系统性能出现性能衰退时通知系统管理员，通常会有服务标准协议，，它能够加强和检索企业永用户和系统管理员之间的对话。企业用户很少参与对性能的补救工
作，关注DW2.0环境内部出现的问题是系统管理员的职责。有时，企业用户会要求一个新
级别的性能。只要企业用户愿意 为性能埋单，就确实可以提升性能的级别。
总结：性能问题是整个DW2.0环境必不可少的特征。有两种类型的性能--事务型和分析型。当事务型处理的性能出现问题时，公司的操作型
活动会受到影响，而当分析型处理出现性能问题是，公司的分析能力受到影响。良好的性能是多方面共同作用的结果，包括但不局限于：
选择合适的索引
移除休眠数据
培训终端用户怎么识别好的和差的代码
监控事务和数据仓库环境，以便当性能变差时，可以有一个用于判断到底出现什么错误的起点
规划容量以便组织可以预见资源将被用完
升级、保证正在使用的是最细版本的硬件和软件
元数据，以便利用重用性，最小化所需的工作量
批处理，减少消耗的时间
事务并行，有效地处理大的工作负荷量
工作负荷量管理，保证一项工作不会因为太小而和其他工作冲突。
数据集市，完成从中央数据仓库中转出主要的分析性处理
探索工具，将统计性处理移动到其他的位置进行
基于事务所要使用的资源将事务分成不同的类
服务标准协议，建立量化的指标来衡量性能
保护交互区来最小化资源的争夺
选择合适的硬件和软件来实行性能
区别农民和探索者的工作
非正规化数据，将经常会被同时访问的数据物理地放在一起
检查由工具（如商业智能工作）自动产生的代码
DW2.0下一代数据仓库架构_第15章 DW2.0和性能(读书笔记)
原文：http://blog.itpub.net/26613085/viewspace-1309063/