SSIS 2008 内に、OLE DB ソースを使用して約 2,000,000 行を取得するデータ フロー タスクがあり、24 のルックアップ変換を 1 つずつ実行して、「コード」データをディメンション テーブルから事前に定義された同等のデータに置き換えるか、 「不明」な値。
フロー全体が各変換を実行するこの 1 つずつのプロセスは、パッケージの実行における主要なボトルネックとなっており、プロセスを高速化する方法が必要です。何か案は？
24 の異なるルックアップのそれぞれにデータ セットをマルチキャストしようとしましたが (必要な列だけが送信されるように)、それらすべてをユニオンに実行すると、すべてのタスクがさまざまなデータ型を好まないように見えます。どのように構成しても、エラーがスローされる傾向があります。私が見逃している別のオプションはありますか？
純粋な TSQL ですべてを行います。200 万行をステージング テーブルに挿入し、UPDATE ステートメントを使用して必要な値を設定します。これはほぼ確実に、行ごとのルックアップ プロセスよりもはるかに高速であり、必要に応じてステージング テーブルにインデックスを配置することもできます。
データが更新されたら、それを別のデータ フローの宛先テーブルにプッシュできます。ステージング テーブルと宛先テーブルが同じサーバー上にある場合は、 を使用INSERT ... SELECT ...してプッシュするだけです。
個人的には、TSQL で簡単に変換できる方法があれば、常に SSIS 変換を避けています。パフォーマンスは向上し、TSQL コードは SSIS パッケージよりも維持しやすいと思います。そうは言っても、SSIS はさまざまな場所からデータを取得し、そのデータをステージング データベースに配信して作業し、手順やスクリプトを実行してデータを変換するための優れた制御フロー ツールです。
ボトルネックは、あなたが思っている場所にない可能性があります。パッケージのパフォーマンスを低下させている可能性があるのは、宛先コンポーネントである可能性があります。パッケージ変換は、バッチ データが宛先に挿入されるまで待機します。これにより、黄色で表示されている変換がゆっくり実行されていると思われます。実際、私の経験上、ルックアップ変換タスクは非常に高速です。
次の例では、フラット ファイル ソースから 100 万行を読み取り、SQL Server に挿入します。ルックアップは 1 つしか使用しませんが、ここで例を示した理由は、複数の宛先コンポーネントを持つことについてのアイデアを提供するためです。さまざまな変換によって処理されたデータを受け入れる複数の宛先があると、パッケージが高速化されます。
この例が、パッケージのパフォーマンスを改善する方法についてのアイデアになることを願っています。
段階的なプロセス:
dbo.ItemInfoSQL Server データベースで、とという 2 つのテーブルを作成しますdbo.Staging。テーブル クエリの作成は、[スクリプト]セクションで利用できます。これらのテーブルの構造は、スクリーンショット # 1に示されています。ItemInfo実際のデータをStaging保持し、テーブルはステージング データを保持して、実際のレコードを比較および更新します。Idこれらの両方のテーブルの列は、自動生成された一意の ID 列です。IsProcessedテーブル ItemInfo の列を使用して、有効でなくなったレコードを識別して削除します。
SSIS パッケージを作成し、スクリーンショット # 2に示すように5 つの変数を作成します。タブ区切りファイルに拡張子を使用したため、変数FileExtensionの値を使用しました。実行時に変数に値が割り当てられます。variable は、ファイルが配置される場所を示します。および変数は、ロード前およびロード後の操作中に使用されるストアド プロシージャを示します。これらのストアド プロシージャのスクリプトは、[スクリプト]セクションで提供されます。.txt*.txtFilePathFolderLocationSQLPostLoadSQLPreLoad
SQL Server データベースを指す OLE DB 接続を作成します。スクリーンショット # 3と # 4に示すように、フラット ファイル接続を作成します。フラット ファイル接続列セクションには、列レベルの情報が含まれています。スクリーンショット # 5は、列データのプレビューを示しています。
スクリーンショット # 6に示すように、制御フロー タスクを構成します。スクリーンショット # 7～ # 10に示すように、タスクPre Loadを構成します。Pre Load はステージング テーブルを切り捨て、ItemInfo テーブルのすべての行に対してフラグを false に設定します。Post Load は変更を更新し、ファイルで見つからないデータベースの行を削除します。これらのタスクで使用されるストアド プロシージャを参照して、これらのタスクで何が行われているかを理解してください。Post LoadLoop FilesIsProcessedExecute SQL
Load Items データ フロー タスクをダブルクリックし、スクリーンショット # 11に示すように構成します。Read Fileフラット ファイル接続を使用するように構成されたフラット ファイル ソースです。Row Count派生列変換であり、その構成はスクリーンショット # 12に示されています。Check Existはルックアップ変換であり、その構成はスクリーンショット # 13～ # 15に示されています。Lookup No Match 出力Destination Splitは左側にリダイレクトされます。ルックアップ一致出力Staging Splitは左側にリダイレクトされます。スクリーンショット＃ 16に示されているのとまったく同じ構成を持っていDestination SplitますStaging Split. 宛先とステージング テーブルの両方に 9 つの異なる宛先がある理由は、パッケージのパフォーマンスを向上させるためです。
dbo.ItemInfoスクリーンショット # 17に示すように、すべての宛先タスク 0 ～ 8 はテーブルにデータを挿入するように構成されています。dbo.Stagingすべてのステージング タスク 0 ～ 8 は、スクリーンショット # 18に示すように、データを挿入するように構成されています。
フラット ファイル接続マネージャーで、スクリーンショット # 19に示すように、変数 FilePath を使用するように ConnectionString プロパティを設定します。これにより、パッケージはフォルダー内の各ファイルをループするときに、変数に設定された値を使用できるようになります。
テスト シナリオ:
Test results may vary from machine to machine.
In this scenario, file was located locally on the machine.
Files on network might perform slower.
This is provided just to give you an idea.
So, please take these results with grain of salt.
パッケージは、Xeon シングル コア CPU 2.5 GHz および 3.00 GB RAM を搭載した 64 ビット マシンで実行されました。
でフラット ファイルをロードしました1 million rows。パッケージは約2 分 47 秒で実行されました。スクリーンショット # 20と # 21を参照してください。
「テスト クエリ」セクションで提供されているクエリを使用してデータを変更し、パッケージの 2 回目の実行時に新しいレコードの更新、削除、および作成をシミュレートしました。
1 million rows次のクエリがデータベースで実行された後、を含む同じファイルをロードしました。パッケージは約1 分 35 秒で実行されました。スクリーンショット # 22と # 23を参照してください。スクリーンショット # 22で、宛先とステージング テーブルにリダイレクトされた行数に注意してください。
それが役立つことを願っています。
テスト クエリ: .
--These records will be deleted during next run
--because item ids won't match with file data.
--(111111 row(s) affected)
UPDATE dbo.ItemInfo SET ItemId = 'DEL_' + ItemId WHERE Id % 9 IN (3)
--These records will be modified to their original item type of 'General'
--because that is the data present in the file.
--(222222 row(s) affected)
UPDATE dbo.ItemInfo SET ItemType = 'Testing' + ItemId WHERE Id % 9 IN (2,6)
--These records will be reloaded into the table from the file.
--(111111 row(s) affected)
DELETE FROM dbo.ItemInfo WHERE Id % 9 IN (5,9)
フラット ファイル接続列 。
Name InputColumnWidth DataType OutputColumnWidth
---------- ---------------- --------------- -----------------
Id 8 string [DT_STR] 8
ItemId 11 string [DT_STR] 11
ItemName 21 string [DT_STR] 21
ItemType 9 string [DT_STR] 9
スクリプト: (テーブルとストアド プロシージャの両方を作成するため) .
CREATE TABLE [dbo].[ItemInfo](
[Id] [int] IDENTITY(1,1) NOT NULL,
[ItemId] [varchar](255) NOT NULL,
[ItemName] [varchar](255) NOT NULL,
[ItemType] [varchar](255) NOT NULL,
[IsProcessed] [bit] NULL,
CONSTRAINT [PK_ItemInfo] PRIMARY KEY CLUSTERED ([Id] ASC),
CONSTRAINT [UK_ItemInfo_ItemId] UNIQUE NONCLUSTERED ([ItemId] ASC)) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Staging](
[Id] [int] IDENTITY(1,1) NOT NULL,
[ItemId] [varchar](255) NOT NULL,
[ItemName] [varchar](255) NOT NULL,
[ItemType] [varchar](255) NOT NULL,
CONSTRAINT [PK_Staging] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO
CREATE PROCEDURE [dbo].[PostLoad]
AS
BEGIN
SET NOCOUNT ON;
UPDATE ITM
SET ITM.ItemName = STG.ItemName
, ITM.ItemType = STG.ItemType
, ITM.IsProcessed = 1
FROM dbo.ItemInfo ITM
INNER JOIN dbo.Staging STG
ON ITM.ItemId = STG.ItemId;
DELETE FROM dbo.ItemInfo
WHERE IsProcessed = 0;
END
GO
CREATE PROCEDURE [dbo].[PreLoad]
AS
BEGIN
SET NOCOUNT ON;
TRUNCATE TABLE dbo.Staging;
UPDATE dbo.ItemInfo
SET IsProcessed = 0;
END
GO
スクリーンショット #1:
スクリーンショット #2:
スクリーンショット #3:
スクリーンショット #4:
スクリーンショット #5:
スクリーンショット #6:
スクリーンショット #7:
スクリーンショット #8:
スクリーンショット #9:
スクリーンショット #10:
スクリーンショット #11:
スクリーンショット #12:
スクリーンショット #13:
スクリーンショット #14:
スクリーンショット #15:
スクリーンショット #16:
スクリーンショット #17:
スクリーンショット #18:
スクリーンショット #19:
スクリーンショット #20:
スクリーンショット #21:
スクリーンショット #22:
スクリーンショット #23:
