通过对数千名数据从业者调查，“在准备数据进行分析时，您认为最具挑战性的是什么? ”。 43% 的受访者回答说，不明确的数据所有权是他们面临的最大挑战，这一比例在所有答案中最高。

随着数据堆栈变得越来越复杂，一个人不再可能将所有事情都记在脑子里，而且通常情况下，发现问题的人并不是解决问题的合适人选。同时，上游和下游依赖关系的数量呈爆炸式增长，使得找到正确的上游所有者或通知受影响的利益相关者变得具有挑战性。

良好的所有权说起来容易做起来难，而且不乏失败的所有权举措。这篇文章包含了从我们所看到的行之有效的方法中学到的经验教训。

• 为业主设定期望

• 定义所有权

• 在正确的背景下通知正确的人

• 克服文化所有权挑战

一 为业主设定期望

对于某些人来说，成为所有者意味着有责任解决所拥有的数据资产的问题。对于其他人来说，这意味着有责任向下游利益相关者通知问题或数据管理、随时间跟踪数据质量，并确保定义相关元数据。如果没有明确的指导方针，每个团队都会做出自己的解释。期望应与数据资产的重要性相关联，例如：

• 低——添加到待办事项中以在本周末之前修复它

• 中——让利益相关者在一天结束前了解并解决问题

• 高——立即停止正在做的一切来解决问题

如果不满足预期，我们建议首先概述您的依赖项和现有的数据控制。

不必要求许多数据团队来理解理想状态：上游生产者拥有并管理其数据质量，相关数据团队承担责任，利益相关者发现问题的时代已经结束。

但实现这一目标说起来容易做起来难。将其分解为几个步骤可以更清楚地表明差距：(1) 整合元数据，(2) 通过相关测试检测问题，(3) 分配所有权，(4) 以他们可以的方式通知相关人员问题采取行动。

如果在没有进行相关测试的情况下过度定义所有权，可能会很好地通知人们，但无法主动检测重要问题。

如果在没有所有权的情况下过度索引检测重要问题，则警报可能会在繁忙的 Slack 通道的噪音中丢失。

只有将有意的测试和相关所有权正确结合起来，才能取得成功。例如，虽然失败的关系测试对于客户数据的所有者来说可能没有多大意义，但知道特定帐户 ID 的创建日期晚于截止日期是他们可以修复的问题。

二 定义所有权

在理想的情况下，可以将堆栈整齐地分组为边界清晰的明确区域。但实际上，所有权界限可能会变得模糊，因此，如果无法轻松地将所有权分配给所有资产，请不要灰心。在定义所有权时，我们将考虑一些最重要的考虑因素，例如定义代码与 UI 中的所有权、跨工具所有权以及跨依赖项的所有权。

理论上——理想的所有权图

实践中——界限模糊

三 在正确的背景下通知正确的人

我们建议全面考虑数据所有权——从上游团队拥有的数据源到最终用户拥有的仪表板。为简单起见，我们将建议分为以下几组：(1) 数据团队、(2) 上游团队 (3) 业务利益相关者。

管理数据团队内的警报

管理数据团队内的所有权是最直接的。团队掌控一切;通常，这些工具位于您管理的堆栈中。您可以使用现有的所有权定义来确保正确的所有者了解正确的问题。假设您使用 Slack 等通信工具，实现此目的的两种最有效方法是标记所有者并根据所有权定义发送警报：

• 标记所有者 - 使用 Slack 句柄关联所有者来标记群组或个人并提高对问题的认识。

• 路由警报 - 将 Slack 渠道与所有权联系起来，并向相关团队的渠道发送警报。这是克服中央通道警报过载的好方法。

通知上游团队

让上游团队掌控其数据质量是每个数据团队的梦想。这里的问题远离数据团队的控制，并且通常是最令人沮丧。

我们通常会看到两种需要以不同方式发出警报的上游团队：技术团队(例如工程团队)和非技术团队(例如拥有客户数据的 SalesOps 团队)。

a.技术团队- 您发送的警报不需要与上面数据团队的示例中的警报有所不同。如果您在源头进行了测试并检测到了问题，工程师应该能够将源头和错误消息之间的点联系起来，并将问题追溯到他们的系统。对于在摄取数据的团队(例如，数据平台)和生成数据的团队(例如，前端工程师)之间有明确划分的大型团队来说，用有关其所涉及的事件或服务的详细信息来补充错误消息可能会有所帮助。

b.非技术团队——将源系统质量的所有权交给非技术团队的作用被低估了。很多时候，繁琐的输入错误(例如不正确的客户数量或重复的客户数量)employee_id最终需要数据团队进行调试、分类和找到合适的所有者。有了正确的上下文，这些团队就可以开始拥有它，而无需数据团队的参与.

如果做得好，这将创造奇迹。根据测试的所有权自动标记企业主，并将警报发送到他们监控的渠道。错误消息是描述性的，并链接到操作手册、到源系统的直接链接以及一些示例记录 - 换句话说，非技术团队在没有数据团队输入的情况下采取行动所需的一切。

通知利益相关者

有时，您可以提醒利益相关者主动向他们通知问题。如果您的利益相关者是精通数据的团队(例如业务领域的一组分析师)，那么这种方法效果最 佳。但是，向您的营销总监发送 Slack 警报，告知有五行未通过订单数据模型的独特测试，这并不是最好的主意。

根据我们的经验，通知受影响的利益相关者的最 佳方式是由具有相关背景的人“声明”。一个示例是在仪表板中显示正在进行的事件，并提供易于理解的描述、数据所有者、状态以及声明事件的时间。

这样做可以最大限度地降低利益相关者依赖存在持续问题的数据的风险，并减少向受影响的利益相关者发送有针对性的 Slack 消息所需的工作。

四 文化所有权的挑战

一件事是被指定为所有者;另一个正在被追究责任。成功拥有所有权既是一项技术挑战，也是一项文化挑战。

当开始数据所有权的工作时，需要考虑以下几点。

请注意在个人层面上分配所有权。虽然将所有权分配给个人很诱人(例如，John Doe)，但这通常不是最好的主意。如果个人离开公司、调动团队或去度假，个人所有权会使管理变得更加困难。相反，请考虑将所有权设置给一组对某个领域有相关了解的人。

高层支持是上游所有权的关键。为了让上游团队负责解决源自其系统的问题，您通常需要高级管理层的人员支持并帮助执行。人们很忙，他们最不希望看到的就是另一波需要关注的警报。理想情况下，找到一个参与其中的人，其主要目标和目标受到最近数据质量问题的影响。

注意信噪比。没有什么比警报超载更快地扼杀良好的所有权意图了。如果您向上游团队发送数百个不相关的警报，他们就不太可能继续关注。请注意警报过载，宁可发送较少的警报，也不要发送过多的警报。

明确期望。明确成为所有者意味着什么。例如，对于严重程度较高的问题，业主必须在四小时内解决问题，但预计不会在工作时间外进行监控。如果没有明确定义的期望，团队中最关心的人最终将隐含地承担大部分问题。宣布数据问题事件是将这种透明度公开化的好方法。

从小事做起。很多时候，所有权计划因过度规划而变得过于复杂，结果却在上路时失败。相反，从一个已经积极采取措施提高数据质量的团队或领域开始。展示一些成功，找出有效的方法，然后加倍努力。