Databricks でのアーカイブのサポート
プレビュー
この機能は、Databricks Runtime 13.3 LTS 以降でパブリック プレビュー段階です。
Databricks のアーカイブ サポートでは、Delta テーブルを含むクラウドオブジェクトストレージでクラウドベースのライフサイクル ポリシーを使用できるようにする機能のコレクションが導入されています。
Databricks は、S3 Glacier Deep Archive と Glacier Flexible Retrieval のみのアーカイブをサポートしています。 アーカイブされたオブジェクトの操作については、AWS ドキュメントを参照してください。
Amazon S3 Glacier Instant Retrieval では、アーカイブサポートを設定する必要はありません。 ただし、クエリを実行すると、スキャンされたすべてのファイルが取得されます。 Databricks では、ライフサイクル ポリシーが構成された Glacier Instant Retrieval に格納されているテーブルに対するクエリを制限するために、ビューを使用することをお勧めします。
Amazon S3 Intelligent-Tiering アーカイブは、ファイルの作成時間ではなくアクセス時間に基づいており、Databricks のアーカイブサポートと互換性がありません。
アーカイブサポートを有効にする必要があるのはなぜですか?
アーカイブサポートでは、アーカイブされたファイルに触れずに正しく回答できるクエリのみが許可されます。 これらのクエリには、次のいずれかに該当するクエリが含まれます。
- メタデータのみをクエリします。
- アーカイブされたファイルのスキャンを必要としないフィルターを用意します。
アーカイブされたファイルのデータを必要とするすべてのクエリは失敗します。
Databricks は、アーカイブされたファイルが正しい結果を返す必要があるクエリの結果を返すことはありません。
アーカイブ サポートがないと、データ ファイルまたはトランザクション ログ ファイルがアーカイブされた場所に移動し、クエリ時に使用できなくなるため、Delta テーブルに対する操作が中断される可能性があります。 アーカイブのサポートでは、可能な限りアーカイブされたデータのクエリを回避するための最適化が導入されています。 また、クエリを完了するためにアーカイブ ストレージから復元する必要があるファイルを識別するための新しい構文も追加されています。
Databricks でテーブルのアーカイブ サポートを有効にしても、クラウド オブジェクト ストレージに定義されているライフサイクル ポリシーは作成または変更されません。 望ましい結果を得るには、クラウドのライフサイクルポリシーと delta.timeUntilArchived
設定を同じにする必要があります。
アーカイブ・データ用に最適化されたクエリ
Databricks のアーカイブ サポートでは、Delta テーブルに対する次のクエリが最適化されます。
クエリー | 新しい動作 |
---|---|
| アーカイブされたファイルを自動的に無視し、アーカイブされていないストレージ階層のデータから結果を返します。 |
Delta Lake メンテナンス コマンド: | アーカイブされたファイルを自動的に無視し、テーブルの残りの部分でメンテナンスを実行します。 |
データを上書きしたり、データを削除したりする DDL および DML ステートメント ( | ターゲット・アーカイブ・データ・ファイルのトランザクション・ログ・エントリーに削除済みマークを付けます。 |
| アーカイブされたファイルを無視し、ライフサイクル ポリシーに達していないファイルのみを確認します。 |
制限事項を参照してください。
初期の失敗とエラーメッセージ
アーカイブされたファイルをスキャンして正しい結果を生成する必要があるクエリの場合、Delta Lake のアーカイブ サポートを構成すると、次のことが保証されます。
- クエリは、アーカイブされたファイルにアクセスしようとすると早期に失敗し、無駄なコンピュートを減らし、ユーザーがクエリを迅速に適応させて再実行できるようにします。
- エラーメッセージは、クエリがアーカイブされたファイルにアクセスしようとしたためにクエリが失敗したことをユーザーに知らせます。
ユーザーは、 SHOW ARCHIVED FILES
構文を使用して、復元する必要があるファイルのレポートを生成できます。 アーカイブされたファイルを表示するを参照してください。
Not enough files to satisfy LIMIT
というエラーが表示された場合は、アーカイブされていないファイルに LIMIT
で指定されたレコード数を満たすだけのデータ行がテーブルにありません。 LIMIT
句を下げて、指定した LIMIT
を満たすだけのアーカイブされていない行を見つけてください。
アーカイブ サポートを有効にする
Databricks で Delta テーブルのアーカイブ サポートを有効にするには、次の構文例のように、基になるクラウド ライフサイクル管理ポリシーで構成されたアーカイブ間隔を手動で指定します。
ALTER TABLE <table_name> SET TBLPROPERTIES(delta.timeUntilArchived = 'X days');
アーカイブ サポートを有効にすると、指定した期間より古いファイルを無視するように Databricks に効果的に指示します。 クラウドオブジェクトストレージにライフサイクルポリシーを設定せずにこの設定を有効にした場合、Databricks はこの指定されたしきい値に基づくファイルを無視しますが、データはアーカイブされません。
Delta Lake は、クラウド アカウントで構成されているライフサイクル管理ポリシーと直接やり取りすることはありません。 クラウドアカウントでポリシーを更新する場合は、Delta テーブルのポリシーを更新する必要があります。 「ライフサイクル管理の移行ルールを変更する」を参照してください。
アーカイブのサポートは、互換性のある Databricks コンピュート環境に完全に依存しており、 Delta テーブルでのみ機能します。 アーカイブ サポートを構成しても、OSS Delta Lake クライアントまたは Databricks Runtime 12.2 LTS 以下の動作、互換性、サポートは変更されません。
アーカイブされたファイルを表示する
特定のクエリを完了するために復元する必要があるファイルを特定するには、次の例のように SHOW ARCHIVED FILES
を使用します。
SHOW ARCHIVED FILES FOR table_name [ WHERE predicate ];
この操作は、アーカイブされたファイルの URI を Spark データフレーム として返します。 オブジェクトストレージプロバイダーからの文書化された指示に従って、必要なアーカイブファイルを復元します。 Databricks復元されたデータを確認する方法については、「復元されたデータのサンプリング方法」Databricksを参照してください。
この操作中、Delta Lake はトランザクション ログに含まれるデータ統計にのみアクセスできます。 デフォルトでは、これらはテーブルの最初の 32 列で収集される次の統計です。
- 最小値
- 最大値
- Null カウント
- レコードの総数
戻されるファイルには、述部を満たすレコードがファイルに存在するかどうかを判別するために読み取る必要があるすべてのアーカイブ・ファイルが含まれます。 Databricks 、復元する必要があるファイルの数を減らすために、データがパーティション分割、 Z-ordered、またはクラスタ化されるフィールドを含む述部を提供することをお勧めします。
アーカイブされたデータを更新または削除する
アーカイブされたファイルのデータに影響を与える MERGE
、 UPDATE
、または DELETE
操作を実行すると、操作は失敗します。 これらの操作を実行するには、高速取得をサポートするストレージ階層にデータをリストアする必要があります。 SHOW ARCHIVED FILES
を使用して、復元する必要があるファイルを特定します。
Databricks は復元されたデータをどのようにサンプリングしますか?
Databricks は、アーカイブ サポートが有効になっているテーブルに対するスキャンを準備するときに、クエリに必要な指定された保持期間よりも古いファイルをサンプリングして、ファイルが復元されたかどうかを判断します。
アーカイブされていると推定されるサンプリング ファイルが復元されたことが結果に示されている場合、Databricks はクエリのすべてのファイルが復元され、クエリが処理されていると見なします。
制限
次の制限があります。
- ファイルの作成時間に基づかないライフサイクル管理ポリシーはサポートされていません。 これには、アクセス時間ベースのポリシーとタグベースのポリシーが含まれます。
- アーカイブされたファイルがあるテーブルで
DROP COLUMN
を使用することはできません。 REORG TABLE APPLY PURGE
はベストエフォートを試みますが、アーカイブされていない削除ベクトル ファイルと参照データ ファイルに対してのみ機能します。 アーカイブされた削除ベクトル ファイルは削除PURGE
。- ライフサイクル管理移行ルールを拡張すると、予期しない動作が発生します。 ライフサイクル管理移行ルールの拡張を参照してください。
ライフサイクル管理の移行ルールを変更する
クラウド ライフサイクル管理移行ルールの時間間隔を変更する場合は、プロパティを更新する必要があります delta.timeUntilArchived
。
アーカイブまでの時間間隔が短縮された場合 (ファイル作成からの時間が短くなった場合)、テーブル・プロパティが更新された後も、Delta テーブルのアーカイブ・サポートは引き続き正常に機能します。
ライフサイクル管理移行ルールの拡張
アーカイブ前の時間間隔が延長された場合 (アーカイブがトリガーされるまでの時間を追加するため)、プロパティ delta.timeUntilArchived
を新しい値に更新すると、エラーが発生する可能性があります。 クラウドプロバイダーは、データ保持ポリシーが変更されても、アーカイブされたストレージからファイルを自動的に復元しません。 つまり、以前はアーカイブの対象となっていたが、現在はアーカイブの対象とは見なされていないファイルは、引き続きアーカイブされます。
エラーを回避するには、プロパティ delta.timeUntilArchived
を、最後にアーカイブされたデータの実際の経過時間より大きい値に設定しないでください。
アーカイブの時間間隔が 60 日から 90 日に変更されるシナリオを考えてみます。
- 60 日から 90 日経過したすべてのレコードは、ポリシーが変更されたときにアーカイブされます。
- 30 日間は、新しいファイルはアーカイブされません (ポリシーが延長されたとき、アーカイブされていない最も古いファイルは 60 日前です)。
- 30 日後、ライフサイクル ポリシーでは、アーカイブされたすべてのデータが正しく記述されます。
delta.timeUntilArchived
設定は、Delta トランザクション・ログによって記録されたファイル作成時刻に対して、設定された時間間隔を追跡します。基になるポリシーに関する明確な知識はありません。 古いアーカイブしきい値と新しいアーカイブしきい値の間の遅延期間中は、次のいずれかの方法を使用して、アーカイブされたファイルのクエリを回避できます。
-
すべてのファイルをアーカイブするのに十分な時間が経過するまで、設定
delta.timeUntilArchived
を古いしきい値のままにしておくことができます。- 上記の例に従えば、最初の 30 日間は毎日、別の 1 日分のデータが Databricks によってアーカイブされたと見なされますが、それでもクラウドプロバイダーがアーカイブする必要があります。 これによりエラーは発生しませんが、クエリされる可能性のある一部のデータ・ファイルが無視されます。
- 30 日後、
delta.timeUntilArchived
を90 days
に更新します。
-
ラグ期間中の現在の間隔を反映するために、設定を毎日更新
delta.timeUntilArchived
ことができます。- クラウド ポリシーが 90 日に設定されている間、アーカイブされたデータの実際の経過時間はリアルタイムで変化します。 たとえば、7 日後に
delta.timeUntilArchived
を67 days
に設定すると、アーカイブされたすべてのデータ ファイルの経過時間が正確に反映されます。 - このアプローチは、ホットティア内のすべてのデータにアクセスする必要がある場合にのみ必要です。
- クラウド ポリシーが 90 日に設定されている間、アーカイブされたデータの実際の経過時間はリアルタイムで変化します。 たとえば、7 日後に
delta.timeUntilArchived
の値を更新しても、アーカイブされるデータは変更されません。Databricks がアーカイブされたかのように扱うデータのみが変更されます。