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 として返します。 オブジェクトストレージプロバイダーからの文書化された指示に従って、必要なアーカイブファイルを復元します。 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 日に変更されたシナリオを考えてみましょう。

  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 がアーカイブされているものとして扱うデータのみが変更されます。