万字详解数据质量那些事儿

大家好，我是老兵。

在数据仓库建设的过程当中，大家是否会有这样的疑问:

1）数仓分层模型是否需要严格遵守
2）照本宣科建设的数仓貌似不好用
3）如何评判一个数仓建设的质量好坏
4）我的数据仓库还能做怎样的升级

我们该如何解决这些问题？其实一般抛出此类话题，说明数仓建设已经发展到一定规模，这个时候需要考虑数仓质量问题。

毫无疑问，要想保持数仓的稳定、高效，数仓质量建设是势在必行的一步。否则再好的业务数据分析也会捉襟见肘，数据运维将变得十分痛苦。

本文将重点阐述，如何构建可实施落地的数仓建设质量体系之路。

1 数仓建设的核心要求

数仓建设普遍是纵向分层建设，横向主题域划分，如下图所示

• ODS层: 贴源层。旨在集团、子公司、互联网及三方外部数据输入层，基本保持源表原貌(存在敏感数据加密)。

• DW层: 数仓层。可细分为dwd和dws子层。DWD层为数据明细层,DWS层为数据汇总层。

• DIM层。维度层，保存一些企业常用的维度表，如: 日期维、地区维、商品维、用户维等。

• DM层: 数据集市层(主题层)。面向应用主题汇总DW层数据(如: 渠道、产品、会员等主题)。

• APP层: 面向具体应用的结果集，包含但不限于：集团共享库、子公司的分析私库、输出接口库等

数仓开发的同学相信对此不会感到陌生，上述数仓分层几乎已经成为行业标准。当然它在一定程度上规范了数据建设的标准，但也仅仅只是个前奏，并不能全面反映数仓建设的核心要求。

数据仓库的核心在于数据模型的可复用性且需要的计算资源是可量化的，可控的。

2 怎么判定好的数据模型设计

好的数据模型设计往往兼顾数据的分区存储，数据的复用性以及计算资源的分配最大化。

而在数据开发时我们经常是从数仓分层的角度出发，仅仅关注数仓分层间的开发，往往没有从这些方面考虑。

那么不合理的数仓模型设计、不规范操作可能会带来什么影响呢？

下面我将通过一个实际工作中遇到的例子来分析。

2.1 场景复现

不规范操作： 直接从DWD层，甚至是ODS层暴力跑SQL

这类操作是我在一次数仓运行缓慢问题排查中发现的。

业务层直接依赖DWD层和ODS层，导致ODS层的任务越来越多。在计算资源不变的情况下，例行化任务跑的越来越慢，甚至拖延了日常核心报表的产出时间。

再来看看具体数据，下面是部分大型例行化任务对应的资源消耗情况。

从图中可以明显感受到这几个大任务已经把凌晨时间段的资源占用完了，导致平台资源一直处于十分紧张的状态。

通过日志统计发现，ODS: DWD: DWS: ADS的读取任务分别是35:44:7:14，直接读取ODS层任务占着四层任务总和的35.3%。

2.2 问题分析

通过对比资源消耗和日志统计，我们总结出了两个问题：

• 大部分任务都是从原始数据直接加工，DWS等聚合模型复用性很差，导致DWD、DWS、ADS层数据建设缺失严重。

• 查询越底层的表，就会导致查询扫描的数据量越大，查询时间越长，消耗资源越大。像是滚雪球一般，查询时间疯狂增长。

随后对ADS应用层引用最大依赖层进行分解，发现高达54.3%的表直接引用了ODS层表，说明有部分ODS层表被进行暴力跨层深加工且没有走可复用的数据模型。

2.3 问题处理

在发现问题后，我重新对数仓的层级表进行改造。主要从拆解表的层级依赖和数据量两方面出发，重构后的DWD、DWS、ADS层如下:

自此，数仓的复用性得到了很大的提高，凌晨计算资源也得到了很大的缓解。

通过对这个实际生产应用问题的分析，我们得出最理想的数仓模型设计应该具备的基本因素。

