1.1. 确保ETL期间的数据质量

1.1.1. ETL即“提取-转换-加载”

1.1.2. 步骤

1.1.2.1. 在提取步骤中，原始数据从一些上游数据源中导出，并将其移动到暂存区

1.1.2.1.1. MySQL

1.1.2.1.2. NoSQL服务器

1.1.2.1.3. CRM系统

1.1.2.1.4. 数据湖中的原始文件

1.1.2.2. 暂存区中的数据按照数据工程师的要求规范进行组合和处理

1.1.2.3. 在加载步骤中，我们将转换后的数据移出暂存区并移至其目的地，该目的地通常是数据仓库中的一个特定表

1.2. 确保转换期间的数据质量

1.2.1. ETL是指先将数据加载到暂存服务器，然后再加载到目标系统的过程

1.2.1.1. ETL为数据工程师提供了在数据投入生产前对其进行验证的机会

1.2.2. ELT要求将数据直接加载到目标系统中

1.2.2.1. ELT则加快了处理速度，但如果没有恰当地进行测试和监控，就会降低数据质量

1.2.3. 转换源数据的原因

1.2.3.1. 只是对字段进行重命名，以匹配目标位置的模式需求

1.2.3.2. 通过筛选、聚合、汇总、去重等方式对源数据进行清洗和整合

1.2.3.3. 同时进行类型转换和单位转换

1.2.3.4. 为了满足行业规定或法规，你可以在此步骤对敏感数据字段进行加密

1.2.3.5. 进行数据治理审计或数据质量检查

2.1. dbt（数据构建工具）、WhereScape或Informatica等ETL系统也容易出现故障

2.1.1. 需要一个强大的测试和警报系统以便在大批量数据生产环境中运行这些程序

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

2.2.1. 空值

2.2.1.1. 是否有任何值是未知的（为空值）？

2.2.2. 容量

2.2.2.1. 有没有收到任何的数据？

2.2.2.2. 收到的数据是太多了还是太少了？

2.2.3. 分布

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

2.2.3.2. 值是否在给定列的范围内？

2.2.4. 独特性

2.2.4.1. 独特性

2.2.5. 已知的不变量

2.2.5.1. 两个对象是否从根本上不同

2.3. 数据测试的两个最佳工具分别是dbt测试和Great Expectation

2.3.1. Great Expectations更为通用

2.3.2. dbt本身并不是一个测试解决方案

2.3.2.1. 如果你已经在使用该框架对数据进行建模和转换了，那么其开箱即用的测试效果非常好

2.4. 要运行数据质量测试

2.4.1. 将转换后的数据加载到临时的暂存表/数据集中

2.4.2. 运行测试以确保暂存表中的数据落在生产所需的阈值范围内

2.5. 如果数据质量测试失败了，则会向负责该数据资产的数据工程师或分析师发送警报，而数据管道也不会运行

2.5.1. 数据工程师能够在影响最终用户或系统之前发现意料之外的数据质量问题

2.5.2. 数据测试可以在转换过程的任何步骤之前或之后进行

2.5.3. 测试是数据质量工作流中的一个重要组成部分，但它并不是团队在解决数据质量问题时应该采取的唯一主动措施

2.6. dbt单元测试

2.6.1. 现代ELT最受欢迎的选择之一

2.6.2. 工具扩展了向被转换的表添加单元测试的能力

2.6.3. dbt模型是独立的SQL语句，它们接收输入数据，对其进行转换，并将转换的一些结果加载到目标表中

2.6.4. 单项测试

2.6.4.1. 可以在不同模型上重复使用的“模板化”测试

2.6.4.2. 采用参数化的SQL查询形式，因此可以接收参数

2.6.4.3. unique测试的是在特定列中的值是不是唯一的

2.6.4.4. not_null测试的是特定列中的值是否为空值

2.6.4.5. accepted_values确保一列中的所有值都是有限集中的一个

2.6.4.6. relationships检查了表之间的“引用完整性”

2.6.4.6.1. 确保如id在内的关键字段是一一对应的

2.6.5. dbt测试通常是很好的测试标准

2.6.6. dbt测试是由你组织中的开发人员以代码形式手动维护的

2.6.6.1. 复杂的测试可以确保获得高质量的数据

2.6.6.2. 会浪费工程资源的时间消耗，所花费的时间也接近于开发模型本身所需的时间

2.6.7. 测试失败必须有意义才能有效

2.6.8. 测试失败仍然是表明出现错误的良好信号，尽管它并不能提供快速修复

2.6.8.1. 需要深入研究栈来消除错误，因为你的ELT测试方案不是正确的端到端测试

2.7. Great Expectations单元测试

2.7.1. 一个开源工具，它以单元测试的形式提供了另一种从数据中“断言你所期望”的方法

2.7.2. 比dbt测试更具可扩展性

2.7.2.1. 用Python编写的，它可以被用于各种ETL/ELT解决方案

2.7.3. 允许单元测试在一系列不同的数据量上运行，从单个小批量数据到完整的数据转换

2.7.4. 作为Python包发布，扩展了有用的命令行界面，并使用Jupyter等工具进行数据验证

2.7.5. Slack集成

2.7.5.1. 设置高度可配置的Slack警报

2.7.6. 仅限于Python

2.7.6.1. 是一个Python工具

2.7.7. 一个完全独立的工具，具有不同的学习曲线

2.8. Deequ单元测试

2.8.1. 一个由AWS构建的开源库，用于运行数据单元测试

2.8.2. 构建在Apache Spark上，因此在格式方面具有很大的灵活性

2.8.3. Deequ的工作方式是断言测试条件并返回失败的数据行或批数据

2.8.4. Deequ测试套件的入口点是VerificationSuite类

2.8.5. 优点

2.8.5.1. 与AWS集成

2.8.5.1.1. 很容易与AWS Glue进行集成，并且在技术博客中进行了详细的在线记录

2.8.5.2. 高可扩展性

2.8.5.2.1. 可以利用Scala作业编排和并行的优势，使其更加高效

2.8.5.2.2. 数据存储在Scala的数据框架中，这是针对大数据生态系统及其挑战而专门构建的

2.8.5.3. 有状态计算

2.8.5.3.1. 可以计算指标的元数据，将所述元数据存储在适当的位置，然后在接收更多数据时重新计算关键指标

2.8.5.4. 内置的异常检测

2.8.5.4.1. 允许对运行指标的平均值和偏差进行检测

2.8.6. 缺点

2.8.6.1. 对于数据工程领域以外的人来说，Scala并不是一种友好的语言

2.8.6.2. 对集成测试的适用性有限

2.8.6.2.1. 与dbt测试按模型运行并自然地跨ELT管道集成了测试断言所不同，Deequ可以灵活地运行在你所提供的任何一批数据上

2.8.6.3. 缺乏直观的用户界面

2.8.6.3.1. 软件非常简单且功能十分强大

2.9. Deequ单元测试

2.9.1. 一个由AWS构建的开源库，用于运行数据单元测试

2.9.2. 构建在Apache Spark上，因此在格式方面具有很大的灵活性

2.9.3. Deequ的工作方式是断言测试条件并返回失败的数据行或批数据

2.9.4. Deequ测试套件的入口点是VerificationSuite类

2.9.5. 优点

2.9.5.1. 与AWS集成

2.9.5.1.1. 很容易与AWS Glue进行集成，并且在技术博客中进行了详细的在线记录

2.9.5.2. 高可扩展性

2.9.5.2.1. 可以利用Scala作业编排和并行的优势，使其更加高效

2.9.5.2.2. 数据存储在Scala的数据框架中，这是针对大数据生态系统及其挑战而专门构建的

2.9.5.3. 有状态计算

2.9.5.3.1. 可以计算指标的元数据，将所述元数据存储在适当的位置，然后在接收更多数据时重新计算关键指标

2.9.5.4. 内置的异常检测

2.9.5.4.1. 允许对运行指标的平均值和偏差进行检测

2.9.6. 缺点

2.9.6.1. 对于数据工程领域以外的人来说，Scala并不是一种友好的语言

