OLAPキューブの増分処理はどのように行うことができますか？

Question

私はsales.Butのために1つの多次元OLAPキューブを持っています。私は巨大なdatabase.Firstly私はOLAPキューブのフル処理を終えました。しかし、それは時間がたくさんかかるので、毎回それを行うだろうたびに私はincremental processing.Butをこの件の期限切れです。私を助けることができますか？

パスをどのようにフォローする必要がありますか？私はいくつかの記事、例えばのようにこの件を扱っていることを発見しました。

しかし、私はパーティションのクエリでどのような状態に書き込むのかわかりません。

Answer 1

ファクトテーブルを分割する一般的な方法は日付です。あなたのソースにはSales_TransactionDateという列があるので、これはパーティション化の属性として明確な選択肢になります。

データの量と作成するパーティションの数に応じて、年、月、日などでパーティションを分割できます。

アイデアは、キューブ全体を1回だけ処理することです。次に、毎晩（たとえば）夜間に、現在の（たとえば）月のパーティションだけを再処理します。これは、より古いデータ（つまり、最後の月末までのデータ）がソースシステム内でを決して変更しない場合にのみ有効です。先月のパーティションが処理されなくなったため、変更があった場合は変更が失われます。

これは、増分処理に重要な問題です。ソースシステムのデータが最初に表示されてからどれぐらいの時間が経過したかを知っておく必要があります（明らかに、キューブに関係する変更のみ - キューブが変更を使用しない列があっても問題ありません）どの段階でそれが不変の状態に落ち着くのかを示します。

タイプ2のゆっくりと変化する属性をどのように使用しているか（そして、ソースシステムに行が最後に更新されたときの表示があるかどうか（例えば、LastUpdated 日時カラム）。

（編集 - 以下のコメントによると）

あなたがちょうど最新のパーティションを処理することによって、可能なすべての変更を取得することを保証しているように、パーティションのサイズを調整する必要があります。たとえば、トランザクションの日付（またはパーティション化に使用している日付）が変更されてから6か月後に行が変更される可能性がある場合は、最後の6か月分のデータを処理して変更を見逃す必要があります。

ただし、この制約は最新のパーティションのサイズにのみ影響します。古いパーティションのサイズは、好きなように変更できます。行を「変更済み」としてマークするメカニズムがソースシステムに存在する場合は、最新パーティションの処理量を減らすことができます。 （一例は「LastUpdated」列で、行が更新されたときの現在の日付/時刻に設定されます。もう1つはSQL CDCです）。