問題タブ [scd]

Amazon Redshift は書き込みではなく読み取り用に最適化されているため、ETL ツール (私の場合は Pentaho データ統合) を使用してゆっくりと変化するディメンション手順を管理するにはどうすればよいですか?

ETL ツールは行ごとに更新/挿入 (ディメンションの参照/更新) を行うため、パフォーマンスは非常に低くなります。

誰かがすでにこの問題を経験していますか?

私は現在、リレーショナル データベース内の既存の履歴データからタイプ 2 SCD を開発する任務を負っている ETL 開発者です。私は、データに対する将来の変更を追跡するタイプ 2 の SCD を完全に作成できますが、目の前のタスクに関してはまったく役に立ちません。

リレーショナル モデルは ODS にあります。そのリレーショナル モデルに基づいて、DW ディメンションでフラット レコードを構築することになっています。変更を監視する必要がある複数の属性があり、それぞれがリレーショナル モデルの特定の関連テーブルにあります。変更履歴は毎日保持する必要があり、同じ日に同じ属性に対して複数の変更が発生した場合は、最後の変更のみが存続します。

どうすればこれに取り組むことができますか? 道に迷いました。前もって感謝します。

PS 2,000 万から 3,000 万行のテーブルと、いつでも変更される可能性がある複数の属性を持つテーブルについて話しているため、SCD に新しいレコードが作成される必要があります。

複数のデータ ソースを使用していくつかのディメンションを設計していますが、データ ソースごとに複数のビジネス キーを調整するために他の人が何をしたのか疑問に思っています。

私の例: 注文システムと実行システムの 2 つのデータ ソースがあります。注文システムには、支払いと何が起こるべきかについての詳細があります。実行システムには、実際に何が起こったかの詳細があります (実行にかかった時間など、誰が注文を実行したか)。単一のファクトを作成するには、両方のシステムからのデータが必要です。

注文システムと実行システムの両方で、それらは Location テーブルです。両方のシステムのビジネス キーは esb を介してマッピングされます。どちらのシステムにも、1 つの場所に関する全体像を構成する属性があります。請求情報は注文システムにあり、緯度と経度は実行システムにあります。また、ロケーション名は両方のシステムに存在します。

両方のシステムからディメンションへの変更に対応する SCD をどのように設計しますか?

私たちはかなり厳密な Kimball の方法論に従いますが、参考までに、私はすべての人の解決策を検討することにオープンです。

Kimball タイプ 2 メソッドを使用して行への変更を既に追跡しているソース システム (OLTP) からいくつかのディメンションを作成しています。彼の最新の本で、彼はこれらを「ゆっくりと変化するエンティティ」と呼んでいますが、それらをデータ ウェアハウスにロードする方法については説明していません。

現在、私の考えは、ライブ データベースから「Valid From」フィールドと「Valid To」フィールドをコピーし、現在の日を使用する通常の方法の代わりに、タイプ 2 のディメンションでそれらを使用することです-1 行を期限切れにします。このようにして、ディメンションはライブ テーブルと同じになります。

データをロードするときは、自然キーと「有効開始日」の日付を結合して行を一致させる必要があります (ソーステーブルはタイプ 2 のために自然キーを繰り返すため)。

基本的にソースシステムを使用して変更を追跡するという私のアプローチに問題があると思う人はいますか?

SCD で complexType の子要素を選択しようとしていますが、SCD は complexType を選択します。SCD のドキュメントは貧弱で、子要素を適切に選択する方法がわかりません。XSD スニペットは次のとおりです。

次のバインディングを作成しました。

私は次のバインディングも試しましたが、これではソースコードも生成されません。

ERP データベースに販売注文の履歴情報がありません。販売注文を含むテーブルがあります。販売注文が承認されると、請求書に変換され、記録された販売注文は削除されます。

必要な情報のみを含む履歴テーブルを ERP にコーディングできます。これはデータ ウェアハウスによって解決されるべきものだと思いました (これも個人的な興味によるものです)。

日付ごとにどれだけの注文があるかを確認したい。たとえば、月ごとの合計金額が XXX の平均 X 件の注文があることを確認したいと考えています。

「有効期限」と「期限まで」の列をどこに追加するかを考えました。そこから私はブロックされています。私のイニシャルはどこでSCDを使用するかですが、私が理解しているように、主キーでそれを行うことはできません。

新しいファクト テーブルを作成する必要がありますか (ERP データベースで行うように) ? 販売注文テーブルからの挿入トリガーまたは削除トリガーにも何かをプログラムしたくありません。1 日の終わりに販売注文テーブルをクリーンアップします。夜間にデータ ウェアハウスを更新するときに更新する必要があります。この場合、注文が承認されないことや、関係のない記録を保存することを考慮する必要はありません。

次のような状況があるとします。

揮発性でないいくつかの属性 (説明と直径 - 修正のための SCD-1 変更によってのみ変更可能) と揮発性の可能性がある属性 (販売グループ、同じ製品の時間の経過とともに変化する可能性がある) を持つディメンション製品）。

そのため、1 つの製品のこれらの揮発性の属性に変化が生じた場合、何らかの方法でそれらを追跡する必要があります。

私はこれらの2つのアプローチを採用しました：

両方の場合:不揮発性属性には SCD-1 を使用し続けます。

アプローチ #1: product_dim で SCD-2 を使用するのは、揮発性属性のみです。

アプローチ #2:販売グループをまったく新しい次元にすると、すべての販売が ETL の瞬間に現在の価値を追跡します。ここでは SCD-2 は必要ありません。

私はデータ ウェアハウスに不慣れで、どちらが優れているのか、その理由を理解しようとしています。私の目標の 1 つは、OLAP ソフトウェアを使用してこれらすべてを読み取ることです。

私はPostgresの初心者です。

Postgres を使用してプロジェクトに SCD タイプ 2 を実装しました。入力ファイルは、毎日約 3,000 万件のレコードを含む完全更新ファイルです。

口座番号がキー列です。

新しいレコードのおおよその数は、1 日あたり 20K になります。ソースからレコードが欠落している場合、そのレコードはターゲットの終了日でクローズされます。クローズされるレコードのおおよその数 - 10,000/日

クエリの実行時間は着実に増加しています。索引付けはプロセスのスピードアップに役立ちますか?

使用するインデックスに関する提案はありますか?