ETL 测试 – 快速指南

ETL 测试 – 快速指南

ETL 测试 – 介绍

数据仓库系统中的数据使用 ETL（提取、转换、加载）工具加载。顾名思义，它执行以下三个操作 –

  • 从您的交易系统中提取数据，该系统可以是 Oracle、Microsoft 或任何其他关系数据库，

  • 通过执行数据清理操作来转换数据，然后

  • 将数据加载到 OLAP 数据仓库中。

您还可以使用 ETL 工具从电子表格和 CSV 文件等平面文件中提取数据，并将其加载到 OLAP 数据仓库中以进行数据分析和报告。让我们举一个例子来更好地理解它。

例子

假设有一家制造公司拥有多个部门，例如销售、人力资源、材料管理、EWM 等。所有这些部门都有单独的数据库，用于维护工作中的信息，每个数据库都有不同的技术、景观、表格名称、列等。现在，如果公司要分析历史数据并生成报告，则应从这些数据源中提取所有数据并将其加载到数据仓库中以保存以供分析工作。

ETL 工具从所有这些异构数据源中提取数据，转换数据（如应用计算、连接字段、键、删除不正确的数据字段等），并将其加载到数据仓库中。稍后，您可以使用各种商业智能 (BI) 工具来使用这些数据生成有意义的报告、仪表板和可视化。

ETL和BI工具的区别

ETL工具用于从不同的数据源中提取数据，转换数据，并将其加载到DW系统中；然而，BI 工具用于为最终用户生成交互式和临时报告、高级管理人员的仪表板、月度、季度和年度董事会会议的数据可视化。

最常见的 ETL 工具包括 – SAP BO 数据服务 (BODS)、Informatica – Power Center、Microsoft – SSIS、Oracle Data Integrator ODI、Talend Open Studio、Clover ETL Open source 等。

一些流行的 BI 工具包括 – SAP Business Objects、SAP Lumira、IBM Cognos、JasperSoft、Microsoft BI Platform、Tableau、Oracle Business Intelligence Enterprise Edition 等。

ETL流程

现在让我们更详细地讨论 ETL 过程中涉及的关键步骤 –

提取数据

它涉及从不同的异构数据源中提取数据。从事务系统中提取的数据因需求和使用的 ETL 工具而异。它通常通过在非工作时间运行预定作业来完成，例如在晚上或周末运行作业。

提取数据

转换数据

它涉及将数据转换为可以轻松加载到 DW 系统的合适格式。数据转换涉及对数据应用计算、连接以及定义主键和外键。例如，如果您想要不在数据库中的总收入的百分比，您将在转换中应用百分比公式并加载数据。类似地，如果您在不同的列中有用户的名字和姓氏，那么您可以在加载数据之前应用连接操作。有些数据不需要任何转换；此类数据称为直接移动或传递数据。

数据转换还涉及数据校正和数据清理、删除不正确的数据、不完整的数据形成和修复数据错误。在将数据加载到 DW 系统之前，它还包括数据完整性和格式不兼容的数据。

将数据加载到 DW 系统中

它涉及将数据加载到 DW 系统中以进行分析报告和信息。目标系统可以是简单的带分隔符的平面文件或数据仓库。

ETL工具功能

典型的基于 ETL 工具的数据仓库使用暂存区、数据集成和访问层来执行其功能。它通常是一个 3 层架构。

  • 分段层-分期层或分段数据库用于存储从不同的源的数据系统中提取的数据。

  • 数据集成层– 集成层转换来自暂存层的数据并将数据移动到数据库，在数据库中数据被排列成层次结构组，通常称为维度，以及事实和聚合事实。DW 系统中的事实表和维度表的组合称为模式。

  • 访问层– 最终用户使用访问层来检索数据以进行分析报告和信息。

下图显示了三个层如何相互作用。

ETL工具功能

ETL 测试 – 任务

ETL 测试在数据移入生产数据仓库系统之前完成。有时也称为表平衡或生产对帐。它与数据库测试的范围和完成此测试所需的步骤不同。

ETL 测试的主要目标是识别和减轻在处理数据以进行分析报告之前发生的数据缺陷和一般错误。

ETL 测试——要执行的任务

