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

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

クラウドライフサイクルポリシーは、古いファイルをアーカイブストレージ層に移動することでストレージコストを削減します。 アーカイブサポートがなければ、ライフサイクルポリシーはDelta Lakeテーブルに対するクエリを壊すことがあります。なぜなら、クエリが読み取るデータファイルが利用できなくなるからです。 「なぜアーカイブサポートを有効にするべきか?」をご覧ください。

アーカイブ サポートを使用するタイミング

以下すべてが正しい場合にテーブルのアーカイブサポートを有効にする:

• ファイル作成時間に基づいてテーブルのデータファイルをアーカイブするライフサイクルポリシーを使用します。
• テーブルに対するほとんどのクエリは、最近のデータを読み取るか、アーカイブされたファイルを除外します。
• アーカイブデータが必要なクエリは稀であり、クラウドプロバイダーのストレージ内のそれらのファイルを誰かが復元するまで待ってから、クエリを再実行できます。 アーカイブされたファイルの復元を参照してください。

クエリが定期的にテーブルの全履歴をスキャンする場合は、アーカイブサポートは使わないでください。 アーカイブファイルが必要なクエリは失敗します。 アーカイブサポートはアクセス時間やタグに基づくライフサイクルポリシーには対応しません。 「制限事項」を参照してください。

必要条件

Azure Databricks は、Azure Archive のアーカイブ サポートのみに対応します。 「ライフサイクル管理によるコストの最適化に関する Azure ドキュメント」を参照してください。

アーカイブ サポートを有効にする必要がある理由

アーカイブサポートでは、アーカイブファイルに触れずに正しい結果を返すクエリのみが許可されています。 これらのクエリには、次のいずれかが含まれます。

• メタデータに対してのみ実行されるクエリ。
• アーカイブ済みファイルをスキャンせずに済むフィルターを設定します。

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

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

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

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

初期不良とエラー メッセージ

正しい結果を得るためにアーカイブファイルをスキャンする必要があるクエリでは、デルタレイクのアーカイブサポートを設定することで以下の効果があります:

• アーカイブ済みファイルにアクセスしようとすると、クエリは早い段階で失敗するため、無駄なコンピューティングが削減され、ユーザーはクエリを迅速に適宜調整して再実行できます。
• エラー メッセージは、クエリがアーカイブ ファイルにアクセスしようとしたためにクエリが失敗したことをユーザーに通知します。

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

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

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

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

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

クラウド アカウントで新しいライフサイクル ポリシーを設定すると、変更が有効になるまでに最大 24 時間かかることがあります。 ライフサイクル管理ポリシーの実行を参照してください。

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

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

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

SHOW ARCHIVED FILES FOR table_name [ WHERE predicate ];

この操作は、アーカイブされたファイルのファイル名を含むSpark DataFrameを返します。 オブジェクト ストレージ プロバイダーのドキュメントに記載された指示に従って、必要なアーカイブ済みファイルを復元します。 アーカイブされたファイルの復元を参照してください。

復元されたデータを Azure Databricks で確認する方法の詳細については、「復元されたデータを Azure Databricks でサンプリングする方法」を参照してください。

アーカイブされたファイルを復元する

復元が必要なすべてのファイルを識別するには、 SHOW ARCHIVED FILES を使用してアーカイブされたファイルの一覧を表示します。

リハイドレート API を使用して、オンライン ストレージ層にファイルを復元します。 アーカイブ層からの Blob のリハイドレートを参照してください。

クラウド プロバイダー ストレージ内のファイルを復元した後、テーブルに対してクエリを実行できます。 アーカイブ サポートは、復元されたファイルを自動的に認識します。 復元されたデータを Azure Databricks で確認する方法の詳細については、「復元されたデータを Azure Databricks でサンプリングする方法」を参照してください。

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

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

復元されたデータを Azure Databricks でサンプリングする方法

Azure Databricks は、アーカイブ サポートが有効になっているテーブルのスキャンを準備する際、ファイルが復元されたかどうかを確認するために、クエリで必要な指定された保持期間よりも古いファイルをサンプリングします。 結果が、アーカイブされていると推定されるサンプル ファイルが復元されたことを示す場合、Azure Databricks はクエリの対象となるすべてのファイルが復元されていると見なし、クエリを処理します。 結果には、アーカイブ対象としてマークされたファイルのデータが含まれます。

サンプリングはすべてのクエリに適用されない場合があります。 制限事項を参照してください。

制限事項

アーカイブサポートには以下の制限があります:

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

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

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

アーカイブ前の時間間隔が短縮された場合(ファイル作成からの時間が短くなる)、テーブルプロパティが更新された後もデルタレイクテーブルのアーカイブサポートは通常通り機能します。

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

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

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

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

delta.timeUntilArchived 設定は、Delta トランザクション ログによって記録されたファイル作成時間に対して設定された時間間隔を追跡します。 基礎となるポリシーについての明示的な知識はありません。 古いアーカイブ閾値と新しいアーカイブ閾値の間の遅延期間中は、アーカイブ済みファイルへのクエリを避けるには、以下のいずれかの方法を取ることができます:

1. すべてのファイルがアーカイブされるのに十分な時間が経過するまで、設定 delta.timeUntilArchived を古いしきい値のままにしておくことができます。
   • 上記の例に従って、最初の 30 日間は毎日、別の日分のデータは Azure Databricks によってアーカイブされたと見なされますが、クラウド プロバイダーによってアーカイブされる必要があります。 これによりエラーは発生しませんが、クエリが実行される可能性のある一部のデータ ファイルが無視されます。
   • 30 日後、delta.timeUntilArchived を 90 days に更新します。
2. ラグ期間中の現在の間隔を反映するために、設定 delta.timeUntilArchived を毎日更新できます。
   • クラウド ポリシーは 90 日に設定されていますが、アーカイブ済みデータの実際の経過期間はリアルタイムで変化します。 たとえば、7 日後に delta.timeUntilArchived を 67 days に設定すると、すべてのアーカイブ済みデータ ファイルの経過期間が正確に反映されます。
   • このアプローチは、ホット層内のすべてのデータにアクセスする必要がある場合にのみ必要です。