是否建议在数据仓库项目中包含审计维度？

Posted 2023-03-29

【中文标题】是否建议在数据仓库项目中包含审计维度？

【英文标题】：It's recommended to include an audit dimension on a datawarehouse project?

【发布时间】：2014-01-05 13:39:54

【问题描述】：

我设计了一个具有 3 个维度和一个事实的数据仓库，为此我阅读了 Kimball、Bouman、Malinowski 的一些书籍......

在名为The Data Warehouse ETL Toolkit 的 Kimball 和 Caserta 书中，第 128 页谈到了审计维度。据我了解，它和其他维度一样是与事实挂钩的维度，主要用于评估数据质量。

问题是……这个审计维度实际上是用在企业环境中的吗？大公司在他们的数据仓库项目中使用它？

我正在做我的最终学位项目，我不知道我是否应该包括这个维度，因为我只在书本上看到过它，但这似乎是一种用于数据质量目的的好方法。

提前致谢。

【参考方案1】：

OP 询问，

这个审计维度实际上是用在企业环境中的吗？大公司在他们的数据仓库项目中使用它？

简短的答案是：是的，有时

长 答案是，审计维度在真正需要时使用。审计维度应该存储 ETL 元数据信息。其中一些元数据可以直接存储在事实表本身中。 load date、loading batch number、job name、user name 等数据可以直接存储在事实表中。

但事实上，当您决定将这些信息存储在事实表本身中时，您很快就会意识到其中许多信息实际上对于大量记录是相同的事实表。

例如，如果您每天在事实表中加载 10 万条记录，那么所有这 10 万条记录的loading job name、source file name、user who executed the job、batch number 等都是相同的。因此，如果您从事实表中删除这些信息，并将其保存在单独的表中并将该单独表的 surrogate key 引用到您的事实中，这确实是有意义的。这减少了数据冗余和空间需求，可能提高了加载速度。正常数据规范化技术，你知道的。

当然，有些信息您应该不放入您的审核维度。比如说，load date-time 的记录。对于您的事实中的所有记录，这将是唯一的 - 所以很明显，如果您要将这些信息放在您的审计维度中，您的审计表将与您的事实一样大。相反，您应该将此类信息放入事实表本身。

我亲眼见过/工作过一些世界上最大的零售和电信行业的数据仓库，并见证了这些数据仓库中的某种审计维度。

【参考方案2】：

是的，它很有用，因为它允许您存储关于每一行的流程元数据。这可能包括：

插入行的作业的名称， 作业执行的标识符， 执行的日期和时间， 源系统或源文件的名称， 执行作业的用户， 已处理的行数。

这些信息对于定期监控以及出现问题时的调试都是非常宝贵的。考虑一个非常简单的例子——当有人错误地加载了错误的源文件时，如何快速识别应该删除且没有审计维度的行？

【讨论】：

好的，但是您知道它是否用于企业环境吗？如果我错了，请纠正我...对于事实的每一行，该审计维度上都会有一行？以及如何监控其他维度的行？有什么办法还是没必要？

我不知道它的使用频率。请记住，有时不需要明确的审计维度 - 您的 ETL 工具可能会生成包含您需要的所有流程元数据的日志。 / 审计维度包含数据加载作业的每次执行的 1 行 - 如果它填充几个事实表并插入数千行，则每一个都引用描述此特定执行的同一审计行。 / 您可以使用审计维度来跟踪事实表和维度表中的更改。

谢谢回复，我会考虑的