数据仓库 - 调整

• 

  简述

  数据仓库不断发展，并且无法预测用户将来要发布的查询。因此，调整数据仓库系统变得更加困难。在本章中，我们将讨论如何调整数据仓库的不同方面，例如性能、数据加载、查询等。
• 

  数据仓库调优难点

  由于以下原因，调整数据仓库是一个困难的过程 -

  • 数据仓库是动态的；它永远不会保持不变。
  • 很难预测用户将来会发布什么查询。
  • 业务需求随时间变化。
  • 用户及其个人资料不断变化。
  • 用户可以从一个组切换到另一个组。
  • 仓库上的数据负载也随时间变化。

  注意− 全面了解数据仓库非常重要。
• 

  绩效评估

  这是一份客观的绩效衡量标准清单 -

  • 平均查询响应时间
  • 扫描率
  • 每天使用时间查询
  • 每个进程的内存使用
  • I/O 吞吐率

  以下是要记住的要点。

  • 有必要在服务水平协议（SLA）中指定措施。
  • 如果响应时间已经比要求的要好，那么尝试调整响应时间是没有用的。
  • 在进行绩效评估时，必须有切合实际的期望。
  • 用户具有可行的期望也很重要。
  • 为了向用户隐藏系统的复杂性，应该使用聚合和视图。
  • 也有可能用户可以编写您没有调整过的查询。
• 

  数据加载调整

  数据加载是夜间处理的关键部分。在数据加载完成之前，不能运行其他任何东西。这是系统的入口点。

  注意− 如果数据传输延迟或数据到达延迟，则整个系统会受到严重影响。因此，首先调整数据负载非常重要。

  下面讨论了多种调整数据负载的方法 -

  • 最常见的方法是使用SQL Layer. 在这种方法中，需要执行正常的检查和约束。当数据被插入到表中时，代码将运行以检查是否有足够的空间来插入数据。如果没有足够的空间可用，则可能必须为这些表分配更多空间。这些检查需要时间来执行，并且对 CPU 的消耗很大。
  • 第二种方法是绕过所有这些检查和约束，将数据直接放入预格式化块中。这些块随后被写入数据库。它比第一种方法更快，但它只能处理整个数据块。这可能会导致一些空间浪费。
  • 第三种方法是在将数据加载到已经包含该表的表中的同时，我们可以维护索引。
  • 第四种方法是将数据加载到已经包含数据的表中，drop the indexes & recreate them当数据加载完成时。第三种和第四种方法之间的选择取决于已经加载了多少数据以及需要重建多少索引。
• 

  完整性检查

  完整性检查高度影响负载的性能。以下是要记住的要点 -

  • 完整性检查需要受到限制，因为它们需要强大的处理能力。
  • 应在源系统上应用完整性检查以避免数据加载性能下降。
• 

  调优查询

  我们在数据仓库中有两种查询 -

  • 固定查询
  • 即时查询

  固定查询

  固定查询定义明确。以下是固定查询的示例 -

  • 定期报告
  • 计划查询
  • 常见聚合

  在数据仓库中调整固定查询与在关系数据库系统中相同。唯一不同的是查询的数据量可能不同。测试固定查询时最好存储最成功的执行计划。存储这些执行计划将使我们能够发现不断变化的数据大小和数据倾斜，因为这会导致执行计划发生变化。

  注意− 我们不能在事实表上做更多，但在处理维度表或聚合时，可以使用 SQL 调整、存储机制和访问方法的常用集合来调整这些查询。

  即时查询

  要了解临时查询，了解数据仓库的临时用户很重要。对于每个用户或用户组，您需要了解以下内容 -

  • 组内用户数
  • 他们是否定期使用临时查询
  • 他们是否经常使用临时查询
  • 他们是否偶尔以未知的时间间隔使用临时查询。
  • 他们倾向于运行的最大查询大小
  • 他们倾向于运行的查询的平均大小
  • 他们是否需要深入访问基础数据
  • 每天经过的登录时间
  • 日常使用高峰时间
  • 他们在每个高峰时段运行的查询数量

  Points to 注意

  • 跟踪用户的配置文件并确定定期运行的查询非常重要。
  • 执行的调整不会影响性能也很重要。
  • 识别经常运行的类似查询和临时查询。
  • 如果识别出这些查询，则数据库将更改并且可以为这些查询添加新索引。
  • 如果识别出这些查询，则可以专门为那些将导致其有效执行的查询创建新的聚合。