数据所有权：实用指南

用于定义和激活数据团队、上游团队和业务利益相关者的所有权的工具包

dbt调查了数千名数据从业者，询问他们：“在准备用于分析的数据时，您认为最具挑战性的是什么？”。43%的受访者回答说，模糊的数据所有权是他们最大的挑战，是所有答案中的最高比例。
这是有充分理由的。随着数据堆栈变得越来越复杂，一个人再也不可能把所有事情都记在脑子里了，而且通常，发现问题的人不是解决问题的合适人选。同时，上下游依赖关系的数量激增，这使得定位正确的上游所有者或通知受影响的利益相关者变得非常困难。
良好的所有权说起来容易做起来难，并且不缺少失败的所有权计划。在Synq，我们与数十个数据团队合作解决了他们的所有权挑战。这篇帖子包含了我们从所看到的工作中获得的经验。
 

• 为所有者设定期望
• 定义所有权
• 用适当的上下文通知适当的人
• 克服文化所有权挑战

为所有者设定期望

对一些人来说，成为所有者意味着你有责任解决你拥有的数据资产的问题。对其他人来说，这意味着您负责通知下游利益相关者问题或数据管理，随着时间的推移跟踪数据质量，并确保定义了相关的元数据。你应该说清楚。如果没有明确的指导方针，每个团队都会做出自己的解释。期望应与数据资产的重要性相联系（请参阅为数据问题设计严重性级别），例如：
低-添加到积压工作中，以在周末之前修复它
中-让利益相关者知道并在当天结束前解决问题
高-停止您正在做的一切来立即解决问题
在期望值不高的情况下，我们建议您从建立依赖关系和现有数据控制的概述开始。
您不必要求许多数据团队了解梦想状态：上游生产商拥有并管理其数据质量的世界，相关数据团队承担责任的世界，以及利益相关者发现问题的时代已经结束。
但实现目标说起来容易做起来难。将其分解为多个步骤可以使您更清楚地了解存在的差距：（1）整合元数据，（2）使用相关测试检测问题，（3）分配所有权，以及（4）以相关人员可以采取行动的方式通知相关人员问题。

如果在没有相关测试的情况下过度索引定义所有权，则可以很好地通知人们，但不能主动检测重要问题。
如果在没有所有权的情况下过度索引检测重要问题，警报可能会在繁忙的Slack通道的噪声中丢失。
只有在故意测试和相关所有权的正确组合下，您才能成功。例如，虽然失败的关系测试对Salesforce客户数据的所有者可能没有多大意义，但知道特定帐户ID的创建日期在关闭日期之后是他们可以修复的。
定义相关测试来检测问题本身就是一个主题（有关更多信息，请参阅我们的异常检测和dbt测试最佳实践指南）。下面，我们将重点定义所有权并通知相关团队。

定义所有权

在理想的世界中，您可以将堆栈整齐地分组到具有明确边界的定义良好的区域中。但在现实中，所有权关系可能会变得模糊，所以如果您不能轻松地将所有权分配给所有资产，请不要气馁。在定义所有权时，我们将考虑一些最重要的考虑因素，例如在代码中定义所有权与UI、跨工具所有权和跨依赖性的所有权。
理论上-理想的所有权地图

In practice — blurred boundaries

使用dbt所有者元标记
dbt内置了使用meta:owner标记指定所有者的支持。所有者显示在dbt文档中，使每个人都很容易看到谁负责。

models:
 - name: users
   meta:
     owner: "@alice"
     model_maturity: in dev

 您可以将其扩展到dbt源，以定义上游团队的所有权。如果在任何数据转换之前源上发生问题，则表示上游团队应该拥有该问题。
另一个好处是，这种方法允许您使用CI检查，例如来自预提交dbt包的检查模型标记，以确保每个数据模型都分配了所有者标记。

使用dbt组启用有意协作

通过dbt 1.5，dbt启动了对组的支持。组对于较大的dbt项目很有帮助，在这些项目中，您希望封装内部逻辑的部分，以便该组的成员只能访问-类似于您只向最终用户公开公共API中的某些端点。如果模型的访问属性是私有的，则只有其组内的所有者可以引用它。
models/marts/finance/finance.yml

