SnowflakeからMicrosoft Fabricのミラーリングされたデータベースにおける制限事項

Snowflake からミラー化されたデータベースMicrosoft Fabricの現在の制限事項については、このページを参照してください。 このページは変更されることがあります。

接続と認証の制限事項

• 次の表に、Snowflake のミラーリングでサポートされる認証方法を示します。

• 現在、ワークスペース ID は Snowflake ミラーリングではサポートされていません。 SharePointなどの一部のソースで使用できます。

• Fabric ワークスペースと Snowflake 間のPrivate Link接続はまだ使用できません。 中間のプライベート接続には、仮想ネットワーク データ ゲートウェイまたはオンプレミス データ ゲートウェイを使用します。

• 共有受信者をワークスペースに追加する必要があります。 データセットまたはレポートを共有するには、まず、管理者、メンバー、閲覧者、または共同作成者のロールを持つaccessをワークスペースに追加します。

• 大文字と小文字の区別: ウェアハウス名、データベース名、スキーマ名、テーブル名、ビュー名を含むすべての Snowflake 識別子では、ミラーリング接続を設定する際およびミラーリング REST API を使用する際に、大文字と小文字が区別されます。 Fabric に入力する文字列の大文字/小文字は、Snowflake 側で構成されている設定と完全に一致している必要があります。 大文字と小文字が一致しない場合、接続エラーが発生したり、テーブルがレプリケーション用に表示されなかったりする可能性があります。多くの場合、説明的なエラー メッセージは表示されません。 たとえば、Snowflake ウェアハウスの名前が ANALYTICS_WH の場合、analytics_wh ではなく、Fabric の接続で ANALYTICS_WH を入力する必要があります。

サポートされているオブジェクトの種類

• 次の表に、ミラーリングでサポートされている Snowflake オブジェクトの種類を示します。

レプリケーションとデータの制限

• ソース テーブルに更新がない場合、レプリケーター エンジンはバックオフを開始し、そのテーブルの期間が指数関数的に増加し、最大で 1 時間になります。 一時的なエラーが発生し、データの更新が妨げている場合も同様に発生する可能性があります。 更新されたデータが検出されると、レプリケーター エンジンは定期的なポーリングを自動的に再開します。
• ソース スキーマ階層は、ミラー化されたデータベースにレプリケートされます。 この機能を有効にする前に作成されたミラー化されたデータベースの場合、ソース スキーマはフラット化され、スキーマ名はテーブル名にエンコードされます。 スキーマを使用してテーブルを再構成する場合は、ミラー化されたデータベースを再作成します。 詳細は、ソース スキーマ階層の複製に関するページをご覧ください。
• ミラーリングでは、名前にスペースまたは特殊文字 (,;{}()\n\t=など) を含む列のレプリケートがサポートされています。 この機能が有効になる前のレプリケーションのテーブルの場合は、ミラー化されたデータベース設定を更新するか、ミラーリングを再起動してそれらの列を含める必要があります。 デルタ列マッピングのサポート に関するページを参照してください。
• Fabric にミラーリングできるテーブルの最大数は 1,000 テーブルです。 現在、1000 の制限を超えるテーブルはレプリケートできません。
  • ミラーリングを構成するときに [すべてのデータをミラー 化] を選択した場合、すべてのテーブルがスキーマ名とテーブル名に基づいてアルファベット順に並べ替えられた場合に、ミラー化対象のテーブルが最初の 1,000 個のテーブルを取得することによって決定されます。 アルファベット順の一覧の一番下にある残りの一連のテーブルはミラー化されません。
  • [すべてのデータをミラー化] をオフにして個々のテーブルを選択すると、1,000 を超えるテーブルを選択できなくなります。
• 計算列と計算テーブル: ミラー化されたデータベースは読み取り専用です。 ミラー化されたデータベースでは、計算列や計算テーブルを直接作成することはできません。 計算列を追加するには、Lakehouse を作成し、ショートカットを使用してミラー化されたデータを参照し、ノートブックまたは SQL を使用して Lakehouse に計算列を作成します。

パフォーマンスの制限事項

• 大きなテーブルのほとんどのデータを変更する場合は、ミラーリングを停止して再起動する方が効率的です。 何十億ものレコードを挿入または更新する場合、時間がかかる場合があります。
• スキーマの一部の変更はすぐに反映されません。 スキーマの変更の中には、スキーマの変更をFabricにレプリケートする前に、データの変更 (挿入、更新、または削除) が必要なものもあります。
• リージョン間の考慮事項: Snowflake インスタンスとFabric容量が異なるクラウド リージョンにある場合、レプリケーションの待機時間とデータ エグレス料金が高くなる可能性があります。 最適なパフォーマンスを実現し、リージョン間のエグレス コストを回避するには、Snowflake インスタンスと同じクラウド リージョンにFabric容量をデプロイします。 リージョン間のデプロイが避けられない場合は、Snowflake や Azure からの追加のエグレス料金を考慮してください。 詳細については、 Snowflake エグレスのドキュメント を参照してください。
• Snowflake から顧客の OneLake にデータをミラーリングする場合、通常、プロセスはインライン URL を介してデータをステージングしてパフォーマンスを向上させます。 Snowflake アカウント レベルのパラメーター PREVENT_UNLOAD_TO_INLINE_URL が true に設定されている場合、次の動作が適用されます。

