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

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

注目に値するのは、すべて同じスキーマを持つ約225のソースデータベースです。

私が見てきたことから、OLE DBソースとOLE DB宛先を使用してSSISで単純なデータフローを構築するには、設計時に列とデータ型を決定する必要があります。つまり、最終的には抽出だけのために200以上のデータフローが発生することになります。

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

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

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

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

これにアプローチする最良の方法は何ですか？.NETプログラミングに関しては、私は初心者なので、基本だけで立ち上がるのに必要な時間も心配です。

単一のパッケージに200個のデータフローを持ちたくありません。開いて検証するのにかかる時間は、あなたの時間の前にあなたを古くするでしょう。

EzAPIは楽しいものですが、.NET と SSISを初めて使用する場合は、まったく必要ありません。実際に作業を完了するよりも、SSISオブジェクトモデルについて学習し、おそらくCOMを扱うことにはるかに多くの時間を費やすと思います。

私は怠け者なので、BIMLをリストにない無料のオプションとしてプラグインします。SOの回答から/programming/13809491/generated-several-similar-ssis-packages-file-data-source-to-db/13809604#13809604

• Bimlは興味深い獣です。VarigenceはMistにライセンスを販売しますが、必要ではありません。あなたが必要になりますすべてがあるBIDSHelper、その後を閲覧BimlScriptニーズに近似レシピのためのルック。それができたら、BIDSHelperとwhooshのコンテキストメニューボタンをクリックすると、パッケージが生成されます。

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

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

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

一般的に、私はパッケージを単一のタスクの解決に集中させようとしています（販売データの読み込み）。2つのデータフローが必要な場合は、そうします。継承が嫌いなのは、インポートエクスポートウィザードのパッケージであり、単一のパッケージに多くの無関係なデータフローが含まれていることです。それらを非常に具体的な問題を解決するものに分解します。表面積が減少するため、将来の機能強化のリスクが低くなります。追加の利点は、ロードに取り組むことができることです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パッケージを維持する（メンテナンスを渡す）方が簡単だと思います。

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

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-configuratから入手でき ます。