groups:
 - name: finance
   owner:
     # 'name' or 'email' is required; additional properties allowed
     email: finance@jaffleshop.com
     slack: finance-data
     github: finance-data-team

models/schema.yml

models:
 - name: finance_private_model
   access: private
   config:
     group: finance

# in a different group!
 - name: marketing_model
   config:
     group: marketing

使用现有的文件夹结构。

如果您已经组织了dbt项目或数据仓库模式，使其类似于您的所有权结构，例如市场营销、财务和运营，那么这是一个很好的选择。使用基于文件夹的所有权，您通常需要较少的时间来设置，并且随着您添加新的数据模型，它们在设计上属于现有所有者组，从而减少了维护。如果您与不为您的代码库做出贡献的非技术涉众（如业务分析师或数据管理员）合作，则这种方法使他们更容易。
按文件夹分配所有权，在Sync UI中设置Slack通道和句柄

定义跨工具所有权

在某些情况下，您希望跨多个工具（从数据库到多个数据仓库和仪表板工具）管理所有权。当您希望查找特定团队拥有的仪表板或构建功能以在发生数据事件时通知下游受影响的利益相关者时，这非常有用。管理代码中的跨工具所有权可能很困难，因为通常没有一致的方法来定义这一点。
在Sync中定义Looker、Clickhouse、Snowflake和dbt之间的所有权的示例

数据的最终产品很少限于堆栈中的一条链。它几乎总是上游数据源、转换和最终用户目标（如仪表板）的集合。数据可靠性仅与该链中最薄弱的环节一样强。如果可能，我们建议跨堆栈管理所有权。
在下面的示例中，尽管上游做出了任何善意的努力，但仪表板的可靠性很低。

• 在CRM中严格记录呼叫（销售运营）=高→
• 具有高测试覆盖率的dbt模型（分析工程师）=高→
• 仪表板（销售分析师）的LookML代码中未解决的错误=低

Sync中基于dbt曝光的数据产品。所有者Engineering会自动获得有关上游源和模型的问题的通知。

用适当的上下文通知适当的人

我们建议您从整体上考虑数据所有权——从上游团队拥有的数据源到最终用户拥有的仪表盘。为了简单起见，我们将建议分为以下几组：（1）数据团队，（2）上游团队，和（3）业务涉众。

在数据团队中管理警报

在数据团队中管理所有权是最简单的。您的团队在控制中；通常，工具在您管理的堆栈中。您可以使用现有的所有权定义来确保正确的所有者知道正确的问题。假设您使用像Slack这样的通信工具，实现这一点的两种最有效的方法是根据所有权定义标记所有者和路由警报：

• 标记所有者-将所有者与Slack句柄相关联，以标记组或个人，并提高问题意识。
• 路由警报-将松弛通道与所有权绑定，并将警报发送到相关团队的通道。这是一种克服中央通道中警报过载的好方法。

正在根据所有权和标记所有者来路由警报。

通知上游团队

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

关于这个主题的书籍已经有了，数据网格和数据契约等概念得到了大量的追随者，这主要是由于这个问题引起了多少共鸣。然而，这些可能很耗时，也很难实现，因此我们将专注于更简单、更容易的步骤，以使上游团队了解问题。

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

a.技术团队-您发送的警报外观不需要与上面的数据团队示例中的警报不同。如果您在源中放置了测试并检测到问题，工程师应该能够连接源和错误消息之间的点，并将问题追溯到他们的系统。对于在接收数据的团队（例如，数据平台）和生成数据的团队之间存在明确划分的较大团队（例如前端工程师），可以使用错误消息与其相关的事件或服务的详细信息来补充错误消息。
b.非技术团队-将源系统质量的所有权带给非技术团队被低估。通常，繁琐的输入错误（如不正确的客户数量或重复的employee_id）最终会出现在数据团队中，以进行调试、分类和查找正确的所有者。在适当的环境下，这些团队可以在没有数据团队参与的情况下开始拥有它（我们越来越多地看到数据团队开始这样做）。
正在向上游运营团队发送警报示例。

