- 数据仓库教程
- DWH - 首页
- DWH - 概述
- DWH - 概念
- DWH - 术语
- DWH - 交付流程
- DWH - 系统流程
- DWH - 架构
- DWH - OLAP
- DWH - 关系型OLAP
- DWH - 多维OLAP
- DWH - 模式
- DWH - 分区策略
- DWH - 元数据概念
- DWH - 数据超市
- DWH - 系统管理员
- DWH - 流程管理员
- DWH - 安全性
- DWH - 备份
- DWH - 调优
- DWH - 测试
- DWH - 未来展望
- DWH - 面试题
- DWH 有用资源
- DWH - 快速指南
- DWH - 有用资源
- DWH - 讨论
数据仓库 - 调优
数据仓库不断发展,用户未来将提出什么样的查询是不可预测的。因此,调整数据仓库系统变得更加困难。本章将讨论如何调整数据仓库的不同方面,例如性能、数据加载、查询等。
数据仓库调优的困难
由于以下原因,调整数据仓库是一个困难的过程:
数据仓库是动态的;它永远不会保持不变。
很难预测用户未来将提出什么查询。
业务需求会随着时间而变化。
用户及其配置文件不断变化。
用户可以从一个组切换到另一个组。
仓库上的数据负载也会随着时间而变化。
注意 - 掌握数据仓库的完整知识非常重要。
性能评估
以下是性能目标衡量指标的列表:
- 平均查询响应时间
- 扫描速率
- 每天查询所用时间
- 每个进程的内存使用量
- I/O 吞吐率
以下是需要记住的几点。
有必要在服务等级协议 (SLA) 中指定这些指标。
如果响应时间已经优于所需时间,则尝试调整响应时间是没有用的。
进行性能评估时,必须有现实的期望。
用户也必须有切实可行的期望。
为了向用户隐藏系统的复杂性,应使用聚合和视图。
用户也可能编写您尚未调整的查询。
数据加载调优
数据加载是隔夜处理的关键部分。在数据加载完成之前,其他任何操作都无法运行。这是进入系统的入口点。
注意 - 如果数据传输或数据到达延迟,则整个系统将受到严重影响。因此,首先调整数据加载非常重要。
下面讨论了各种数据加载调优方法:
最常见的方法是使用SQL 层插入数据。在这种方法中,需要执行正常的检查和约束。当数据插入表中时,代码将运行以检查是否有足够的空位来插入数据。如果可用空间不足,则可能需要为这些表分配更多空间。这些检查需要时间来执行,并且对 CPU 的消耗很大。
第二种方法是绕过所有这些检查和约束,并将数据直接放入预先格式化的块中。这些块随后写入数据库。它比第一种方法更快,但只能与整个数据块一起使用。这可能会导致一些空间浪费。
第三种方法是在将数据加载到已经包含数据的表中时,我们可以维护索引。
第四种方法是,要将数据加载到已经包含数据的表中,删除索引并重新创建它们,当数据加载完成后。第三种方法和第四种方法的选择取决于已经加载了多少数据以及需要重建多少索引。
完整性检查
完整性检查严重影响加载性能。以下是需要记住的几点:
需要限制完整性检查,因为它们需要大量的处理能力。
应在源系统上应用完整性检查,以避免数据加载性能下降。
查询调优
数据仓库中有两种查询:
- 固定查询
- 即席查询
固定查询
固定查询是明确定义的。以下是固定查询的示例:
- 定期报告
- 预定义查询
- 常用聚合
调整数据仓库中的固定查询与在关系数据库系统中相同。唯一的区别在于要查询的数据量可能不同。在测试固定查询时,最好存储最成功的执行计划。存储这些执行计划将使我们能够发现变化的数据大小和数据倾斜,因为它会导致执行计划发生变化。
注意 - 我们无法对事实表做更多操作,但在处理维度表或聚合时,可以使用通常的 SQL 微调、存储机制和访问方法集合来调整这些查询。
即席查询
要了解即席查询,重要的是要知道数据仓库的即席用户。对于每个用户或用户组,您需要了解以下内容:
- 组中用户的数量
- 他们是否定期使用即席查询
- 他们是否经常使用即席查询
- 他们是否偶尔在未知的时间间隔内使用即席查询。
- 他们倾向于运行的最大查询大小
- 他们倾向于运行的平均查询大小
- 他们是否需要对基础数据的钻取访问
- 每天经过的登录时间
- 每日使用高峰时间
- 他们每小时高峰运行的查询数量
需要注意的几点
跟踪用户配置文件并识别定期运行的查询非常重要。
执行的调整不会影响性能也很重要。
识别经常运行的类似和即席查询。
如果识别出这些查询,则数据库将更改,并且可以为这些查询添加新的索引。
如果识别出这些查询,则可以专门为这些查询创建新的聚合,这将导致其高效执行。