DW Performance Notes

第一章 DW性能的要素

1.1 性能度量

查询的响应时间

• 查询提交到返回第一行数据的时间
• 查询提交到最后一行数据的时间

我的理解：响应时间是一个直观的用户体验。本质上是查询所消耗的CPU 时间，IO开销，PE效率（并行系统）

1.2 生产效率

响应时间快对用户的生产效率有很大的帮助。更及时知道业务的变化。

1.3 数据容量

数据量越大，查询性能越差。

有如下几种方法提高大数据量的查询：

• Denormalization （ 通过预计算值、物理存放相关数据在一个数据块上来减少连接和计算操作）对Denormalization要审慎，因为Denormalization只对特定一部分用户提高了访问性能，对其他用户是降低了访问性能和提高了数据异常的可能性。
• Indexing（index提高了访问性能，但是增加了额外的空间和管理开销，其次index无法解决未知的问题）
• Parallelism（硬件架构以提升性能）
• Archiving （休眠数据）

第二章 DW用户分类

了解你的用户，以及用户怎样使用数据，是提高DW性能很重要（可能是最简单直接的）的方法。

2.1 Farmer 和 Explorer

• Farmer 是用predefined查询，使用OLAP分析（star schema），分析企业的运营状况（KPI, ScoreCard等汇总数据
• 多维度分析
• 有限的数据概要分析（data profiling）
• Explorer是Ad hoc查询，从数据中挖掘知识，发掘让业务增长或发展新业务的方向，通过分析会制定新的feature、营销策略和CRM方法，一般3NF满足非确定性的分析。

• 数据概要分析
• 数据抽取（选取）
• 模型建立（数据训练，建立抽象模型）
• 数据分类
• 有限的多维度分析

2.2 其他分类方法

• 职员和管理层
• 职员，往往是operational 数据分析（ODS IV），数据量很少
• 管理层，往往战略制定，数据量很大
• 非技术用户和技术用户
• 非技术用户，不懂技术，希望分析结果很容易呈现在其眼前。类似不会写SQL的那些人。
• 技术用户，很懂技术知道如何使用DW，懂Join。
• 预定义和Ad hoc查询
• 预定义查询不应该具有性能问题
• Ad hoc可能有性能问题
• 汇总和细节
• 汇总数据具有性能优势，但是丢失了信息以及需要元数据管理描述汇总算法
• 细节数据具有高度灵活性和可扩展性，但是性能很差