以下是 ETL 测试中涉及的常见任务列表 –

  • 了解用于报告的数据
  • 查看数据模型
  • 源到目标映射
  • 对源数据进行数据检查
  • 包和架构验证
  • 目标系统中的数据验证
  • 验证数据转换计算和聚合规则
  • 源系统和目标系统之间的示例数据比较
  • 目标系统中的数据完整性和质量检查
  • 数据性能测试

ETL 与数据库测试

ETL 测试和数据库测试都涉及数据验证，但它们并不相同。ETL 测试通常对数据仓库系统中的数据执行，而数据库测试通常在事务系统上执行，其中数据来自不同的应用程序到事务数据库中。

在这里，我们强调了 ETL 测试和数据库测试之间的主要区别。

ETL测试

ETL 测试涉及以下操作 –

  • 验证从源系统到目标系统的数据移动。

  • 验证源和目标系统中的数据计数。

  • 根据要求和期望验证数据提取、转换。

  • 验证在转换过程中是否保留了表关系 – 连接和键 – 。

常见的 ETL 测试工具包括QuerySurge、Informatica等。

数据库测试

数据库测试更强调数据的准确性、数据的正确性和有效值。它涉及以下操作 –

  • 验证是否维护了主键和外键。

  • 验证表中的列是否具有有效的数据值。

  • 验证列中的数据准确性。示例– 月数列的值不应大于 12。

  • 验证列中的缺失数据。检查是否存在实际上应该具有有效值的空列。

常用的数据库测试工具有Selenium、QTP等。

下表捕获了数据库和 ETL 测试的主要功能及其比较 –

Function 数据库测试 ETL测试
Primary Goal 数据验证和集成 用于 BI 报告的数据提取、转换和加载
Applicable System 业务流程发生的交易系统 包含历史数据且不在业务流程环境中的系统
Common tools QTP、硒等 QuerySurge、Informatica 等
Business Need 它用于集成来自多个应用程序的数据，影响严重。 它用于分析报告、信息和预测。
Modeling ER法 多维
Database Type 它通常用于 OLTP 系统 应用于OLAP系统
Data Type 具有更多连接的规范化数据 具有更少连接、更多索引和聚合的非规范化数据。

ETL 测试 – 类别

ETL 测试分类是根据测试和报告的目标完成的。测试类别因组织标准而异，也取决于客户要求。通常，ETL 测试根据以下几点进行分类 –

  • 源到目标计数测试– 它涉及匹配源和目标系统中的记录计数。

  • 源到目标数据测试– 它涉及源和目标系统之间的数据验证。它还涉及目标系统中的数据集成和阈值检查和重复数据检查。

  • 数据映射或转换测试– 它确认源和目标系统中对象的映射。它还涉及检查目标系统中数据的功能。

  • 最终用户测试– 它涉及为最终用户生成报告，以验证报告中的数据是否符合预期。它涉及发现报告中的偏差并交叉检查目标系统中的数据以进行报告验证。

  • 重新测试– 它涉及修复目标系统中数据中的错误和缺陷，并再次运行报告以进行数据验证。

  • 系统集成测试– 它涉及测试所有单个系统，然后结合结果以查找是否存在任何偏差。可以使用三种方法来执行此操作：自顶向下、自底向上和混合。

根据数据仓库系统的结构，ETL 测试（不考虑使用的工具）可以分为以下几类 –

新的 DW 系统测试

在这种类型的测试中，构建并验证了一个新的 DW 系统。数据输入来自客户/最终用户以及不同的数据源，并创建了一个新的数据仓库。稍后，在 ETL 工具的帮助下，在新系统中验证数据。

迁移测试

在迁移测试中，客户已有数据仓库和ETL，但他们正在寻找新的ETL工具来提高效率。它涉及使用新的 ETL 工具从现有系统迁移数据。

变更测试

在变更测试中，将来自不同数据源的新数据添加到现有系统中。客户还可以更改 ETL 的现有规则，也可以添加新规则。

报告测试

报告测试涉及为数据验证创建报告。报告是任何 DW 系统的最终输出。报告根据其布局、报告中的数据和计算值进行测试。

ETL 测试——挑战

