数据仓库 - 随着时间的推移存储独特的数据

Posted 2023-03-29

【中文标题】数据仓库 - 随着时间的推移存储独特的数据

【英文标题】：Data Warehouse - Storing unique data over time

【发布时间】：2017-08-24 17:16:50

【问题描述】：

基本上，我们正在为我们的软件构建一个报告仪表板。我们让客户能够查看基本的报告信息。

示例：（我已经从这个示例中删除了我们实际系统的 99% 的复杂性，因为这应该仍然可以理解我正在尝试做的事情）

一个示例指标是...在特定时间段内查看的唯一产品数量。又名，如果客户在一个月内分别查看了 5 种产品 100 次。如果您运行该月的报告，它应该只显示查看的产品数量为 5。

对于如何以可以在任何时间范围内查询数据并返回查看产品的唯一计数的方式存储数据是否有任何建议。为了这个例子……假设有一条规则，应用程序不能直接查询源表，我们必须将汇总数据存储在不同的数据库中并从那里查询。

附带说明一下，我们存储了大量其他指标，我们按天汇总存储这些指标。但是由于唯一性问题，这个特定的指标是不同的。

我个人认为这是不可能的。我们目前的解决方案是我们提供 4 个预先计算的时间范围，在这些时间范围内，受唯一性影响的指标可用。如果您使用自定义时间范围，则该指标将不再可用，因为我们没有预先计算数据。

【问题讨论】：

我想知道...与其将摘要数据保存在其他地方，不如定义一个返回项目计数（或任何摘要数据）的 VIEW 并应用日期范围过滤器风景？甚至更好...定义一个存储过程，该过程根据源数据上的日期范围（作为参数传递）应用 SELECT 语句。

我们需要预先计算和存储这些数据，因为我们正在运行它数百万行，因此每次客户端运行报告时动态生成这些数据需要很长时间。在逐个客户端的基础上，它只需要几秒钟，这还不错。但是这些数据也被用于基准测试（将一个客户端与其他客户端组进行比较），当一次为数千个客户端运行时，动态计算需要很长时间。使用我们预先计算的数据库，其他指标只需几分之一秒即可一次聚合数千个客户。

您使用的是哪种数据仓库方法，Inmon 还是 Kimball？

我不知道。但我觉得这超出了问题的范围。我正在寻找有关如何将数据存储在 SQL 数据库中以完成我所要求的问题的高级答案。

【参考方案1】：

您的问题是您正在尝试更改事实表的粒度。这是做不到的。

您最好的选择是我认为您现在正在做的事情 - 以日、周和月为单位定义汇总事实表，以支持您的性能限制。

您可以通过告知用户这将比标准聚合慢来解决自定义时间范围。例如，想要了解周二销售的独特产品的数量的用户可以编写这样的查询，但会损失一些性能：

select  distinct dim_prod.pcode
        ,count(*)
from    fact_sale
        join dim_prod on dim_prod.pkey = fact_sale.pkey
        join dim_date on dim_date.dkey = fact_sale.dkey
where   dim_date.day_name = 'Tuesday'
group by dim_prod.pcode

查询也可以针对每日汇总而不是事务事实编写，并且由于扫描的数据更少，因此运行速度更快，甚至可能满足您的需求

【参考方案2】：

根据您提供的信息，我认为您正在尝试衡量“一个月内（例如）查看的独特产品的数量”。

不确定您是否使用 Kimball 方法来设计事实表。我相信在 Kimball 方法中，会推荐一个累积快照事实表来满足这样的要求。

我可能是在向皈依者讲道（在这种情况下道歉），但如果不是这样，我会让你通过以下链接查看专家详细解释了这个概念： http://www.kimballgroup.com/2012/05/design-tip-145-time-stamping-accumulating-snapshot-fact-tables/

我还包含了来自 Kimball 的另一个链接，它详细解释了不同类型的事实表：

http://www.kimballgroup.com/2014/06/design-tip-167-complementary-fact-table-types/

希望详细解释这些概念。非常乐意回答任何问题（尽我所能）

干杯 尼丁