读数据质量管理：数据可靠性与数据质量问题解决之道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. 数据转换工具

>  4.4.4.2.1. Snowflake

>  4.4.4.2.2. Redshift

>  4.4.4.2.3. Databricks

>  4.4.4.2.4. Apache Sparks

>  4.4.4.2.5. dbt

>  4.4.4.2.6. Apache Airflow

>  4.4.4.2.7. Perfect
  • 4.4.4.3. 商业智能工具
>  4.4.4.3.1. Looker

>  4.4.4.3.2. Tableau

>  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. 通过保证开放的沟通并对数据健康问题保持透明，团队赢得了足够的信任，得以建立一个自助式的数据平台，全天候地为决策赋能

posted @ 2024-11-24 08:27  躺柒  阅读(11)  评论(0)  编辑  收藏  举报