ETL 测试不同于数据库测试或任何其他常规测试。在执行 ETL 测试时，人们可能不得不面对不同类型的挑战。在这里，我们列出了一些常见的挑战 –

  • ETL 过程中的数据丢失。

  • 不正确、不完整或重复的数据。

  • DW系统包含历史数据，因此数据量太大且极其复杂，无法在目标系统中进行ETL测试。

  • ETL 测试人员通常无权查看 ETL 工具中的作业计划。他们几乎无法访问 BI 报告工具来查看报告和报告中数据的最终布局。

  • 难以生成和构建测试用例，因为数据量太大且复杂。

  • ETL 测试人员通常不了解最终用户报告要求和信息的业务流。

  • ETL 测试涉及用于目标系统中数据验证的各种复杂 SQL 概念。

  • 有时不向测试人员提供源到目标的映射信息。

  • 不稳定的测试环境会延迟一个过程的开发和测试。

ETL – 测试人员的角色

ETL 测试人员主要负责验证数据源、提取数据、应用转换逻辑以及将数据加载到目标表中。

下面列出了 ETL 测试人员的主要职责。

验证源系统中的表

它涉及以下操作 –

  • 计数检查
  • 将记录与源数据协调
  • 数据类型检查
  • 确保没有加载垃圾邮件数据
  • 删除重复数据
  • 检查所有钥匙是否到位

应用转换逻辑

在加载数据之前应用转换逻辑。它涉及以下操作 –

  • 数据阈值验证检查，例如年龄值不应超过 100。

  • 应用转换逻辑前后的记录计数检查。

  • 从暂存区到中间表的数据流验证。

  • 代理键检查。

数据加载

数据从暂存区加载到目标系统。它涉及以下操作 –

  • 从中间表到目标系统的记录计数检查。

  • 确保关键字段数据不丢失或为空。

  • 检查汇总值和计算度量值是否已加载到事实表中。

  • 检查基于目标表的建模视图。

  • 检查 CDC 是否已应用于增量加载表。

  • 维表中的数据检查和历史表检查。

  • 根据加载的事实和维度表并根据预期结果检查 BI 报告。

测试 ETL 工具

ETL 测试人员也需要测试工具和测试用例。它涉及以下操作 –

  • 测试ETL工具及其功能
  • 测试 ETL 数据仓库系统
  • 创建、设计和执行测试计划和测试用例。
  • 测试平面文件数据传输。

ETL 测试 – 技术

在开始测试过程之前定义正确的 ETL 测试技术很重要。您应该接受所有利益相关者的认可，并确保选择正确的技术来执行 ETL 测试。这种技术应该为测试团队所熟知，并且他们应该了解测试过程中涉及的步骤。

可以使用多种类型的测试技术。在本章中，我们将简要讨论测试技术。

生产验证测试

要执行分析报告和分析，生产中的数据应该是正确的。此测试是在移动到生产系统的数据上完成的。它涉及生产系统中的数据验证并将其与源数据进行比较。

源到目标计数测试

这种类型的测试是在测试人员执行测试操作的时间较少时完成的。它涉及检查源系统和目标系统中的数据计数。它不涉及检查目标系统中数据的值。也不涉及数据映射后数据是升序还是降序。

源到目标数据测试

在这种类型的测试中，测试人员验证从源到目标系统的数据值。它检查源系统中的数据值和转换后目标系统中的相应值。这种类型的测试非常耗时，通常在金融和银行项目中进行。

数据集成/阈值验证测试

在这种类型的测试中，测试人员验证数据范围。检查目标系统中的所有阈值是否符合预期结果。它还涉及在转换和加载后将来自多个源系统的数据集成到目标系统中。

示例– 年龄属性的值不应大于 100。在日期列 DD/MM/YY 中，月份字段的值不应大于 12。

应用程序迁移测试

当您从旧应用程序迁移到新应用程序系统时，应用程序迁移测试通常会自动执行。这种测试可以节省大量时间。它检查从旧应用程序中提取的数据是否与新应用程序系统中的数据相同。

数据检查和约束测试

它包括执行各种检查，例如数据类型检查、数据长度检查和索引检查。在这里，测试工程师执行以下场景 – 主键、外键、NOT NULL、NULL 和 UNIQUE。

重复数据检查测试

此测试涉及检查目标系统中的重复数据。当目标系统中有大量数据时，生产系统中可能存在重复数据，从而导致分析报告中的数据不正确。

可以使用 SQL 语句检查重复值，例如 –

Select Cust_Id, Cust_NAME, Quantity, COUNT (*) 
FROM Customer
GROUP BY Cust_Id, Cust_NAME, Quantity HAVING COUNT (*) >1;

