大数据测试怎么做，数据应用测试、数据平台测试、数据仓库测试

本期内容由中通科技高级质量工程师龙渊在公益讲座中分享，他从大数据测试整体介绍、数据应用测试、数据平台测试以及数据仓库测试等方面，与大家共同探讨了大数据测试的方法实施与落地。

以下是讲座正文：

今天我们分享的内容主要从大数据简介、数据应用测试、数据平台测试、数据仓库测试这四个方面展开。由于我目前在中通科技这边主要负责数据仓库测试这部分，所以今天今天分享的内容主要还是以数据仓库测试为主。数据应用和数据平台方面给大家做一下整体的介绍，带大家做一个全面的了解。

下面我们就正式开始今天的内容。首先，我们了解一下什么是大数据。

大数据简介

大数据，是指一个公司创造或收集的“结构化”、“半结构化”或者“非结构化”的海量数据集合。它的意义不在于掌握的数据量是最大的，而在于能否有效、专业的对这些数据进行加工处理，并让这些海量的、多样化的数据产生最大的价值。

大数据主要有以下四个特征：

体量大存储单位从过去的GB到TB，直至PB、EB级别。

多样化数据类型复杂多样，包括结构化、半结构化数据还有视频、音频及图片这些非结构化数据。

价值高将原始数据采集、清洗、挖掘、数据分析之后，具有较高的价值。

时效性数据的采集、计算、展示需要满足不同场景的时效。比如说公司的业务报表，一般都要在第二天早上业务方和产品方上班之前就要把数据拷出来，对实效性是有一定的要求的。再比如说一些数据大屏，要满足秒级更新频率的数据。

接下里来我们一起看一下数据从哪里来到哪里去的整个数据链路。

首先是数据采集这一块。主要是我们把从业务系统、日志、埋点、数据文件中的一些数据采集过来。存储到大数据的系统，主要是以HDFS文件系统为主，其他的还有比如ES、Kafka、TIDB等。

数据采集过来之后，我们会对一些脏数据或者测试数据进行清洗和转换，主要是一些测试数据，包括把格式不一致的数据统一转换成统一的格式等。

数据清洗完成之后，我们会对数据进行建模，这部分是数据仓库的核心。把拥有共同属性和共同业务逻辑的表整合到一起，提供给不同的场景方、业务方使用。

数据建模之后，我们根据不同的业务需求进行指标的一些汇总、计算。数据计算完成后，我们会把数据推送到不同的业务方、不同的系统，供他们分析使用。

以上就是整个大数据的数据链路，接下来我们一起来了解一下中通大数据的架构。

最下面是数据存储，这里刚刚也讲过了，最主要的是HDFS，也包括一些TIDB、REDIS、ES等等。上面是资源管理，这里使用的主要是Yarn。

然后计算层主要是分为两个部分，一个是实时计算，主要是以Fink和Sparkstreaming为主，批量计算这部分主要是Hive、Presto跟Spark。

在这些计算服务上面，我们这边做了一些基础服务的平台。比如说调度，调度是一个集计算与管理于一体的一个平台，主要是对任务和数据的计算做统一的管理，主要是针对离线数据这一块。

在此基础上实现了历史数据查询、数据订阅、数据下载等一些数据服务。

最上面一层主要是我们的数据应用这一块，比如说数据报表、数据大屏等一些可视化的数据平台。

以上就是我们中通科技的一个整体的数据架构，接下来我们一起了解一下什么是大数据测试。

大数据测试：通常是指对采用大数据技术的系统或应用的测试。它可以分成两个维度，对数据本身的测试，对大数据系统或应用产品的测试。

下面这两张图一个是数据报表，是一个数据展示的平台。第二张是数据管理平台，是对数据进行管理的一个平台。他们分别是数据纬度和系统纬度。

首先我们一起来看一下数据测试，数据测试是指数据质量的测试，主要关注数据的完整性、准确性、一致性、及时性、可用性这五个维度。

