Fabricのミラーリングを使用すると、複雑なETL（抽出、変換、ロード）を回避し、既存のSnowflakeウェアハウスデータをMicrosoft Fabric内のその他のデータと統合するための簡単な体験が提供されます。 既存の Snowflake データを Fabric の OneLake に直接継続的にレプリケートできます。 Fabric 内では、強力なビジネス インテリジェンス、人工知能、データ エンジニアリング、データ サイエンス、データ共有のシナリオのロックを解除できます。
FabricでのミラーリングのためにSnowflakeデータベースを構成する方法についてのチュートリアルは、Tutorial: SnowflakeからMicrosoft Fabricミラー化データベースを構成するを参照してください。
ファブリックでミラーリングを使用する理由
Fabric のミラーリングでは、複数のベンダーの異なるサービスをまとめる必要はありません。 代わりに、分析ニーズを簡素化するように設計され、Microsoft、Snowflake、およびオープンソースの Delta Lake テーブル形式を読み取ることができる 1000 のテクノロジ ソリューション間のオープン性とコラボレーションのために構築された、高度に統合された、エンドツーエンドで使いやすい製品を利用できます。
どのような分析エクスペリエンスが組み込まれていますか?
ミラー化されたデータベースは、 ファブリック データ ウェアハウス 内のアイテムであり、 Warehouse および SQL 分析エンドポイントとは異なります。
ミラーリングでは、Fabric ワークスペースに次の項目が作成されます。
- ミラー化されたデータベース項目。 これにより、データ エンジニアリング、データ サイエンスなどのダウンストリーム シナリオが可能になります。 ミラーリングは次の管理を行います。
- SQL 分析エンドポイント
Important
Iceberg テーブルのサポート: Iceberg テーブルをミラー化する場合は、Iceberg テーブル データを含む基になるストレージへのストレージ接続を提供する必要があります。 同じストレージ接続を介して到達可能な Iceberg テーブルのみをミラー化できます。 Iceberg テーブルの格納場所を検索するには、Snowflake で SYSTEM$GET_ICEBERG_TABLE_INFORMATION システム関数を実行します。 詳細については、「チュートリアル: Snowflake から Microsoft Fabric のミラー化されたデータベースを構成する」を参照してください。
ミラー化された各データベースには、自動生成された SQL 分析エンドポイント があり、ミラーリング プロセスによって作成された差分テーブルの上に豊富な分析エクスペリエンスが提供されます。 ユーザーは、読み取り専用のコピーであるため、データ オブジェクトを定義してクエリを実行できるが、SQL 分析エンドポイントからデータを操作できない、使い慣れた T-SQL コマンドにアクセスできます。 SQL 分析エンドポイントでは、次のアクションを実行できます。
- Snowflake の Delta Lake テーブル内のデータを参照するテーブルを調べる。
- コード行を記述することなく、コード クエリやビューを作成したり、データを視覚的に探索したりすることはありません。
- SQL ビュー、インライン TVF (テーブル値関数)、ストアド プロシージャを開発して、T-SQL でセマンティクスとビジネス ロジックをカプセル化します。
- オブジェクトに対するアクセス許可を管理します。
- 同じワークスペース内の他のウェアハウスと Lakehouse のデータに対してクエリを実行します。
SQL クエリ エディターに加えてSQL Server Management Studio (SSMS)、 Visual Studio Code 用の MSSQL 拡張機能、さらには GitHub Copilot など、SQL 分析エンドポイントに対してクエリを実行できるツールの広範なエコシステムがあります。
サポートされている Snowflake オブジェクトの種類
次の表に、ミラーリングでサポートされている Snowflake オブジェクトの種類を示します。
| オブジェクトの種類 | サポートされている | 注記 |
|---|---|---|
| マネージド テーブル | はい | レプリケーションに対して完全にサポート |
| 氷山テーブル | はい | 基になる Iceberg テーブル ストレージへのストレージ接続が必要です。 ミラーリングできるのは、同じストレージ接続を介して到達可能な Iceberg テーブルのみです。 |
| Views | はい | 12 時間ごとに同期でサポートされます |
| マテリアライズドビュー | はい | 12 時間ごとに同期でサポートされます |
| 外部テーブル | いいえ | サポートしていません |
| 一時的なテーブル | いいえ | サポートしていません |
| 一時テーブル | いいえ | サポートしていません |
| 動的テーブル | いいえ | サポートしていません |
セキュリティに関する考慮事項
ファブリック ミラーリングを有効にするには、次のアクセス許可を含む Snowflake データベースのユーザーアクセス許可が必要です。
CREATE STREAMSELECT tableSHOW tablesDESCRIBE tables
詳細については、Access Control ストリーミング テーブルの特権 および ストリームに対する必要なアクセス許可に関する Snowflake のドキュメントを参照してください。
Important
ソース Snowflake ウェアハウスで確立された詳細なセキュリティは、Microsoft Fabricのミラー化されたデータベースで再構成する必要があります。
詳細については、Microsoft Fabric での
サポートされている認証方法
次の表に、Snowflake のミラーリングでサポートされる認証方法を示します。
| 認証方法 | サポートされている | 注記 |
|---|---|---|
| ユーザー名とパスワード | はい | Snowflake ネイティブ認証 |
| Microsoft Entra ID (SSO) | はい | Entra ID経由でのシングル サインオン |
| キー ペア認証 | はい | サービス アカウント シナリオの RSA キー ペア |
| ワークスペース ID | いいえ | Snowflake では現在サポートされていません |
ファイアウォールの背後にある Snowflake のミラーリング
Snowflake データ ソースにアクセスするためのネットワーク要件を確認します。 Snowflake データ ソースがパブリックにアクセス可能ではなく、プライベート ネットワーク内にある場合は、 仮想ネットワーク データ ゲートウェイを作成 するか、 オンプレミス データ ゲートウェイをインストールしてデータ をミラーリングします。 Azure Virtual Networkまたはゲートウェイ マシンのネットワークは、プライベート エンドポイント経由で Snowflake インスタンスに接続するか、ファイアウォール規則で許可する必要があります。 開始するには、「チュートリアル: Snowflake からミラーリングされたデータベースを Microsoft Fabric に構成する」を参照してください。
Private Linkとワークスペース ID:
- Private Link: Fabric ワークスペースと Snowflake 間の直接Private Link接続はまだサポートされていません。 その間、プライベート接続には、仮想ネットワーク データ ゲートウェイまたはオンプレミス データ ゲートウェイを使用します。
- ワークスペース ID: ワークスペース ID 認証は現在、Snowflake ミラーリングではサポートされていません。
ミラー化された Snowflake のコストに関する考慮事項
データを Fabric OneLake にレプリケートするために使用される Fabric コンピューティングは無料です。 ミラーリング ストレージのコストは、容量に基づいて上限まで解放されます。 詳細については、「ミラーリングコストおよびMicrosoft Fabric価格を参照してください。 SQL、Power BI、または Spark を使用してデータを照会するためのコンピューティングは、通常の料金で課金されます。
ファブリックでは、ミラーリング用の OneLake へのネットワーク データイングレス料金は課金されません。
データがミラー化されている場合、Snowflake コンピューティングとクラウド クエリのコストが発生します(仮想ウェアハウス コンピューティングとクラウド サービス コンピューティング)。
- Snowflake 仮想ウェアハウスのコンピューティング料金:
- Snowflake で読み取られているデータ変更があり、その後 Fabric にミラーリングされている場合、コンピューティング料金は Snowflake 側で課金されます。
- データの変更を確認するためにバックグラウンドで実行されるメタデータ クエリは、Snowflake コンピューティングに対して課金されません。ただし、
SELECT *などのデータを生成するクエリは Snowflake ウェアハウスを起動し、コンピューティングは課金されます。
- Snowflake サービスのコンピューティング料金:
- 作成、メタデータ クエリ、アクセス制御、データ変更の表示、DDL クエリなどのバックグラウンド タスクに対するコンピューティング料金はありませんが、これらのクエリにはクラウド コストが伴います。
- 使用している Snowflake エディションの種類に応じて、クラウド サービスのコストに対応するクレジットに対して課金されます。
次のスクリーンショットでは、ファブリックにミラー化されている関連する Snowflake データベースの仮想ウェアハウス コンピューティングとクラウド サービスのコンピューティング コストを確認できます。 このシナリオでは、クラウド サービスのコンピューティング コストの大部分 (黄色) は、前に説明した点に基づくデータ変更クエリから取得されます。 仮想ウェアハウスのコンピューティング料金（青）は、データ変更が Snowflake から取得され、それが Fabric にミラー化されることによって生じます。
コスト最適化に関する推奨事項
ミラーリングによる Snowflake コンピューティング コストを最小限に抑えるには、次のベスト プラクティスを検討してください。
- 既存の倉庫を再利用します。 ミラーリング専用のウェアハウスを作成する代わりに、アプリケーションがソース テーブルの更新に既に使用しているのと同じウェアハウスを使用するようにミラーリングを構成します。 この方法では、不要な倉庫のウェイクアップと自動中断のサイクルを回避できます。 アプリケーションがテーブルを更新すると、ミラーリング レプリケーターは、ウェアハウスがまだアクティブな間、ほぼすぐに変更を取得するため、別のウェアハウスをウェイクアップする必要はありません。 一部の組織では、予算を分離するために専用のウェアハウスを使用する場合があります。 この設定は、コスト削減と予算の細分性のトレードオフです。
- 必要なテーブルのみをミラー化します。 データベース全体をミラーリングすると、Snowflake の使用量が想定外に増加し、Fabric 容量が急増する可能性があります。 まず、分析シナリオに必要なテーブルのみを選択します。 必要に応じて、後でテーブルを追加できます。
- 想定外の再シードがないか監視します。 再シード (データの完全な再読み込み) では、テーブル全体が処理され、テーブル サイズに比例したコンピューティング コストが発生します。 スキーマの変更 (DBT などのツールによってトリガーされたものも含む) は、継続的な再シードを引き起こす可能性があります。 初期コピーの繰り返し動作を示すテーブルの [ミラーリングの状態] ページを監視し、トリガーとトラブルシューティングのガイダンスについては、以下の「再シード」セクションを確認してください。
- ミラーリングは継続的に実行されます。 ミラーリングでは、現在、スケジュールまたはレプリケーションウィンドウはサポートされていません。 レプリケーターは変更を継続的にポーリングするため、Snowflake のコンピューティングリソース使用量が継続的に発生します。 それに応じて、Snowflake の予算を計画します。
Snowflake 固有のクラウド クエリ コストの詳細については、「 Snowflake のドキュメント: 全体的なコストについて」を参照してください。