由于以下原因，目标系统中出现重复数据 –

  • 如果未定义主键，则可能出现重复值。
  • 由于不正确的映射或环境问题。
  • 将数据从源系统传输到目标系统时出现手动错误。

数据转换测试

数据转换测试不是通过运行单个 SQL 语句来执行的。它非常耗时，并且涉及为每一行运行多个 SQL 查询以验证转换规则。测试人员需要对每一行运行 SQL 查询，然后将输出与目标数据进行比较。

数据质量测试

数据质量测试包括数字检查、日期检查、空值检查、精度检查等。测试人员执行语法测试报告无效字符、错误的大写/小写顺序等，参考测试检查数据是否符合数据模型。

增量测试

执行增量测试以验证 Insert 和 Update 语句是否按照预期结果执行。此测试是使用旧数据和新数据逐步执行的。

回归测试

当我们更改数据转换和聚合规则以添加新功能以帮助测试人员发现新错误时，这称为回归测试。回归测试中出现的数据错误称为回归。

重新测试

在修复代码后运行测试时，称为重新测试。

系统集成测试

系统集成测试涉及单独测试系统的组件，然后集成模块。系统集成可以通过三种方式完成：自顶向下、自底向上和混合。

导航测试

导航测试也称为测试系统的前端。它通过检查前端报告的所有方面来涉及最终用户的观点测试 – 包括各个领域的数据、计算和聚合等。

ETL 测试 – 过程

ETL 测试涵盖了 ETL 生命周期中涉及的所有步骤。它从了解业务需求开始，直到生成摘要报告。

下面列出了 ETL 测试生命周期下的常见步骤 –

  • 了解业务需求。

  • 验证业务需求。

  • 测试估计用于提供运行测试用例和完成总结报告的估计时间。

  • 测试计划涉及根据业务需求根据输入找到测试技术。

  • 创建测试场景和测试用例。

  • 一旦测试用例准备就绪并获得批准，下一步就是执行执行前检查。

  • 执行所有测试用例。

  • 最后一步是生成完整的总结报告并提交关闭流程。

ETL 测试 – 场景

ETL 测试场景用于验证 ETL 测试过程。下表解释了 ETL 测试人员使用的一些最常见的场景和测试用例。

Test Scenarios 测试用例

Structure Validation

它涉及根据映射文档验证源表结构和目标表结构。

应在源系统和目标系统中验证数据类型。

源和目标系统中数据类型的长度应该相同。

源系统和目标系统中的数据字段类型及其格式应相同。

验证目标系统中的列名。

Validating Mapping document

它涉及验证映射文档以确保已提供所有信息。映射文件应该有变更日志，维护数据类型、长度、转换规则等。

Validate Constraints

它涉及验证约束并确保它们应用于预期的表。

Data Consistency check

它涉及检查完整性约束（如外键）的滥用。

属性的长度和数据类型在不同的表中可能会有所不同，但它们的定义在语义层保持不变。

Data Completeness Validation

它涉及检查是否所有数据都从源系统加载到目标系统。

计算源系统和目标系统中的记录数。

边界值分析。

验证主键的唯一值。

Data Correctness Validation

它涉及验证目标系统中的数据值。

表中有拼写错误或不准确的数据。

当您在导入时禁用完整性约束时，将存储 Null, Not Unique 数据。

Data Transform validation

它涉及为输入值和预期结果创建一个场景电子表格，然后与最终用户进行验证。

通过创建场景来验证数据中的父子关系。

使用数据剖析来比较每个字段中的值范围。

验证仓库中的数据类型是否与数据模型中提到的相同。

Data Quality Validation

它涉及执行数字检查、日期检查、精度检查、数据检查、Null 检查等。

示例– 所有值的日期格式应该相同。

Null Validation

它涉及检查 Null 值，其中提到了该字段的 Not Null。

Duplicate Validation

当数据来自源系统的多个列时，它涉及验证目标系统中的重复值。

根据业务要求验证主键和其他列是否存在任何重复值。

Date Validation check

验证 ETL 过程中执行的各种操作的日期字段。

执行日期验证的常见测试用例 –

  • From_Date 不应大于 To_Date

  • 日期值的格式应该正确。

  • 日期值不应包含任何垃圾值或空值

Full Data Validation Minus Query

