3

我们的数据仓库使用来自数据源的累积数据（并且无法反转累积）来创建雪花模式。我们必须处理的一个要求是我们的架构必须能够用于创建基于日期范围的报告。

我们的模式看起来像这样（简化）：

+------------------------------------------+
| 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 的状态（对于用户，例如“完成”） ，同样。数据提供者的重要之处在于：它只是为我们提供了当前状态的快照。我们无权访问历史数据。

4

2 回答 2

2

我假设您为此使用了一些非常强大的硬件。您的设计有一个主要缺点 - 事实表和“统计”维度之间的连接。

通常，事实表包含维度和度量。在我看来，您的“统计”维度和事实表之间可能存在 1-1 关系。由于事实表本质上是一个“多对多”关系表，因此将您的统计信息放在单独的表上是没有意义的。另外，您说统计表具有“按用户”的信息。

每当您在仓储中说“按 X”时，您几乎总能确定 X 应该是一个维度。

我会看到有关直接在其上建立度量的事实表。我不确定您要如何“反转”统计表上的累积？您的意思是它是跨日期范围累积的吗？用户？如果数据不是原子的，你能做的最好的就是给出你所拥有的......

于 2012-12-17T13:56:31.597 回答
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

通过这样的设计，您可以避免查询中的所有联接。然后您必须专注于表分区和索引以提高性能。

也许，也不需要分析整个数据历史，您可以将一些数据移动到存档。

于 2012-12-18T07:39:01.200 回答