ETL测试的前世今生

自己是做数据仓库ETL测试的，可能这还是个新的工种，没什么经验可循，大家都在摸着石头过河。

 

 

首先，什么是数据仓库，我的感性理解是：

 

将一个公司范围内的业务数据进行收集汇总，放在一个很大的池子里，以便后续计算分析使用，这个池子就是数据仓库。以电商领域为例，主要是一些客户数据、交易数据、以及一些网站行为数据。

数据仓库和前台业务数据库的一大不同是，数据仓库是记录历史的，即它会将每天的数据都保存下来。可以把使用数据的人带回到历史上的任何一天，看当时的数据情况是什么样的。当然这个历史的开头是数据仓库的诞生日期啦。

 

 

那什么是数据仓库的ETL开发呢：

 

所谓ETL就是数据的抽取、清洗、装载，简单理解就是将最一开始收集上来的数据做不同层次的筛选、关联、计算、汇总并将结果存储在更高的数据层次，新的数据层次又会成为更高数据应用的数据输入源，数据ETL的最终层次主要有两个：1. 服务于组织内部的应用，向企业运营人员和管理人员提供数据支持；2.服务于组织外部，主要指向组织的客户和合作伙伴提供与其业务相关的数据分析支持，包括历史趋势、行业内市场情况等。

 

ETL开发工作就是实现不同数据层级的数据计算和装载，不同的数据层级计算逻辑主要受两方面的影响：1，当前计算所处的数据层级，是数据基础层，逻辑主题层，还是数据应用接口层等；2，最终业务逻辑的需求，有短期性质的灵活性要求较高的需求，也有较长期性质稳定性和可延续性较高的需求。不同的需求对如何设计不同数据层次的刷新逻辑和不同数据层测的数据结构有不同的要求。

 

最理想的结果是，不同的数据层次逻辑在设计时兼顾需求的灵活与稳定，在数据主题划分、层次划分时逻辑分明，此外新的需求进入时尽量避免不同层次数据的同时运算。

 

一般来讲，长期的稳定性要求高的需求，计算时的层次结构比较清晰，即低层数据向中层数据汇总，而中层数据向高层数据汇总，高层数据向应用层汇总，逻辑清晰，而且每一层的数据复用度较高。

灵活性需求的计算，层次就不会这么分明，有时候一个应用层数据的计算，需要同时以低层、中层、高层数据为输入源。

 

因此，不同的数据规划和设计会对具体的数据需求的实现逻辑有一定的影响。

而数据仓库架构师的任务就是要设计合理的数据层次架构以及各数据层所提供数据的内容和相关关系。

 

因此，数据仓库架构师为数据仓库ETL开发工程师服务。

 

明确了ETL工作的内容后，不得不提到的一个角色就是数据仓库的ETL测试。

面对海量数据和复杂的业务逻辑，准确地获取相关的数据并正确地计算是ETL的最基本要求，而ETL开发工程师也是人，是人就会写出有BUG的程序。

 

因此ETL测试的基本工作就是对ETL开发中涉及的数据情况进行分析，对ETL刷新逻辑进行check，并对最终ETL开发完成的刷新逻辑进行确认是否正确，及是否满足业务需求。

 

这里之所以说基本，是因为ETL测试还有并不基本的工作内容，主要有以下亮点：

 

1.

有时由于ETL开发人员自身的限制，所设计的数据刷新方案虽然能满足业务放的数据需求，但是在数据流结构、数据刷新效率、对现有数据层次中数据的使用等并不合理或不是最优的方案。因此ETL测试人员在能力允许的情况下，针对这些方面给出一定的建议或意见。确保在项目范围内的数据结构设计和刷新逻辑最优或更加合理。

 

2.

此外，对于经验丰富、对数据仓库环境有足够了解、对所涉及业务的数据环境也有足够了解的ETL测试工程师，在ETL详细设计环节中，给出更高层次的建议。比如对于稳定行的数据刷新需求，所设计的数据流结构，是否与现有的数据层次有冗余和不一致；在某数据层次增加的数据内容，是否有一定的可复用性；如果被其他业务逻辑复用是否会导致数据重复、数据不一致、数据丢失等情况。

 

 

其实对于ETL测试工作来讲与传统的功能测试或其他底层的测试工作有一定的不同，这种不同是ETL开发所特有的性质所引起的。

 

ETL开发的特性：

 

深入到ETL开发的内部来讲，ETL开发就是按照设计的思路将一些数据从一些源数据中通过where条件 select出来，并对其进行group by汇总，如果有必要还需要和其他数据源进行join操作。虽然设计逻辑也有复杂简单之分，但我们会在设计的时候尽量将复杂的逻辑进行简化切分，不至于在一个项目中有太复杂的逻辑。

 

经过一段时间的ETL开发或测试工作之后，你就会发现绝大多数情况下，一个表的刷新过程会有一句或几句SQL语句解决。最多也不会超过5句。总行熟大概在100-200行范围内，最多也不会超过500行。

 

这就是ETL开发的特点：设计分析阶段至关重要，因为其是从一个共用的数据池中存取数据，一不留神影响到的不止是自己的应用。而设计分析完成、确定了刷新逻辑之后，则每个表的刷新过程则会变得比较简单。除了代码行数有限之外，SQL语句本身的陈述式特性，也使得其逻辑不比像Java、C等命令式语言，会有诸多循环、判断、分支、跳转等复杂性。

 

 

因此，面对这样特性的数据仓库ETL开发，ETL测试工作也需要更加关注与设计分析。

 

当然SQL语句的测试也是必须的，只不过由于其“不复杂”性，对于数据刷新逻辑的描述来讲，一段SQL的描述性要远远强于设计文档中的一大段密密麻麻的文字。

 

谁不喜换简单、明了、准确的描述呢，这样，经验尚浅的ETL测试人员就极易被“错误”的SQL逻辑所误导，认为这就是需求所需要的刷新逻，这样当然就测不出问题了。