本期内容由中通科技高级质量工程师龙渊在公益讲座中分享，他从大数据测试整体先容、数据应用测试、数据平台测试以及数据堆栈测试等方面，与各人共同探讨了大数据测试的方法实行与落地。
以下是讲座正文：
本日我们分享的内容主要从大数据简介、数据应用测试、数据平台测试、数据堆栈测试这四个方面睁开。由于我目前在中通科技这边主要负责数据堆栈测试这部分，所以本日本日禀享的内容主要还是以数据堆栈测试为主。数据应用和数据平台方面给各人做一下整体的先容，带各人做一个全面的了解。
下面我们就正式开始本日的内容。首先，我们了解一下什么是大数据。
大数据简介
大数据，是指一个公司创造或网络的“布局化”、“半布局化”或者“非布局化”的海量数据聚集。它的意义不在于把握的数据量是最大的，而在于能否有用、专业的对这些数据举行加工处理，并让这些海量的、多样化的数据产生最大的价值。
大数据主要有以下四个特征：
体量大存储单位从已往的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岁以下一般大学还没有毕业，应该是收罗不到的。所以我们要分析下，看到底是用户在填入信息的时候填写错了？还是因为什么其他缘故原由导致的？否则会影响我们后面数据的判断的质量。
（以上内容通过道普云定期约请业内专家举办的公益讲座整理而来，观看讲座回放可私信我获取回放链接）
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