（1）数据模型可复用
（2）整体资源消耗合理可控

这两个基本要素，也是数据质量建设解决的核心问题。

数仓质量的建设是数仓体系必备环节。否则一个业务还没有起来就已经被高昂的数据成本所压垮，最终走入望数兴叹的尴尬境地。

3 数仓质量度量体系及升级思路

数据仓库想做到高效、稳定、易用，一个完善可靠的质量度量体系必不可少。

业界评估数据质量的标准不尽相同，本文从以下可信度、复用度、规范度、资源度、稳定度、完善度六个维度考核数仓建设质量以及对应的升级思路。

3.1 可信度

数据可信是数仓的立身之本。连数据的可信度都不高的数仓很显然得不到业务团队的青睐。

要做到数据可信首先要确保以下几点：

1） 准确性

准确性是指数据记录的信息是否存在异常或错误。数据记录的异常或错误可能会存在数据链路的各个环节。

最为常见的数据准确性错误如：埋点上报异常，乱码，数据计算规则错误。常见的准确性指标有：缺失值占比、错误值占比、异常值占比、抽样偏差、数据噪声。

在计算这些指标的时候通常需要数据团队与其他团队一起合作，对数据进行校验。

例如数仓数据的准确性往往在数据埋点上传的时候就会受到挑战。

升级思路

• 建设公司级标准的埋点SDK

  即便公司级已有一套标准的SDK，由不同的业务性技术人员接入时也会因理解问题或内部沟通问题导致埋点数据上报误差。

• 建设后台埋点上报测试平台

  此时经常需要数据开发人员利用对埋点进行测试以及规范，确保源头准确性，并相应的调整取数规则。

• 对比第三方平台

  当然，我们也可以利用第三方平台的数据对一些指标数据进行对比，如果很多公司很早之前就接入过类似友盟，有赞这样的平台。对于一些核心数据可以拿第三方平台数据进行参考。

2）数据唯一性

唯一性指的是数据库的数据不存在重复的情形。

数仓当中一般没有主键唯一约束的概念。我们通过数据同步工具将数据库中的数据导入到数仓当中很难避免数据重复。

升级思路

• 数据清洗侧加入数据唯一性规则：

  例如同一笔订单因为宕机等原因被重复消费，这种数据不符合数据唯一性。为了避免这类情况会很多做法，比如：kafka幂等、flink的checkpoint、下游数据库主键唯一去重等。

• 建设数据质量监控体系：

  对数据内容的的质量进行一系列检测，并计算出若干量化指标，最后产出数据质量报告供该数据的订阅者查阅。如下图：

合理的数据质量监控体系使表的关注者能及时收到相关的告警信息，发现和解决数据问题。而不是等业务人员找到技术人员反应问题，彼时已经相对被动。

3） 数据一致性

一致性是指数据是否遵循了统一的规范，主要体现在数据记录的规范和数据是否符合逻辑。

一致性并不意味着数值上的绝对相同，而是数据收集、处理的方法和标准的一致。常见的一致性指标有：采集方法一致、转化步骤一致、取值逻辑一致。

例如计算DAU时业务线以设备ID进行计算而不是用户ID。

3.2 复用度

复用度即下层表被上层表的平均引用次数。对应一个数据表而言，其复用度应该是它的下游表个数，也就是有多少张表是由该表直接参与计算产生的。

而对每一层的所有表，取它们复用度的平均值，就是该层的平均复用度。

例如DWD层的复用度一般应该在2-3左右，如果小于2，往往说明DWD层的数据模型设计的不够好，复用性比较差。

升级思路

• 建设发散性结构数仓模型:

  如下图，我们可以看到，一个比较差的模型设计，自上而下是一条线。而理想的模型设计，它应该是交织的发散性结构。

3.3 规范度

规范度描述数据遵循预定的语法规则的程度，是否符合其定义，比如 表是否被归属到确定的分层以及主题域中，同时表明是否反映了该表的分层信息和业务主题域信息。

