Databricks でのアーカイブのサポート

備考

プレビュー

この機能は、Databricks Runtime 13.3 LTS 以降でパブリック プレビュー段階です。

Databricksのアーカイブ サポートにより、 Deltaテーブルを含むクラウド オブジェクト ストレージでクラウド ベースのライフサイクル ポリシーを使用できるようになります。 Delta Lakeテーブルでアーカイブサポートを有効にすると、Databricksはテーブルで指定された期間よりも古いファイルを無視するようになります。

要件

アーカイブ機能を利用するには、S3 Glacier Deep ArchiveまたはGlacier Flexible Retrievalが必要です。アーカイブされたオブジェクトの操作方法については、AWS のドキュメントを参照してください。

Amazon S3 Glacier Instant Retrieval では、アーカイブサポートを設定する必要はありません。 ただし、クエリを実行すると、スキャンされたすべてのファイルが取得されます。 Databricks では、ライフサイクル ポリシーが構成された Glacier Instant Retrieval に格納されているテーブルに対するクエリを制限するために、ビューを使用することをお勧めします。

警告

Amazon S3 Intelligent-Tieringのオプションである非同期アーカイブアクセス階層は、ファイル作成時間ではなくアクセス時間に基づいてアーカイブを行うため、Databricksのアーカイブサポートとは互換性がありません。

アーカイブサポートを有効にする必要があるのはなぜですか?

アーカイブサポートでは、アーカイブされたファイルに触れずに正しく回答できるクエリのみが許可されます。 これらのクエリには、次のいずれかに該当するクエリが含まれます。

• メタデータのみをクエリします。
• アーカイブされたファイルのスキャンを必要としないフィルターを用意します。

アーカイブされたファイルのデータを必要とするすべてのクエリは失敗します。

重要

Databricks は、アーカイブされたファイルが正しい結果を返す必要があるクエリの結果を返すことはありません。

Databricksでテーブルのアーカイブサポートを有効にしても、クラウドオブジェクトストレージ用に定義されたライフサイクルポリシーが作成または変更されることはありません。ライフサイクル管理の移行ルールを変更するを参照してください。

アーカイブ サポートがないと、データ ファイルまたはトランザクション ログ ファイルがアーカイブされた場所に移動し、クエリ時に使用できなくなるため、Delta テーブルに対する操作が中断される可能性があります。 アーカイブのサポートでは、可能な限りアーカイブされたデータのクエリを回避するための最適化が導入されています。 また、クエリを完了するためにアーカイブ ストレージから復元する必要があるファイルを識別するための新しい構文も追加されています。

アーカイブ・データ用に最適化されたクエリ

Databricksのアーカイブサポートは、Deltaテーブルに対する以下のクエリを最適化します。

