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 テーブルに対して次のクエリーが最適化されます。

クエリー

新しい動作

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を満たすのに十分なアーカイブされていないローを見つけます。

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

Databricks for 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 DataFrameとして返します。

注

Delta Lake は、この操作中にトランザクション ログに含まれるデータ統計 (最小値、最大値、null カウント、および最初の 32 列のレコードの合計数) にのみアクセスできます。 戻されるファイルには、述部を満たすレコードがファイル内に存在するかどうかを判別するために読み取る必要があるすべてのアーカイブ・ファイルが含まれます。 Databricks では、復元する必要があるファイルの数を減らすために、可能であれば、データがパーティション分割、Z-ordered、またはクラスター化されているフィールドを含む述語を提供することをお勧めします。

アーカイブされたデータを更新または削除する

アーカイブされたファイル内のデータに影響を与えるMERGE 、 UPDATE 、またはDELETE操作を実行すると、操作は失敗します。 これらの操作を実行するには、高速取得をサポートするストレージ層にデータを復元する必要があります。 SHOW ARCHIVED FILES を使用して、復元する必要があるファイルを特定します。

制限

次の制限があります。

  • ファイルの作成時刻に基づかないライフサイクル管理ポリシーはサポートされていません。 これには、アクセス時間ベースのポリシーとタグベースのポリシーが含まれます。

  • アーカイブされたファイルを含むテーブルで DROP COLUMN を使用することはできません。

  • REORG TABLE APPLY PURGE は最善の努力をしますが、アーカイブされていない削除ベクトルファイルと参照データファイルでのみ機能します。 PURGE アーカイブされた削除ベクトルファイルは削除できません。

  • ライフサイクル管理移行ルールを拡張すると、予期しない動作が発生します。 ライフサイクル管理移行ルールの拡張を参照してください。

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

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

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

ライフサイクル管理移行ルールを拡張する

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

重要

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

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

  1. ポリシーが変更されると、60 日から 90 日経過したすべてのレコードが既にアーカイブされます。

  2. 30 日間、新しいファイルはアーカイブされません (最も古いアーカイブされていないファイルは、ポリシーが拡張された時点で 60 日経過しています)。

  3. 30 日が経過すると、ライフサイクルポリシーはアーカイブされたすべてのデータを正しく記述します。

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

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

    • 上記の例に従うと、最初の 30 日間は毎日、別の日分のデータは Databricks によってアーカイブされたと見なされますが、クラウド プロバイダーによってはまだアーカイブされていません。 これはエラーにはなりませんが、クエリーになる可能性のある一部のデータファイルを無視します。

    • 30 日後、 delta.timeUntilArchived を 90 daysに更新します。

  2. 設定 delta.timeUntilArchived を毎日更新して、ラグ期間中の現在の間隔を反映できます。

    • クラウド ポリシーは 90 日に設定されていますが、アーカイブされたデータの実際の保存期間はリアルタイムで変化します。 たとえば、7 日後、 delta.timeUntilArchived を 67 days に設定すると、アーカイブ内のすべてのデータ ファイルの経過時間が正確に反映されます。

    • この方法は、ホット層のすべてのデータにアクセスする必要がある場合にのみ必要です。

注

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