参考DAMA教材，数据质量提升的步骤包括了数据剖析（数据探查）、原因梳理及实施的3步不断迭代循环。

数据剖析

       理论上数据质量应该由数据使用人来评估，作为大数据团队的需求方，业务团队对于这个是没有概念的，最常见的场景仅仅是业务方提出取数需求，报表需求等来拿数据，偶尔对比一下不同报表的数据。但是作为大数据团队，如果要对外提升自己团队的数据质量，我认为需要自己探查数据源以及对自己的数据负责。

       针对数据源剖析和梳理，需要明白如下几点

       1.数据全量/增量存储，关系到如何ELT取数规则。我认为既然采用了ELT的方式，那么在设计维度表模型时可以考虑将变化速度较慢以及某些仅关注当前状态的维度汇集设计成非分区表。在ODS层已经存储了全量数据，满足了回溯的需求，且可以一定程度上减少存储的消耗。

       2.字段的空值和‘’字符串、极值、数据量分布、数据格式、唯一性、列之间的依赖、约束。更深包括联系业务而落数据的方式，更好的理解数据。如埋点，可能APP团队将全埋点和代码埋点合并在一条数据，而H5团队分为了2条数据；或者如用户进行了股票交易，那么在资金、交易、账户多个表的数据联系。

       3.数据准确性。第二条提到了数据分布，可以根据常识、业务判断数据是否准确；若表内部记录之间存在关联，则也需要关注。如行为埋点信息，用户根据时间排序，上下两条的url和点击事件需要能够串联。这个主要是根据不同的表进行关注。核心是不能脱离业务。

实施方式

理论终究是理论，我们没法找到一个最全的列表来涵盖所有情况，需要不断总结。但是我认为思考的范围可以根据DAMA提出的数据质量维度发散思考得到，再结合实际。主要的维度包括数据准确性、完备性、一致性、合理性、及时性。设计的方面包含了前台、中台，即数据源、数据模型和数据使用。

准确性：即真实程度

数据源：

        1.参考数据剖析里的数据准确性，需要结合业务和数据。主要还是通过数据探查和上游团队沟通，确定方案。数据可能达不到100%的准确，这时候需要确定一个可接受的准确性占比并在加工的时候整理维护清洗规则。清洗规则需要详细，明细到不同日期，不同版本，使用的数据集等等，使开发人员和后来人员能够快速了解。

        2.数据源文档的完整和实效性保证。上游可能由多个数据源，同一个数据源可能有多个意思差不多的字段，需要能够区分，最好能够对应到业务流程。

数据模型：

        1.业务修改需要能够及时同步指标口径。但是这需要各位老板去推动，单靠数据团队没法推动，所以这一点可能比较难。

        2.数据落地方式，表结构修改等，需要及时同步。

        3.明确指标口径，不赘述。

数据使用：对模型进行宣导，防止应用层错误使用数据

完备性：是否存在所有必要的数据，主要体现在数据模型。

        若采用Kimball指导思想，那么首要的是梳理出所有指标，作为范围进行设计模型。原则是不删除数据，只要上游能够获取到的，有必要获取的数据都需要落到数据，哪怕是清洗规则也不允许删除数据。

         若考虑从整体业务出发，那么必有一个人能够全面了解业务，但是我认为还是需要业务方的介入，进行指标范围的确认。

一致性：数据集内和数据集之间的数据相符程度。

        这里只探讨数据模型，对于应用层数据，主张统一从数仓层统一出数据，这样只需要保证数据模型数据的一致性即可保证应用层数据质量。一致性更多的是设置一些校验规则和规范的确立。一致性是标准化的基础，标准化促成一致性。

包括：1.数据字典 2.数据规范 3.数据之间通过业务校验 4.字段值唯一性 5.ETL清洗规则等

合理性：数据符合预期的程度

        目前能想到的是通过应用来校验，有一些数据即时通过了上一条的各种校验，仍然在使用时存在问题。包括数据的逻辑，数据的使用难易程度，可能需要需要重新设计来使模型更加合理。需要数据接口的开发使用后反馈。

及时性

或许首先想到的是数据的延迟，深究下来，主要可以提升的包括

1.代码的可维护性。需要缩短定位的门槛，维护文档，代码的注释，字段的注释，任务版本迭代的说明，wiki的配套归档

2.整体任务的链路设计。任务依赖太过复杂，中间加工层次过多都会导致这个问题。

3.任务的效率，性能问题。

4.应用系统的延迟程度，非可控，依赖于上游系统的设计

5.后台支持，如flink设置的延迟等。但是需要考虑延迟的必要性，如车载的系统实时性和BI的实时性，不能一味追求实时