原文：
towardsdatascience.com/dont-fix-bad-data-do-this-instead-d45262444cf2
照片由No Revisions在Unsplash上拍摄
来自前线的报道
几年前，我们的数据平台团队旨在确定我们的数据用户的主要关注点。我们在与我们的数据平台互动的个人中进行了调查，不出所料，主要关注点是数据质量。
我们最初的反应，典型的工程思维，是开发数据质量工具。我们引入了一个名为 Contessa 的内部工具。尽管它有些笨重，需要大量的手动配置，但 Contessa 简化了对数据质量标准维度的检查，包括一致性、及时性、有效性、唯一性、准确性和完整性。运行这个工具几个月后，进行了数百次数据质量检查，我们得出以下结论：
-
数据质量检查偶尔帮助数据用户在更短的时间内发现数据已被破坏，无法依赖。
-
尽管频繁执行数据质量检查，但数据质量的主观感知没有明显改善。
-
对于许多问题，尤其是通过自动化数据质量检查（如一致性或有效性）识别的问题，从未采取过任何纠正措施。
调查和客观测量是有用的工具，但没有任何东西能取代咖啡和蛋糕边的讨论，正如简·卡鲁瑟斯在她的书中所写，“首席数据官手册”。确实，我推荐这本书给任何人，因为一对一的对话帮助我们发现了情况的重要角度。以下是一些对话的展开情况：
“嘿，你说数据质量差，你这是什么意思？”
1 定价业务分析师：“我们正在为辅助产品 X 设置价格。在我们使用的数据集中，我们没有关于每个订单产品 X 实际收入的实际数据。我们有一个数据集，但它只包含购买时 X 的预期收入值。我们还可以看到每个产品的实际收入，但不是按订单粒度。”
2 产品分析师：“在我们的客户旅程中，有几个接触点我们会将客户引导到我们的合作伙伴网站——如果他们对购买第三方产品 Y 感兴趣。我们定期从合作伙伴那里下载交易数据，并对其进行分析以优化这一服务。在 30%的情况下，我们缺少客户离开到合作伙伴网站的具体接触点信息。”
3 数据分析师：“我们准备了一个包含深链接列表的数据集——关于客户点击了哪些优惠的信息。然而，对于某些深链接组，优惠的日期格式并不是我们预期的格式。我们不得不过滤掉这些记录，并且我们不考虑它们。”
这些案例中有一个共同点：我们的数据质量工具无法解决这些问题；解决方案在其他地方。
在案例#1 中，解决方案涉及将实际的辅助收入数据模型扩展到所需的粒度。
对于案例#2，前端开发者审查了所有可能发生重定向的步骤，并在重定向 URL 中添加了一个查询参数。
在案例#3 中，问题出现是因为负责在存储数据之前获取验证过的出发日期的 API 调用在某些情况下超时了。工程团队在 API 调用上实施重试逻辑解决了这个问题。
主要问题要么是数据没有被记录，要么是没有按照我们的预期进行整合、连接或理解。
在他的 1861 年小说《远大前程》中，查尔斯·狄更斯讲述了皮普的故事，一个对爱情、财富和社会地位抱有巨大期望的孤儿，却遭遇了无数的幻灭。一个著名的数据质量框架被命名为“远大前程”，确实是一个合适的标题。
这个比喻恰当地描述了数据用户（包括数据科学家、分析师、数据工程师、产品经理、UX 研究人员和商业决策者）面临的挑战。我们对数据的期望很高，当现实不符合这些期望时，这往往会导致挫败感。
与上述类似案例中的根本问题是，尽管数据消费者期望某些结果，但并不能保证这些期望会得到满足。例如，并非每个记录都包含重定向参数，或者所有记录可能都没有填写日期。此外，能够解决这些问题的能力的人往往并不知道这些问题。
-
当数据消费者的期望与现实不符时，这会表现为数据质量问题。
-
数据消费者的期望往往是隐含的，并没有明确表达出来。
-
数据消费者可以应用数据清洗技术，但通常他们没有太多手段将低质量数据转化为高质量数据。
-
数据质量检查充当了一个安全网，有助于早期识别问题，但它们并不能防止问题最初发生。
快进
我们没有放弃，随着我们前进，我们意识到即使是看似简单的问题也需要复杂的解决方案。导致改进的是技术（硬性）和文化（软性）措施的组合。
这些措施的基本要求是建立数据所有权文化。这涉及到建立一个系统，其中每个生成数据的实体都与一个人类组织单位相关联，例如一个负责问责制的团队。这个单位应该能够明确承诺或拒绝与数据相关的期望。这种承诺在技术上表示为数据合同。
确保数据质量依赖于两个主要支柱，软性措施和硬性措施，它们同等重要。
硬性措施
数据质量检查
数据质量检查是在事后识别数据问题的。它们不能阻止数据质量问题发生，但它们可以，尤其是在与血缘和警报解决方案或更好的断路器结合使用时，缩短检测时间并增加减轻“损坏数据”造成的损害的机会。市场充满了像 Soda.io、Monte Carlo、Great Expectations、Informatica、Talend 等工具。我们用市场上的一个工具替换了我们内部制作的 Contessa。
数据集成测试
我们最近开创了数据集成测试，这与标准的数据质量检查有显著不同，因为它们是一种主动措施。
本质上，这些测试旨在在问题发生之前识别潜在的数据质量问题。在我们的设置中，来自订单处理生产系统的数据通过 Google PubSub 服务进行流式传输，然后用于交易性能分析。
每当提出一个更改生产应用程序代码的 git 合并请求时，就会自动启动集成测试。这确保数据合同保持完整。这些测试不仅验证数据模式，还检查数据内容。
为了说明这一点，当放置一个带有特定价格和其他详细信息的订单时，我们期望相应的事件能够准确地发布，并带有预期的值。通过使用样本数据进行的集成测试确认了这一点，从而在它影响生产系统之前保护了数据的完整性和一致性。
集成测试在发布前就验证数据合同不会损坏。
软性措施
数据协作流程
简而言之，这项措施确保了数据分析师、产品经理和工程师之间的合作。实际上，这意味着：
-
产品经理从产品开发初期和功能规范开始就涉及分析。他们做出数据驱动的决策。
-
领域数据分析工程师和分析师评估是否需要记录额外的数据点以及这对报告的影响，确定新的数据发布需求，并发出任何潜在的重大变更信号。他们与领域产品经理和领域工程师保持同步，熟悉待办事项和路线图，并参与定义和修改事件、数据集和属性。
-
领域工程师了解技术变化对数据结构和逻辑的影响，他们负责通过定义数据质量和集成测试来保持数据合同完整，以验证业务逻辑的变化是否反映在分析层面。当数据质量检查揭示应用程序错误时，他们从源头解决问题。
领域数据参与者之间的数据协作流程
产品思维
我们的心态发生了转变，这带有产品思维的某些标志。
-
并非所有数据都同等重要，这就是为什么我们将它们分类为几个层级，就像制造商将产品分类为产品层级一样。例如，财务报告数据位于最高层级。另一方面，如开发者生产力或候选人面试指标等数据可能偏差 5%，但世界并不会因此崩溃。
-
清楚地传达产品层级之间的功能和质量差异，以有效地管理数据用户期望。我们寻求提供关于有意权衡的透明度，以建立数据消费者的信任。
-
对每个新功能的投资与收益做出明智的决策，并清楚地传达结果是很重要的。例如，我们可能能够将预期净收益模型的准确性提高 5%，但模型开发和计算成本将增加 7%。这是一个产品决策。
-
另一方面，经常发生的情况是，数据用户视为数据质量问题的内容，从数据分析工程师的角度来看，可能是一个新功能请求或不同的数据产品。是否实施它又是一个产品决策。
摘要
不，我们真的无法事后修复数据质量。我们实际上做的是：
-
建立一个流程，以增强我们预防数据质量问题并尽早发现它们的能力。
-
在数据所有者手中促进问责制。如果你是数据所有者，你也要对其质量负责。这包括将关于数据质量的隐含期望转化为明确的标准。
-
将产品思维应用于数据。注意投资与收益。
除非另有说明，所有图像均由作者提供。
扫一扫
9万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
