读数据质量管理：数据可靠性与数据质量题目办理之道13数据相沿 ...

1. 数据相沿

1.1. MyDoom的病毒
1.2. 现在，许多团队以致整个公司都在使用数据，这要求数据管理的方式要更便于合作，同时也更不容许发生错误
1.3. 从采用dbt和Apache Airflow等开源工具来实现数据转换和编排，到使用Snowflake和Databricks等云端数据堆栈和数据湖
1.4. 数据仪表板和报告独立存在、只生成一次、很少被使用、从来不更新的日子已经一去不复返了

• 1.4.1. 如今，数据要被全公司的终端用户使用，所以必须把数据做成合格的产品，而且要进行公道的维护和管理，才能大规模地发挥其作用
  

1.5. 当你努力获得更可靠的数据时，假如你不知道起点在那里，就很难找到目标地

• 1.5.1. 数据相沿就是能提供这些信息的数据“地图”​，无论数据管道的哪个阶段受到了数据宕机的影响，它都会告诉你
  
• 1.5.2. 当自动化和端到端的覆盖得以实现时​，相沿会更增强盛
  

1.6. 与检测和警报相结合，数据相沿就构成了真正的数据可靠性的基础，而且是现代数据栈中越来越重要的组成部分
1.7. 可访问性让你能够为用户提供一定程度的“可控自由”​，将数据质量从散布在几个可见性数据表中的孤立实体转变为可以在广泛平台上被真正实现的东西
2. 站点可靠性工程

2.1. 站点可靠性工程的目标是从保障可靠性出发，对软件体系的维护和运营进行优化
2.2. SRE的主旨在于，用自动化手段办理边际环境和“未知的未知”​（好比有bug的代码、服务器故障、病毒等）带来的困扰
2.3. 终极目标是创建一套方法，让工程师可以用自动化手段代替人工，维护企业快速增长的代码库，而且包管在体系发生题目时提供全方位的保障
2.4. SRE实在是一套思考和接近生产的方式

• 2.4.1. 大多数开发体系的工程师也可以作为该体系的SRE
  

3. 端到端字段级别的相沿

3.1. 数据工程师对模式变更、空值、分布错误等题目并不生疏，这些题目即便在最健康的数据体系中也会存在

• 3.1.1. 尽管数据测试是预防这些题目的首要步骤，但数据相沿正在成为数据管道根因分析和影响分析流程中的重要组成部分
  
• 3.1.2. 数据相沿也可以帮助数据工程和分析团队看到在数据生命周期每个阶段中数据的健康状况
  
• 3.1.3. 作为保障数据可靠性措施的一部分，数据相沿是帮助理解故障数据的输入和输出的重要工具
  

3.2. 数据相沿指的是数据集在其整个生命周期各个阶段的地图，从导入数据堆栈或数据湖，一直到最终分析层的可视化

• 3.2.1. 数据相沿就是数据从A点到B点的路线记录
  
• 3.2.2. 对于数据管道来说，数据相沿追踪上游数据源体系（即数据堆栈和数据湖）和下游依赖关系（好比分析报告和数据仪表板）之间的关系，提供了数据演变的整体视图
  
• 3.2.3. 即便是最基本的SQL查询也是非常复杂的，所以从零开始构建数据相沿并不轻易
  
• 3.2.4. 相沿图是手动创建的，而这必要对全公司的数据环境以及全部组件之间的联系有着全面了解
  

3.3. 解析数据

• 3.3.1. ANTLR是一种开源的查询解析器的生成器，可以读取、处理、执行和转换布局化文本或二进制文件
  
• 3.3.1.1. 使用该查询解析器提取定义语法的列，你可以获取更基本的SELECT子句用例的字段级关系
  
• 3.3.2. 你必要从种种复杂的关系和可能的交互所组成的蜘蛛网中抽象出来，以便实现为用户提供真正强盛的产品体验这一愿景
  

3.4. 构建用户界面

