如何识别你的业务关键数据
实用步骤：识别业务关键的数据模型和仪表板，提高数据可信度
本文与 Lindsay Murphy 合作撰写
并非所有数据都是平等的。如果您在数据团队工作，您知道如果某个仪表板出现问题，您会放下手头的所有工作处理它，而其他问题可以等到周末处理。这其中有很好的原因。前者可能意味着整个公司都缺失了数据，而后者可能没有什么重大影响。
然而，随着团队规模的扩大和数据模型和仪表板数量的增加，跟踪所有业务关键数据可能会很困难。这就是为什么会出现这些情况：
“我不知道财务部门依赖这个仪表板进行月度审计报告”
或者
“什么鬼，我们的 CEO 把我匆忙制作的一个一次性请求的仪表板收藏了六个月？”
本文将介绍：
- 为什么您应该识别关键业务数据资产
- 如何识别关键仪表板和数据模型
- 创建关键数据的正常运行文化
为什么您应该识别关键业务数据
当您绘制出关键业务资产的地图后，您可以概览整个堆栈，显示哪些数据模型或仪表板是业务关键的，它们在哪里使用以及它们的最新状态。
这可以非常有用，有很多不同的方式：
- 它可以成为一份重要的文档，有助于驱动业务各方对最重要的数据资产的一致性
- 它可以培养数据团队的信心，使其可以更改和更新现有的模型或功能，而不必担心会破坏下游的关键事项
- 在问题出现时，它可以实现更好的决策、速度和优先级
- 它可以使您的团队有权将更多精力集中在高度关键的资产上，而让一些不太重要的事情滑过
本文将介绍如何识别关键业务数据模型和仪表板。您可以将大多数相同的原则应用于其他可能对您的业务至关重要的数据资产。
什么数据是业务关键的
用于决策的数据非常重要，如果数据不正确，可能会导致错误的决策，随着时间的推移，会失去对数据的信任。但是，数据驱动的企业拥有真正业务关键的数据。如果此数据错误或过时，您将面临一些紧急情况，如果不解决，会立即对业务产生影响，例如…
- 数以万计的客户可能会收到错误的电子邮件，因为反向 ETL 工具从过时的数据模型中读取
- 您向监管机构报告错误的数据，您的 C 级管理人员可能会承担个人责任
- 您的预测模型未运行，数百名客户支持员工在节假日前无法获得下一个班次的排班
绘制这些用例需要您深入了解公司的工作方式，了解利益相关者最重要的方面以及问题的潜在影响。
识别您的业务关键仪表板
Looker 暴露了有关内容使用情况的元数据，您可以使用自己的数据来丰富它，使其更有用。在以下示例中，我们将使用 Looker，但大多数现代 BI 工具都以某种形式启用基于使用情况的报告（Lightdash 还具有内置的使用分析功能，Tableau Cloud 提供管理员见解，Mode 的 Discovery 数据库提供对使用数据的访问，这只是其中的几个例子）。
基于业务关键用例的重要性
当您与业务领导人交谈时，可以询问以下问题：
- 未来三个月您的首要任务是什么？
- 如何衡量您所在领域的成功？
- 过去一年中您遇到的最重要的问题是什么？
您的业务领导可能不知道平均客户支持响应时间从圣诞节时的两小时跳到了24小时是由于陈旧的上游数据预测错误，但他们会向您描述痛苦的经历。如果您可以绘制出最关键的操作和工作流程，并了解数据的使用方式，您将开始揭示真正关键的数据。
基于仪表板使用情况的重要性
最明显重要的仪表板是所有公司都使用的仪表板。其中大多数您可能已经知道，例如“公司范围的关键绩效指标”、“产品使用仪表板”或“客户服务指标”。但有时您会惊讶地发现，有许多人依赖于您不知道存在的仪表板。
在大多数情况下，您应该过滤最近的使用情况，以不包括六个月前有大量用户但上个月没有使用的仪表板。当然也有例外情况，例如每三个月才使用一次的季度 OKR 仪表板。
基于 C-suite 使用情况的重要性
不管你喜不喜欢，如果您的 CEO 经常使用某个仪表板，那么它就很重要，即使只有少数其他用户。在最坏的情况下，您会意识到 C-suite 成员已经在使用有错误数据的仪表板数个月了，而您却毫不知情。
“我们发现我们的 CEO 经常查看每日邮件，其中包含有关收入的报告，但它被错误地过滤为包括特定细分，因此与集中的公司 KPI 仪表板不匹配。” —— 加拿大医疗保健初创公司
如果您有员工记录系统，则可以轻松获取人员职称的标识符，并使用此丰富您的使用数据。如果没有，您可以维护这些的手动映射，并在执行团队变更时进行更新。
虽然按资格使用高度相关，但您的首要任务应该是绘制业务关键用例。例如，一家更大的金融科技公司有一个由监管报告负责人使用的仪表板，以与监管机构共享关键信息。这些数据的准确性对您的 CEO 可能比他们每天看的仪表板更重要。
识别业务关键数据模型
由于许多 dbt 项目超过数百或数千个数据模型，因此了解哪些是业务关键的很重要，这样您就会知道何时应该优先运行或测试失败，或构建额外的强壮测试。
具有许多下游依赖项的数据模型
您可能有一组数据模型，如果它们出现错误，其他所有内容都会受到延迟或影响。这些通常是其他所有内容都依赖的模型，例如 users、orders 或 transactions。
您可能已经知道这些是哪些。如果不知道，您还可以使用 dbt 生成的 manifest.json 文件作为每次调用的构件的一部分以及每个节点的 depends_on 属性来循环遍历所有模型，并计算依赖于它们的模型的总数。
在大多数情况下，你会发现有一些模型具有不成比例的依赖关系。这些应该被标记为关键。
关键路径上的数据模型
数据模型很少是关键的本身，但通常是由于其下游依赖的重要性，例如重要的仪表板或用于为网站用户提供建议的机器学习模型
一旦你经过了艰苦的工作，确定了你的业务关键下游依赖和用例，就可以使用dbt中的暴露来手动映射这些，或使用自动连接你的血统跨工具的工具。
任何关键资产的上游都应被标记为关键或在关键路径上。
如何保持关键数据模型定义的更新
尽可能自动化标记你的关键数据模型。例如：
- 使用pre-commit dbt包中的check-model-tags来强制执行每个数据模型具有关键性标记
- 构建一个脚本，或使用一个工具，自动向所有上游于业务关键资产的模型添加
critical-path标记
定义关键性标签
如何定义关键性没有一个正确的答案，但你应该问自己两个问题
- 你对如何不同对待关键数据资产有什么计划
- 如何在关键性上保持一致的定义，使每个人都在同一个页面上
大多数公司使用分层方法（例如铜、银、金）或二进制方法（例如关键、非关键）。两种选择都可以工作，最佳解决方案取决于你的情况。
你应该在定义关键性时保持一致，并将这些写入你的新员工入职培训中，并避免推迟这一点。例如，分层的定义可能是
- Tier 1：机器学习系统使用的数据模型，用于确定哪些用户可以注册你的产品
- Tier 2：CMO用于每周营销审查的仪表板
- Tier 3：你的产品经理用于跟踪每月产品参与度的仪表板
如果你不断更新和标记你的资产，会导致缺乏信任并且假定你不能依赖这个定义。
在哪里定义关键性
没有一个正确的地方定义关键性，但通常在创建数据资产的工具中或在数据目录（例如Secoda）中完成。
在创建数据资产的工具中定义关键性
在dbt中，你可以将关键性定义保留在与数据模型定义一起的.yml文件中。这有几个优点，例如能够在合并PR时强制执行关键性，或轻松地在数据目录或可观察性工具等工具之间传递此信息
models: - name: fct_orders description: All orders meta: criticality: high在.yml文件中定义关键性的示例
在BI工具中，一个让每个人都透明的选项是使用例如” Tier 1 ”标记仪表板的标题，以指示它的关键性。这些数据通常可以被提取并用于其他工具中。
定义数据目录中的重要性
在数据目录中，您可以轻松地访问所有公司数据，并通过搜索整个堆栈找到常见问题的答案，这使得对指标和模型的协调更加容易。
根据重要性采取行动
只有在您因此而采取不同的行动时，映射业务关键资产才会有所回报。以下是一些通过设计构建质量的流程。
仪表盘：
- 在推送到生产之前，一级仪表板需要进行代码审查
- 一级仪表板应符合特定的性能指标，如加载时间和一致的视觉布局
- 一级仪表板的使用情况应由所有者每月进行监控
数据模型：
- 对关键数据模型进行测试或运行失败应在同一天内采取行动
- 关键数据模型的问题应发送到 PagerDuty（一个值班团队成员），以便快速采取行动
- 关键数据模型应至少具有唯一和非空测试以及定义所有者
您可以在我们的指南“为数据问题设计严重性级别”中了解更多有关如何处理数据问题的信息
总结
如果您确定并映射出业务关键数据资产，则可以更快地采取重要问题的行动，并有意识地确定构建高质量数据资产的位置。
- 要识别业务关键仪表板，请从业务用例开始查看。然后考虑使用数据，例如用户数量或是否有任何 C 级别用户使用仪表板
- 业务关键数据模型通常具有许多下游依赖项和/或关键下游依赖项
- 在创建数据资产的工具中直接定义关键性，或使用数据目录
- 明确如何在业务关键资产内处理问题，并制定通过设计构建质量的程序