它涉及使用减查询来验证源表和目标表中的完整数据集。

  • 您需要同时执行源减目标和目标减源。

  • 如果减号查询返回一个值，则应将其视为不匹配的行。

  • 您需要使用Intersect语句匹配源和目标中的行。

  • Intersect 返回的计数应与源表和目标表的单个计数相匹配。

  • 如果减号查询不返回任何行并且计数相交小于源计数或目标表计数，则该表包含重复行。

Other Test Scenarios

其他测试场景可以是验证提取过程没有从源系统提取重复数据。

测试团队将维护一个 SQL 语句列表，这些语句运行以验证没有从源系统中提取重复数据。

Data Cleaning

在将数据加载到暂存区之前，应删除不需要的数据。

ETL 测试 – 性能

ETL 性能调优用于确保 ETL 系统是否可以处理多个用户和事务的预期负载。性能调优通常涉及 ETL 系统上的服务器端工作负载。它用于测试多用户环境中的服务器响应并查找瓶颈。这些可以在源和目标系统、系统映射、会话管理属性等配置中找到。

ETL 性能

如何进行 ETL 测试性能调优？

按照下面给出的步骤执行 ETL 测试性能调整 –

  • 步骤 1 – 找到生产中正在转换的负载。

  • 第 2 步– 创建相同负载的新数据或从生产数据移动到本地性能服务器。

  • 步骤 3 – 禁用 ETL，直到生成所需的负载。

  • 第 4 步– 从数据库表中获取所需数据的数量。

  • 第 5 步– 记下 ETL 的最后一次运行并启用 ETL，以便获得足够的压力来转换创建的整个负载。运行

  • 步骤 6 – ETL 完成运行后，计算创建的数据。

关键绩效指标

  • 找出转换负载所需的总时间。
  • 找出性能时间是有所改善还是有所下降。
  • 检查整个预期负载是否被提取和转移。

ETL 测试——可扩展性

ETL测试的目标是获得可信的数据。可以通过使测试周期更有效来获得数据可信度。

全面的测试策略是建立有效的测试周期。测试策略应该涵盖 ETL 过程每个阶段的测试计划，每次数据移动时，并说明每个利益相关者的职责，例如，业务分析师、基础设施团队、QA 团队、DBA、开发人员和业务用户。

为了确保从各个方面准备好测试，测试策略应该关注的关键领域是 –

  • 测试范围 – 描述要使用的测试技术和类型。

  • 搭建测试环境。

  • 测试数据可用性- 建议拥有涵盖所有/关键业务需求的生产数据。

  • 数据质量和性能验收标准。

ETL 测试 – 数据准确性

在 ETL 测试中，数据准确性用于确保数据是否按预期准确加载到目标系统。执行数据准确性的关键步骤如下 –

价值比较

值比较涉及将源系统和目标系统中的数据进行最小转换或不进行转换。它可以使用各种 ETL 测试工具来完成，例如 Informatica 中的 Source Qualifier Transformation。

在数据准确性测试中也可以进行一些表达式转换。SQL 语句中可以使用各种集合运算符来检查源系统和目标系统中的数据准确性。常见的运算符是减号和相交运算符。这些运算符的结果可以被视为目标系统和源系统中的值偏差。

检查关键数据列

可以通过比较源系统和目标系统中的不同值来检查关键数据列。这是一个可用于检查关键数据列的示例查询 –

SELECT cust_name, Order_Id, city, count(*) FROM customer 
GROUP BY cust_name, Order_Id, city;

ETL 测试 – 元数据

检查元数据涉及验证映射文档的源表结构和目标表结构。映射文档包含源列和目标列、数据转换规则和数据类型以及定义源和目标系统中表结构的所有字段的详细信息。

数据长度检查

目标列数据类型的长度应等于或大于源列数据类型。让我们举个例子。假设您在源表中有名字和姓氏，并且每个名字的数据长度定义为 50 个字符。然后，目标系统中全名列的目标数据长度应至少为 100 或更多。

数据类型检查

数据类型检查涉及验证源数据类型和目标数据类型并确保它们相同。转换后的目标数据类型可能与源数据不同。因此，还需要检查转换规则。

约束/索引检查

约束检查涉及根据设计规范文档验证索引值和约束。所有不能有 Null 值的列都应该有 Not Null 约束。主键列按照设计文档编制索引。

ETL 测试 – 数据转换

