Loading
0

避免在数据仓库和BI项目上出现这些错误:第3部分

在本系列的第1部分第2部分中,描述了数据仓库(DW)和商业智能(BI)项目如何成为许多组织的高度优先事项。项目发起人寻求在整个企业中授权更多更好的数据驱动决策和行动; 他们打算扩展其用于BI,分析和数据发现的用户基础,以便用户做出明智的决策。

避免的这一系列错误集中在帮助组织回避DW项目中遇到的数据质量问题。 此处提供的提示将有助于确保DW团队计划和实施新功能时的满意度。

以下是各种实践者遇到的更多错误:

取决于BI报告测试以发现数据仓库中的缺陷

DW项目充满挑战-从仓库中的数据质量到BI报表中的派生值。如果不能及时解决,那么糟糕的数据质量(尤其是在数据仓库中)可能会导致整个项目停顿。

由于缺乏数据质量,数据仓库常常不能达到预期的效果。 研究表明,将数据从源移动到数据仓库和数据保管库的各个区域时,数据质量通常会下降。在开始加载源时以及在清理,转换,聚合和集成到数据仓库的每个步骤中,应该对数据质量进行彻底的评估。

以下是五个DW数据问题(在多项研究中均已确定),这些问题发生的可能性最大,并直接影响项目的成功。请注意,这些风险很少与BI报告中的缺陷相关。

  • 源数据质量错误-来自内部和外部源
  • 源到目标的数据映射和架构错误
  • 多个ETL流程导致的数据错误
  • 查询性能问题ETL流程
  • 数据清理和转换错误

BI和分析报告测试应全部关于确保从数据仓库正确访问数据,定义报告布局,满足可用性要求,报告向下钻取和汇总正常工作。当您得知数据集市中的数据丢失或重复或者在ETL验证期间应该发现的其他缺陷时,则不应进行BI报告测试过程。

qlik界面视图

无法充分执行DW性能,负载和压力测试

大多数项目经理不会在其DW项目的开发过程中延迟功能和数据质量测试。但是,太多的DW项目正在开发生命周期的后期阶段测试性能,负载,压力,安全性和恢复-有时没有足够的时间来纠正发现的任何重要问题。

不合格的性能可能是取消DW项目的重要原因。应该针对查询响应时间和ETL时间(例如每小时,每天)探索DW性能。 当访问数百万或更多行进行计算时,查询响应时间可能长达几分钟。 除少数例外,这是不可接受的。这样的性能将负面影响DW对用户的可用性。

DW性能在很大程度上取决于数据库性能。老式的开发方法将性能测试保留在开发生命周期的后期。 根本不可能提早测试性能,因为直到游戏后期才有代表性的工作系统。

敏捷数据库性能测试的一些最佳实践包括:

  • 制定绩效测试计划:应该确定针对单个交易和常见用例的测试。 测试负载应配置为在从空闲到断点应力测试的各种负载下测试吞吐量。 并发测试应改变目标数据,以识别应用程序框架和数据库级别的缓存问题。
  • 提供足够的时间和预算:用于部署合适的性能测试环境。 性能测试平台应具有生产规模或可量化的比例。
  • 规划实际可扩展的数据:这可以是生产快照(对于现有系统),或者可能需要针对新的或快速增长的系统进行实际可扩展的综合数据。

无法向项目团队提供足够的测试结果指标

在测试团队中,关键的可交付成果之一是传递测试工作进度和测试状态的信息。测试指标对于了解当前的测试工作并考虑开发和测试中需要的改进至关重要。

如今,许多DW测试是由业务分析师,数据分析师和开发人员进行的。结果,许多DW项目上的可行测试指标可能不可用。许多QA团队的成员减少了对DW测试的参与,部分原因是缺乏与数据相关的技术技能,这是测试DW项目所需的技能。

始终需要与质量保证相关的指标。您的项目团队将只能改进和控制在计划,开发,执行和完成测试时所测量的内容,这些测试使用量化进度和成功的指标来报告。

质量保证指标必须设计为值得信赖,并用于制定可行的项目决策。在DW测试期间开发的度量标准为项目和业务经理提供了两个主要好处:可以查看1)发布到生产中的成熟度和准备情况,以及2)开发中的软件产品的质量。测试报告通过清楚地评估DW项目的质量和完整性,可以有效地管理软件开发过程。

每个DW主要质量类别的度量标准-数据库管理质量,数据模型/架构质量,数据仓库数据质量-理想情况下应包括:测试用例通过/失败度量标准,生产率度量标准(即计划的测试是运行还是未运行) ,DW组件的缺陷率密度,按优先级/严重性发现的缺陷以及测试未涵盖的要求。

质量检查团队应向利益相关者提供测试指标,以证明其测试进度。而且,质量保证指标可帮助项目涉众制定出行与不行项目决策。


慧都 BI 提供Qlik的产品和技术服务,更有企业级BI业务分析解决方案,我们拥有包括TableauPower BI和 IBM Cognos全球领先的BI产品,并提供相关解决方案,让数据创造无限价值。详情可咨询慧都网在线客服>>