在前面 中通科技大数据质量保障探索与实践(上)中具体分析了数据应用的质量保障,主要是功能和接口层面,那么数据层面是如何进行保障设计的呢?下面具体来看一下:
首先了解下数据仓库的层级设计,一般数据仓库都会分为三大层:操作数据层(数据接入层),应用数据层及公共数据层(轻度汇总,明细和维度层)。中通将公共数据层进行了细分,数据仓库的测试主要集中在公共数据层和应用数据层的测试。整个层级通过 ETL 流程进行数据的采集抽取,数据存储,转换/清洗,建模,计算,推送来实现数据流转。
数据仓库分层及 ETL 过程
上图是数据仓库的测试流程,从这个流程中可以看出来和数据应用的测试没有太多不同,具体的不同点这里进行了标注。
一般业务层的测试需求是提供产品的具体功能和逻辑,产品会给出 PRD 或接口文档进行参考和理解需求。数据仓库的需求都是通过业务方对表、字段、数据的理解给到数据仓库,再提出数据方面的需求。但是业务方又不清楚抽取过来,落到数据仓库之后表的设计。因此测试人员需要整理相应的表结构,字段类型,字段之间的对应关系,处理的逻辑规则来明确测试需求。
业务层测试会根据需求文档,通过对具体需求的理解,进行需求分析,脑图的一些设计,从而编写出覆盖业务场景的一些测试用例。而数据仓库的用例都是表字段和逻辑处理规则方面的用例,有些用例还需要通过具体的 SQL 进行说明。脚本方面主要是语言方面的差异。业务层测试主要是通过 Python,Java 等一些语言进行脚本编写。数据仓库使用的都是 SQL 进行测试脚本的编写。因此数据仓库的测试人员对 SQL 的要求比较高。
业务层测试基本是发完线上报告就算测试完成。而数据仓库的测试多了一个测试完成后的数据分析过程,主要的分析方法有:描述分析、诊断分析、预测分析和指令分析。
数据仓库的策略是根据 ETL 的流程进行测试的,目前中通数据的整体流程都会进行测试,着重点会放在数据建模和数据计算上。测试策略分成了定义,测试维度,测试范围,测试准备,测试工具,测试方法,测试目标七个维度进行诠释。具体策略如下图所示:
在了解了中通的数据仓库层级设计,ETL 数据测试流程及方法,可以看出关注的重点还是数据本身,即数据质量。下面对于如何保障数据质量做了一些总结,主要分为事前预防,事中监控和事后处理三个方面:
主要是产品经理和老板们制定一些管理机制,质量标准和模型规范,让数据在入口处就有很好的保障。
主要是由开发进行平台的搭建,由测试进行平台的质量保障和业务规则的补充。
主要是数据出了问题,由开发进行数据的修复,产品进行需求的搜集,优化质量标准和数据模型。
从以上三个方面保障线上数据质量,在用户发现或感知问题之前知道问题,从而快速进行解决。其实对于数据仓库而言,由于数据量大,数据质量完全把控起来是非常困难的。因此,性价比最高的是做线上的数据监控。
数据监控主要包括前端,后端服务,存储,数据采集和调度几个部分,其中前端主要包括监控的规则配置和执行,监控大盘,报警配置,权限配置四个模块。后端服务主要包括用户登录模块,监控规则模块,报警模块和系统管理模块。使用 MySQL 进行数据存储,数据采集层进行底层数据收集,通过服务接口进行后端的任务调度。监控平台除了平台本身还包括其它两个方面,分别是业务的逻辑规则和数据产品思维的补充和完善。
首先在数据操作层的测试环境与业务方进行对接。测试环境验证没问题,会在生产上对接 1-2 条业务线进行试点。试点顺利后进行数据操作层的推广,随着推广,平台质量和规则得以完善,最终会在数据应用层进行线上监控,实现数据的一头一尾的完整监控流程。(如下图)
基础架构是根据不同公司的不同定位而进行定制的,在中通主要包括查询,调度,元数据,实时管理,机器学习等模块。计算主要是 OLAP 和流计算,OLAP 的计算引擎主要是 Presto、Kylin、Hive、Impala,流计算主要是 Spark Streaming、Flink。还有很多不同类型的监控:小米监控,MR 监控,Spark 监控,Presto 监控。HDFS,HBase,TIDB 等进行底层的数据存储。另外,还有一些文件治理的服务,如下图。
基础架构图
在前面数据仓库保障的部分讲到了 ETL 流程,基础架构是为数据仓库提供数据服务的,因此中通自研了 ETL 系统。下面我们来看下 ETL 系统的架构图和如何进行 ETL 系统测试的。
首先是前端页面,连接后端进行调度作业,由分发器将请求分发到各个节点,由 DataX 和 Sqoop 做数据同步,查询引擎为 Hive 和 Presto,计算引擎为 Spark 和 Kylin,大数据集群和 Kubernetes 云计算做分布式底层。
ETL 测试主要是进行接口测试, 编写测试脚本请求接口,通过参数化配置生成对应的配置文件,自动运行任务,最后生成数据并对数据结果进行自动比对,从而实现 ETL 系统的自动化测试。(如下图)
基础架构还有很多的系统,这里就不一一列举了,从上面讲到的 ETL 自动化测试可以看出来,基础架构的测试主要是进行一头一尾的数据和中间规则的测试。基础架构的测试策略有哪些呢?来看下图详细描述。
使用的组件主要有调度平台,元数据平台,查询平台。分别进行优先级,依赖,权限,分发,表结构,血缘,属性,统计,语法,资源,集群方面的测试。
基础架构是为数据仓库和数据应用提供服务支持的,因此在保障方面中通做了一些工具的集成,以下是集成平台 - 中通大数据质量平台。
大数据质量平台分为四个层次:用户交互层,逻辑层,服务层和执行层。web 页面(包括一些汇总数据,图表显示等),逻辑层主要是一些对数据的处理:例如自定义的 SQL 检查,数据质量分析,配置管理,血缘分析工具,数据对比,权限管理,异构数据同步等工具。服务层主要是提供服务接口:例如元数据服务,权限服务,流程服务,字典服务,调度服务,监控服务等。执行层主要包括 Hive/Presto、Spark/Flink、Shell 等工具来进行执行操作。
大数据质量平台
最上面是数据情况,包含 Hive 、关系 DB、HBase、Redis 的表数、规则数和告警数。中间是 7 天,14 天,30 天的图表展示。最下面的是对应在具体的表或系统中的告警数。
含有 Hive/关系 DB/HBase/Redis 四个 sheet 页。其中分别包含了配置告警通知,分配设定开发者,关联前置任务,更改生命周期等模块。在表的详情里面可以配置规则,以 Hive 为例:Hive 表行数,总数,空值,平均值等常见的检查,可以自动生成对应的查询规则。如果这些不满足用户需求,还可以进行自定义的规则配置,可以通过阈值,SQL 对比等方式进行规则的定制。
质量平台首页
功能页面展示
首先谈谈对数据敏感度的理解,是业务理解力、数据理解力二者的综合结果。数据分为结构化数据,半结构化数据,非结构化数据。数据的形式是多种多样的,有最直观的数字,有 XML,JSON 等有一定格式规律的数据,有音乐或者电影能够让你瞬间产生历史记忆的一些无规则的数据。换句话说这些数据都是有自己背后的隐藏的含义,因此理解数据背后的含义是非常重要的。那么如何理解数据背后的含义呢?工作中最好的办法就是熟悉公司的业务。当有一天看到的数据和知道的业务数据去对比的时候相差超过心中阈值,那么自然会去了解其中的原因,这也是数据敏感度的形成和重要作用的体现。因此分析数据的能力是十分重要的,那么分析数据的习惯如何培养呢?
一个项目做完后,应当回头看看哪里做得好,哪里还可以改进,这个项目产生什么价值,慢慢形成相关项目的数据模型。
俗话说好记性不如烂笔头。当把很多项目,经验,一些很好的看法见解等认为有价值的东西整理为笔记,时间长了,也就拥有了一个思维库。可以通过这个思维库养成特有的一个思考方式,从而对数据有独特的观点和分析能力。
有些东西是要反复跟客户/业务人员讲的,例如查准率和查全率的区别,同比环比的区别等。这时候可以精心花时间准备两页 PPT 来说明,从而培养对数据的总结能力。
这里的表达指的是需要把思考和分析的事情说出来,说明白。这样与别人沟通的时候才能表达出准确的意思,从而提高数据准确的交互能力。
时刻注意数据分析的结果是否具有误导性,也就是 “注意数据的谎话”,但是数据本身是不会说谎的,而是取决于如何做数据分析、如何展示结果,也就是做数据分析的意义。那么数据的本质意义是什么呢?网上的定义是信息的表现形式和载体。这里我理解为理解力,就是理解一件事物的能力。理解事物的深浅就是这个当前数据的本质意义。所以就工作而言,深入的理解业务,理解公司的产品,理解产品的用户需求,这才是数据在工作中的意义。
大家都知道分析预测是大数据的一个非常显著的特点。虽然目前数据和算法还不足以完全的预测未来,但是可以感知到未来大概率会发生的事情,即大数据可以预测未来的趋势。其实可以简单的把大数据理解为能够分析概率的机器,它虽然无法保障你能做出正确的决策,但可以让你做出当前的最佳决策。因此大数据分析预测、指导实践的深层次应用将成为未来工作发展的重点。
大数据质量保障设计是一条漫长的,不断向前进步和发展的道路。设计是方向,数据是主体。作为这条道路上的一名质量人,如何保障方向的正确性和主体的准确性将会成为一直追寻的课题。相信大数据质量保障的同路人们会在大数据的道路上越走越深,越走越远。