データウェアハウスの設計中にステージングデータベースを使用する利点
現在、データウェアハウスアーキテクチャを設計しています。本番環境からデータを抽出してデータウェアハウスに配置するためのさまざまなオプションを検討しているときに、主に次の2つのアプローチを提案する多くの記事に出くわしました-
- 本番DB ---->データウェアハウス（スタースキーマ）----> OLAPキューブ
- 本番DB ----> Staging Database ----> Data Warehouse（Star Schema）----> OLAP Cube
パフォーマンスと運用データベースの処理負荷の削減の観点から、どちらがより良いアプローチかはまだわかりません。
データウェアハウスを設計するときに、どちらのアプローチが適切かを検討してください。
以下のポイントは、 DWBI Organization's の記事から引用しています。
次のいずれかのシナリオがある場合は、ステージング領域が必要になることがあります。
- Delta Loading：データはソースから増分的に読み取られ、変換の目的でデータの増分セットを一時的に保存できる中間ストレージが必要です
- 変換の必要性：ウェアハウスでデータを使用する前に、データのクレンジング、検証などを実行する必要があります
- デカップリング：処理に時間がかかり、ソースシステムへの接続を維持したくない場合（おそらく、ソースシステムが常に使用されています）実際のビジネスユーザー）処理の全期間中、したがって、ソースシステムからデータを1回で読み取り、ソースから切断して、「自分の側」でデータの処理を続行することを好む
- デバッグの目的：常にソースに戻る必要はなく、ステージング領域のみから問題がある場合はそれをトラブルシューティングできます
- 障害回復：ソースシステムが一時的で、データの状態が変化している可能性があります。アップストリーム障害が発生した場合、その時点までにソースが変更されているため、データを再抽出する立場にない可能性があります。ローカルコピーがあると役立ちます
パフォーマンスと処理の減少だけが考慮事項ではありません。ステージングを追加すると、latencyが増加する場合があります（つまり、ビジネスインシデントの発生とその報告の間の時間遅延）。しかし、私は上記の点があなたがより良い判断をするのに役立つことを願っています。
ETL = Extract、Transform、およびLoad。変換ビットを使用したステージングデータベースのヘルプ。個人的には、常にステージングDBとETLステップを含めます。
ステージングデータベースは、ソースデータをデータウェアハウスのFACTおよびDIMENSIONの宛先と同等の構造にするのに役立ちます。また、ウェアハウスとウェアハウスETLプロセスをソースデータから分離します。
データウェアハウスの宛先テーブルが、いくつかの追加のディメンションフィールドのみを使用して実稼働DBテーブルをほぼマップしている場合、ステージングデータベースを無視してできます。これにより、開発時間を少し節約できます。あなたとしてこれをお勧めしません：
- データウェアハウスソリューションをソースデータベースに直接結びつけることになります
- ほとんどの場合、非常に複雑なETLステップが発生します
- ETLプロセス中のソースデータベースの変更が原因で、競合状態/孤立レコードが発生する可能性があります
- データウェアハウスの人々が「フラム」タイプの音を発することがある
おそらく、何らかのデータ操作（日付をDATE_DIMキーに変換し、値を集計する）を実行することになりますが、その場合、ステージングDBは、変換ロジックと計算をデータウェアハウスの操作（データのディメンション化）から分離するのに役立ちます。
この種のパターンにも遭遇した可能性があります。
[PROD DB] -(ETL)-> [RAW DB] -(ETL)-> [STAGING DB] -(ETL)-> [DW DB] -(ETL)-> [DM DB]
パフォーマンスの考慮事項が重要な場合は、確認する必要があります。あなたの場合、RAW_DBは本番データベースの正確な1：1コピーであり、それを作成するETLステップは、最新の夜間バックアップからDBを再作成するだけの場合があります。 （従来、RAW_DBは、各フィールドを純粋なテキストとしてさまざまな外部ソースからデータを取得するために使用されていました。これらのフィールドは、予期されるデータ型に変換され、例外が発生したときに処理されます。これは、1つのソースとそのニースの強く型付けされた正規化データベース）
このRAW_DBから、次のETLプロセスは、ステージングを切り捨てて、ステージングにデータを入力します。これにより、STAGING DBには、ウェアハウスに送られるすべての新規/更新済みレコードが含まれます。
これらすべてのステップのもう1つの追加の利点は、特定の実行について、各差分データベース内のレコード値を確認し、どのETLプロセスが悲しみをもたらしているかを特定できるため、奇妙なデータのデバッグに本当に役立つことです。
中間のステージングデータベースを使用することには、いくつかの潜在的な利点があります。すべてのソリューションに対応できる完璧なサイズはありません。潜在的な利点には次のものがあります。
- 適切な場合は、運用データベースのスナップショットを作成し（毎日のバックアップまたはホットサイトのスナップショットが既にある場合があります）、復元したバックアップまたはスナップショットからETLを実行できます。これにより、運用データベースの負荷を節約できます。
- ETLプロセス以外には役に立たない多くの中間テーブルを必要とするETLの複雑な処理が必要になる場合があります。これらの中間テーブルでデータウェアハウスを混乱させたくない場合があります。
- 生データは一度に利用できない場合があり、データウェアハウスを構築するETLプロセスを開始する前に、どこかにそれを蓄積する必要があります。
- データウェアハウスには、ETLでは満たすことができないプロダクションウィンドウの要件がある可能性があるため、本番データベースではなく、または本番データベースに加えて、「出力」（つまり、データウェアハウスの新しいレコード）をステージングする必要があります。
- 本番システムは高度にセキュリティ保護された環境にある可能性があり、何らかの理由で、ETLプロセスが未加工の本番データに完全にアクセスできないように決定されている可能性があります。本番データベースを制御するグループは、必要なデータのみをステージングデータベースに抽出して、ETLプロセスが必要なものだけを確認できるようにする場合があります。これは、本番システムとETLプロセスがさまざまなサードパーティベンダーによって管理されているところです。
- ETLプロセスが大きな中間テーブルを作成する可能性があります。 ETLステージング領域の空のモデルデータベースから始めて、運用データベースやレポートデータベースのようにスペースをより外科的な方法で回復しようとするよりも、毎日「捨てる」ほうが、スペース管理が簡単になる場合があります。 。
あなたにとって重要かもしれないし、重要ではないかもしれない不利な点もあります。これらの主なものは、別のデータベースサーバーを持っている必要があります。同じサーバーを使用して本番データベースやデータウェアハウスデータベースをホストしている場合、多くの利点が無意味になる可能性があります。
ステージングエリアは、その場で処理できれば必要ありません。しかし、私たちはできますか？ステージングエリアを回避できない理由はいくつかあります。1.ソースシステムは、通常、データの読み込み時間全体よりも短い特定のタイムスロットでのみ抽出できます。ソースシステムへの接続が失われる前に、物事を抽出して保持することをお勧めします。 2. 2つ以上の異なるシステムを結合する必要があるいくつかの条件に基づいてデータを抽出したい。例えば。他のシステムにも存在する顧客のみを抽出したい場合。 2つの物理的に異なるデータベースの2つのテーブルを結合するSQLクエリを実行することはできません。 3.さまざまなソースシステムでは、データ抽出に割り当てられたタイミングが異なります。 4.データウェアハウスのデータ読み込み頻度がソースシステムの更新頻度と一致しない5.同じソースシステムのセットから抽出されたデータが複数の場所（データウェアハウス読み込み、ODSロード、サードパーティアプリケーションなど）で使用される。）6. ETLプロセスには、データを一時的にステージングするために追加のスペースを必要とする複雑なデータ変換が含まれます。
明らかにステージング領域は、データのロード中に多くの柔軟性を提供します。それなら、別のステージングエリアを常に持つ必要はありませんか？ステージエリアを設けることによる影響はありますか？はい、いくつかあります。 1.ステージング領域はレイテンシを増加させます。これは、ソースシステムの変更がデータウェアハウスで有効になるために必要な時間です。多くのリアルタイム/ほぼリアルタイムのアプリケーションでは、ステージング領域はかなり避けられます。ステージング領域のデータは余分なスペースを占有します。2。実際には、ステージング領域があることの利点は、問題よりも重要です。したがって、一般的には、データウェアハウジングプロジェクトで特定のステージング領域を指定することをお勧めします。