一般的な ETL のヒント
<オール> <リ>宛先ごとに整理することを検討してください (たとえば、Customer ディメンションを生成するすべてのコードは、ソースに関係なく同じモジュール内にあります)。これは、サブジェクト指向の ETL として知られることもあります。これにより、検索がはるかに簡単になり、コードの保守性が向上します。
<リ>
SQL2000 データベースがごちゃごちゃしている場合、SSIS のデータ フローがデータを処理する方法としては扱いにくいことがわかるでしょう。原則として、ETL ツールは複雑さに対してスケーリングが不十分です。金融会社のすべてのデータ ウェアハウス プロジェクトの半分のようなものは、ストアド プロシージャ コードを明示的なアーキテクチャ上の決定として使用しています。まさにこの理由からです。大量のコードを insprocs に配置する必要がある場合は、all を配置することを検討してください。 sprocs のコードの。
多くの複雑なスクラブまたは変換を含むシステムの場合、100% sproc アプローチは、すべての変換とビジネス ロジックを 1 か所に配置する唯一の実行可能な方法であるため、はるかに保守しやすくなります。 ETL/sproc システムが混在している場合、変換全体を追跡、トラブルシューティング、デバッグ、または変更するには、複数の場所を調べる必要があります。
ETL ツールのスイート スポットは、比較的単純な変換を行う多数のデータ ソースを持つシステムにあります。
<リ>コードをテスト可能にして、コンポーネントを分離してテストできるようにします。 ETL ツールの複雑なデータ フローの途中からしか実行できないコードは、テストがはるかに困難です。
<リ>ビジネスロジックなしでデータ抽出をダムにし、ステージング領域にコピーします。ビジネス ロジックが抽出レイヤーと変換レイヤーに分散している場合、変換を分離してテストできず、バグの追跡が困難になります。変換がステージング領域から実行されている場合は、ソース システムへの強い依存性を減らし、テスト容易性を向上させます。これは、ほぼ完全に同種のコード ベースを可能にするため、sproc ベースのアーキテクチャでは特に有利です。
<リ>一般的なゆっくりと変化するディメンション ハンドラーを構築するか、利用可能な場合は既製のものを使用します。これにより、この機能の単体テストが容易になります。これが単体テストできる場合、システム テストでは、提示されたデータが正しいかどうかだけをテストするだけで、コーナー ケースのすべてをテストする必要はありません。これは思ったほど複雑ではありません。私が最後に書いたものは、約 600 行または 700 行の T-SQL コードでした。同じことが一般的なスクラブ関数にも当てはまります。
<リ>可能であれば、段階的に読み込みます。
<リ>コードをインストルメント化します。ログ エントリを作成し、チェックの合計やカウントなどの診断を記録します。これがなければ、トラブルシューティングはほぼ不可能です。また、アサーション チェックは、このエラー処理を考える良い方法です (b の行数は等しいか、A:B の関係は実際には 1:1 ですか)。
<リ>合成鍵を使用します。ソース システムの自然キーを使用すると、システムがデータ ソースに結び付けられ、ソースを追加することが難しくなります。システム内のキーと関係は常に整列している必要があります - null はありません。 「記録されていない」エラーについては、ディメンション テーブルに特定の「エラー」または「記録されていない」エントリを作成し、それらと照合します。
<リ>オペレーショナル データ ストア (多くの宗教戦争の対象) を構築する場合は、スター スキーマの ODS キーをリサイクルしないでください。ディメンションを構築するために必ず ODS キーで結合しますが、自然キーで一致させてください。これにより、スター スキーマに影響を与えることなく、ODS を任意に削除して再作成することができます (その構造を変更する可能性があります)。この機能を持つことは、ODS 構造を変更したり、いつでも ODS のブルート フォース再デプロイを実行したりできるため、真のメンテナンス ウィンです。
ポイント 1 ～ 2 と 4 ～ 5 は、すべてのシステムを構築できることを意味します。 任意のサブシステム (単一のディメンションやファクト テーブルなど) のコードは、システム内の 1 つの場所にのみ存在します。このタイプのアーキテクチャは、多数のデータ ソースにも適しています。
ポイント 3 はポイント 2 の反対です。基本的に、SQL ツールと ETL ツールのどちらを選択するかは、変換の複雑さとソース システムの数によって決まります。データが単純で、データ ソースの数が多いほど、ツール ベースのアプローチが適しています。データが複雑になればなるほど、ストアド プロシージャに基づくアーキテクチャに移行する必要性が強くなります。一般に、両方ではなく、どちらか一方のみ、またはほぼ排他的に使用する方が適切です。
ポイント 6 により、システムのテストが容易になります。ソース データの複数のバージョンをシステムに提示できるようにする必要があるため、SCD や変更ベースの機能のテストは面倒です。変更管理機能をインフラストラクチャ コードに移動すると、テスト データ セットを使用して分離してテストできます。これは、システム テスト要件の複雑さを軽減するため、テストに有利です。
ポイント 7 は、大量のデータに対して観察する必要がある一般的なパフォーマンスのヒントです。システムの一部については、増分ロードのみが必要な場合があることに注意してください。小さい参照テーブルと寸法の場合は、必要ない場合があります。
ポイント 8 は、あらゆるヘッドレス プロセスに密接に関連しています。夜中に起きた場合は、翌日何がうまくいかなかったのかを確認するためのいくつかの戦闘チャンスが必要です.コードが何が起こっているかを適切に記録してエラーをキャッチしない場合、トラブルシューティングがはるかに困難になります。
ポイント 9 は、データ ウェアハウスに独自の命を吹き込みます。ウェアハウスに独自のキーがある場合、ソース システムを簡単に追加および削除できます。緩やかに変化するディメンションを実装するには、ウェアハウス キーも必要です。
ポイント 10 は、新しいシステムを追加したり、レコードのカーディナリティを変更したりする必要がある場合に ODS を再構築できるため、メンテナンスと展開に有利です。また、ODS キーに依存せずに、ディメンションを ODS の複数の場所からロードできることも意味します (たとえば、手動の会計調整を追加することを考えてください)。