ETL 测试 - 快速指南

---

ETL 测试 – 简介

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

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

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

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

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

例子

让我们假设有一家制造公司，有多个部门，如销售、人力资源、物料管理、EWM 等。所有这些部门都有单独的数据库，用于维护工作信息，每个数据库都有不同的技术、环境、表格现在，如果公司想要分析历史数据并生成报告，则应提取来自这些数据源的所有数据并将其加载到数据仓库中以保存以进行分析工作。

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

ETL 和 BI 工具的区别

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

最常见的 ETL 工具包括 SAP BO Data Services (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测试工具有QuerySurge、Informatica等。

数据库测试

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

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

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

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

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

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

下表列出了数据库和 ETL 测试的主要特征及其比较 -

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 测试人员使用的一些最常见的场景和测试用例。

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 中的源限定符转换。

在数据准确性测试中也可以进行一些表达式转换。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测试——数据完整性

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

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

• 检查聚合函数（总和、最大值、最小值、计数），

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

计数验证

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

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。

• 它有一个设计库，其中包含可重用的查询片段。您也可以创建自定义查询对。

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

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

• 它允许用户安排测试运行（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 解决方案能够根据业务需求及其未来的潜在增长进行扩展。