5

ソースが大きくて設計が不適切なsql2kデータベースであり、より適切に設計されたsql2k5データベースであるETLを実行することになっています。私はSSISが進むべき道だと思います。誰かがやることリストやチェックリスト、または私が何かを忘れないように注意すべきことを提案できますか？後で後ろに噛まれないように、これにどのようにアプローチすればよいですか。

4

5 に答える 5

29

一般的な ETL のヒント

  1. 送信先ごとに整理することを検討してください (たとえば、ソースに関係なく、Customer ディメンションを生成するすべてのコードが同じモジュール内にあります)。これは、サブジェクト指向 ETL と呼ばれることもあります。これにより、検索がはるかに簡単になり、コードの保守性が向上します。

  2. SQL2000 データベースがごちゃごちゃしている場合、SSIS データ フローがデータを処理する方法として扱いにくいことに気付くでしょう。原則として、ETL ツールは複雑になるほど拡張性が低くなります。金融会社のすべてのデータ ウェアハウス プロジェクトの約半分は、明示的なアーキテクチャ上の決定としてストアド プロシージャ コードを使用して行われています。まさにこの理由からです。大量のコードを sproc に配置する必要がある場合は、すべてのコードを sproc に配置することを検討してください。

    多くの複雑なスクラブまたは変換を含むシステムの場合、100% sproc アプローチは、すべての変換とビジネス ロジックを 1 か所に配置する唯一の実行可能な方法であるため、はるかに保守しやすくなります。ETL と sproc が混在するシステムでは、複数の場所を調べて、変換全体を追跡、トラブルシューティング、デバッグ、または変更する必要があります。

  3. ETL ツールのスイート スポットは、比較的単純な変換を行う多数のデータ ソースがあるシステムにあります。

  4. コードをテスト可能にして、コンポーネントを分離して個別にテストできるようにします。ETL ツールの複雑なデータ フローの途中からしか実行できないコードは、テストがはるかに困難です。

  5. ビジネス ロジックのないデータ抽出をダムにし、ステージング領域にコピーします。抽出レイヤーと変換レイヤーにビジネス ロジックが分散している場合、分離してテストできない変換が発生し、バグの追跡が困難になります。変換がステージング領域から実行されている場合は、ソース システムへの強い依存性を減らし、テスト容易性をさらに高めます。これは、ほぼ完全に同種のコード ベースを可能にするため、sproc ベースのアーキテクチャでは特に有利です。

  6. 汎用の緩やかに変化するディメンション ハンドラーを構築するか、利用可能な場合は既製のハンドラーを使用します。これにより、この機能の単体テストが容易になります。これが単体テストできる場合、システム テストでは、提示されたデータが正しいかどうかだけをテストするだけで、コーナー ケースのすべてをテストする必要はありません。これは思ったほど複雑ではありません。私が最後に書いたものは、約 600 行または 700 行の T-SQL コードでした。同じことが、一般的なスクラブ関数にも当てはまります。

  7. 可能であれば、段階的に読み込みます。

  8. コードをインストルメント化します。ログ エントリを作成し、チェックの合計やカウントなどの診断を記録します。これがなければ、トラブルシューティングはほぼ不可能です。また、アサーション チェックは、このためのエラー処理を考える良い方法です (b の行数が等しい場合、A:B の関係は実際には 1:1 です)。

  9. 合成鍵を使用します。ソース システムの自然キーを使用すると、システムがデータ ソースに結び付けられ、ソースを追加することが難しくなります。システム内のキーと関係は常に整列している必要があります - null はありません。「記録されていない」エラーについては、ディメンション テーブルに特定の「エラー」または「記録されていない」エントリを作成し、それらと照合します。

  10. オペレーショナル データ ストア (多くの宗教戦争の対象) を構築する場合は、スター スキーマの ODS キーをリサイクルしないでください。ディメンションを構築するために必ず ODS キーで結合しますが、自然キーで一致させてください。これにより、スター スキーマに影響を与えることなく、ODS を任意に削除して再作成することができます (その構造を変更する可能性があります)。この機能を持つことは、ODS 構造を変更したり、任意の時点で ODS のブルート フォース再デプロイを実行したりできるため、真のメンテナンス ウィンです。