大数据系统一般指使用Hadoop生态组件搭建的或自主研发的大数据系统，主要包括数据存储、计算、分析等组件。大数据应用产品比较丰富，典型的有BI报表、数据挖掘产品、数据分析平台等。

大数据系统测试是比较复杂的，首先包括Hadoop本身生态的一些组件，再就是包括我们自己做的一些数据应用平台、数据开发平台，主要包括这三块内容。

接下来我们一起来看一下大数据测试相比其他传统的测试有哪些难点。

技术门槛高首先它的技术复杂、多样，比如我们之前看到的，包括实时数据、离线数据它们处理数据的架构、框架都是不一样的，技术也都是不一样的。再者，对SQL编写能力的要求会比业务测试会高很多，不仅仅要求能够写一些复杂的业务逻辑，还要有一定的问题定位的能力。第三点是它的自动化、性能测试场景比较复杂。

测试效率低第二个难点是测试效率低。测试效率低体现在大数据技术手段的多样复杂；任务运行时间比较长，以我们的数据仓库为例，为一个任务修复一个问题，跑完可能需要一个小时，任务运行时间比较长。再一个就是缺少测试工具，我们这边也正在规划准备开发一个大数据测试平台。再一个就是回归测试难，主要因为数据链路太长，改一个东西可能会影响到整个数据链路。

环境问题多第三个难点是环境问题比较多，首先测试和生产的环境之间的差异还是很大的。因为大数据这边的集群比较大，所以测试环境没有办法做到像正常环境那样完善，所以它的测试环境也比较难以管理，测试环境的资源也比较有限。

数据验收难

第四个，数据的验收难。主要体现在验收标准比较模糊，场景缺乏一些统一的标准，主要是数据不像一些业务功能或者展示功能可以有直接的感知，我们无法感知到数据是不是准确。

数据复杂多样最后一个是数据复杂多样，数据类型的话我们刚才也讲过了，不仅仅有结构化、半结构化的数据，还有一些视频、图片的数据，所以处理起来的技术难度还是很大的。

以上是我总结的几个我认为的难点，其实也还有其他的。我们了解完整个大数据测试后，接下来就一起了解一下数据应用测试。

数据应用测试

首先我们一起了解一下测试的对象是什么。

第一个是数据报表这一块，数据报表包含了我们常见的业务分析报表、经常能看到的一些数据大屏之类。

第二块是数据平台，数据应用平台主要有一些智能营销平台，比如说画像分析平台，自助取数平台、权限管理平台等等。

第三个是数据接口，数据接口主要做两个功能，一个是查询功能，另一个是数据装载接口。

下面的图片是给大家举的一个数据报表的例子，从这个图片上我们可以看到，其实数据报表在功能层面主要是做展示、查询，下载的功能。

从上面的内容我们可以得到，数据应用的测试方法主要有以下这些：

web测试，包括页面功能、样式的测试。

接口测试，这部分跟传统的业务测试是一样的。

数据测试，页面展示的数据是否满足需要等。

容灾测试，当时数据出现一些问题的时候有没有一些兜底的方案？或者说有没有备用方案可以让数据快速恢复。

性能测试，主要还是针对接口和数据库索引的测试。

数据平台测试

接下来这部分内容是数据平台测试，我们这里的数据平台主要针对的是开发层、底层，包括一些数据开发的平台、数据查询的平台、包括一些一键ETL的平台等。

这里给大家举了两个例子，一个是我们这边的数据开发平台。它主要做数据计算、任务管理这些功能，它是由一个个的Hadoop组件组建而成的。

第二个例子是一个数据应用平台，主要是做一些数据的展示和管理。

它的测试方法相比之前我们讲的数据应用的测试方法，多了一个组件测试，针对一些组件的特性，包括Hadoop、Kafka、flink等它们本身使用的技术上的特性。

再一个就是数据的容灾测试，比如说故障演练。

性能测试中，针对Hadoop组件的基准测试是跟其他普通测试不同的地方。

