1

ヨーロッパとアジアにあるさまざまなデータ サーバーからデータを収集したいと考えています。海底ネットワークを詰まらせる単純なデータ クエリ タスクを実行するのではなく、ローカル サイトで使用できる 2 台のマシンを考えています。

次のことができるように、マスター パッケージを設計することを考えています。

  1. リモート セットアップ タスクを実行する
  2. psexec dtexec ... を使用してローカルでデータ コレクション パッケージを起動します。
  3. 複数の生ファイルにローカルに保存されているデータを取得します (データの種類ごとに 1 つ)
  4. ジッパーを閉めて引き戻した
  5. 解凍してローカルサーバーに一括アップロード

データは奇妙なクラス ライブラリを介して利用できるため、データ収集はカスタム スクリプト ソースを介して処理されます。

タスクは予期せず失敗する可能性があります。特定の場所で特定の種類のデータが正常にキャプチャされ、他のデータが失敗した場合、それを再度実行したくありません。

可能であれば、この設計を簡素化し、より堅牢にするにはどうすればよいですか?

4

2 に答える 2

1

低速または高価な WAN リンクを介した抽出

あなたの説明は適切だと思います。低速または高価な WAN リンクの場合、データ転送の量を減らす必要があります。これに対するいくつかのアプローチは次のとおりです。

  • データ キャプチャを変更しました。
  • 圧縮。

ソースで新しいトランザクションまたは変更されたデータを簡単に識別できる場合は、変更のみを送信することでデータ量を減らすことができます。ソースにリソースがあるが、変更されたデータを簡単に識別できない場合は、次のようなことができます (必要に応じて、このための汎用フレームワークを構築します)。

  • ソースから抜粋
  • 誕生日が添付される可能性が低いアルゴリズムを使用してハッシュ値を計算します (MD5、SHA-1 など)。
  • 形式のハッシュ値を持つデータベースまたはファイルを維持します (ソース システム キー、すべての非キー属性のハッシュ値)
  • 一致しないハッシュ値を持つものをすべてまとめて、WAN リンク経由で送信します。
  • ハッシュのデータベースを更新します。

堅牢な分散抽出

このような分散システムには多くの障害モードがあるため、これにはかなり堅牢なエラー処理メカニズムを実装する必要があります。障害モードの例は次のとおりです。

  • ソース システムまたはネットワーク接続の 1 つが、おそらくスケジュールに基づいてダウンします。
  • データ パッケージの 1 つが到着が遅れています
  • 何らかの理由でデータが破損しています。
  • 一時的な負荷やその他の問題によってタイムアウトが発生するため、転送をチャンクする必要があります。

倉庫システムの要件によっては、個々のフィードの障害を許容する必要がある場合があります。これには、堅牢なエラー処理戦略を設計する必要があります。

Merge-on-Extract と Merge-on-Transform の比較

システムが同一の場合 (小売店チェーンの POS システムなど)、変換フェーズの前にデータをマージすることで、おそらくより単純なアーキテクチャが得られます。これは、少なくとも監査目的で、ステージング領域がデータ ソースを認識している必要があることを意味します。

少数のシステムまたは複数の異種ソースがある場合、変換プロセス中にデータ マージを行う必要があります。この状況では、ETL には、少なくとも一部のプロセスについて、ソース システムごとに個別のルーチンが含まれている可能性があります。

ODS は必要ですか？

データ ウェアハウジングにおける大きな宗教戦争の 1 つは、ODS を持つべきかどうかです。私は ODS 構造の有無にかかわらずシステムを作成しましたが、個々のケースでは設計上の決定に理由がありました。これに対する私の見解は、この決定のどちらの側にも普遍的な説得力のある議論がないということです.これは、そもそも宗教戦争が存在する通常の理由です.

50,000 フィートのビューに対する私の見解は、ソース システムが多く、データが均一であるほど、ODS の主張が強くなるということです。これについて、ガートナー スタイルの象限を描くことができます。

High+--------------------------+--------------------------+
    |                          |                          |
    | Kimball Model (low/high) | Enterprise Data Warehouse|
H   | Unified ODS model hard   |        (high/high)       |
e   | to meaningfully design.  | ODS both difficult and   |
t   | Flat star schemas easier | probably necessary to    |
e   | to fit disparate         | make a manageable system |
r   | data into.               | Better to separate trans-|
g   |                          | formation ahd history.   |
e   +--------------------------+--------------------------+
n   |                          |                          |
e   |                          |  Consolidated Reporting  |
a   |   Data Mart (low/low)    |       (high/low)         |
i   |                          |  ODS easy to implement   |
t   |   ODS probably of        |  and will simplify the   |
y   |   little benefit         |  overall system          |
    |                          |  architecture            |
    |                          |                          |
Low +--------------------------+--------------------------+
Low                  Number of data sources            High
于 2008-12-13T12:07:30.753 に答える
0

おそらく、すべての場所でそれを行うマスター パッケージを作成することは避けるでしょう。代わりに、1 つの場所に対してこれらの手順を実行する構成可能なパッケージを作成します (場所固有のプロパティを指定する SSIS 変数を使用)。

このパッケージを .cmd スクリプトから実行するか、必要に応じて複数のプロセス実行タスクを含むマスター SSIS パッケージを作成し、それぞれが適切な変数値で最初のパッケージを開始できるようになりました。

PS はい、マスター パッケージでは、パッケージ実行タスクではなく、DTEXEC を開始するプロセス実行タスクを使用する必要があります。残念ながら、パッケージ実行はあまり構成可能ではありません。フィードバック ID=295885。

于 2008-12-13T08:58:30.557 に答える