2.9.6.2. 对集成测试的适用性有限

2.9.6.2.1. 与dbt测试按模型运行并自然地跨ELT管道集成了测试断言所不同，Deequ可以灵活地运行在你所提供的任何一批数据上

2.9.6.3. 缺乏直观的用户界面

2.9.6.3.1. 软件非常简单且功能十分强大

3.1. Apache Airflow、Luigi、Matillion和Stitch等工具让团队能够更好地管理编排层的数据质量，该层以编程方式编写、调度和监控数据管道中的工作流

3.2. “检查点”

3.2.1. 通常被称为有向无环图(Directed Acylic Graph，DAG)

3.3. Apache Airflow（和其他编排工具）有向无环图最常见的数据宕机类型是质量变低的查询和错误的Python代码

3.4. 满是错误的代码可能是人为错误（例如令人讨厌的缩进错误）引起的，而当Apache Airflow作业运行所花费的时间比预期更长时，查询的质量会降低

3.5. 调度程序的SLA

3.5.1. 在编排层防止数据事故的另一种流行方法是将“断路器”方法用于数据管道的运行

3.5.2. 断路意味着当数据不符合一组质量阈值时，数据管道将停止运行

3.5.3. 断路器是CI/CD工作流程中的常见做法，也是一种防止系统因新软件部署而发生中断的手段，许多相同的概念都可以应用于数据管道

3.5.4. 团队可以在测试和CI/CD流程中的其他步骤（如版本控制）之上集成断路器

3.5.5. 可以在指标更新完成后实施一个有用的断路器，在允许任何下游作业执行前先运行完整性测试

3.5.6. 如果发现输送到管道中的上游数据不准确，则暂停管道中间的数据工作流

3.5.7. 断路器可以防止数据产品将高质量和低质量的数据混合，从而确保可用数据的可靠性

3.5.7.1. 线路闭合：数据正在流经管道

3.5.7.2. 线路开启：数据没有流经管道

3.5.8. 核心解决方案

3.5.8.1. 数据沿袭

3.5.8.2. 跨管道的数据分析

3.5.8.3. 能够通过分析发现的问题来自动触发线路

3.5.9. 断路器被用于防止竖井式数据管道的新鲜度、容量和分布问题，但类似的原理也可以应用于大规模自动化

3.6. 为Apache Airflow DAG安装断路器是防止数据质量问题的一种更为积极主动的方法，如果数据不满足新鲜度、容量和模式阈值的要求，则可以在编排层停止数据管道

3.7. 断路是一种有价值且节省成本的工具，但它通常仅用于最关键的数据宕机事件

3.7.1. 断路不仅可以防止不良数据破坏原本完美的管道，而且还可以确保在运行具有（难以发现的）数据质量问题的DAG时不会产生回填成本

3.8. SQL检查运算符

3.8.1. 可验证给定DAG的内容是否与多个关键元素（包括值、间隔和阈值）的预期相一致

3.8.2. 将允许你运行自定义的SQL检查运算符，这些运算符从给定的SQL查询中返回单行，以检查该行中的任何返回值是否为False

3.9. 如果没有战略化地审慎实施，断路器和SQL检查运算符可能会阻止整个数据管道运行那些与问题无关且高质量的作业，从而阻止分析型数据流向下游系统

4.1. 解决数据宕机不只是在下游仪表板中出现空值时对相关方做出回应，或者当你在收到CEO发来关于“丢失数据”的疯狂电子邮件时重新访问你的Snowflake查询

4.2. 数据宕机应该能够通过在数据管道的各个阶段集成数据质量检查来进行主动预防

4.2.1. 从最初的数据仓库或数据湖中接收数据，到最终在商业智能层中的实际应用

4.3. 虽然数据质量问题不能单靠技术来解决，但收集、清洗、接收、处理和编排数据时考虑数据可靠性一定会对数据质量的提高有所帮助

4.4. 即使有最严格的SQL检查，那些“未知的未知”也可能会被遗漏

4.5. 数据永远不会完全可靠，而我们最好可以尽早接受这一事实