数据仓库测试

接下来我们重点来讲一下数据仓库测试，首先看一下它的定义。

数据仓库(Data Warehouse)：一个面向主题的（Subject Oriented）、集成的 （Integrated）、相对稳定的（Non-Volatile）、反映历史变化的（Time Variant）数据集合，用于支持管理决策和信息的全局共享。

从上面这个图中我们可以看到，穿插了一个“ETL”的概念。什么是“ETL”呢？ETL是指从数据源提取数据，经过清洗、转化、加载，并最终存储到目标数据仓库的过程。

也就是图中表示的，从数据抽取到数据加载的整个过程，我们称之为“ETL”。

了解完整体概念后，我们一起来了解一下中通数据仓库的框架。

ODS：源数据层，和业务数据保持一致，保留最近七天的数据。

DW：明细数据层，数据经过了清洗转化，明细模型数据。

DM：数据仓库层，根据业务主题、颗粒多不同做汇总，形成宽表。

DIM：数据维度层，提供基础配置信息、用户信息。

ST：数据应用层，为数据产品提供结果数据。

可能这个图片上的有一些名称大家看起来有些陌生，因为不同的公司可能在命名的时候会有所不同，包括分层也会有所差别，但是整体的思想都是差不多的。

首先我们来看一下操作数据层，它主要存储的是从业务操作系统抽取过来的数据，是保持不变的，在中通这边ODS层（操作数据层）一般会保留7天。

然后对操作数据层的数据进行清洗、转化之后，会把数据存到DW层。DW层主要做两个事情，第一个是存储经过清洗和转换的数据，第二点就是可能会有一些公共的明细数据需要在这里做一个明细的模型，主要是做这两块。

再上面一层是汇总数据层，主要是对共有的一些属性维度去进行汇总。

然后在这个图里我们还可以看到有一个维度层，维度层主要是提供的基础的配置信息、用户信息，一般是配合其他层的数据来使用的。

最上面一层是ST数据应用层，是各种指标的数据汇总展示。

将整个架构打平来展示，制作了下面的流程图。

我们在这里拿“订单信息”举了一个例子，它在原数据库的时候这张表叫做order_info，是一张订单信息表。它出库的时候这张表的名字就变成了ods_order_info，到达我们的ods层，这层只是保存数据，并不做任何处理。

然后数据经过清洗、转换，会存储到dw层，也就是我们上图中看到的dw_order_info。

数据经过清洗转换之后，可能会有一些公共的数据要整合。之后我们会把这些数据模型整合成一张大的数据框表，比如说订单信息这边有可能还会集成一些用户信息等会进行整合。

明细数据会存到明细数据模型数据这边，模型这边要对这些数据进行一些汇总指标的处理。数据表在这里可能会集成一些其他表的属性，名称就变成了dm_order_info。dm层存储的数据颗粒度比较细，主要是方便应用层数据的开发。

如果我们要分析用户数据的话，我们可以直接从dm层这边取用户信息进行汇总就行了，这里数据表就变成st了。

应用层数据处理、储存好了之后会把数据推送到数据报表、数据平台或者其他数据接口，供其他数据产品或者业务、管理层使用。

// 数据血缘

从这张表我们可以引出一个数据血缘的概念。

数据血缘：数据的来龙去脉，主要包含数据的来源、数据的加工方式、映射关系以及数据出口。

数据血缘就是数据的来龙去脉，它主要做两件事情，第一件事情就是追根溯源，快速地查询出来我这个字段是从哪张表上来的，中间经过了哪些环节。第二个是反映了数据的变化过程。

上面这个图片我们可以看到从Table A到Table G，中间集成了很多其他的表。

数据血缘属于元数据的一部分，清晰的数据血缘是数据平台维持稳定的基础，更有利于数据变更影响分析以及数据问题排查。

数据血缘的范围：数据血缘单纯的数据角度来看包含的维度有数据库、表、字段、系统、应用程序，即数据存储在什么数据库的什么表，对应的字段是什么以及字段的属性，数据所属的系统以及与数据有关的应用程序。