クエリー	新しい動作
SELECT * FROM <table_name> LIMIT <limit> [WHERE <partition_predicate>]	アーカイブされたファイルを自動的に無視し、アーカイブされていないストレージ階層のデータから結果を返します。
Delta Lake メンテナンス コマンド: OPTIMIZE、 ZORDER、 ANALYZE、 PURGE	アーカイブされたファイルを自動的に無視し、テーブルの残りの部分でメンテナンスを実行します。
データを上書きしたり、データを削除したりする DDL および DML ステートメント ( REPLACE TABLE、 INSERT OVERWRITE、 TRUNCATE TABLE、 DROP TABLE	ターゲット・アーカイブ・データ・ファイルのトランザクション・ログ・エントリーに削除済みマークを付けます。
FSCK REPAIR TABLE	アーカイブされたファイルを無視し、ライフサイクル ポリシーに達していないファイルのみを確認します。

初期の失敗とエラーメッセージ

アーカイブされたファイルをスキャンして正しい結果を生成する必要があるクエリの場合、Delta Lake のアーカイブ サポートを構成すると、次のことが保証されます。

• クエリは、アーカイブされたファイルにアクセスしようとすると早期に失敗し、無駄なコンピュートを減らし、ユーザーがクエリを迅速に適応させて再実行できるようにします。
• エラーメッセージは、クエリがアーカイブされたファイルにアクセスしようとしたためにクエリが失敗したことをユーザーに知らせます。

ユーザーは、 SHOW ARCHIVED FILES 構文を使用して、復元する必要があるファイルのレポートを生成できます。 アーカイブされたファイルを表示するを参照してください。

重要

エラーNot enough files to satisfy LIMITが発生した場合、テーブルにはアーカイブされていないファイルにLIMITで指定されたレコード数を満たすのに十分なデータ行がありません。LIMIT句を下げて、指定されたLIMITを満たすのに十分なアーカイブされていない行を見つけます。制限事項を参照してください。

アーカイブ サポートを有効にする

Deltaテーブルのアーカイブサポートを有効にするには、基盤となるクラウドライフサイクル管理ポリシーで設定されているアーカイブ間隔を手動で指定します。

SQL

ALTER TABLE <table_name> SET TBLPROPERTIES(delta.timeUntilArchived = 'X days');

timeUntilArchived時間を設定すると、Databricks は指定された期間よりも古い Delta Lake テーブル内のファイルを無視します。この設定は、クラウドアカウントのライフサイクルポリシーとは別個のものです。一方の変更は他方に影響を与えません。クラウドアカウントのライフサイクルポリシーを更新する場合は、Delta Lakeテーブルのアーカイブ設定も更新する必要があります。ライフサイクル管理の移行ルールを変更するを参照してください。

クラウドオブジェクトストレージにライフサイクルポリシーを設定せずにこの設定を有効にすると、アーカイブサポートによってクエリが成功し、結果にはアーカイブ対象としてマークされたファイルからのデータが含まれます。Databricksが復元されたデータをどのようにサンプリングするかを参照してください。

警告

クラウド ライフサイクル ポリシーでは、Delta トランザクション ログ ( _delta_log/ディレクトリ) をアーカイブしてはなりません。制限事項を参照してください。

重要

アーカイブのサポートは、互換性のある Databricks コンピュート環境に完全に依存しており、 Delta テーブルでのみ機能します。 アーカイブ サポートを構成しても、OSS Delta Lake クライアントまたは Databricks Runtime 12.2 LTS 以下の動作、互換性、サポートは変更されません。

アーカイブされたファイルを表示する

特定のクエリを完了するために復元する必要のあるファイルを特定するには、 SHOW ARCHIVED FILESを使用します。

SQL

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 はクエリのすべてのファイルが復元されたとみなし、クエリ処理を実行します。結果には、アーカイブ対象としてマークされたファイルからのデータが含まれています。

サンプリングはすべてのクエリに適用されるとは限りません。制限事項を参照してください。

制限

次の制限があります。

• アーカイブ サポートはデータ ファイルにのみ適用されます。Deltaトランザクション ログ ( _delta_log/ディレクトリ) 内のいずれかのファイルがアーカイブ ストレージ層に移動されると、テーブルは完全にアクセスできなくなり、テーブルに対するすべてのクエリは失敗します。 _delta_log/パスがアーカイブに含まれないように、クラウド ライフサイクル ポリシーを構成する必要があります。S3 ライフサイクル設定の例を参照してください。
• ファイルの作成時間に基づかないライフサイクル管理ポリシーはサポートされていません。 これには、アクセス時間ベースのポリシーとタグベースのポリシーが含まれます。
• アーカイブされたファイルがあるテーブルで DROP COLUMN を使用することはできません。
• REORG TABLE APPLY PURGE はベストエフォートを試みますが、アーカイブされていない削除ベクトル ファイルと参照データ ファイルに対してのみ機能します。 アーカイブされた削除ベクトル ファイルは削除PURGE。
• ライフサイクル管理移行ルールを拡張すると、予期しない動作が発生します。 ライフサイクル管理移行ルールの拡張を参照してください。
• LIMIT アーカイブサポートが有効になっているテーブルに対するクエリでは、復元されたデータのサンプリングはトリガーされません。テーブルのデータが復元された場合、復元されたデータに対するクエリのほとんどは成功しますが、 LIMITクエリはDELTA_ARCHIVED_FILES_IN_LIMITエラーを返します。Databricksが復元されたデータをどのようにサンプリングするかを参照してください。

ライフサイクル管理の移行ルールを変更する

クラウドライフサイクル管理の遷移ルールの時間間隔を変更する場合は、プロパティdelta.timeUntilArchived同じ間隔に更新する必要があります。

アーカイブまでの時間間隔が短縮された場合 (ファイル作成からの時間が短くなった場合)、テーブル・プロパティが更新された後も、Delta テーブルのアーカイブ・サポートは引き続き正常に機能します。

ライフサイクル管理移行ルールの拡張

アーカイブ前の時間間隔が延長された場合 (アーカイブがトリガーされるまでの時間を追加するため)、プロパティ delta.timeUntilArchived を新しい値に更新すると、エラーが発生する可能性があります。 クラウドプロバイダーは、データ保持ポリシーが変更されても、アーカイブされたストレージからファイルを自動的に復元しません。 つまり、以前はアーカイブの対象となっていたが、現在はアーカイブの対象とは見なされていないファイルは、引き続きアーカイブされます。

重要

エラーを回避するには、プロパティ delta.timeUntilArchived を、最後にアーカイブされたデータの実際の経過時間より大きい値に設定しないでください。

アーカイブの時間間隔が 60 日から 90 日に変更されるシナリオを考えてみます。

1. 60 日から 90 日経過したすべてのレコードは、ポリシーが変更されたときにアーカイブされます。
2. 30 日間は、新しいファイルはアーカイブされません (ポリシーが延長されたとき、アーカイブされていない最も古いファイルは 60 日前です)。
3. 30 日後、ライフサイクル ポリシーでは、アーカイブされたすべてのデータが正しく記述されます。

delta.timeUntilArchived設定は、Delta トランザクション・ログによって記録されたファイル作成時刻に対して、設定された時間間隔を追跡します。基になるポリシーに関する明確な知識はありません。 古いアーカイブしきい値と新しいアーカイブしきい値の間の遅延期間中は、次のいずれかの方法を使用して、アーカイブされたファイルのクエリを回避できます。

1. すべてのファイルをアーカイブするのに十分な時間が経過するまで、設定 delta.timeUntilArchived を古いしきい値のままにしておくことができます。

   • 上記の例に従えば、最初の 30 日間は毎日、別の 1 日分のデータが Databricks によってアーカイブされたと見なされますが、それでもクラウドプロバイダーがアーカイブする必要があります。これによりエラーは発生しませんが、クエリされる可能性のある一部のデータ・ファイルが無視されます。
   • 30 日後、 delta.timeUntilArchived を 90 daysに更新します。

2. ラグ期間中の現在の間隔を反映するために、設定を毎日更新 delta.timeUntilArchived ことができます。

   • クラウド ポリシーが 90 日に設定されている間、アーカイブされたデータの実際の経過時間はリアルタイムで変化します。 たとえば、7 日後に delta.timeUntilArchived を 67 days に設定すると、アーカイブされたすべてのデータ ファイルの経過時間が正確に反映されます。
   • このアプローチは、ホットティア内のすべてのデータにアクセスする必要がある場合にのみ必要です。

注記

delta.timeUntilArchived の値を更新しても、アーカイブされるデータは変更されません。Databricks がアーカイブされたかのように扱うデータのみが変更されます。