通过广泛的数据质量、准确性和异常检查获得对数据的信任。
Airbnb 已经开始了一个大规模的项目，以确保整个公司的数据可信。为了使员工能够更快地利用数据做出决策并为业务指标监控提供更好的支持，我们引入了Midas，一个分析数据认证过程，用于认证所有重要的指标和数据集。
为该过程的一部分，我们制定了强大的数据质量检查和异常检测强制性要求，以防止数据错误在数据仓库中传播。
我们还制定了指导方针，作为数据模型认证过程的一部分，需要实施哪些特定的数据质量检查。在管道中添加数据质量检查已成为我们数据工程工作流程中的标准做法，并帮助我们在管道早期检测到许多关键的数据质量问题。
在这篇博文中，我们将概述我们在添加大量数据检查（即数据质量、准确性、完整性和异常检查）以防止全公司范围内的数据错误时所面临的挑战，以及这如何激励我们构建一个新框架以轻松地大规模添加数据检查。
挑战
在 Airbnb 的分析数据生态系统中，我们使用 Apache Airflow 来安排 ETL 作业或数据管道。Hive SQL、Spark SQL、Scala Spark、PySpark 和 Presto 被广泛用作不同的执行引擎。然而，由于团队开始在不同的执行引擎中构建类似的数据质量检查，我们遇到了其他固有问题：
- 我们没有任何集中的方式来查看跨团队的数据检查覆盖率。
- 数据检查指南的更改需要在整个公司的代码库中的多个位置进行更改。
- 面向未来的实施几乎不可能扩展。团队不断地重新发明轮子，并在代码库中传播重复的代码。
不同的团队经常需要构建工具来满足自己对不同数据检查的需求。每个数据工程 (DE) 团队都开始在孤岛中构建数据检查工具。尽管这些团队中的每一个都在构建可靠的工具来满足他们各自的业务需求，但由于以下几个原因，这种方法存在问题：
- 我们开始并行构建多个框架。
- 数据检查框架的维护成本很高，并引入了运营开销。
- 缺少功能和缺乏灵活性/可扩展性使得这些框架难以在整个公司中重复使用。
每个检查都作为 ETL 管道的一部分在 Airflow 中作为单独的任务添加。Airflow DAG 文件很快变得庞大。由于以下几个不同的因素，这些检查的操作开销增长到难以维护的程度：
- 不支持阻塞与非阻塞检查。轻微的检查失败或误报通常会阻碍关键数据管道的 SLA。
- ETL 逻辑和数据检查变得紧密耦合且不可重用。
- 维护在操作上变得具有挑战性，因为我们手动跟踪依赖项，这也使得添加更多检查变得困难。
引入Wall框架
为了解决这些工具差距，我们着手构建一个统一的数据检查框架，该框架将满足以下要求并确保更大的可用性加班：
- 可扩展：统一 Airbnb 使用的数据检查方法
- 配置驱动：将检查定义为 YAML 格式的文件以加快开发速度
- 易于使用：提供简化的界面以促进全公司更快的采用
Wall 是编写离线数据质量检查的铺垫路径。它是一个框架，旨在保护我们的分析决策免受不良数据错误的影响，并确保整个 Airbnb 的数据可信。
Wall Framework 是在 Apache Airflow 之上用 Python 编写的。用户可以通过编写一个简单的配置文件并在他们的 DAG 中调用帮助函数来向他们的 Airflow DAG 添加数据质量检查。
- Wall 在一个通用框架下提供了公司目前可用的大部分质量检查和异常检测机制，使数据检查更容易标准化。
- 它支持基于 SQL 的模板化自定义业务逻辑、准确性检查和可扩展的预定义检查库。
- Wall 是配置驱动的——不需要代码来添加检查。
- 检查可以在 ETL 管道中以Stage-Check-Exchange模式或作为独立检查使用。
- 该框架是可扩展的——任何团队都可以很容易地按照开源模型将他们团队特定的检查添加到 Wall（根据 Data Engineering Paved Path 团队的批准）。
- 业务用户可以轻松添加质量检查，而无需为每次检查创建任何气流 DAG 或任务。
- Wall 负责基于 SQL 的检查和异常检测任务的创建。它还负责阶段和交换任务的创建，并以解耦的方式设置对检查的适当依赖。因此，在迁移到 Wall 之后，ETL 管道得到了极大的简化，我们已经看到我们能够摆脱 70% 以上的 DAG 代码的情况。
更多点击标题