首先，我的信念是，数据治理应有助于加快决策制定，确保分析是建立在正确的和可靠的数据。它通过减少需要审计工作事后或协调同一指标的两种不同的计数实现这一点。当数据治理出现问题，它可以产生相反的效果，削弱了它力求创造信任和组织放缓至抓取。在最坏的情况下，我看到这种情况发生在专有的语言或数据存储，留下几个选项，但撕都记录下来，并重新开始。

错误1：“管理”错误数量的数据

我看到许多公司都随着数据的成熟建立了SLA。他们拥有一些始终需要正确的数据，有些数据的优先级稍低，但结构合理，有些数据则是荒野的西部。当然，对所有事情进行正确的测试都很好，但这是不切实际的。尽管数据变化很快，并且要保持良好的建模和质量检查仍然需要大量时间才能进行实际分析。这些层是进行这种权衡的一种机制：如果数据位于最高，最受监视的层中，则使其保持最新状态应优先于分析。如果位于最低层，则可以首先进行分析。

我认为做得最好的公司在其最高层中的表越少越好。您需要维护的东西越少，维护它们就越好，同时还能满足您工作中的其他一些要求。如果您可以根据业务推动因素对数据进行建模，则效果特别好。最近，我与一家交付公司进行了交谈，该公司有一个用于“交货”的核心表，其中每一行都是交付，而列代表了您可能想知道的关于交付的所有可能属性。只要该表是正确的，该公司的大多数分析都是正确的。它是可维护的，并且易于在整个公司范围内进行沟通。

错误2：以错误的方式执行治理

如果你的商业智能工具，包含了所有的建模逻辑-如果所有的指标定义生活在一个产品-再建设一个仪表板或做分析的必要数据治理，即使它基于快速变化的数据也是如此。这给您带来了两种结果之一：随着基础数据的变化，您花费了大量时间来维护该逻辑，或者您的系统中存在一些过时的东西。更糟糕的是，这会给最终用户带来混乱的体验。我见过BI实现，用户必须对10多个“收入”定义进行排序，而不知道哪种定义正确或适用于其特定目的。极有可能将这些定义中的一半以上用于一次性分析，并且永远不应该进入模型，但是软件要求对它们进行建模。

因此，我建议始终在自己的单独层中进行数据治理。在Mode下，我们使用DBT对数据进行建模。其他人则使用Airflow或市售产品。在数据仓库中(而不是在另一个工具中)以表的形式对数据进行建模和测试有助于避免上述错误。它还使您的模型具有可移植性，因此您可以更轻松地切换前端工具，或者将同一模型用于商业智能和机器学习。