如果做得好，这将产生奇迹。根据测试的所有权自动标记业务所有者，并将警报发送到他们监视的通道。错误消息是描述性的，并链接到runbook、到源系统的直接链接和几个示例记录——换句话说，在没有数据团队输入的情况下，非技术团队需要采取行动的所有内容。
“从一开始就让一个团队参与进来。我们发现了一个已经在积极使用数据的团队。你希望一个希望干净数据的团队成为试验品”——与LendInvest数据团队负责人Rupert的网络研讨会。

通知利益相关者

有时，您可以提醒利益相关者主动通知他们问题。如果您的利益相关者是精通数据的团队，例如业务领域中的一组分析师，则这最有效。但向营销总监发送Slack警报，指出五行未通过订单数据模型的独特测试，这不是最好的主意。
根据我们的经验，通知受影响的利益相关者的最佳方法是让具有相关上下文的人“声明”它。例如，在仪表板中显示正在进行的事件，并提供易于理解的描述、数据所有者、状态和事件声明的时间。
以编程方式在Looker磁贴中显示正在进行的事件

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

文化所有权挑战

一件事是被分配为所有者；另一个是被追究责任。所有权的成功既是一个技术挑战，也是一个文化挑战。

当您开始所有权之旅时，需要考虑以下几点。

• 注意在个人级别分配所有权。虽然将所有权分配给个人很有吸引力（例如，John Doe），但这通常不是最好的想法。如果员工离开公司、调动团队或度假，个人所有权会使管理变得更加困难。相反，考虑将所有权设置为一组对领域有相关理解的人（例如，@finance analytics）。

“我们最大的数据事件之一发生在一个离开公司的人出现在关键数据警报的所有者身上。每个人都认为它正在被调查，这造成了一种错误的安全感，并使它在几周内无法解决”——100人数据团队的数据主管。

• 高级买进是上游所有权的关键。为了让上游团队获得源自其系统的问题的所有权，您通常需要来自高级管理层的人员来购买并帮助实施它。人们很忙，他们最不想看到的是另一个需要注意的警报流。理想情况下，在游戏中找到一个肤浅的人，他的关键目标和目标受到最近数据质量问题的影响。

“确保您得到业务资深人士的认可，并让他们了解数据错误的业务影响”-与LendInvest数据团队负责人Rupert举行网络研讨会

• 注意信噪比。没有什么比警报过载更快地扼杀良好的所有权意图。如果您向上游团队发送数百个不相关的警报，那么他们不太可能继续关注。请注意警报过载，不要发送太多警报，而是发送更少的警报。
• 明确期望。弄清楚作为一个所有者意味着什么。例如，对于高严重性问题，所有者必须在四小时内解决问题，但不希望进行非工作时间监控。如果没有明确定义的期望，您团队中最关心的人最终将含蓄地拥有大多数问题。为数据问题声明事件是公开这种透明度的一种很好的方法。
• 从小处开始。通常，所有权计划因过度规划而变得过于复杂，结果在橡皮泥上路时失败。相反，从一个团队或领域开始，已经有动机对其数据质量做一些事情。展示一些成功，找出有效的方法，然后加倍努力。

总结

当数千名数据从业者接受关于他们最大挑战的调查时，含糊不清的所有权是排名最高的答案。这是有充分理由的。数据堆栈的规模和复杂性都在爆炸式增长，没有人能够记住所有的事情。在这篇文章中，我们探讨了如何克服这一点。

• 为业主设定期望——明确对业主的期望。例如，清楚地说明应如何解决低、中和高严重性问题。
• 定义所有权-所有权可以在代码或UI中定义。例如，在代码中定义所有权使强制所有者标记存在于CI中变得更容易。在UI中定义所有权使分配跨工具所有权变得更容易，并引入了非技术涉众。
• 应该跨堆栈管理通知具有正确上下文所有权的正确人员，但数据团队、上游团队和下游干系人需要不同的警报。
• 克服文化所有权挑战——所有权既是一项技术挑战，也是一项文化挑战。从小处做起，找一个你有高层支持的团队，并注意警惕超载。