在微服务架构中使用断路器模式，在出现数据质量问题时，断路器会打开，防止低质量数据传播到下游进程。结果是报告中的低质量数据将在某个时间段内丢失，但如果存在，则保证肯定是正确的。本文描述了实施和部署断路器的细节，并分为三个部分：
- 数据管道基础现实
- 数据管道的断路器模式
- 在生产中实施断路器
数据管道基础现实
数据管道是一种逻辑抽象，表示将原始数据转换为观察分析所需的一系列数据转换。在我们的数据平台中，我们每天都有数千条数据管道运行。每个管道都从不同来源提取数据，并应用一系列ETL和分析查询，以报告，仪表板，ML模型，输出表的形式生成见解。这些见解既用于数据驱动的业务操作，也用于 - 产品客户体验。
我们在100多个关系数据库以及NoSQL存储中收集了4种类型的数据：
- 用户输入数据（UED）：客户在使用产品时输入的数据
- 行为分析数据：捕获产品使用情况的点击流数据
- 企业数据：用于客户服务，计费等的后台系统
- 第三方数据：包括社交Feed，贷方文件，银行数据等
使用Kafka，Sqoop，Oracle GoldenGate和十几种原生工具，使用批量摄取框架将来自数据源的数据提取到数据湖Lake（HDFS / S3）中；然后使用多个查询引擎（Hive，Spark）分析Lake中的数据，并将其移至MPI仓库（如Vertica）；结果通过服务数据库如Cassandra，Druid获得。
在数据管道中，数据质量问题在不同阶段引入。我们将问题分为三个部分：a）与源有关的问题; b）与摄取有关的问题; c）参照完整性。对于每个存储桶，我们遇到很多最常见问题，这些问题的根本原因是操作错误，逻辑错误，缺乏变更管理，数据模型不一致。
数据管道的断路器模式
电路断路器以主动管理电涌，否则电涌会过载并引起房屋着火。通过权衡电力供应，断路器可以防止潜在的火灾。断路器模式在微服务架构中也很流行 - 而不是让API等待缓慢或饱和的微服务，断路器主动跳过调用服务。最终结果是可预测的API响应时间，以及某些服务可能无法获得的权衡。解决微服务问题后，断路器关闭，服务可用。
数据管道的断路器遵循类似的模式。主动分析数据的质量 - 如果它低于阈值，而不是让管道工作继续并混合高质量数据和低质量数据，这时打开断路器，阻止低质量数据到达下游处理。因此，如果数据质量低，则会丢失，对于数据工程师，分析师，数据科学家和其他有见解的消费者而言，这是一个易于理解的约定。
它取代了根据具体情况手动验证结果的需要，在湖中摄取的数据在每小时或每日批次持续存放在一个集结区；分析每批次的数据质量 - 当检测到问题时，断路器打开，防止此批次数据到达下游处理，断路打开时，会提醒团队诊断问题，如果可以解决问题，则回填该批次并使其可用于下游处理。
在数据流水线断路器模式中，有两种状态：
- 断路器关闭：数据正在流经管道。
- 断路器开放：数据不流动，即发现问题，因此下游数据不可用
在打开和关闭状态下，不断检查数据分区的质量（每小时/每天）。当数据批次满足质量阈值时，断路器从打开状态转为关闭状态。相反，当数据质量失效时，断路器从闭合变为开放。数据质量问题分为硬警报和软警报。与硬警报相比，软警报不会改变电路的状态，但会显示警告以及见解。
在数据平台中实现断路器
实施断路器需要实现3个核心功能：
- 跟踪数据沿袭：查找从源表到输出表，报告，ML模型的转换中涉及的所有表和作业。
- 配置文件数据管道：跟踪与数据管道关联的事件，统计信息和异常。分析分为操作和数据级别，如稍后所述。
- 控制断路器：根据分析发现的问题触发断路器
跟踪数据沿袭是通过分析与管道作业相关联的查询来完成的。具体而言，管道由作业组成; 每个作业都由一个或多个脚本组成; 每个脚本由一个或多个SQL语句组成。分析输入和输出表的SQL查询。管道的沿袭被定义为三元组<作业名称，输入表格，输出表格>的数组。这不是一次性活动。它在不断发展。每个脚本由一个或多个不同语言的查询组成：SQL与一些Pig。然后将它们粘在一起，一个输出成为下一个工作的输入。
分析分为两个桶：
- 操作性能分析：重点是工作健康和数据结构健康。作业健康涉及跟踪执行相关的统计数据，如完成时间，开始时间等.Data Fabric健康专注于跟踪系统组件的事件和统计数据，即源数据库，摄取工具，调度框架，分析引擎，服务数据库，发布框架（如如Tableau，QlikView，SageMaker等）
- 数据分析：本文的重点是分析数据相关模式。
控制断路器基于使用分析发现的问题。使用绝对阈值/规则或基于异常检测/ ML模型的相对发现问题。
数据流水线断路器是一种使数据可用性与数据质量成比例的模式。通过定义硬和软警报如何控制断路器，它允许更改为数百个下游表提供数据的关键表的比例斜率。