最適なSSISのデータフローの設定

Question

私は2つのvarchar（2000）列でかなり広いです350メガバイトのテーブルを持っています。 SSISデータフローを使用すると、OLEDBの「高速ロード」宛先を経由してAzure SQL DWにロードするのに60分かかります。私は（SSIS Azure feature packから）Azureブロブ先となる、そのデータフローに目的地を変更し、1.5分で完了し、同じデータ・フロー（その新しいフラットファイルからおよびポリ塩基は約2分かかります）。私は、既存の1ギガバイトのフラット・ファイルを持っている別のソースについては

。 Azure SQL DWのOLEDB宛先へのSSISデータフローは90分かかります。ファイルをblobストレージにコピーし、Polybaseのロードに5分かかります。

SSISはSSIS 2014で、Azure SQL DWと同じ地域のAzure VM上で実行されています。バルク負荷は制御ノードを通過するが、Polybaseはすべての計算ノードで並列化されるため、バルク負荷はPolybaseよりもはるかに遅いことがわかっています。しかし、これらのバルクロード数は非常に遅いです。

バルクロードを使用してAzure SQL DWステージテーブルにできるだけ高速にロードするためのSSISデータフローとデスティネーションの最適な設定は何ですか？

• ステージテーブルジオメトリ= HEAPは
• データフローの設定（私は信じて最速です）：特に私は、私は考えていないよ、他の設定に加えて、以下の設定の最適値に興味
  • DefaultBufferMaxRows =？
  • DefaultBufferSize =？
• OLEDB先の設定
  • データアクセスモード=表またはビュー - 高速負荷
  • 未確認=アイデンティティを保つヌルの=を保ちますか？
  • テーブルロック=？
  • チェック制約=？
  • 1バッチあたりの行数=？
  • 最大挿入コミットサイズ=？

Answer 1

ポリ塩基は確かにSQL DWにロードするための最速の方法です。あなたが提案したHEAPも最速の目的地タイプです。 SQL CATチームのこの記事をbest practices for loading to Clustered Columnstore using SSISでご覧ください。ここでのエンジニアリングチームからの推薦は、DefaultBufferMaxRows（デフォルトは10Kである）、DefaultBufferSize（デフォルトは10 MBです）、バッチあたりの行数、および最大挿入がコミットサイズを調整してみてくださいすることです。

私は、数年前、Parallel Data WarehouseまたはAPSアプライアンスプラットフォームシステムとも呼ばれるPDWのAzure SQLデータウェアハウスの前提バージョンに対して、SSISの広範なパフォーマンステストを行いました。そのテストでは、ローカルCPUがボトルネック、特にシングルコアであることがよくありました。これは、CPU使用率をコア別に監視すると、Perfmonを使用して明らかに確認できます。

スループットを向上させるためにできることがいくつかありました。単一のコアにCPUがバインドされている場合、複数の同時SSISパッケージを実行すると、より多くのコアを利用できるようになり、より高速に実行されます。これを行うには、ソースファイルを複数のファイルに分割し、デスティネーションを複数のテーブルにする必要があります。デスティネーションテーブルをパーティション化し、各ロードに異なるパーティションが含まれている場合は、データをロードした後にパーティション切り替えを使用して、単一のテーブルに統合することができます。

パッケージ内に複数のデータフローを作成することもできます。これにより、複数のSSISローダーを並行して実行するのと同じパフォーマンスが得られますが、ソースファイルを複数のファイルに分割する必要があります。宛先、複数のテーブルを使用してスループットを最大化します。

私が試みたもう1つのアプローチは、1つのデータフロー内に並列ローダーを持つことでした。これは1台のローダーよりも高速でしたが、上記の2つのアプローチよりも遅かったです。

また、SSISでcharをバイナリchar変換に変換すると、この処理が高速化されることがわかりました。また、ソースとしてテキストファイルを使用するよりも、SQLソースを使用する方が高速でした。

もう1つの試みはSSIS Balanced Data Distributorです。 BDDは、複数の同時SSISパッケージを実行することなく、ソースシステム上の複数のコアを使用する別の方法です。

SSISパッケージを実行するときは、perfmonを使用してCPUを監視し、単一のコアで実行されているか、複数のコアに分散しているかどうかを確認してください。あなたが単一のコアを釘付けにしているなら、それはあなたのボトルネックである可能性が最も高いです。

また、VARCHAR（2000）の列​​に関して。入ってくるデータが本当にこのサイズになると思わない場合は、VARCHARカラムのサイズを減らしてください。将来この動作を改善する予定ですが、現在のところ、データ移動サービスはVARCHARデータを固定長にパディングします。これはもちろん、最も広い値が2000文字よりはるかに小さい場合、必要以上に多くのデータが移動されていることを意味します。

こちらがお役に立てば幸いです。