系统思考数据质量

|0x00 质量标准体系

在谈一件事情的质量时,我们通常会想起ISO的标准,例如ISO9000,如果一件商品被打上了ISO的标签,对于自己产品的质量,是一件最有说服力的证据。
那么在数据领域有这种标准吗?有,比如ISO8000ISO9126、或者是GB/T36344-2018,但这些标准一来显得太过于“重”,二来理解和寻找资料也是困难重重,三是按照这些规范来落地也不太现实。因此把其中精华的部分抽取出来,总结成几项大的原则,再根据公司的实际情况,补充细节部分,对于数据领域的从业者而言,更为切合实际一些。
以ISO9126软件质量模型为例,包含了6个大的特性和27个子特性,其中大部分移植到数据领域,通常也是适合的。
ISO9126质量体系如下图所示:

|0x01 从数据视角思考7个一级特性

我们把ISO9126的一级特性拿出来,按照数据领域的理解,一条条过一下。
功能性
功能性提供了软件/数据产品所需要的功能,包括适合、准确、互操作和保密安全。如果用通俗的语言解释,就是数据要有、数据要准、数据要全、数据是安全的。能够按照交付标准产出数据,数据是准确的,并且能够满足使用者的诉求,同时安全性要得到保证。
这些特性在很多文章中都有提到过,只不过没有提升到数据质量体系的高度来进行阐述。例如对于数据的一致性而言,有很多地方都可以用到这个概念,比如CAP理论,比如数据库的外键,比如逆向接口开发,等等。但数据一致性所影响的,依旧是数据的准确性,那么数据一致性就应该是准确性的一种解读,而不是一个子项。
可靠性
指产品在规定的条件下,在规定的时间内完成规定功能的能力。映射到数据系统中,便是数据使用者,在使用时,数据能够按时产出。对应的要求,就是数据链路的可靠性,例如上游数据是否按时产出、Job的调度是否正确,等等。
易用性
在指定使用条件下,产品被理解、 学习、使用和吸引用户的能力。这一条是绝大多数数据从业者所忽视的一条,也就是自己做出来的报表,能否让用户读懂,而不仅仅是做出了报表产出了数据。例如我们对于数据指标的定义,用户是否接受,或者是我们所提供的数字,是否能够真的反映了商业的变化,而不仅仅是为了统计而统计。对于使用者而言,数据的结果是否能够被理解、是否满足了自己的诉求,通常跟产品需求和项目规划有关。
在规定的条件下,相对于所用资源的数量,软件产品可提供适当性能的能力。例如最近大火的实时数仓,例如老生常谈的数据倾斜,就是效率的一种解读。这些能力最终影响的,是软件所提供的价值能力,因为提供的数据越实时、计算的问题越复杂,理论上可以带来更多的价值增量。
维护性
在规定条件下,规定的时间内,使用规定的工具或方法修复成功的能力。对于互联网这一类高速增长的业务而言,如果仅仅是为了满足需求,采取了烟囱式的开发手段,那么维护起来就一定是个灾难。因此,提供数据的复用能力,就是体现维护性的重点。通常来说提升数据的维护性有两个方面,一个是软件本身,提供Cube这种预计算的能力,一种是开发过程,提高数据的模型质量,降低理解和维护成本。
可移植性
从一种环境迁移到另一种环境的能力。这个能力考验的是数据架构或者工具的能力,例如当对于数据的要求从离线转向实时,过去写好的SQL代码是否能够完好迁移。或者是当开发架构从A迁移至B(Hadoop -> Spark / Storm -> Flink),所付出的成本有多少。

|0x02 数据质量定义的拆分

这些特点可以直接拿来用吗?从概念上讲,是可以的,但是却并没有延伸到我们的日常工作中,也就是停留在概念阶段,那么如何将我们的日常工作与这些标准结合起来,就是下一步要思考的问题。
从结果上来看,如果“用户体感”不佳,也就是功能性出现了问题,都可以归因为数据质量有问题,因为最终交付的是质量结果。而要解决这个问题,就需要思考数据开发的整个链路,也就是开发过程的可靠性。虽然开发过程中可能出现许许多多的意外,导致了数据对不上/没有准时产出/结果出现波动等情况,但它们的结果却是相同的,就是“数据质量”不好
因此,我们应该把数据质量进一步切分,分为“用户可见”的数据质量,和“研发可见”的数据质量。解决“用户可见”是“治标”,通过快速恢复结果的兜底方案,来解决用户侧的问题,解决一时的困境;而解决“研发可见”是“治本”,对研发过程中平台可靠、建模清晰、数据安全等根本问题进行考量,解决长期的困境。

|0xFF “治本”,就要转换观念

大一点的公司都会配有数据测试团队,但大部分的数据开发同学对测试没有太强的感知,因为不会像后端团队那样,被各种测试的流程卡住,总体上还是处于比较早期的阶段:讲效率、重产出、轻规范
这个其实涉及到数据团队的定位问题,因为我们更多的将自己定位成业务人员,是站在与产品/运营同一角度,来解决业务问题的,而不是像工程团队那样,以稳定性为第一要务,那么要彻底解决数据质量的问题,首先就要将自己的身份定位转换过来,以研发过程的规范为抓手,来统筹整个质量体系的建设。
那么很多人要问了,我们考核的标准,不应该是价值的产出吗?如果站在业务团队的角度出发,是的,但如果站在工程团队的角度出发,就不是。道理很简单,对于工程团队,数据质量和交付效率才是第一要求,至于业务的价值,占比就不应该太重。
如果我们将重心放在产出上,那么对于数据出现的问题,往往倾向于用“治标”的方式来解决,例如动不动就降级、看不懂就不管、出了问题再解决。而只有把重心转向研发过程的管控,也就是考虑平台的性能是否满足需求、调度系统设计的不合理如何解决、数据模型如何更加合理、数据事故如何有效复盘,才能真正的“治本”。
当然,这是一个一线工程师无法自己决定的决策,但不论如何,我们应该有这样的意识,即当未来社会的发展向数字化迈进的时候,数据从业者也会产生分化,一部分人需要更多的考虑业务问题,而另一部分人需要更多的考虑质量问题。
但眼下,我们需要与测试的同学进行协作,先解决当前的问题,也就是数据测试流程的规范化,这个我们下期再说。
继续阅读
阅读原文