如果数据仓库中只有较少比例的表有分层信息，那这个数据仓库建模肯定是不合格的。

同样的，如果表没有被归属到确定的主题域，用户在使用数据的时候也很难找到这张表，这样的数据数仓建模不规范。

除了表以外，数据表中的字段命名是否规范、具有直接血缘继承关系的字段命名是否一致也属于规范度衡量的范畴。

3.4 资源度

资源度主要取决于对表的成本量化。表的成本就是简单的由其自身的计算成本和存储成本相加。

而在计算其下游表的成本的时候，就要叠加上游表的成本进去。同样的，在一个表有多个下游表的情况下，其成本应该分摊到其所有下游表的成本中。

这里可以总结出数仓中表的成本公式，在老兵之前的文章也有讲到过，如下图：

表 的成本：

其中 为表 的入度， 为表 的出度，(=1,2,...,)为表 的所有上游表， 为表 的存储成本， 为表的直接任务计算成本。

当我们发现数据表的成本极高，就需要关注计算任务是否有可以优化的地方或者继续存在的必要。

比如常见的资源优化的手段：

• 升级计算引擎（比如有Hive切换到Spark）

• 数据分区本地预计算

• 列存储&文件压缩

3.5 稳定度

稳定度可以用两个标准来衡量：

• 及时性

• 容错性

及时性是指数据从产生到可以查看的时间间隔，也叫数据的延时时长。

比如一份数据是以T+1进行更新的，结果到了第二天甚至第三天才能统计完，这样的任务显然不符合数据及时性。

在和数据打交道的时候经常会出现一下场景：

• 场景一：当数据分析人员发现数据明显异常，就会要求数据开发进行排查。数据开发花费大量的时间定位问题的根源

• 场景二：数据开发定位到数据一次是因为外部源数据异常，导致下游的计算都出现问题。但是修复数据过程需要人工介入且低效。

如果数仓应付不了以上这些场景，说明它的容错性是很低的。

归结起来这样的数据仓库存在两个问题：问题根源定位慢以及修复数据成本高

升级思路

• 参考老兵上一篇文章（腾讯分析师第三弹：数据治理那些事儿）

• 引入第三方工具

小团队如果无法做到如（1）一样比较完善的系统，推荐引入DataX（数据同步框架）和DolphinScheduler（海豚调度框架）。

结合自身的业务与这两个框架结合也可以比较好的保证数仓建设的稳定度。

3.6 完善度

完善度是指DW中各层数据模型建设的完善程度，DW包括DWD明细层和DWS/DWM等汇总层。

对于DWD明细层的完善度，我们用汇总层对ODS层的跨层引用率来衡量。

如上图，绿色箭头的我们认为是规范的跨层引用，黄色次之，而红色部分则不建议这样做。

按照数仓建模规范，跨层应用是应该被避免的现象，如果DWS/DWM等汇总层的计算必须跳过DWD层直接应用ODS层数据，那就说明DWD层的数据模型不够完善，还未覆盖所有的明细查询场景。

在数仓模型建设过程中，我们应该追求0%的跨层应用率。

• ODS层应该完全由DWD层屏蔽，实现原始数据与上层数据的隔离。

• DWS/DWM等汇总层的完善度，我们则需要通过汇总层对业务查询的支持率来衡量，即有多少业务查询需求是有汇总层直接支持的。

与跨层引用率不同，我们对这里的支持率只是要求越高越好，但是面对复杂多变的业务查询需求，这里的支持率很难做到100%。

4 写在最后

还记得前辈说过的话：升级数据仓库，重点在数据质量场景，对此我深以为然。如何更好的建设数据仓库，维护一套标准的数据质量体系，是数仓人需要关注的一个重点。

希望本文能给数仓开发的小伙伴带来启发，帮助大家建设一个高质量、稳定高效的数仓。

》》》更多好文，欢迎关注我的gzh: 大数据兵工厂