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関数は、累積のために機能しません（異なるセットに属する2つの値を追加することはできません）。

計算を実行可能にするために従うことができるベストプラクティスはありますか？スキーマ設計に何か問題がありますか？

オンライントレーニングに関するデータを報告する必要があります。データソースは、10年以上前の部品を使用するレガシーデータプロバイダーであるため、内部ロジックを再構築することはできません。統計ディメンションには、たとえば、Webベースのトレーニング（WBT）でユーザーが達成した進行状況（％）、WBTページあたりの呼び出し数、WBTのステータス（ユーザーの場合、「完了」など）が含まれます。 、 そう。データプロバイダーについて重要なことは、現在の状態のスナップショットを提供するだけです。過去のデータにアクセスすることはできません。

4

2 に答える 2

2

このためにかなり強力なハードウェアを使用していると思います。設計には1つの大きな欠点があります。それは、ファクトテーブルと「統計」ディメンションの間の結合です。

通常、ファクトテーブルにはディメンションとメジャーが含まれます。「統計」ディメンションとファクトテーブルの間に1対1の関係がある可能性が高いように思われます。ファクトテーブルは本質的に「多-多」の関係テーブルであるため、統計を別のテーブルに置くことは意味がありません。さらに、統計テーブルには「ユーザー別」の情報があると言います。

倉庫で「ByX」と言うときはいつでも、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 に答える