データウェアハウスのステージングアーキテクチャ
これは、データウェアハウスの設計に関する質問です。ヘルスケアデータウェアハウスをセットアップし、約20,000のテーブルと2つのTBデータの1を組み合わせた2つの主要なソースシステムから始めます。1）非常に次元の高いデータです2）必要ありません。大きな影響を与えるt OLTPシステム
インクリメンタルキンボールデザインを選択しました。私の質問は、すべてのデータがステージングされ、挿入/更新に分類されてデータウェアハウスに入れられるかどうかです。その後、ステージングデータは次の増分ロードのためにクリアされます。
これにより、データのコピーが1つ残ります。
もう1つの方法は、段階的にロードしてステージングし、挿入/更新にソートして、ソースシステムと同じ形式で保存する方法です。次に、ソースシステムからのデータを完全なコピーからデータウェアハウスに結合します。
これにより、基本的にデータの2つのコピーが残り、1つはソースシステムの形式で、1つは実際のデータウェアハウスにロードされます。
これのベストプラクティスは何ですか？元々は、データウェアハウスにコピーを保存し、読み込みごとにソーステーブルをクリアするのが最善だと思っていました。
ただし、その場合、既存のディメンションに戻って列を追加する必要がある場合は、依存するすべてのソーステーブルを再ロードする必要があります。さらに、あなたは歴史を失うでしょうか？
それを2度保存するのは本当に非効率的だと思います...デザイン、経験、ベストプラクティスについて考えてみたかっただけです。
個人的には、抽出、変換、永続的なデータストレージ用のステージングテーブルがあります。
フルエクスポートを行うか増分ロードを行うかは、使用しているツール、戦略、アプリスキーマとデータがそれをサポートしているかどうかによって異なります。完全なエクスポートを回避できない場合があります。
列をディメンションに追加することは大したことではありませんが、履歴データのバックフィルは非常に困難であるか、まったく不可能かもしれません。アプリが特定の時点でどのようになっていたかを遡及的に再構築しようとすることは、主要な作業になります。あなたはそれを正当化するために非常に良いケースが必要でしょう。
あなたが言及することはすべて可能ですが、コスト/利益にそれだけの価値があるかどうかを判断できるのはあなただけです。
これは、仕様に大きく依存します。このようなプロジェクトでは、ストレージスペースはそれほど高価ではありません（2万テーブルには、おそらくはるかに大きな開発予算が必要になります）。
DWHは通常、ソースシステムよりも多くの履歴を維持する必要があることに注意してください。振り返って新しいディメンション列または新しいファクトを追加する場合は、ソース間にデータボールトを構築することをお勧めします。システムとキンボールデータマート。
ドキュメント化された詳細な履歴と、データマートレイヤーの柔軟性の向上。これは、ユーザーに近い必要があるため、実行可能な限りの柔軟性が必要です。
通常、ODS（オペレーショナルデータストア、ソースシステムのコピー）は、最初にETLプロセスの階層化（メンテナンスとトラブルシューティングに役立てる）に非常に役立ちますが、最終的にはオペレーショナルレポートに非常に役立ちます。
また、インデックスを追加したり、クレイジーなクエリを作成したりできるという贅沢もあります。それに対して。
これを使用してトラブルシューティングを行うこともできます（実際のソース内の移動するターゲットではなく、ロードしたデータのコピーがあるため）。次に、レプリケーションツールを5分ごとにODSにトリクルフィードさせることができれば、非常に便利なアーキテクチャがあります。
ここで「非効率」については忘れてください。 ETLプロセスが1つのレイヤーに押しつぶされてトラブルシューティングを行うODSレイヤーがないために、ETLプロセスをトラブルシューティングできない場合、実際には非効率になります。