数据血缘从业务角度来看包含的维度主要是数据所属业务线，涉及到业务便要梳理清楚数据的产生逻辑、数据的使用逻辑以及业务线之间的关联关系。

// 数据仓库表类型

接下来我们开始了解数据仓库测试的对象，直白一点讲就是一张表，这张表分为以下几种类型：

全量表：没有分区的表，数据全量更新或者增量合并，我们通常理解就是把这些数据放到了一个文件夹里面。这样会有什么好处呢？全量表查询的效率非常高，成本比较低。但是它不能反应数据状态，只保存最新状态的数据。

分区表：有分区的表，比如我们把订单信息放到了几个文件夹去储存，一个文件夹按照天去切分。分区表分为两种，一种是增量的，每天存一份。第二种是全量更新，比如我们可能会把历史之前所有的数据存储在某一天的数据里面。

分区表的好处是可以查询到历史数据的状态以及变化过程，但是可以保存历史数据的状态，一般使用日期或者地区作为分区条件。有一个缺点是在一些时间节点上容易产生数据漂移。

临时表：放在tmp的表，这种表一般是测试或开发临时保存一些数据时用的，一般不需要我们去测试。一般只会保存很短的时间，过了时间系统会自动清掉。

拉链表：是一种维护历史状态，以及最新状态数据的一种表，一般只会插入更新有状态变化的数据，保存数据的历史状态，不变更。这样做的好处就是节省存储资源。

外部表：是建表的时候被external 修饰的表。删除外部表的时候，只会删除元数据，数据本身不删除，外部表可以自己指定路径，跨部门使用比较安全。

接下来我们一起来看一下整个测试数据仓库的流程。

首先我们会去做预评审，做一些需求探索，包括一些需求细节的讨论。讨论好了之后会安排一场真实的需求评审。评审完成之后，开发开始进行一些架构设计，编写一些技术文档。技术文档编写好了之后，我们这边会有一个技术评审。评审完之后，测试工作开始启动。

在开发阶段，测试开始编写测试用例和测试代码。进入测试阶段后，首先我们会进行冒烟测试。冒烟测试通过之后，开始进行测试执行阶段。测试执行上线之后，会有一个线上冒烟，然后会有一个产品验收的环节。这两个环节都通过之后，开始一些数据监控的部署和生产。

了解完测试流程，我们再一起来看一下数据质量的五个标准。

// 数据质量标准

数据完整性数据信息是否存在缺失的状况，数据缺失的情况可能是整个数据记录缺失，也可能是数据中某个字段信息的记录缺失。

数据一致性数据是否遵循了统一的规范，数据集合上下游的的数据是否保持了统一的格式，指标定义是否一致。

数据及时性数据从产生到可以查看的时间间隔，也叫数据的延时时长，也是我们通常所说的任务运行时间。

数据准确性数据记录的信息是否存在异常或错误；数据逻辑是否正确。

数据可用性数据能够真实、有效的反应业务的情况。

一般我们主要从这五个方面去衡量数据的质量。

// 数据接入测试

刚才我们讲了整个数据流程，我们把整个数据框架打平了之后，我们把整个流程切分了几个环节。首先我们一起来看一下数据接入这部分的测试。

数据接入：业务数据或者文件通过一定的技术手段复制到大数据系统的过程。

首先我们一起看一下数据抽取这部分，这部分测试我们主要关注四个维度。第一个是数据测试，数据测试主要关注数据总量和字段这两块。数据总量是否一致、数据是否存在重复、字段是否存在错位、格式是否一致。

元数据这一块主要是关注两个方面，一个是字段，另一个是建表语句。字段主要关注数量、类型和命名规范。建表语句主要关注注释、类型、存储位置和存储格式是否正确。

第三个我们需要关注抽取任务，也就是整个调度任务的测试，首先第一块我们需要关注任务的运行时间，然后参数配置和接入的方式是否正确。