• 3.4.1. 重点显示哪些连接可能与特定的用例或题目相干
  
• 3.4.2. 数据团队一般最关心最下游层（在Looker或Tableau等工具中的商业智能对象）或最上游层（存储在数据堆栈或数据湖中的来源表或字段，它们通常是数据事件的根因）​
  
• 3.4.2.1. 最下游层的商业智能报告和仪表板是数据使用者用于一样平常工作的最终产品
  
• 3.4.2.2. 最重要的上游层（也就是数据堆栈或数据湖中的来源表）是用户必要利用的对象，它可以帮助用户逐层追踪相沿，并找到表格或字段存在数据质量题目的那个上游层
  
• 3.4.2.3. 一旦用户找到题目所在，就可以在该表格或字段中进行修复，从而办理题目
  
• 3.4.3. 可视化框架
  
• 3.4.3.1. Apache Preset
  
• 3.4.3.2. React Virtuoso
  

3.5. 字段关系

• 3.5.1. SELECT语句相沿
  
• 3.5.1.1. 由SQL的SELECT语句定义的字段关系
  
• 3.5.1.2. 字段之间的关系，上游字段的一个更改会直接影响到下游字段
  
• 3.5.2. 非SELECT语句相沿
  
• 3.5.2.1. 由全部其他的SQL语句定义的字段关系
  
• 3.5.2.2. 字段和表之间关系，下游字段通常是由上游字段经筛选或排序逻辑生成的
  

3.6. 听取团队成员的意见并参考每个人的发起
3.7. 致力于原型开发

• 3.7.1. 客户就是我们的指路明灯
  

3.8. 发布并迭代

• 3.8.1. 时间是至关重要的，当我们优先思量一个项目时，必须确保参与该项目标全部人的时间效率都是最高的
  
• 3.8.2. 建功能特性、向客户展示、请求反馈，然后根据必要进行优化或修改
  
• 3.8.3. 越来越多的数据团队将开始采用自动化相沿和其他知识图谱来识别数据质量题目的来源
  

4. 数据相沿的基本要求

4.1. 各行业的数据团队一直使用数据表级别的相沿来生成上下游之间的依赖关系，从而优化数据可靠性工作流
4.2. 数据表级别的相沿在宏观层面上非常有用，但它不能提供足够的细节来帮助数据团队了解数据管道究竟为什么以及是怎样发生故障的
4.3. 第一步都应该是理解用户的需求，并据此研究出在公道的时间内能够做出怎样的成果
4.4. 重要功能

• 4.4.1. 快速产生代价
  
• 4.4.1.1. 快速了解代码、运行和数据的变动对下游数据字段和报表的影响
  
• 4.4.1.2. 提炼出数据对象间在字段级别的关系，数据表级别对于快速办理题目来说太过粗糙了
  
• 4.4.2. 安全的架构
  
• 4.4.2.1. 不希望相沿直接调取用户数据或个人可识别信息
  
• 4.4.2.2. 采用调取元数据、记录文档、查询记录等信息的方式，而把用户数据留在客户的环境中
  
• 4.4.3. 自动化
  
• 4.4.3.1. 采用自动化的工具，根据数据生命周期的更改来更新数据资产
  
• 4.4.4. 与流行的数据工具集成
  
• 4.4.4.1. 一个可以生成整个数据管道中全部节点的知识图谱，从数据堆栈或数据湖的摄取开始，一直到商业智能或分析层
  
• 4.4.4.2. 数据转换工具
  

1. >  4.4.4.2.1. Snowflake
3. >  4.4.4.2.2. Redshift
5. >  4.4.4.2.3. Databricks
7. >  4.4.4.2.4. Apache Sparks
9. >  4.4.4.2.5. dbt
11. >  4.4.4.2.6. Apache Airflow
13. >  4.4.4.2.7. Perfect

复制代码

• 4.4.4.3. 商业智能工具
  

