我们的数据仓库使用累积数据（并且无法反转累积）从数据源创建雪花模式。我们必须应对的一个要求是我们的架构必须可用于根据日期范围创建报告。
我们的架构看起来像这样（简化）：
+------------------------------------------+
| fact |
+-------+-----------------+----------------+
| id | statisticsDimId | dateRangeDimId |
+-------+-----------------+----------------+
| 1 | 1 | 10 |
| 2 | 2 | 11 |
| 3 | 3 | 12 |
| 4 | 4 | 13 |
| 5 | 5 | 14 |
| 6 | 5 | 15 |
| 7 | 5 | 16 |
| ... | ... | ... |
| 10001 | 9908 | 11 |
| 10002 | 9909 | 11 |
+-------+-----------------+----------------+
+-------------------------------------------------+
| date_range_dimension |
+-------+-----------------------------------------+
| id | startDateTime | endDateTime |
+-------+--------------------+--------------------+
| 10 | '2012-01-01 00:00' | '2012-01-01 23:59' |
| 11 | '2012-01-01 00:00' | '2012-01-02 23:59' |
| 12 | '2012-01-01 00:00' | '2012-01-03 23:59' |
| 13 | '2012-01-01 00:00' | '2012-01-04 23:59' |
| 14 | '2012-01-01 00:00' | '2012-01-05 23:59' |
| 15 | '2012-01-01 00:00' | '2012-01-06 23:59' |
| 16 | '2012-01-01 00:00' | '2012-01-07 23:59' |
| 17 | '2012-01-01 00:00' | '2012-01-08 23:59' |
| 18 | '2012-01-01 00:00' | '2012-01-09 23:59' |
| ... | ... | ... |
+-------+--------------------+--------------------+
+-----------------------------------------------------+
| statistics_dimension |
+-------+-------------------+-------------------+-----+
| id | accumulatedValue1 | accumulatedValue2 | ... |
+-------+-------------------+-------------------+-----+
| 1 | [not relevant] | [not relevant] | ... |
| 2 | [not relevant] | [not relevant] | ... |
| 3 | [not relevant] | [not relevant] | ... |
| 4 | [not relevant] | [not relevant] | ... |
| 5 | [not relevant] | [not relevant] | ... |
| 6 | [not relevant] | [not relevant] | ... |
| 7 | [not relevant] | [not relevant] | ... |
| ... | [not relevant] | [not relevant] | ... |
| ... | [not relevant] | [not relevant] | ... |
| 10001 | [not relevant] | [not relevant] | ... |
| 10002 | [not relevant] | [not relevant] | ... |
+-------+-------------------+-------------------+-----+
我们希望使用以下内容创建报告数据集：
SELECT *
FROM fact
INNER JOIN statistics_dimension
ON (fact.statisticsDimId = statistics_dimension.id)
INNER JOIN date_range_dimension
ON (fact.dateDimId = date_range_dimension.id)
WHERE
date_range_dimension.startDateTime = [start]
AND
date_range_dimension.endDateTime = [end]
问题是我们的统计维度中的数据已经累积，我们无法反转积累。我们计算了事实表中的近似行数，得到了5,250,137,022,180。我们的数据有大约250万个日期范围排列，我们需要将它们计算到我们的日期维度和事实表中，因为它们的积累。由于累积，SQL的SUM函数对我们不起作用（您不能添加属于非不同集的两个值）。
我们可以遵循最佳做法，使其在计算上可行吗？我们的架构设计有问题吗？
我们需要报告有关在线培训的数据。数据源是遗留数据提供者，其部分时间超过10年 - 因此没有人可以重建内部逻辑。统计维度包含 - 例如 - 用户在基于Web的培训（WBT）中完成的进度（％），每个WBT页面的调用次数，WBT的状态（对于用户，例如“已完成”） ，aso。关于数据提供者的重要事情是：它只是给我们一个当前状态的快照。我们无法访问历史数据。
答案 0 :(得分：2)
我假设你有一些相当强大的硬件。您的设计有一个主要缺点 - 事实表和“统计”维度之间的连接。
通常，事实表包含维度和度量。在我看来，你的“统计”维度与事实表之间可能存在1-1的关系。由于事实表本质上是一个“多 - 多”关系表，因此将统计数据放在单独的表中是没有意义的。另外，你说统计表有“按用户”的信息。
任何时候你在仓库中说“By X”，你几乎总能确定X应该是一个维度。
我会看到直接在其上构建事实表。我不确定你要在“反转”统计表上的积累时做些什么？你的意思是它是在日期范围内累积的吗？用户？如果数据不是原子的，那么你能做的就是给你所拥有的......
答案 1 :(得分：1)
您可以通过以下方式减少计算此任务所需的维数：
在我们当前的数据仓库中，我们使用以下方法：
time_dimension
time_key (bigint)
time_date (date)
(other time related columns)
fact_table
(keys to other dimensions)
time_key_start (bigint) /* reference to time_dimension, time_key */
time_key_end (bigint) /* reference to time_dimension, time_key */
value_1
value_2
此外，time_dimension中的键是“智能”。我知道很多人不同意这样的设计，但是当性能有待提高时，我们可以通过直接查询time_key来减少查询中使用的维数，条件如下：
time_key_start = to_char('2012-01-01','J')::bigint
and
time_key_end = to_char('2012-01-02','J')::bigint
使用此类设计，您可以避免查询中的所有联接。然后，您必须关注表分区和索引以提高性能。
也许，也不需要分析整个数据历史记录，您可以将一些数据移动到存档。