計画的な解決策: ストレージ統合のサポートは開発中であり、PREVENT_UNLOAD_TO_INLINE_URLが true に設定されている場合に動作する代替のステージング パスを提供します。 このソリューションは、VNet と OPDG のシナリオのブロックを解除します。 このページで、可用性に関する更新プログラムを確認してください。

• 再シード動作: reseed は、テーブル全体の完全なデータ 再読み込みです。 増分同期 (変更された行のみを処理) とは異なり、再シードはテーブル内のすべてのデータを再読み取りして書き込み直します。 Reseeds では、特に大きなテーブルの場合、大きな Snowflake コンピューティング コストが発生する可能性があります。
  • 再シードを引き起こすもの:

• 不要な再シードを回避するためのベスト プラクティス:
  • アクティブ ミラーリングの外部でスキーマの変更をスケジュールします。 DBT またはその他のスキーマ管理ツールを使用する場合は、メンテナンス期間中にそれらをスケジュールするか、スキーマの変更を実行する前にミラーリングを一時停止します。
  • DDL の頻繁な変更は避けてください。 1 日を通して増分変更を行うのではなく、スキーマの変更をより少ない大きなバッチに統合します。
  • 想定外の再シードがないか監視します。 [ ミラーリングの状態] ページで、初期コピーの動作を繰り返し表示するテーブルを監視します。 大きなテーブルが数分ごとに再シードされる場合は、上流側のDDL変更を確認してください。
  • コストへの影響に注意してください。 2 億 2,600 万行のテーブル (最大 26.5 GB) の再シードには、かなりのコンピューティング時間がかかります。 このコストにスキーマ変更の頻度を掛けて、コストへの影響を見積もります。

セキュリティの制限事項

• Fabric では、Snowflake の行レベル セキュリティ (RLS) ポリシーおよび列レベル セキュリティ (CLS) ポリシーは複製されません。 Fabricで同等のセキュリティ ポリシーを手動で再構成する必要があります。
• 共有受信者をワークスペースに追加する必要があります。 データセットまたはレポートを共有するには、まず、管理者、メンバー、閲覧者、または共同作成者のロールを持つaccessをワークスペースに追加します。

コストと課金に関する考慮事項

ミラーリングによる Snowflake コンピューティング コストを最小限に抑えるには、次のベスト プラクティスを検討してください。

• 既存の倉庫を再利用します。 ミラーリング専用のウェアハウスを作成する代わりに、アプリケーションがソース テーブルの更新に既に使用しているのと同じウェアハウスを使用するようにミラーリングを構成します。 この方法では、不要な倉庫のウェイクアップと自動中断のサイクルを回避できます。 アプリケーションがテーブルを更新すると、ミラーリング レプリケーターは、ウェアハウスがまだアクティブな間、ほぼ即座に変更を取得するため、別のウェアハウスをスリープ解除する必要がなくなります。 一部の組織では、予算を分離するために専用のウェアハウスを使用する場合があります。 この選択は、コスト削減と予算の細分性のトレードオフです。
• 必要なテーブルのみをミラー化します。 データベース全体をミラーリングすると、Snowflake の使用量が想定外に増加し、Fabric 容量が急増する可能性があります。 まず、分析シナリオに必要なテーブルのみを選択します。 必要に応じて、後でテーブルを追加できます。
• 想定外の再シードがないか監視します。 再シード (データの完全な再読み込み) では、テーブル全体が処理され、テーブル サイズに比例したコンピューティング コストが発生します。 スキーマの変更 (DBT などのツールによってトリガーされたものも含む) は、継続的な再シードを引き起こす可能性があります。 初期コピーの繰り返し動作を示すテーブルの [ミラーリングの状態] ページを監視し、トリガーとトラブルシューティングのガイダンスについては「再シード」セクションを確認します。
• ミラーリングは継続的に実行されます。 ミラーリングでは、現在、スケジュールまたはレプリケーションウィンドウはサポートされていません。 レプリケーターは変更を継続的にポーリングするため、Snowflake のコンピューティングリソース使用量が継続的に発生します。 それに応じて、Snowflake の予算を計画します。

サポートされているリージョン

データベース ミラーリングとオープン ミラーリングは、すべてのMicrosoft Fabricリージョンで使用できます。 詳細については、「Fabric が使用できるリージョン」を参照してください。

関連コンテンツ

• ファブリックのミラーリングとは
• Snowflake のミラーリング
• チュートリアル: Snowflake から Microsoft Fabric へのミラー化データベース構成