系统思考数据质量

系统思考数据质量

|0x00 质量标准体系

在谈一件事情的质量时，我们通常会想起ISO的标准，例如ISO9000，如果一件商品被打上了ISO的标签，对于自己产品的质量，是一件最有说服力的证据。

那么在数据领域有这种标准吗？有，比如ISO8000、ISO9126、或者是GB/T36344-2018，但这些标准一来显得太过于“重”，二来理解和寻找资料也是困难重重，三是按照这些规范来落地也不太现实。因此把其中精华的部分抽取出来，总结成几项大的原则，再根据公司的实际情况，补充细节部分，对于数据领域的从业者而言，更为切合实际一些。

以ISO9126软件质量模型为例，包含了6个大的特性和27个子特性，其中大部分移植到数据领域，通常也是适合的。

ISO9126质量体系如下图所示：

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

我们把ISO9126的一级特性拿出来，按照数据领域的理解，一条条过一下。

【功能性】

功能性提供了软件/数据产品所需要的功能，包括适合、准确、互操作和保密安全。如果用通俗的语言解释，就是数据要有、数据要准、数据要全、数据是安全的。能够按照交付标准产出数据，数据是准确的，并且能够满足使用者的诉求，同时安全性要得到保证。

这些特性在很多文章中都有提到过，只不过没有提升到数据质量体系的高度来进行阐述。例如对于数据的一致性而言，有很多地方都可以用到这个概念，比如CAP理论，比如数据库的外键，比如逆向接口开发，等等。但数据一致性所影响的，依旧是数据的准确性，那么数据一致性就应该是准确性的一种解读，而不是一个子项。

【可靠性】

指产品在规定的条件下，在规定的时间内完成规定功能的能力。映射到数据系统中，便是数据使用者，在使用时，数据能够按时产出。对应的要求，就是数据链路的可靠性，例如上游数据是否按时产出、Job的调度是否正确，等等。

【易用性】

在指定使用条件下，产品被理解、 学习、使用和吸引用户的能力。这一条是绝大多数数据从业者所忽视的一条，也就是自己做出来的报表，能否让用户读懂，而不仅仅是做出了报表产出了数据。例如我们对于数据指标的定义，用户是否接受，或者是我们所提供的数字，是否能够真的反映了商业的变化，而不仅仅是为了统计而统计。对于使用者而言，数据的结果是否能够被理解、是否满足了自己的诉求，通常跟产品需求和项目规划有关。

【效率】

在规定的条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。例如最近大火的实时数仓，例如老生常谈的数据倾斜，就是效率的一种解读。这些能力最终影响的，是软件所提供的价值能力，因为提供的数据越实时、计算的问题越复杂，理论上可以带来更多的价值增量。

【维护性】

在规定条件下，规定的时间内，使用规定的工具或方法修复成功的能力。对于互联网这一类高速增长的业务而言，如果仅仅是为了满足需求，采取了烟囱式的开发手段，那么维护起来就一定是个灾难。因此，提供数据的复用能力，就是体现维护性的重点。通常来说提升数据的维护性有两个方面，一个是软件本身，提供Cube这种预计算的能力，一种是开发过程，提高数据的模型质量，降低理解和维护成本。

【可移植性】

从一种环境迁移到另一种环境的能力。这个能力考验的是数据架构或者工具的能力，例如当对于数据的要求从离线转向实时，过去写好的SQL代码是否能够完好迁移。或者是当开发架构从A迁移至B（Hadoop -> Spark / Storm -> Flink），所付出的成本有多少。

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

这些特点可以直接拿来用吗？从概念上讲，是可以的，但是却并没有延伸到我们的日常工作中，也就是停留在概念阶段，那么如何将我们的日常工作与这些标准结合起来，就是下一步要思考的问题。

从结果上来看，如果“用户体感”不佳，也就是功能性出现了问题，都可以归因为数据质量有问题，因为最终交付的是质量结果。而要解决这个问题，就需要思考数据开发的整个链路，也就是开发过程的可靠性。虽然开发过程中可能出现许许多多的意外，导致了数据对不上/没有准时产出/结果出现波动等情况，但它们的结果却是相同的，就是“数据质量”不好。

因此，我们应该把数据质量进一步切分，分为“用户可见”的数据质量，和“研发可见”的数据质量。解决“用户可见”是“治标”，通过快速恢复结果的兜底方案，来解决用户侧的问题，解决一时的困境；而解决“研发可见”是“治本”，对研发过程中平台可靠、建模清晰、数据安全等根本问题进行考量，解决长期的困境。

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

大一点的公司都会配有数据测试团队，但大部分的数据开发同学对测试没有太强的感知，因为不会像后端团队那样，被各种测试的流程卡住，总体上还是处于比较早期的阶段：讲效率、重产出、轻规范。

这个其实涉及到数据团队的定位问题，因为我们更多的将自己定位成业务人员，是站在与产品/运营同一角度，来解决业务问题的，而不是像工程团队那样，以稳定性为第一要务，那么要彻底解决数据质量的问题，首先就要将自己的身份定位转换过来，以研发过程的规范为抓手，来统筹整个质量体系的建设。

那么很多人要问了，我们考核的标准，不应该是价值的产出吗？如果站在业务团队的角度出发，是的，但如果站在工程团队的角度出发，就不是。道理很简单，对于工程团队，数据质量和交付效率才是第一要求，至于业务的价值，占比就不应该太重。

如果我们将重心放在产出上，那么对于数据出现的问题，往往倾向于用“治标”的方式来解决，例如动不动就降级、看不懂就不管、出了问题再解决。而只有把重心转向研发过程的管控，也就是考虑平台的性能是否满足需求、调度系统设计的不合理如何解决、数据模型如何更加合理、数据事故如何有效复盘，才能真正的“治本”。

当然，这是一个一线工程师无法自己决定的决策，但不论如何，我们应该有这样的意识，即当未来社会的发展向数字化迈进的时候，数据从业者也会产生分化，一部分人需要更多的考虑业务问题，而另一部分人需要更多的考虑质量问题。

但眼下，我们需要与测试的同学进行协作，先解决当前的问题，也就是数据测试流程的规范化，这个我们下期再说。