数仓指标一致性

数仓数据质量衡量标准

我们对数仓数据指标质量衡量标准通常有四个维度：正确性、完整性、时效性、一致性。

正确性：正确性代表了指标的可信度，如果一个指标无法保证其正确性，那么是不能提供出去使用，因为很有可能会导致作出错误的业务决策，通常会使用明细数据对比、维度交叉对比、实时对比离线等方式校验数据的正确性；另外一方面可以增加一些DQC校验，例如唯一性验证、最大/最小值验证等。

完整性：完整性可以从两个方面来说：一个是模型数据的完整性，例如字段是否存在空值、数据量是否波动比较大有数据缺失等；另一方面指标的丰富程度，是否有完整的数据指标来支撑业务上的分析决策。

时效性：数据产出是否及时，例如对于实时数据保证一分钟以内的延时，离线数据保证在每天8点必产出。因为离线任务是走周期性调度的，可以对不同重要程度的任务设置不同的调度优先等级，重要任务高优先级调度，以保证其产出的时效性，另外可以做一些任务处理上的优化，常见数据倾斜问题，缩短任务处理时间。

一致性：一致性表示相同的业务指标在不同的场景下(这里的场景可以系统、数据模型、实时/离线等)其指标值不一致。通常的问题可能是计算口径不一致、计算数据来源不一致等等。

关于数据质量衡量标准除了以上四个维度外，可能还会有规范性、安全性等上面的考虑，其中一致性是出现比较多的一类问题，同时排查起来的难度也比较大，笔者将结合实际开发中遇到的一致性问题谈谈自己的看法。

指标一致性

指标一致性从问题表现上分为三类：不同模型中相同数据指标其值不一致、交叉维度数据汇总值不一致、实时/离线指标不一致，接下来分别谈谈这几类问题。

1

不同模型中相同数据指标值不一致

这类问题通常是比较明显的，在两个不同的数据模型对比时或者是在两个不同的系统中相同指标时其值不一致，其原因通常有以下几点：

• 指标计算口径不一致，指标由不同的数据需求方提出其对指标的定义不同或者是不同的数据开发同学对指标的理解不同导致了不同的计算口径， 例如广告订单统计，一个是session口径，一个是cookie口径；
• 计算使用的数据源不一致，这里面可能是有重复的采集链路，数据采集的规则又不一致；
• 不同的业务口径数据，使用了相同的指标命名，没有按照数据开发规范或者是没有统一的字段命名规范导致命名歧义，例如下单金额/支付金额同时命名为order_amt。

对于相同的指标我们都知道需要采取的策略就是复用，将公共的指标沉淀到dws层或者是adm层，提供给上层不同的使用方，但是为什么还是会经常出现一致性问题，我认为可以从组织合理性、需求/模型评审机制角度去解决。

组织的合理性

在早期的数仓建设中，不同的数据开发人员随着不同业务线的方式去建设该业务域的数据，也就是我们常说的烟囱式开发，这种方式的优点就是可以随业务快跑，但是随着公司的体量变大业务线变多，这种方式就不适用了，因为不同业务线的数据开发人员很难达到信息完全互通，必然会导致很多重复性的建设工作，从数据埋点、采集、开发都有可能会重复建设，因此需要将数据以中台化的方式提供出去，在组织结构上建立中台部门，专门负责数据中间层的开发，对于这部分人员需要有全局的视角去看待数据指标的沉淀，上层应用层由专门的业务线的数据开发负责

需求/模型评审机制

建立统一的需求评审机制，从需求承接时间、制定需求模板(业务背景、所需的数据指标等)等制定一套规范，严格把控需求质量，如果需求承接本身变得很混乱，例如需求不明确、需求没有统一管理，那么很可能会导致重复性的建设工作；模型评审主要评审模型设计的是否合理，表/字段命名是否规范、应该是全量表还是增量表、分层是否按照要求、公共指标应该放在dws层还是adm层等，保证模型的质量来避免以后出现的二义性。

2

交叉维度数据汇总值不一致

交叉维度数据汇总值不一致表示的是不同低维向相同高维汇总得到的指标不一致，例如在广告场景中，广告投放会创建投放计划，投放计划里面会投放不同的商品，在统计广告效果数据就会产生计划维度数据、商品维度数据，但是可能会出现计划维度向上汇总账户数据与商品维度向上汇总账户数据不一致。这里出现的原因一般有以下几点：

• 数据缺失，在明细数据层某个维度的数据出现空值情况导致向上汇总记录丢失；
• 计算口径不一致，例如商品维度数据与计划维度数据其计算的口径不一致，必然导致向上汇总结果不一致。

解决这类问题，需要提前对数据进行交叉验证，即明细层与不同维度层数据进行交叉验证，确保数据的一致性。

3

实时、离线指标不一致

目前大多数情况下使用的数仓架构还是经典的Lambda架构，因此实时、离线指标不一致仿佛成为了数据开发人员的一个共识，导致出现一致性问题通常有以下几点原因：

• 计算逻辑无法对齐，其原因有二：一、实时、离线是两个不同的数据团队成员开发，其对业务的理解不同；二、离线逻辑本身相对比较复杂，可以做很多补偿逻辑，实时处理却相对比较简单；
• 数据源不一致，通常接入的数据源有日志与binlog，binlog基本都能保证一致，但是对于日志在一些场景不能做到完全一致，例如风控场景提供的点击日志提供下游使用，实时、离线反作弊模型差异导致风控过后的数据存在差异；
• 离线、实时技术栈对一致性的支持程度不同，离线通常都是批处理的调度模式，当出现异常情况，只需要重新调度直接进行分区覆盖即可，而实时处理本身对消息处理的顺序性有比较高的要求，另外加上端到端一致性实现复杂等等，在某些场景并不能保证与离线同等的一致性。

针对以上问题，提供两种思路：第一种是预先实时、离线指标对比，找到其中产生数据gap的原因并且解决， 尽量降低实时与离线之间的差异，同时也可以提前说明实时指标准确率；第二种流批一体的架构，流批一体可以从计算统一，也可以是存储统一，这里主要介绍流批一体的OLAP架构，只需要将数据实时或者离线写入OLAP存储引擎中，直接在OLAP进行分析，这种方式弱化了离线、实时的概念，例如Hologres 、Doris等。