ポイント 1 ～ 2 および 4 ～ 5 は、特定のサブシステム (単一のディメンションまたはファクト テーブルなど) のすべてのコードがシステム内の 1 つの場所に存在するシステムを構築できることを意味します。このタイプのアーキテクチャは、多数のデータ ソースにも適しています。

ポイント 3 はポイント 2 の反対です。基本的に、SQL ツールと ETL ツールのどちらを選択するかは、変換の複雑さとソース システムの数によって決まります。データが単純で、データ ソースの数が多いほど、ツール ベースのアプローチが適しています。データが複雑になればなるほど、ストアド プロシージャに基づくアーキテクチャに移行する必要性が強くなります。一般に、両方ではなく、どちらか一方を排他的またはほぼ排他的に使用することをお勧めします。

ポイント 6 により、システムのテストが容易になります。ソース データの複数のバージョンをシステムに提示できるようにする必要があるため、SCD や変更ベースの機能のテストは面倒です。変更管理機能をインフラストラクチャ コードに移動すると、テスト データ セットを使用して分離してテストできます。これは、システム テスト要件の複雑さを軽減するため、テストに有利です。

ポイント 7 は、大量のデータに対して観察する必要がある一般的なパフォーマンスのヒントです。システムの一部については、増分ロードのみが必要な場合があることに注意してください。小さい参照テーブルと寸法の場合は、必要ない場合があります。

ポイント 8 は、あらゆるヘッドレス プロセスに密接に関連しています。夜中に起きた場合は、翌日何がうまくいかなかったのかを確認するためのいくつかの戦闘チャンスが必要です. コードが何が起こっているかを適切に記録してエラーをキャッチしない場合、トラブルシューティングが非常に困難になります。

ポイント 9 は、データ ウェアハウスに独自の命を吹き込みます。ウェアハウスに独自のキーがある場合、ソース システムを簡単に追加および削除できます。緩やかに変化するディメンションを実装するには、ウェアハウス キーも必要です。

ポイント 10 は、新しいシステムを追加したり、レコードのカーディナリティを変更したりする必要がある場合に ODS を再構築できるため、メンテナンスと展開に有利です。また、ODS キーに依存せずに、ディメンションを ODS の複数の場所からロードできることも意味します (たとえば、手動の会計調整を追加することを考えてください)。

于 2009-01-13T19:33:38.267 に答える
5

私は、毎日、毎週、毎月、毎年、200 以上の分散データベースから中央データベースにデータをプルする ETL プロセスの経験があります。それは膨大な量のデータであり、私たちの状況に特有の多くの問題があります。しかし、私が見ているように、状況に関係なく考慮すべき項目がいくつかあります。

  • ソース側と宛先側の両方で、ファイル ロックを考慮してください。他のプロセスがファイルをロックしていないことを確認する (必要に応じてそれらのロックを削除することは理にかなっています) ことが重要です。

  • ファイルを自分でロックします。特にソースでは、途中で更新されたデータを取得しないように、データを引き出すときにファイルをロックするようにしてください。

  • 可能であれば、すべてのデータではなくデルタをプルします。データのコピーを取得し、すべてではなく変更された行のみをプルします。データセットが大きいほど、これは重要になります。必要に応じてジャーナルとトリガーを調べてください。ただし、特定の基準に基づいてこのデータを取得することがより重要になるため、これがおそらく私があなたに与える一番のアドバイスです。プロジェクトにかなりの時間が追加されたとしても。

  • 実行ログ。いつ機能し、いつ機能しなかったかを確認してください。プロセスで特定のエラーをスローすると、デバッグに非常に役立ちます。

  • 書類、書類、書類。これを正しく構築すると、それを構築し、その後長い間考えなくなります。しかし、保証することができます。あなたまたは他の誰かが、それを強化したり、バグを修正したりするために、ある時点で戻ってくる必要があります. このような状況では、ドキュメントが重要です。

