第一章 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可能有性能問題
- 彙總和細節
- 彙總數據具有性能優勢，但是丟失了信息以及需要元數據管理描述彙總算法
- 細節數據具有高度靈活性和可擴展性，但是性能很差