1. >  4.4.4.3.1. Looker
3. >  4.4.4.3.2. Tableau
5. >  4.4.4.3.3. Mode

复制代码

• 4.4.4.4. 要思量数据体系中全部数据表之间可能出现的连接和关系
  
• 4.4.5. 提取列级别的信息
  
• 4.4.5.1. 许多表级别的相沿办理方案主要基于解析查询日志，但这无法提取解析后的列信息，此中的元数据是帮助用户理解数据异常和其他题目所必需的内容
  
• 4.4.5.2. 在最基本的环境下，字段级别的数据相沿可以大大减少检测和办理数据质量题目所需的时间，其目标是减少数据团队对其数据管道进行溯源所需的总时间
  
• 4.4.6. 审查营收报告中的可疑数字
  
• 4.4.7. 减少数据债务
  
• 4.4.8. 管理个人可识别信息
  

4.5. 数据相沿的设计

• 4.5.1. 三个元素
  
• 4.5.1.1. 目标表格，存储在下游报告中
  
• 4.5.1.2. 目标字段，存储在目标表格中
  
• 4.5.1.3. 来源表格，存储在数据堆栈中
  
• 4.5.2. 非选定字段对从来源表中提取的行产生影响，但它们不会对结果表中的字段值产生影响
  

5. 案例分析

5.1. 并非每个组织都知道如何实现这些数据的全部代价

• 5.1.1. 数据经常被困在信息孤岛中，关于数据的服务请求堆积在工单队列中，而这些请求永远无法到达超负荷地为整个组织提供服务的数据工程师和分析师那里
  

5.2. 随着分布式架构逐渐成为数据驱动型组织的全新黄金标准，自助式的举措方式对于许多数据向导者来说将会让他们梦想成真
5.3. “可控自由”原则

• 5.3.1. controlled freedom
  
• 5.3.2. 集中式数据团队仅仅控制少数的关键方面：如何摄取数据，如何保障数据安全，如何以最佳格式优化数据，然后将其发布到标准的高管报告中
  
• 5.3.3. 团队能够包管数据来源值得信赖，数据本身是安全的，且公司在高层报告中使用一致的指标和定义时，数据使用者就有信心在这个框架内能够自由访问并利用数据
  

5.4. 去中心化数据团队

• 5.4.1. 5个团队负责数据管理：数据标记与收集、数据工程、数据分析、数据科学和数据架构
  
• 5.4.2. 分析师和工程师之间有明确的界限
  
• 5.4.2.1. 分析师靠近业务部门，了解痛点，并努力探求和验证新的数据来源
  
• 5.4.3. STM（Source to Target Mapping，从来源到目标的映射）
  
• 5.4.3.1. 本质在于允许工程师根据定义明确的执行手册来进行操作，从而构建支持业务数据需求所需的数据管道和架构
  
• 5.4.4. 通过给工程师提供要办理的题目而不是让他们整合分析策略，团队中的实践者可以保持专注，并致力于那些为业务目标提供支持的项目
  
• 5.4.5. 去中心化方法并不适用于每一个组织
  
• 5.4.5.1. 团队布局的需求将根据公司为数据设置的SLA而有所差别
  

5.5. 避免追逐闪亮的新科技，而应该选择办理题目的技能

• 5.5.1. 数据向导者不应盲目追求技能的新潮
  
• 5.5.2. 实现自助式分析
  
• 5.5.2.1. 包括批量的、微批量的、流式的、布局化的和非布局化的
  
• 5.5.2.2. 排序、切片和切块
  

5.6. 创建数据信任

• 5.6.1. 要让这种自助式分析的模式发挥作用，组织必要信赖数据的准确性、可靠性和可信度
  
• 5.6.2. 当你放弃透明度或开始隐藏东西时，人们就会失去信任，而重新获得信任会非常困难
  
• 5.6.3. 通过包管开放的沟通并对数据健康题目保持透明，团队赢得了足够的信任，得以创建一个自助式的数据平台，全天候地为决策赋能
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。