最后一个导入测试主要是针对文件的，需要关注导入路径和文件的大小。

下面是从业务口抽取到大数据系统的例子，我们可以看到从MySQL中不同的表中，把所有的数据抽取到一张表里面，但是在业务库中这些表的数据结构都是一模一样的。

这是代码截图，大家可以看一下。

这里我们就引出了一个业务系统一个分表分库的概念：

分库分表是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据库组成 ，将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的。

了解完数据接入这部分，我们继续了解一下什么是数据转化和清洗。

// 数据清洗、数据转化

数据清洗：按照一定的规则剔除或者填充不满足实际需要的业务数据。

这里的清洗主要包括三部分的内容，第一部分是测试数据、第二个是错误的数据，第三个是缺失的数据。错误的数据我们可以关注数据是否重复、格式是否错误、字段描述的信息是否错误。

数据转化：按照一定的规则、技术手段转化不同格式或者颗粒度不同的数据。

首先我们看一下格式的转换，比如说时间格式，在不同的业务系统可能会有不同的时间格式，但是到我们大数据系统，为了方便下游数据的使用，我们会统一转换成一种数据格式。包括一些字段编码也是这样。

然后数据的颗粒度，我们在DW层的数据明细层到数据应用层的整个过程，都是颗粒度不断转化的一个过程。

还包括一些业务规则、商务规则和一些指标。

这边给大家举了一个数据清洗方面的例子，这个例子主要是做了两个工作，第一个是对重复数据的处理，第二个是对测试数据的剔除处理。

我们是怎么去测试的呢，首先关注去重前后数据量的差异，第二个要检查一下我们去重的规则和清洗的规则是否生效。

我上面单独写了一段自动对比的代码大家可以看一下，测试数据单独落在一张表里面，开发的数据在单独的开发表里面，然后通过唯一字段关联之后，判断两个字段是否相等，对结果进行汇总。

// 数据逻辑测试

我把整个数据模型层和数据应用层都放到一起了，统称为数据逻辑计算。逻辑计算是数据按照一定的业务规则或者计算逻辑整合、汇总的过程。

我们一起了解一下逻辑计算我们要测试哪些东西，第一个我们要看一下数据量，我们要判断一下哪些因素会影响到数据的总量。

首先是过滤条件，条件不多不少，再就是值域的开闭区间。影响数据总量的第二点是关联方式，通常常用的关联方式有三种，left join、inner join、full join，需要理解每一种数据关联方式对数据有什么影响。

再就是关联条件，关联条件一定是唯一的，再者不能存在失效的关联条件。还有数据的日期范围、逻辑关系的检查、去重的方式、去重的阶段和分组、排序的方式都会影响整个数据量。

第二部分是数据的指标，包括字段来源、字段处理、特殊字段、条件判断、聚合、排序以及计算方式是否正确、数据的波动是否合理。

第三部分是整个的调度测试，主要是任务和配置的测试，主要关注任务的运行时长和参数的配置方面。

这边也给大家举了一个例子。数据逻辑测试是整个数据仓库测试中最复杂的，它涉及到很多颗粒度的转化，以及业务逻辑的计算和整合。所以这里给大家放了一个测试脚本，主要做了数据的计算。

下面这两个截图是测试的步骤，先开始测试数据总量。数据总量没有问题的情况下，第二步开始对每一个字段具体的业务指标进行测试。我们要保证我们的测试要覆盖到开发表的每一条数据里的每一个字段的值，这样测试才会覆盖的比较全面。

// 数据加载测试

加载：数据按照对应的映射关系加载到数据应用库表的过程。

整个ETL过程最后一个环节就是加载，数据的推送，就是把我们大数据这边已经处理好的数据和表推送到业务系统、数据平台、报表平台等。

这一部分主要关注数据和调度，数据量和之前的采集环节相类似，有一点需要特别关注，oracle、MySQL这些传统数据库中的数据表，我们需要关注一下索引、约束以及注释和字段类型是否正确。

