SSIS はクラウドデータウェアハウスの境界で力尽きていませんか？

SSIS は、データソースとデータウェアハウスの双方が SQL Server であり、往々にして同一データセンター内に存在していた時代の産物です。その前提においては非常に優れたツールでした。しかし、ウェアハウスが Microsoft Fabric、Snowflake、Databricks、Google BigQuery などのモダンなクラウド環境へと移行した瞬間、既存パッケージの追従が極めて困難になります。

SSIS がプラットフォームの境界で力尽きる理由

• 両端が SQL Server であることを前提とした設計： 非マイクロソフト系のシステムを対象にするには、独自ライセンスとバージョン管理を伴うサードパーティ製コネクタの追加導入が避けられません。
• データ変換が中間 ETL サーバー上で実行される： データはネットワークを経由して SSIS サーバーに運ばれ、そこのデータフローバッファメモリを通過し、再びネットワークを越えてウェアハウスへ書き込まれます。サーバーのメモリと CPU コアがボトルネックとなり、2 重のデータ転送コストが毎回発生します。
• ETL サーバー専用のライセンス費用： SSIS は SQL Server に付随するため、パッケージを実行するだけの中間サーバーに対しても SQL Server ライセンスが必要です。
• クラウドへの移行が「単なるリフト」に終わる： Azure-SSIS Integration Runtime は、過去のパッケージをそのままの形で Azure 上で稼働させます。オンプレミスで抱えていたすべての技術的負債が、そのままクラウド上へと引き継がれてしまいます。

これは SSIS 自体の不具合ではありません。単一プラットフォーム向けに設計され、その使命を全うしたツールだからこその限界です。

ロード処理が本来属するべき場所

• ターゲットデータベースエンジン内部： Fabric、Snowflake、Databricks、BigQuery は強力なセットベースエンジンです。自動生成された差分ロードは、中間サーバーを介さずに、ウェアハウス自身のコンピュート上で直接高速に実行されるべきです。
• プラットフォームに依存しないデータモデル： データウェアハウスの構造をモデルとして 1 度だけ宣言し、現在利用しているデータベース向けにも、将来移行するクラウド向けにも、それぞれ最適なネイティブコードを自動生成させます。
• 過去のパッケージを持ち越さない移行： クラウド移行は、手作業で作られた何百ものレガシーロードの保守を終わらせる絶好の契機であり、古いパッケージの置き場所をクラウドへ変えるための作業ではありません。

Datavault Builder による変革

Datavault Builder は、1 つのデータモデルから SQL Server、Azure SQL、Fabric、Snowflake、Databricks、BigQuery、Oracle、PostgreSQL 向けのウェアハウスをネイティブ自動生成し、オンプレミスおよびクラウド双方のデータソースに対応した取り込み機能を標準で備えています。

• ロード処理はウェアハウス内で直接実行： ターゲットエンジンに合わせてコンパイルされたセットベースの差分 SQL を実行します。中間 SSIS サーバーも、データフローバッファの制限も、余計な ETL サーバーライセンスも不要です。
• データソースへのダイレクト接続： データベース、ファイル、REST API、NoSQL、Python ソース、Kafka ストリームからのバッチ、差分、CDC ロードに対応。高額なサードパーティ製コネクタ層は不要になります。
• プラットフォームは単なるターゲット切り替え： 今日は SQL Server 向けに生成し、明日は Fabric や Snowflake 向けに生成する。移行はコードの書き直しではなく「再生成」で完了します。
• パッケージをホストするのではなく、計画的に退役させる： モデルにマッピングされたソースから順に、クラウド VM 上でパッケージを動かし続ける必要がなくなります。
• 段階的な移行が可能： オンプレミスシステム間にとどまる処理は、移行の準備が整うまで既存の SSIS をそのまま使い続けることができます。

今すぐ判断すべきこと

移行対象のウェアハウスをターゲットにしているパッケージをリストアップしてください。それらのパッケージこそが、単純なクラウド移行によって負債をそのまま持ち越してしまう対象であり、新しいプラットフォーム向けに自動生成へ置き換えるべき最優先の候補です。