HTH、他に何か思いついたら更新しません。

于 2009-01-13T19:33:33.413 に答える
4

さて、私は私がいる会社のETLを開発しています。

私たちはSSISを使用しています。API を使用して、独自の dtsx パッケージを生成およびビルドします。

SSIS は、エラーの管理には向いていません。コンテキストに応じてさまざまな意味を持つ「OleDb エラー」が発生することがあります。

API ドキュメンテーションを読んでください (多くは語られていません)。

そこから始めるのに役立ついくつかのリンク: http://technet.microsoft.com/de-de/library/ms135932(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms345167.aspx

http://msdn.microsoft.com/en-us/library/ms403356.aspx

http://www.codeproject.com/KB/database/SSISProgramming.aspx?display=PrintAll&fid=382208&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26&select=2551674

http://www.codeproject.com/KB/database/foreachadossis.aspx

http://wiki.sqlis.com/default.aspx/SQLISWiki/ComponentErrorCodes.html

http://www.new.facebook.com/inbox/readmessage.php?t=1041904880323#/home.php?ref=logo

http://technet.microsoft.com/en-us/library/ms187670.aspx

http://msdn.microsoft.com/ja-jp/library/microsoft.sqlserver.dts.runtime.foreachloop.foreachenumerator.aspx

http://www.sqlis.com/post/Handling-different-row-types-in-the-same-file.aspx

http://technet.microsoft.com/en-us/library/ms135967(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms137709(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms345164(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms141232.aspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/ssisperf.mspx

http://www.ivolva.com/ssis_code_generator.html

http://www.ivolva.com/ssis_wizards.html

http://www.codeplex.com/MSFTISProdSamples

http://www.experts-exchange.com/Microsoft/Development/MS-SQL-Server/SSIS/Q_23972361.html

http://forums.microsoft.com/MSDN/MigratedForum.aspx?siteid=1&PostID=1404157

http://msdn.microsoft.com/en-us/library/aa719592(VS.71).aspx

http://forums.microsoft.com/MSDN/MigratedForum.aspx?siteid=1&ForumID=80

http://blogs.conchango.com/jamiethomson/archive/2005/06/11/SSIS_3A00_-Custom-Logging-Using-Event-Handlers.aspx

http://blogs.conchango.com/jamiethomson/archive/2007/03/13/SSIS_3A00_-Property-Paths-syntax.aspx

http://search.live.com/results.aspx?q=%s&go=Buscar&form=QBJK&q1=macro%3Ajamiet.ssis

http://toddmcdermid.blogspot.com/2008/09/using-performupgrade.html?showComment=1224715020000

http://msdn.microsoft.com/en-us/library/ms136082.aspx

http://support.microsoft.com/kb/839279/en-us

「スパム」で申し訳ありませんが、それらは私にとって非常に便利です。

于 2009-01-13T19:34:32.883 に答える
3

私たちは大規模なETL (レガシー AS400 アプリから Oracle EBS へのクライアントの移動) を行っており、実際に (変更を加えた) お勧めできるプロセスがあります。

  1. 重要なターゲット テーブル/フィールドを特定します。
  2. 重要なソース テーブル/フィールドを特定します。
  3. ビジネス ユーザーと協力して、ソースをターゲットにマッピングします。
  4. 品質の問題についてソース データを分析します。
  5. 特定されたデータ品質の問題の責任者を決定します。
  6. 責任者にソース内のデータをクリーンアップしてもらいます。
  7. ステップ 1 から 3 の情報に基づいて、実際の ETL を作成します。

私の経験では、最もトリッキーなステップは 2 と 3 です。ビジネス ユーザーが 1 回のパスで必要なすべてのビットを正しく識別できるようにするのは難しい場合があり、データがどこから来ているのかを正確に識別するのはさらに難しい場合があります (ただし、私が見ている不可解なファイル名とフィールド名に関係があります!)。ただし、このプロセスは、大きなミスを回避するのに役立ちます。

于 2009-01-13T19:30:18.337 に答える