第二块是我们配置的调度是否合理，任务的运行时间是否合理。

// 数据监控

刚刚前面讲的是我们在测试环节要做的事情，后面这部分我们讲一下，整个数据表上线之后，应该怎么去做一些线上冒烟的测试。首先我们做了一个数据监控。

数据监控是针对生产数据的变化按照一定的技术手段、业务规则进行监控、预警，并及时反馈异常数据。

为什么要做数据监控呢？首先是因为生产数据的不确定性，业务系统的数据是我们大数据这边无法管控的。第二个是缺乏高效的自动化手段，数据的自动化成本是很高的，效果和投入不成正比。第三个原因是生产操作经常会存在一些不规范情况。最后一个是数据链路过长，整个集群和计算框架都会存在一些不稳定的因素。

基于以上原因，我们做了一套数据监控。

数据监控的标准还是针对数据本身，所以我们还是以数据质量的标准去制定我们的监控标准：数据完整性、数据一致性、数据准确性、数据及时性、数据可用性。

监控的范围主要包括三方面：调度任务、表、字段。

调度任务主要是我知道调度任务的运行状态是否成功，包括调度任务的数据量、运行时间是否合理。表主要以数据波动为主，包括数据是否为0。字段主要以值域的判断和枚举值的判断为主。

下面是我们这边的一个数据监控平台，有一些规则，包括一些数据量、总和、空值、平均值的一些检测。底层以sql为主，进行的一个封装。把sql的查询结果和你预期的结果进行对比，如果查询的结果在你预期的范围之内，这个任务就会通过。如果不在范围之内，就会以告警的方式通知相关人员，然后去判断是业务的问题还是代码逻辑的问题。

下面是我列举的一些规则，我们一起看一下。首先是调度任务的运行时间、状态，可能有一些会加一个开始时间，看一下任务有没有及时的开始。

表这一部分主要是监查数据量是不是为0，每天的数据增量对比，同比环比的数据，检查一下表里面是不是有测试数据的存在，平均值的波动以及重复数据的检查，主要的检查范围就是这些。

第三个维度是字段，包括刚刚提到的枚举值，极限值，也是我们刚刚提到的值域的判断，以及空值率、格式的检查和关联字段的检查。

我这里只是给大家列举了一些类别，但是具体的规则还是需要大家自己根据业务去制定的。

下面给大家举了一个案例：

波动分析

首先我们来看一下波动分析，就是整个数据量的波动，我们可以看到中间这个地方有一个数据量特别的高。如果这块数据的波动突然出现异常了，我们就需要对这部分数据进行分析。

是业务系统今天本身就产生了这么多数据？还是我们的数据任务有问题？还是数据加工有问题？

时效分析

时效是指任务是否能够按照预定的时间完成。前面我们也讲过了，我们在衡量整个数据仓库质量的时候，有一个很重要的特性就是数据的时效性。如果任务运行的时间过长，就会影响下游的任务，影响下游任务的产出时间。

从下面这张图我们可以看到，11月5日这一天，任务跑了70分分钟，那我们需要去分析判断一下，到底是什么原因。如果是代码问题，那需要进行优化修改。如果资源不够，我们需要去进行一些资源的优化，或者通过加机器的方式去解决。

值域分析

接下来的部分是值域分析，主要针对字段。这里给大家举了一个公司员工年龄的例子，我们正常的公司员工一般在20岁到65岁这样一个区间，如果超出这个范围，这个数据就是异常的、不应该被采集到的。

通过下面这个图片我们可以看到有一条数据是20岁以下，有一条数据是在70岁左右。70岁一般来说是已经退休了，20岁以下一般大学还没有毕业，应该是采集不到的。所以我们要分析下，看到底是用户在填入信息的时候填写错了？还是因为什么其他原因导致的？否则会影响我们后面数据的判断的质量。

（以上内容通过道普云定期邀请业内专家举办的公益讲座整理而来，观看讲座回放可私信我获取回放链接）