web-dev-qa-db-ja.com

ETL：200テーブルからの抽出-SSISデータフローまたはカスタムT-SQL？

私の分析に基づいて、データウェアハウスの完全な次元モデルでは、200を超えるソーステーブルからの抽出が必要になります。これらのテーブルの一部は、増分ロードの一部として抽出され、他のテーブルはフルロードになります。

注目に値するのは、約225のソースデータベースがすべて同じスキーマであるということです。

私が見てきたことから、SSISでOLE DB sourceおよびOLE DB destinationを使用して単純なデータフローを構築するには、列とデータ型を決定する必要があります設計時です。つまり、最終的には抽出だけで200を超えるデータフローが発生することになります。

保守性の観点からすると、これは私にとって大きな問題です。抽出コードにある種の抜本的な変更を加える必要がある場合、200の異なるデータフローを変更する必要があります。

別のオプションとして、一連のメタデータテーブルから抽出するソースデータベース、テーブル名、列を読み取る小さなスクリプトを書きました。コードは複数のループで実行され、動的SQLを使用して、リンクサーバーとOPENQUERYを介してソーステーブルから抽出します。

私のテストに基づいて、これはまだOLEDBの送信元と宛先でSSISデータフローを使用するほど高速ではありません。だから私はどのような選択肢があるのか​​と思っています。これまでの考えは次のとおりです。

  1. [〜＃〜] ezapi [〜＃〜] を使用して、単純なデータフローでプログラムによってSSISパッケージを生成します。抽出するテーブルと列は、前述の同じメタデータテーブルから取得されます。
  2. サードパーティソフトウェアを購入する（動的データフローコンポーネント）

これに取り組む最善の方法は何ですか？ .NETプログラミングに関しては、私は初心者なので、基本だけで立ち上がるのに必要な時間も問題です。

sql-serversql-server-2005ssisdata-warehouseetl
12
8kb

1つのパッケージに200のデータフローを含める必要はありません。オープンして検証するだけの時間は、あなたの時間の前にあなたを古くするでしょう。

EzAPIは楽しいですが、.NETとに慣れていない場合は、SSISが必要です。実際に作業を行うよりも、SSISオブジェクトモデルについて学習し、おそらくCOMを処理することに多くの時間を費やすことになると思います。

私は怠惰なので、BIMLをあなたがリストしなかった無料のオプションとしてプラグインします。 SO= https://stackoverflow.com/questions/13809491/generating-several-similar-ssis-packages-file-data-source-to-db/の回答から13809604＃13809604

  • Biml は面白い獣です。バリジェンスはミストのライセンスを喜んで販売しますが、それは必要ありません。必要なのは BIDSHelper で、次に BimlScript を参照して、ニーズに近いレシピを探します。それができたら、BIDSHelperとwhooshの状況依存メニューボタンをクリックすると、パッケージが生成されます。

それもあなたのためのアプローチかもしれません。パッケージの動作を記述するBIMLを定義してから、パッケージを生成します。変更を加える場所を説明し、N個のパッケージを修正する必要があるシナリオでは、いいえ、問題の定義を修正してパッケージを再生成します。

または、フレームワークに十分に精通している場合は、EzAPIなどを使用して、壊れたものをすべて修正します。これを2005とタグ付けしたので、既存のパッケージに大量の変更を加える必要がある場合は PacMan を試すこともできます。

SSISの設計に関する考慮事項

一般的に言って、私はパッケージが単一のタスク（販売データの読み込み）の解決に焦点を合わせるようにしています。 2つのデータフローが必要な場合は、それも必要です。継承が嫌いなのは、インポートエクスポートウィザードのパッケージであり、関連のない多くのデータフローが1つのパッケージに含まれています。それらを非常に特定の問題を解決するものに分解します。表面積が減少するため、将来の拡張のリスクが軽減されます。追加の利点は、私のミニオンがDimProductsパッケージのロードを処理している間、SnowflakeFromHellのロードに取り組むことができることです。

次に、マスターパッケージを使用して、子ワークフローを調整します。私はあなたが2005年にいることを知っていますが、SQL Server 2012のSSISのリリースは猫のパジャマです。プロジェクト展開モデルと、パッケージ間での緊密な統合が大好きです。

TSQL vs SSIS（私の話）

純粋なTSQLアプローチに関しては、以前のジョブでは、73ステップのジョブを使用して、すべてのInformixデータをSQL Serverに複製しました。通常、約9時間かかりましたが、12時間程度まで伸びることがあります。新しいSANを購入してから約7時間以上かかりました。同じ論理プロセスは、SSISで書き直され、一貫して2時間未満でした。その時間を短縮する最大の要因は、SSISを使用して得た "無料の"並列化でした。エージェントジョブは、これらのすべてのタスクを順次実行しました。マスターパッケージは基本的にテーブルを処理ユニット（「レプリケートテーブル1の実行」、テーブル2などの直列化されたタスクの5つの並列セット）に分割し、バケットをほぼ等しいサイズの作業ユニットに分割しようとしました。これにより、60個程度のルックアップ参照テーブルにすばやくデータが入力され、「実際の」テーブルに入るときに処理が遅くなっていました。

SSISを使用する私にとってのその他の利点は、「無料」の構成、ロギング、および丸穴に打ち込む必要のある正方形データ用の.NETライブラリーへのアクセスが得られることです。獣のグラフィカルな性質のおかげで、純粋なTSQLアプローチよりもSSISパッケージの保守（パスオフ保守）の方が簡単であると思います。

いつものように、あなたの走行距離は異なる場合があります。

12
billinkc

200個のソーステーブルと225個のデータベースがあるとおっしゃっていました。 200のソーステーブルは、225のデータベースすべてからのすべてのテーブルの数であると想定しています（各データベースに200のテーブルがあり、合計テーブル数が45000になるため）。また、データベースのスキーマは225のデータベースでも同じであると述べました。

最初に1つのデータベースのみのSSISパッケージを構築し、ジョブをスケジュールするときに、パッケージ構成を使用してデータベース接続文字列を変更するだけです（SQL 2005の場合、パッケージ配置モデルを使用します）。以前の応答で述べたように、SQL 2012には、プロジェクト配置モデルを使用してパラメーターを構成する新しい方法があります。

SSISを使用したパッケージ構成の詳細については、こちらをご覧ください http://www.sql-server-performance.com/2007/package-configuration-2005/

ここからプロジェクトパラメータの使用に関する詳細情報を取得できます https://stackoverflow.com/questions/15206184/how-to-configure-ssis-2012-project-to-run-under-different-environment-構成

0
Harb