读数据质量管理：数据可靠性与数据质量问题解决之道09数据可靠性

1.       数据可靠性

1.1.         数据可靠性指的是一个组织在整个数据生命周期中提供高数据可用性和健康状况的能力

• 1.1.1.           是高数据质量带来的结果

• 1.1.1.1.            高质量的大数据是这个大规模转型平台的核心

• 1.1.2.           随着公司接收到比以往更多的事务型数据和第三方数据，以及组织中的所有员工在数据生命周期的各个阶段都会与这些数据进行交互，这些数据的可靠性变得越来越重要

• 1.1.3.           数据可靠性必须有意识地构建到组织的各个级别，从用来构建和管理数据栈的流程和技术，到在下游进一步沟通和分析有关数据问题的方式

1.2.         历史数据并不能反映出受众的日常生活现状，而实时数据变得至关重要

• 1.2.1.           不仅可以用来确定广告支出，还可以用来了解当前用户与应用程序和互联网上内容的交互状态

1.3.         实现数据可靠性的基础是关注数据治理、数据质量和重构系统

• 1.3.1.           对其数据质量和数据治理工作进行重大投资

• 1.3.2.           通过投资数据测试和数据可观测性并设置明确的数据可靠性SLA来评估数据可靠性，能够在数据宕机影响下游消费者之前进行补救

1.4.         预先并跨领域投资受DevOps启发的流程，即数据测试和数据可观测性

1.5.         构建一个弹性且性能良好的数据平台

1.6.         设置并协同跨组织数据的SLA、SLI和SLO

1.7.         将数据质量策略从仅由数据工程师和其他上游角色管理的孤立体验，转变为更广泛的、由公司优先考虑的事情是一个渐进的过程

2.       摄取数据时

2.1.         确保在将数据导入数据仓库或数据湖之前的高数据质量

2.2.         组织通常会根据业务需求从内部、外部和第三方来源获取数据

• 2.2.1.           你的决策质量取决于你用来洞察和分析的数据

• 2.2.2.           输入的是垃圾，输出的也是垃圾

2.3.         为进入其数据生态系统的所有数据建立了严格的数据质量控制标准

2.4.         数据清洗、数据整理（将数据结构化并转换为所需格式的过程）和数据测试等最佳实践都是组织确保数据质量满足其组织需求的方式

• 2.4.1.           该领域出现了大量工具来为公司自动化完成这一过程

• 2.4.2.           对该过程进行自动化，组织不仅可以在数据清洗时节省时间和资源，而且可以确保在数据进入其生态系统时持续控制和管理传入数据的质量

• 2.4.2.1.            其格式

• 2.4.2.2.            一致性

• 2.4.2.3.            完整性

• 2.4.2.4.            新鲜度

• 2.4.2.5.            唯一性

2.5.         数据清洗

• 2.5.1.           数据清洗通过从数据集中删除不完整、不相关、不正确、格式不对或重复的数据来准备并修改数据以供未来进行分析

• 2.5.2.           数据清洗的职责也开始越来越多地落在数据生产者身上

• 2.5.2.1.            无论谁“负责”数据清洗，我们都要让组织中的其他成员了解数据的重要性，因为公司中的每个人都在确保数据完整性方面发挥着关键作用

2.6.         数据充实(data enrichment)

• 2.6.1.           在数据充实的过程中，组织能够把一手数据或第三方数据整合并添加到已经在使用的数据集中

• 2.6.2.           对数据进行充实，组织能够为其数据集增加更多价值，最终使数据变得更加有用和可靠

2.7.         数据测试

• 2.7.1.           在数据清洗后，数据测试是在摄取数据前抵御低质量数据的最佳防线

• 2.7.1.1.            数据测试是一个在生产之前或生产期间验证组织对数据的假设的过程

• 2.7.1.2.            编写检查唯一性和not_null（非空）等基本测试是组织对其源数据进行基本假设测试的方法

• 2.7.1.3.            dbt是数据领域具有精确测试能力的另一种解决方案

• 2.7.1.4.            数据测试只会发现预期的数据质量问题，它没有可扩展性或知识来解释“未知的”数据质量问题

• 2.7.1.5.            用被动监控和异常检测来补充测试是非常重要的

• 2.7.2.           确保数据采用正确的格式供其团队使用，并确保数据满足其业务需求

• 2.7.3.           单元测试

• 2.7.3.1.            单元测试检查一行代码(SQL)是否做了它应该做的事情，可以用于非常小的数据片段

• 2.7.3.2.            在对数据进行单元测试时，必须将业务逻辑与“黏合代码”(glue code)分开

• 2.7.4.           功能测试

• 2.7.4.1.            功能测试用于大型数据集，并且通常与数据验证、完整性、摄取、处理、存储和ETL相分离

• 2.7.4.2.            经常发生在数据管道（预分析层）中

• 2.7.5.           集成测试

• 2.7.5.1.            用于确保数据管道符合有效性标准（即在预期范围内）

• 2.7.5.2.            在利用生产数据之前，团队会使用集成测试在管道中运行假数据

• 2.7.6.           常见的数据质量检查

• 2.7.6.1.            空值

>  2.7.6.1.1.             是否有未知值(NULL)？

• 2.7.6.2.            新鲜度

>  2.7.6.2.1.             数据有多新？

>  2.7.6.2.2.             最近一次更新是一小时前还是两个月前呢？

• 2.7.6.3.            容量

>  2.7.6.3.1.             数据集代表了多少数据？

• 2.7.6.4.            分布

