3

私はいくつかのアプリに取り組み、データウェアハウジングのいくつかの詳細に問題を抱えている他の開発者と話をしました。

私が見た主な問題は、運用データストアの変更データ検出（CDC）に関するものです。 更新とハード削除は、運用データストアで検出するのが難しい場合があります。

更新は、updated_at列を現在のタイムスタンプで自動的に更新するトリガーをすべてのテーブルに挿入することで処理できます。ただし、削除はより困難です。1つの解決策は、削除されたID、テーブル、およびタイムスタンプで監査テーブルを更新するトリガーを設定することです。

トリガーを使用することは、変更データの検出を行うための最も合理的な方法のようですが、私が見たもう1つのオプションは、データベーストランザクションログファイルを解析することです。ただし、運用データストアデータベースの更新が難しくなる可能性があります。

私の質問は、人々は通常この問題をどのように処理するのかということです。私はかなりの調査を行いましたが、データウェアハウジングを行っている多くの企業が、独自の次善のソリューションを展開しているようです。

CDCに関連する問題を回避するために私が見た別の解決策は、データウェアハウス全体（またはソースデータに関連する部分）を時々再構築することです。これにより、すべてのデータが最新であり、バグがないことが保証されます。運用データストアでCDCを実行するコード内。

4

3 に答える 3

2

これが、更新と削除を処理する通常の方法です。

ソース システムの更新

一部の DBMS は、すべてのテーブルに追加された場合、常に増加する一意の識別子をウェアハウスに提供する列を提供します。SQL Server には TIMESTAMP 列があります。Oracle は ora_rowscn 疑似列を提供していますが、これはブロック レベルで優れています。

私は使用していませんが、Postgres には xmin 疑似列があり、同様の方法で使用できると思います。これにはいくつかの懸念がありますが、データ ウェアハウスの変更追跡の目的では、うまくいくかもしれません。

最終変更日を更新するソース システムの UPDATE トリガーは、別のオプションです。この日付を非常に高い精度で維持して、抽出を行うときに ODS で大規模な更新を行っている何かが実行されている場合に、レコードが「欠落」するリスクを減らします。

ソース システムでの削除

削除されたレコードに関しては、すべてのソース テーブルに主キー (できれば 1 つの列、た​​だし複数も可能) があることを確認することをお勧めします。この列全体を毎日ステージテーブルに抽出し、ソースと比較してターゲットテーブルから「欠落」している行を特定し、「ソース削除」フラグまたはターゲットレコードの何かを更新します。元のトランザクションがなくなっても、ファクト テーブルには履歴が保持されている必要があるため、通常はディメンション テーブルに対してのみこれを行います。

于 2012-07-05T18:44:46.847 に答える
1

postgresqlのユーザーおよび開発者として、あなたが説明したようにトリガーを使用することは、-私見--最善の方法です。データの管理と保護という設計上の目的はデータベースに任せてください。更新日と、削除日で処理される論理削除を使用すると、トランザクションの履歴証跡を簡単に提供できます。低負荷期間を使用して「削除された」データを履歴テーブルに移動すると、運用テーブルを管理しやすくすることができます。

于 2012-07-04T14:07:16.693 に答える
0

適切に設計されたデータ ウェアハウスでは、ファクト テーブルに対して削除や更新を行うべきではなく、挿入のみを行うべきだと思います。次に、タイムスタンプまたはシーケンシャル ID を介して挿入をキャッチするのは簡単です。

于 2012-07-04T13:23:51.543 に答える