读数据质量管理：数据可靠性与数据质量问题解决之道11根因分析

1. 解决大规模数据质量问题

1.1. 为关键的数据管道制定一个变乱管理计划
1.2. 使用异常检测作为大规模变乱检测方案的一部分
1.3. 在变乱发生时，举行全面的根因分析与影响分析
1.4. 通过测试、持续集成/持续部署、数据可观测性与更多的数据来积极自动地应对数据质量问题
1.5. 暂停数据管道、找到问题根源都只是恢复数据可靠性并继续信任数据的冰山一角
2. 在软件研发过程中解决数据质量问题

2.1. 无论是单独的数据管道体系，还是大型的数据体系，此类“数据宕机”问题的解决方案都已经存在
2.2. DevOps生命周期

• 2.2.1. 计划
  
• 2.2.1.1. 研发团队与产品和贸易团队协作，从而了解软件的目的与SLA
  
• 2.2.2. 编码
  
• 2.2.2.1. 编写软件的代码
  
• 2.2.3. 构建
  
• 2.2.3.1. 将软件发布到一个测试环境中
  
• 2.2.4. 测试
  
• 2.2.4.1. 对软件举行测试
  
• 2.2.5. 发布
  
• 2.2.5.1. 将软件发布为产品
  
• 2.2.6. 部署
  
• 2.2.6.1. 将软件与现有应用程序共同集成和部署
  
• 2.2.7. 运维
  
• 2.2.7.1. 运行该软件，并根据需要举行调整
  
• 2.2.8. 监控
  
• 2.2.8.1. 监控软件的运行状态，并对问题发出警报
  
• 2.2.9. 不断循环往复的
  

2.3. DevOps生命周期的循环反馈流程

• 2.3.1. 资助团队可靠地实现大规模交付与业务目的相一致的功能
  
• 2.3.2. 我们往往倾向于被动地处理数据质量问题，因此在数据分析方面还没有以故意义且可扩展的方式来推动应用这套反馈流程
  

2.4. 有效的变乱管理是在软件故障发生时减少杂乱、尽快恢复正常业务运行的关键

• 2.4.1. 如果你没有提前计划好应对潜在变乱的措施，那么在面对复杂的真实问题时，套路化的变乱解决方案可能根本不管用
  

2.5. 变乱管理就是要对可能出现在日常工程流程中的问题举行鉴别、溯源、解决、分析和防备
3. 数据变乱管理

3.1. 当数据体系越来越多地采用分布式架构，且企业摄取的数据规模越来越庞大时，出现错误（和变乱）的概率也一定增加
3.2. 数据可靠性生命周期

• 3.2.1. 通过将数据可靠性生命周期应用于数据管道，数据工程师团队可以把检测、解决甚至提前防备数据质量问题的步骤更加无缝地衔接起来，从而确保数据质量问题不会影响到业务运营
  

3.3. 关键步骤

• 3.3.1. 变乱检测
  
• 3.3.2. 响应
  
• 3.3.3. 根因分析
  
• 3.3.4. 解决
  
• 3.3.5. （不做指责的）复盘
  

4. 变乱检测

4.1. 将变乱检测和数据工程与分析的工作流程联合起来，从而确保当故障发生时，数据的拥有者与终端用户都能通过合适的沟通渠道得到关照
4.2. 在数据进入生产环境之前就举行测试
4.3. 当数据管道被损坏或者数据仪表板瓦解时，你起首要做的就是举行变乱检测
4.4. 变乱可以通过数据监控与警报被检测到，这一过程可以手动实现，也可以通过设定阈值来自动实现
4.5. 变乱检测也可以作为异常检测或者数据可观测性解决方案的一部分，并根据汗青数据模式和定制化规则定期自动触发
4.6. 变乱检测的一个重要部分就是异常检测

• 4.6.1. 高质量的异常检测体系应当能够借助算法的微调来提高信噪比并低落假阳性率，并且在精确率和召回率之间达到平衡
  

4.7. 数据团队总是倾向于以为仅凭异常检测就足以“解决”变乱管理方面的问题

• 4.7.1. 变乱管理问题从来不会被真正“解决”
  
• 4.7.2. 仅仅依靠异常检测是一个单点故障
  
• 4.7.3. 变乱检测应当是一个多层面的过程，不仅包含检测变乱，还包括对变乱的响应、解决和防备，并且要不断迭代和重复这些步骤
  

4.8. 异常检测是一种工具，而不是灵丹灵药

• 4.8.1. 一个盼望实现自动化运营的数据团队，假如仅依赖异常检测，而不借助测试、版本管理、可观测性、相沿等其他的技能工具，那么等待着团队的最好环境就是层出不穷的问题，而最差环境则是挫败感和漫长的数据宕机恢复时间
  
• 4.8.2. 不要仅仅依靠异常检测本身来解决数据质量问题，因为“检测到”有一个故障，并不意味着故障就能被立刻“解决”​
  
• 4.8.3. 仅凭异常检测无法真正构建出可信任、可依靠、透明度高的数据体系，从而满足洞察力驱动型企业的需求
  

4.9. 当异常检测被端到端（例如跨数据堆栈、数据湖、ETL和贸易智能工具）实现，而并非仅仅在数据平台的其中一两层实现时，它对业务来说是极具价值的
5. 响应

5.1. 良好的变乱响应机制的核心在于有效沟通，好在响应机制的大部分工作可以通过PagerDuty或者Slack等交流工具提前预备并自动完成
5.2. 据团队应当提前为标准的数据变乱响应流程编写执行脚本(runbook)和自动化运营手册(playbook)