执行数据转换有点复杂，因为它无法通过编写单个 SQL 查询然后将输出与目标进行比较来实现。对于 ETL 测试数据转换，您可能必须为每一行编写多个 SQL 查询以验证转换规则。

首先，确保源数据足以测试所有转换规则。对数据转换执行成功的 ETL 测试的关键是从源系统中挑选正确且足够的样本数据来应用转换规则。

下面列出了 ETL 测试数据转换的关键步骤 –

  • 第一步是创建输入数据和预期结果的场景列表，并与业务客户进行验证。这是在设计期间收集需求的好方法，也可以用作测试的一部分。

  • 下一步是创建包含所有场景的测试数据。利用 ETL 开发人员自动执行使用场景电子表格填充数据集的整个过程，以实现多功能性和移动性，因为场景可能会发生变化。

  • 接下来，利用数据分析结果来比较目标数据和源数据之间每个字段中值的范围和提交。

  • 验证 ETL 生成字段的准确处理，例如代理键。

  • 验证仓库中的数据类型与数据模型或设计中指定的相同。

  • 在测试参照完整性的表之间创建数据场景。

  • 验证数据中的父子关系。

  • 最后一步是执行查找转换。您的查找查询应该是直接的，没有任何聚合，并且预计每个源表只返回一个值。您可以像之前的测试一样直接在源限定符中加入查找表。如果不是这种情况，请编写一个查询，将查找表与源中的主表连接起来，并比较目标中相应列中的数据。

ETL 测试——数据质量

在 ETL 测试期间检查数据质量涉及对加载到目标系统中的数据执行质量检查。它包括以下测试 –

号码检查

目标系统中的数字格式应相同。例如，在源系统中，列编号的格式是x.30，但如果目标只有30，那么它必须加载不前缀x 。在目标列号中。

日期检查

源系统和目标系统中的日期格式应一致。例如，它应该在所有记录中都相同。标准格式为：yyyy-mm-dd。

精密检查

精度值应按预期显示在目标表中。例如，在源表中，该值为 15.2323422，但在目标表中，它应显示为 15.23 或 15 的舍入。

数据检查

它涉及根据业务需求检查数据。不符合特定条件的记录应该被过滤掉。

示例– 只有那些 date_id >=2015 和 Account_Id != ‘001’ 的记录应该加载到目标表中。

空检查

根据该字段的要求和可能的值，某些列应为 Null。

示例– 终止日期列应显示 Null，除非且直到其活动状态列为“T”或“已故”。

其他检查

可以完成诸如 From_Date 之类的常见检查不应大于 To_Date。

ETL 测试——数据完整性

检查数据完整性是为了验证加载后目标系统中的数据是否符合预期。

可以为此执行的常见测试如下 –

  • 检查聚合函数（sum、max、min、count），

  • 检查和验证没有转换或简单转换的列的源和目标之间的计数和实际数据。

计数验证

比较源表和目标表中的记录数计数。可以通过编写以下查询来完成 –

SELECT count (1) FROM employee; 
SELECT count (1) FROM emp_dim;

数据配置文件验证

它涉及检查源表和目标表（事实或维度）中的聚合函数，例如计数、总和和最大值。

列数据配置文件验证

它涉及比较不同的值和每个不同值的行数。

SELECT city, count(*) FROM employee GROUP BY city; 
SELECT city_id, count(*) FROM emp_dim GROUP BY city_id;

重复数据验证

它涉及验证列或列组合中的主键和唯一键，这些列或列组合根据业务需求应该是唯一的。您可以使用以下查询来执行重复数据验证 –

SELECT first_name, last_name, date_of_joining, count (1) FROM employee
GROUP BY first_name, last_name HAVING count(1)>1;

ETL 测试 – 备份恢复

系统的备份恢复旨在确保系统从故障中尽快恢复，并在不丢失任何重要数据的情况下尽早恢复操作。

ETL 备份恢复测试用于确保数据仓库系统从硬件、软件或网络故障中成功恢复并丢失任何数据。

必须准备适当的备份计划以确保最大的系统可用性。备份系统应该能够轻松恢复，并且应该在不丢失任何数据的情况下接管发生故障的系统。

ETL 测试 备份恢复涉及将应用程序或 DW 系统暴露在任何硬件组件、软件崩溃等极端条件下。下一步是确保启动恢复过程、完成系统验证并实现数据恢复。