>  2.7.6.4.1.             数据是否在可接受的范围内？

>  2.7.6.4.2.             给定列中数据的单位是否相同？

• 2.7.6.5.            缺失值

>  2.7.6.5.1.             数据集中是否缺失了任何值？

• 2.7.7.           “不良数据”(bad data)

• 2.7.8.           数据工程师永远不应该使用未经测试的数据来运行数据管道

• 2.7.8.1.            在运行管道前清楚地了解数据的健康状况

• 2.7.9.           测试职责分散到数据集上，由各自的分析师和工程师负责创建和维护他们正在构建数据管道并日常交互的数据集的测试

• 2.7.9.1.            数据质量保证团队来处理数据测试，其职责包括为业务用例创建测试并维护现有的测试

3.       度量和维护管道中的数据质量

3.1.         20世纪90年代，当网站宕机时，大多数人都注意不到网站重新启动并再次上线的时间，因为大多数网站的用户数量都很低

3.2.         如今，每个人都会注意到你的服务或应用程序是什么时候宕机的

3.3.         如今，几乎所有托管软件的企业都依赖站点可靠性工程(SRE)来确保生产中的应用程序始终可靠

• 3.3.1.           让SRE团队保持对其系统健康状况的持续关注是非常重要的

3.4.         可观测性是工程领域最新加入的一个术语

• 3.4.1.           描述了这一需求，指的是监控、跟踪和检测事件，以防止宕机

3.5.         SRE的核心在于应用程序的可观测性被分为三大支柱

• 3.5.1.           指标是指随时间的推移测量出来的数据的数字表示

• 3.5.2.           日志是在给定时间戳所发生事件的描述性、定性文本记录

• 3.5.2.1.            关于特定事件是何时发生的这一有价值的背景信息

• 3.5.3.           跟踪表示分布式环境中因果相关的事件

3.6.         高数据质量的指标

• 3.6.1.           新鲜度

• 3.6.1.1.            数据是最新的吗？

• 3.6.1.2.            最后一次生成数据是什么时候？

• 3.6.1.3.            其中包含/省略了哪些上游数据呢？

• 3.6.2.           分布

• 3.6.2.1.            数据是否在可接受的范围内？

• 3.6.2.2.            格式是否正确？

• 3.6.2.3.            数据完整吗？

• 3.6.3.           容量

• 3.6.3.1.            所有的数据都送达了吗？

• 3.6.4.           模式

• 3.6.4.1.            模式是什么，它是如何变更的？

• 3.6.4.2.            谁做出了这些变更，是出于什么原因呢？

• 3.6.5.           沿袭

• 3.6.5.1.            对于给定的数据资产，受其影响的上游来源和下游资产都有哪些呢？

• 3.6.5.2.            是谁在生成这些数据

• 3.6.5.3.            谁又依赖这些数据来做出决策呢？

• 3.6.6.           让你了解数据在其生命周期每个阶段的健康状况的关键度量标准，并为我们提供了一个查看数据质量的全新视角

3.7.         数据宕机时间是指数据丢失、错误或不准确的时间段，通常表明数据管道已经出现了损坏

• 3.7.1.           确定数据的可靠性并确保人们有足够的信心使用该数据

• 3.7.2.           鉴于SRE将应用程序宕机时间作为时间的函数进行测量，我们也可以用类似的方式来测量数据的宕机时间

• 3.7.3.           测量数据的正常运行时间和宕机时间是广泛适用的，这也为理解数据健康状况提供了一个良好的起点

4.       下游的数据质量

4.1.         当数据通过管道传回收集数据的应用程序和服务时，你在数据到达分析层甚至更高层之前都很可能不会意识到数据是“坏的”​

4.2.         数据可靠性仪表板，在数据到达仪表板后跟踪检测所需时间(Time To Detection，TTD)、解决所需时间(Time To Resolution，TTR)和其他数据质量指标

• 4.2.1.           不相关或错误数据所占比率

• 4.2.2.           给定数据集中空值或缺失值的数量，或者说数据的完整性

• 4.2.3.           数据的及时性

• 4.2.4.           重复值的百分比

• 4.2.5.           数据的一致性

• 4.2.6.           能够持续访问和使用数据的职能团队的数量

• 4.2.6.1.            适用于应用了分布式数据架构（比如数据网格）的情况，数据质量对其来说至关重要

4.3.         SLA建立了客户承诺和对未达到SLO的惩罚

4.4.         SLI就是被测量的具体数字

4.5.         SLO是为SLI设置的实际目标值

4.6.         净推荐值(Net Promoter Score，NPS)度量利益相关方对数据的满意度

4.7.         设置SLA和SLI的一种简单方法是了解他们将使用数据做什么，以及应该通过测试、可观测性和其他工具对哪些数据进行优先级排序

• 4.7.1.           编写数据测试甚至监控所有关键数据资产几乎是不可能的

4.8.         评估数据质量

• 4.8.1.           完整性

• 4.8.1.1.            数据有多完整？

• 4.8.2.           及时性

• 4.8.2.1.            数据是否准时到达？

• 4.8.3.           有效性

• 4.8.3.1.            数据是否满足所有语法要求（即格式、类型或范围）​？

• 4.8.4.           准确性

• 4.8.4.1.            数据是否描述了它所试图代表的真实环境？

• 4.8.5.           一致性

• 4.8.5.1.            数据是否与广泛理解和接受的定义相一致？

• 4.8.6.           唯一性

• 4.8.6.1.            单个数据点是否被多次记录？