適用対象:✅ Warehouse in Microsoft Fabric
Microsoft Fabricでは、ウェアハウスは、構成された保持期間に基づいて、さまざまなバージョンのデータを自動的に保持および保持します。 この保持期間は、タイム トラベル クエリの実行、 テーブルの複製の作成、 復元ポイントの使用、 およびウェアハウス スナップショットの作成を実行できる過去の期間を決定します。
データ保持は、倉庫の作成時に自動的に開始されます。 既定では、倉庫は 30 日間データ履歴を保持します。 保持期間は、1 ~ 120 日の任意の値に構成できます。 システムは、リテンション期間が終了した後、期限切れのファイルを自動的に削除します。
ウェアハウスは、構成された保持期間内にすべての挿入、更新、および削除を保持します。
- 保持期間を長くすると 、タイム トラベル クエリ、過去の時点でのテーブルクローン、復元ポイント、およびウェアハウス スナップショットの期間が長くなります。 ただし、保有期間が長いほど、ストレージの使用量と関連するコストが増加します。
- リテンション期間を短縮すると 、ストレージ コストは削減されますが、履歴データのクエリまたは復旧を実行できる期間は制限されます。
データ保持のしくみ
データが変更されると、ウェアハウスは以前のバージョンの状態をすぐに破棄しません。 代わりに、以前のバージョンのデータは Delta Lake トランザクション ログの一部として保持されます。 このバージョン管理メカニズムにより、タイム トラベル、テーブルクローン、復元ポイント、およびウェアハウス スナップショットが機能できるようになります。
履歴データのバージョンが構成された保持期間を超えると、バックグラウンド ガベージ コレクション プロセスによって、期限切れのファイルが OneLake から自動的に削除されます。 このクリーンアップ プロセスは非同期的に実行され、アクティブなクエリや進行中のトランザクションには影響しません。
ウェアハウスは、データ バージョンが作成された時刻から、保持されているデータの有効期間を絶対カレンダー日数で測定します。これには、Microsoft Fabric容量が一時停止された時間も含まれます。
保有期間の範囲
保持期間を明示的に構成しない場合、既存の倉庫では既定の保持期間として 30 カレンダー日が使用されます。 データ保持期間は、1 日から 120 日まで構成できます。
データ保有期間を構成する
T-SQL コマンド ALTER DATABASE ... SET を使用して、ウェアハウスのデータ保有期間を設定します。 手順と詳細については、「
保持期間を変更するときの動作
保持期間を変更したときの動作を理解することは、予期しないデータ損失やストレージ サイズの増加を回避するために変更を計画するのに役立ちます。
リテンション期間を増やす
保持期間を長くすると、新しい設定がすぐに有効になります。 ただし、以前の短い保有期間にシステムが既にクリーンアップした履歴データを回復することはできません。 変更時に OneLake にまだ存在するデータ バージョンのみが、延長保有期間の恩恵を受けます。
たとえば、現在、倉庫に 7 日間の保持期間があり、それを 60 日に増やす場合、その時点から変更が適用されます。 システムによってクリーンアップされ、7日以上前のデータバージョンは変更前に復旧することができません。 ただし、変更時の 7 日間の期間内のすべてのデータ バージョンと、今後新しく作成されたバージョンは、最大 60 日間保持されます。
リテンション期間の短縮
保持期間を短縮すると、新しい短い保持期間の範囲外になったデータ バージョンがクリーンアップの対象になります。 クリーンアップ プロセスはバックグラウンドで非同期的に実行され、瞬時には実行されません。 既に進行中のアクティブなクエリは影響を受けません。
たとえば、倉庫に 30 日間の保持期間があり、それを 7 日に減らすと、8 日から 30 日の間のデータ バージョンがバックグラウンド クリーンアップの対象になります。
Important
データ アクセスの観点からは、保持期間の短縮は元に戻すことができません。
その後すぐに再びリテンション期間を長くしても、その間に短い期間の外に落ちたデータにはアクセスできなくなります。 保持期間を短縮する前に、新しい保持期間が組織のデータ回復とコンプライアンスの要件を満たしていることを確認します。
リテンション期間の締め切り日
time_travel_retention_cutoff_date システム カタログ ビューの 列には、現在構成されている保持期間ではなく、移動データが使用可能な実際の最も早い日付が反映されます。 最も古い実際のデータは、構成された保持期間とは異なる場合があります。
ユーザー構成の保持期間は、今後システムが保持 する必要がある 履歴の日数を定義します。 ただし、 実際の回復可能な履歴 は、保持が変更される前に保持されたデータによって異なります。
次の 2 つの状況により、構成されたリテンション期間と実際の使用可能な履歴の間に相違が発生します。
- リテンション期間が短縮されました。ウェアハウスは、新しいリテンション期間より古い履歴データを直ちにガベージコレクション用にマークし、それを完全に削除します。
- その後、リテンション期間が増加しました 。ウェアハウスは削除された履歴を復元できません。 構成された完全なウィンドウが使用可能になるまで、新しい履歴が蓄積されるのを待つ必要があります。
データ保持シナリオ
保持期間を構成する方法を決定するときは、次のシナリオを検討してください。
コンプライアンスと監査
規制またはコンプライアンスの要件を持つ組織は、監査義務を満たすためにデータを長期間保持する必要がある場合があります。 保持期間を 90 日または 120 日に構成すると、監査担当者が時間の経過に伴うデータ変更を確認するための、より広範な履歴期間を提供できます。
開発とテスト
履歴データの重要度が低い開発またはテスト ワークスペースの場合、保持期間を 1 ~ 7 日に短くすると、ストレージ コストが削減されます。 この削減は、ワークスペースを迅速なプロトタイプ作成や反復開発に使用する場合に便利です。
コストの最適化
ウェアハウスが頻繁に大規模なデータ変更を行う場合 (毎日のフル ロードなど)、保持された履歴データの量が大幅に増加する可能性があります。 このようなシナリオでは、リテンション期間を短縮することで、適切な復旧期間を維持しながらストレージ コストを制御できます。
データ復旧の準備
運用ウェアハウスの場合、保持期間を長く維持すると、偶発的なデータ破損が発生した場合に、 復元ポイント、 テーブルクローン、 タイム トラベル クエリを使用してデータを回復する柔軟性が向上します。
構成可能なリテンション期間が依存する機能に与える影響
構成された保持期間は、Fabric Data Warehouseの次の機能全体で一様に適用されます。 保持期間を変更すると、これらの機能の可用性と動作に直接影響します。
タイム トラベル
タイム トラベル を使用すると、保持期間内の過去の特定の時点に存在していたデータに対してクエリを実行できます。
FOR TIMESTAMP AS OFクエリ ヒントは、構成された保持期間内の任意のポイントからデータを取得できます。
たとえば、保持期間が 15 日に設定されている場合は、過去 15 日間まで存在していたデータを照会できます。
テーブルの複製
テーブルクローンは保持期間に基づいています。 テーブルの複製は、構成された保持期間内にのみ過去の時点で作成できます。 保持期間を超えて複製を要求すると、エラーが発生します。
復元ポイント
復元ポイントを使用して、ウェアハウスを復元します。 システムは、構成されたリテンション期間に対して、システムによって生成された復元ポイントとユーザー定義の復元ポイントの両方を保持します。 リテンション期間が経過すると、システムは復元ポイントを自動的に削除します。
- ウェアハウスは、システム生成の復元ポイントを 8 時間ごとに自動的に作成します。 これらの復元ポイントは、構成されたリテンション期間に使用できます。
- ユーザー定義の復元ポイントは、構成されたリテンション期間に使用できます。 システムは、有効期限が切れた後にこれらの復元ポイントを自動的に削除します。
Fabricは、十分な復元ポイントが常に使用可能になるように、最小限の復元ポイント数を維持します。
ウェアハウス スナップショット
ウェアハウス スナップショットは、 構成された保有期間内にデータを参照できます。 スナップショット タイムスタンプは、構成された保有期間内の任意の時点、またはデータベースの作成時刻のいずれか後の任意の時点に設定できます。
ストレージの課金
データの保持は、OneLake ストレージの使用量に直接影響します。 保持されている各バージョンのデータはストレージ領域を占有し、保持期間が長いほど履歴バージョンが蓄積されます。
リテンション期間の構成を計画する際は、データ履歴アクセスが長くなる利点と関連するストレージ コストとのトレードオフを考慮してください。 ストレージの監視の詳細については、「 容量メトリック アプリを使用した監視」を参照してください。
- 保持されるデータ ファイル: OneLake に Parquet ファイルとして格納されているデータの履歴バージョンは、ストレージを使用します。 ストレージ コストは、保有期間中のデータ変更の量と頻度に比例します。
- 復元ポイント: システム生成およびユーザー定義の復元ポイントのメタデータもストレージを使用します。 ただし、復元ポイントは主にメタデータを格納し、既存のデータ ファイルを参照するため、ストレージのオーバーヘッドは比較的小さくなります。
- リテンション期間のコンピューティング料金なし: 履歴データの保持のみにコンピューティング料金は発生しません。 コンピューティング料金は、データのクエリまたは復元をアクティブに行う場合にのみ適用されます。
保有期間の変更によるストレージへの影響を見積もる場合は、次の点を考慮してください。
- ウェアハウス内のデータ変更の 1 日あたりの平均量。
- 現在の保持期間と提案された新しい保持期間。
- 2 つの期間の間の差分に、平均日次変更量を乗算すると、ストレージ使用量のおおよその変化が生まれます。
設計上の考慮事項
- 組織のデータ復旧、コンプライアンス、コストの要件に基づいて保持期間を構成します。 既定値の 30 日は、ほとんどのワークロードでデータの可用性とストレージ コストのバランスを取ります。
- 保有期間の変更をバックアップとディザスター リカバリー戦略と調整します。 リテンション期間が目標復旧ポイント (RPO) と一致していることを確認します。
- 保持期間を変更した後に OneLake ストレージの使用量を監視して、ストレージ コストへの影響を把握します。
- ユーザーへの影響がないように、可能な限りアクティビティの少ない期間中に保持期間の変更を計画します。
- 保持期間は、倉庫レベルで設定されます。 データセットごとに異なる保持期間が必要な場合は、それらを個別のウェアハウスに整理することを検討してください。 個々のテーブル レベルの保持設定は現在サポートされていません。
制限事項
- 保有期間を日数で指定します。 小数部の値はサポートされていません。
- リテンション期間を短縮しても、すぐにストレージが再利用されるわけではありません。 期限切れのデータのクリーンアップは、バックグラウンドで非同期的に行われます。
- Microsoft Fabric容量を一時停止すると、ガベージ クリーンアップ アクティビティに影響します。 このプロセスでは、容量が一時停止されている間、現在のデータ保持設定よりも古い履歴データは削除されません。 容量が回復すると、クリーンアップ活動が追いつきます。
- 保持設定は倉庫にのみ適用されます。 Lakehouse の SQL 分析エンドポイントはサポートされていません。
- Query Insights と SQL 監査ログは、このデータ保持ポリシーの対象ではなく、個別に管理されます。
削除されたアイテムの保持 (プレビュー)
削除されたアイテムの保持期間 は、削除または廃止された後に、設定可能な期間にわたってウェアハウスおよび関連するテーブル、スキーマ、スナップショット、権限、保存されたクエリを維持します。 これにより、誤って削除しても、データが完全に失われたり、ビジネスに影響を与える停止が発生したりすることはありません。 ドロップされたリテンションは、最低7暦日の保持期間を保証し、テナントレベルでのリテンション設定が個別に可能です。 [項目の回復] テナント設定で、削除されたアイテムの保持期間を構成できます。