ETL 测试 – 自动化

ETL 测试主要使用 SQL 脚本并在电子表格中收集数据来完成。这种执行 ETL 测试的方法非常缓慢且耗时，容易出错，并且是在样本数据上执行的。

手动 ETL 测试中的技术挑战

您的 ETL 测试团队编写 SQL 查询来测试仓库系统中的数据，他们需要使用 SQL 编辑器手动执行这些查询，然后将数据放入 Excel 电子表格并手动进行比较。此过程耗时、资源密集且效率低下。

市场上有各种工具可以自动化这个过程。最常见的 ETL 测试工具是 QuerySurge 和 Informatica Data Validation。

查询激增

QuerySurge 是一种数据测试解决方案，旨在测试大数据、数据仓库和 ETL 过程。它可以为您自动化整个过程，并很好地融入您的 DevOps 策略。

QuerySurge 的主要功能如下 –

  • 它具有查询向导，可以快速轻松地创建测试查询对，而无需用户编写任何 SQL。

  • 它有一个带有可重用查询片段的设计库。您也可以创建自定义 QueryPair。

  • 它可以将源文件和数据存储中的数据与目标数据仓库或大数据存储进行比较。

  • 它可以在几分钟内比较数百万行和列的数据。

  • 它允许用户安排测试以 (1) 立即运行，(2) 任何日期/时间，或 (3) 在事件结束后自动运行。

  • 它可以生成信息丰富的报告、查看更新并将结果自动通过电子邮件发送给您的团队。

为了自动化整个过程，您的 ETL 工具应该在 ETL 软件完成其加载过程后通过命令行 API 启动 QuerySurge。

QuerySurge 将在无人值守的情况下自动运行，执行所有测试，然后将结果通过电子邮件发送给团队中的每个人。

就像 QuerySurge 一样，Informatica Data Validation 提供了一个 ETL 测试工具，可帮助您在开发和生产环境中加速和自动化 ETL 测试过程。它使您可以在更短的时间内交付完整、可重复和可审计的测试覆盖率。它不需要编程技能！

ETL 测试 – 最佳实践

要测试数据仓库系统或 BI 应用程序，需要采用以数据为中心的方法。ETL 测试最佳实践有助于最大限度地减少执行测试的成本和时间。它提高了要加载到目标系统的数据质量，从而为最终用户生成高质量的仪表板和报告。

我们在这里列出了一些 ETL 测试可以遵循的最佳实践 –

分析数据

分析数据以了解需求以建立正确的数据模型非常重要。花时间了解需求并为目标系统建立正确的数据模型可以减少 ETL 挑战。研究源系统、数据质量并为 ETL 模块构建正确的数据验证规则也很重要。应根据源系统和目标系统的数据结构制定 ETL 策略。

修复源系统中的错误数据

最终用户通常知道数据问题，但他们不知道如何解决这些问题。在它们到达 ETL 系统之前找到这些错误并纠正它们很重要。解决此问题的常用方法是在 ETL 执行时，但最佳实践是在源系统中查找错误并在源系统级别采取措施纠正它们。

寻找兼容的 ETL 工具

常见的 ETL 最佳实践之一是选择与源系统和目标系统最兼容的工具。ETL 工具为源和目标系统生成 SQL 脚本的能力可以减少处理时间和资源。它允许人们在最合适的环境中的任何地方处理转换。

监控 ETL 作业

ETL 实施期间的另一个最佳实践是 ETL 作业的调度、审计和监控，以确保按预期执行负载。

集成增量数据

有时，数据仓库表的大小较大，并且不可能在每个 ETL 周期都刷新它们。增量加载确保只有自上次更新以来更改的记录才会被带入 ETL 过程，这对可扩展性和刷新系统所需的时间产生巨大影响。

通常，源系统没有时间戳或主键来轻松识别更改。如果在项目后期发现，此类问题的成本可能非常高。ETL 最佳实践之一是在初始源系统研究中涵盖这些方面。这些知识有助于 ETL 团队识别更改的数据捕获问题并确定最合适的策略。

可扩展性

最好的做法是确保提供的 ETL 解决方案是可扩展的。在实施时，需要确保 ETL 解决方案可根据业务需求及其未来的潜在增长进行扩展。

觉得文章有用？

点个广告表达一下你的爱意吧 ！😁