• 5.2.1. 执行脚本为你提供了关于如何使用不同服务及其遇到的常见问题的说明
  
• 5.2.1.1. 要把故障发生时的角色提前分配好
  
• 5.2.2. 自动化运营手册则会提供处理变乱的分步流程
  

5.3. 除了“变乱响应人”外，通常还会有一名“变乱指挥官”来负责分配工作、整合信息，而变乱响应人和其他利益相关方则会一起解决问题
5.4. 在具体的业务环境中，元数据可以作为一种强大的工具来有效判断哪些团队会受到某一数据宕机变乱的影响
6. 根因分析

6.1. 根因分析(Root Cause Aanlysis，RCA)
6.2. 数据变乱可能悄无声息地出现在整个数据管道中，并影响数十甚至上百张数据表
6.3. 低数据质量的一个常见原因是新鲜度问题

• 6.3.1. 数据的版本异常老旧
  
• 6.3.2. 背后的原因多种多样
  
• 6.3.2.1. 某个程序的作业卡在了计算队列里
  
• 6.3.2.2. 计算体系超时
  
• 6.3.2.3. 某个互助同伴没有及时上传数据
  
• 6.3.2.4. 软件错误
  
• 6.3.2.5. 意外的日程安排变更导致你的程序作业从有向无环图(D A G)里被移除
  

6.4. 大多数数据问题的根源

• 6.4.1. 进入程序作业、数据管道或体系的数据发生某种意外的变更
  
• 6.4.2. 转换数据的逻辑（ETL、SQL、Spark作业等）发生了变更
  
• 6.4.3. 某种事件型故障
  
• 6.4.3.1. 计算超时错误
  
• 6.4.3.2. 授权问题
  
• 6.4.3.3. 数据底子设施故障
  
• 6.4.3.4. 日程变更
  
• 6.4.4. 快速诊断故障原因需要的不仅仅是合适的工具，更需要对这三类问题为什么以及是如何发生的有全局认知
  

6.5. 变乱的发生往往不是由于单一因素，反而常常是多种因素的共同作用

• 6.5.1. 要把这些多因素综合的故障看成可贵的学习机会，用于流程优化和技能微调
  
• 6.5.2. 在软件（和数据）体系变得越来越复杂的今天，精确诊断某次故障或变乱的单一确切原因或根源正变得越发艰
  
• 6.5.3. 体系瓦解的原因很少是唯一的
  

6.6. Amazon的五步法框架

• 6.6.1. 发现问题
  
• 6.6.2. 思考这个问题为什么会发生，并纪录其原因
  
• 6.6.3. 判别该原因是不是问题的根源
  
• 6.6.3.1. 该原因可否被防备？
  
• 6.6.3.2. 该原因可否在其发生前提前被检测出来？
  
• 6.6.3.3. 如果该原因是人为失误，那么为什么会发生如许的环境？
  
• 6.6.4. 继续重复这些步骤，把上面的“原因”迭代成“问题”
  
• 6.6.5. 当你确信已经找到问题的根源时，就可以停止了
  

6.7. 随着数据工程师努力减少手动作业量，他们研发出许多智能流程、测试方法、数据新鲜度检查方法以及其他解决方案用以诊断数据变乱，避免它们传播到下游
6.8. 对数据管道举行根因分析的五个步骤

• 6.8.1. 查看数据相沿
  
• 6.8.1.1. 追溯到体系中出现问题的最上游节点，而那里就是故障最开始发生的地方，你也要去那里寻找答案
  
• 6.8.1.2. 最上游节点的数据仪表板就可以提供全部的答案，帮你迅速诊断出问题的根源
  
• 6.8.1.3. 要确保参与数据变乱解决的全部人（数据工程师、数据分析师、分析工程师、数据科学家等）都能获取最新版本的数据相沿
  
• 6.8.1.4. 数据相沿应当包含贸易智能陈诉、呆板学习模型、反向ETL池等数据产品
  
• 6.8.1.5. 自动化字段级别的相沿常常是数据工程团队的高回报投资选项，因为它能资助我们简朴快速地了解哪些数据资源是损坏的，以及这些损坏的部分是如何影响下游的数据产品和数据仪表板的
  
• 6.8.2. 查看代码
  
• 6.8.3. 查看数据
  
• 6.8.3.1. 查看有异常字段的数据表中的其他字段大概能为你判断数据异常的根源提供线索，这种方法一样平常比较有用
  
• 6.8.3.2. 要确保全部参与解决数据故障的职员都能方便地对数据举行切割和分块，如许才能便捷地分析数据事故与不同的数据段、时间段以及其他数据分段的相关性
  
• 6.8.4. 查看运行环境
  
• 6.8.4.1. 许多数据事故的直接诱因是运行ETL/ELT数据转换工作的运行环境
  
• 6.8.4.2. dbt是处理这些程序运行问题的一个有效的开源工具
  
• 6.8.5. 借助你同伴的资助
  
• 6.8.5.1. 你的团队同伴可以提供有价值的知识或见解，帮你诊断数据中的问题
  
• 6.8.5.2. 要确保全部参与解决数据故障的职员都能获取关于数据全部权和使用环境的元数据，如许他们就能知道出了问题可以去向谁提问
  
• 6.8.5.3. 保留一份数据变乱的汗青纪录，并纪录相关的文档，这也很有资助
  
• 6.8.6. 可以把根因分析从令人焦虑的深夜告急电话转变成在整个组织中规模化可持续的通用标准流程
  

6.9. 根因分析在（接近）实时地解决甚至防备数据质量问题上是一个强有力的工具，但是要记得，数据管道的瓦解常常不是某个单一问题导致的