通常、SSISを介したオンプレミスのSQLサーバーETLワークフローでは、どこからでもデータをステージングテーブルにロードし、検証と変換を適用して、それらをダウンストリームのデータウェアハウステーブルにロード/マージします。
私の質問は、Azureで同様のことを行う必要があるかどうかです。AzureSQLデータベースにステージングテーブルとダウンストリームテーブルのセットがあるか、ステージングとしてazureストレージ領域を使用し、そこからADFを介して最終的なダウンストリームテーブルにデータを移動します。
ワイルドに思えるかもしれませんが、ADFを使用して移動するステージングデータベースとダウンストリームデータベースを別々にするという提案もあります。
データ移動パイプラインを実行するためのさまざまなモデルがあり、完璧なモデルはありません。アプリケーションの決定に役立つ場合に備えて、私が目にする一般的なパターンについていくつかコメントします。
データをステージングしてディメンションを作成しようとしている多くのデータウェアハウスでは、生のソースデータを生データとして他のデータベース/テーブルにロードし、挿入したい形式に処理するプロセスがよくあります。ファクトテーブルとディメンションテーブル。このプロセスは、データの到着が遅れたり、データが後日修正されたりする可能性があるため、複雑になります。そのため、これらのシステムは、ターゲットファクトテーブルのパーティションテーブルを使用して設計され、パーティションに相当するデータを再処理できるようになっています（例：1日）ファクトテーブル全体を再処理する必要はありません。さらに、データ自体がDWでの表現方法から遠く離れた形式で提供されている場合、そのステージングテーブルでの変換プロセスは集中的になる可能性があります。多くの場合、オンプレミスシステムでは、これらは、本番システムから分離するために、別のデータベース（場合によっては同じSQL Server上）で処理されます。さらに、これらのステージングテーブルが元のソースデータ（CSVファイルなど）から再作成できる場合もあるため、そのソースマテリアルのレコードの保存場所ではありません。これにより、そのデータベースで単純なリカバリモードを使用することを検討できます（これにより、完全リカバリと比較して、ログIO要件とリカバリ時間が短縮されます）。すべてのDWが処理されたDWデータに完全復旧モードを使用するわけではありませんが（パイプラインが存在するため、代わりに2台目のマシンにデュアルロードを実行するものもあります）、SQL Serverで完全復旧と物理ログレプリケーション（AlwaysOn可用性グループ）を使用する機能により、世界のさまざまな地域でデータベースのディザスタリカバリコピーを作成する柔軟性。（必要に応じて、そのサーバーでクエリ読み取りスケールアウトを実行することもできます）。この基本モデルにはさまざまなバリエーションがありますが、多くのオンプレミスシステムにはこのようなものがあります。
SQL Azureを見ると、同等のモデルをセットアップする方法を検討する際に重要ないくつかの類似点といくつかの相違点があります。
元の質問にたどり着くには、SQL Azureでデータロードパイプラインを実行できますか？はい、できます。オンプレミスでの既存の経験と比較していくつかの注意点がありますが、それは機能します。公平を期すために、ステージングテーブルを使用せずにCSVファイルなどから直接ロードする人もいます。多くの場合、それらはそれほど多くの変換を行わないため、YMMVはニーズに基づいています。
お役に立てば幸いです。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加