Dwh 简明教程
Data Warehousing - Tuning
数据仓库不断发展,无法预测用户将来会发布什么查询。因此,调整数据仓库系统变得更加困难。在本章中,我们将讨论如何调整数据仓库的不同方面,例如性能、数据加载、查询等。
Difficulties in Data Warehouse Tuning
由于以下原因,调整数据仓库是一项困难的过程:
-
数据仓库是动态的;它永远不会保持恒定。
-
很难预测用户将来会发布什么查询。
-
业务需求会随着时间的推移而改变。
-
用户及其个人资料不断变化。
-
用户可以从一个组切换到另一个组。
-
仓库上的数据负载也会随着时间的推移而变化。
Note − 对数据仓库有全面的了解非常重要。
Performance Assessment
下面是有关性能的客观衡量标准。
-
Average query response time
-
Scan rates
-
每天查询所用时间
-
Memory usage per process
-
I/O throughput rates
以下为需要记住的要点。
-
必须在服务级别协议 (SLA) 中指定衡量标准。
-
如果响应时间已经优于所需响应时间,则尝试调优响应时间没有任何用处。
-
在进行性能评估时,必须有切合实际的期望非常重要。
-
同样重要的是,用户必须有切合实际的期望。
-
为了对用户隐藏系统的复杂性,应使用聚合和视图。
-
用户还可能编写您未进行调优的查询。
Data Load Tuning
数据加载是夜间处理的关键部分。在数据加载完成之前,不能运行其他任何操作。这是进入系统时的入口。
Note − 如果数据传输延迟或数据到达延迟,则整个系统都将受到严重影响。因此,首先调优数据加载非常重要。
有不同的数据加载调优方法,如下所述 −
-
一种非常常见的方法是使用 SQL Layer 插入数据。在此方法中,需要执行常规检查和约束。当数据插入到表中时,代码将运行以检查是否有足够的插入数据空间。如果没有足够的空间,则可能必须为这些表分配更多空间。这些检查需要花费时间并且需要大量的 CPU。
-
第二种方法是绕过所有这些检查和约束,并将数据直接置于预格式化块中。这些块稍后会被写入数据库。此方法比第一种方法更快,但它只能用于整个数据块。这可能导致一些空间浪费。
-
第三种方法是在将数据加载到已包含表的表中时,我们可以维护索引。
-
第四种方法表明,若要将数据加载到已包含数据的表中,请在数据加载完成后 drop the indexes & recreate them 。第三种方法和第四种方法之间的选择取决于已加载了多少数据以及需要重建多少索引。
Tuning Queries
数据仓库中有两种查询 −
-
Fixed queries
-
Ad hoc queries
Fixed Queries
固定查询定义明确。以下是固定查询的示例 −
-
regular reports
-
Canned queries
-
Common aggregations
数据仓库中固定查询的调整与关系数据库系统中的调整相同。唯一的区别在于要查询的数据量可能不同。在测试固定查询时,最好存储最成功的执行计划。存储这些执行计划将使我们能够发现不断变化的数据大小和数据偏斜,因为它将导致执行计划发生更改。
Note − 我们不能对事实表进行更多操作,但在处理维表或汇总时,可使用通常收集的 SQL 调整、存储机制和访问方法来调整这些查询。
Ad hoc Queries
要理解即席查询,了解数据仓库的即席用户非常重要。对于每个用户或用户组,你需要了解以下内容 −
-
组中的用户数
-
他们是否定期使用即席查询
-
他们是否经常使用即席查询
-
他们是否偶尔在未知的时间间隔使用即席查询。
-
他们倾向于运行的最大查询大小
-
他们倾向于运行的平均查询大小
-
他们是否需要钻取访问基础数据
-
每天的已用登录时间
-
每日使用高峰时间
-
他们在高峰每小时运行的查询数
Points to Note
-
跟踪用户个人资料并识别定期运行的查询非常重要。
-
同样重要的是,执行的调整不应影响性能。
-
识别频繁运行的类似查询和即席查询。
-
如果识别出这些查询,那么数据库将会改变,并且可以为那些查询添加新索引。
-
如果识别出这些查询,那么便可以为那些将会导致其有效执行的查询专门创建新的聚合。