Azure Databricks でのアーカイブ サポート
重要
この機能は、Databricks Runtime 13.3 LTS 以降のパブリック プレビュー段階にあります。
Azure Databricks でのアーカイブ サポートでは、Delta テーブルを含むクラウド オブジェクト ストレージでクラウドベースのライフサイクル ポリシーを使用できるようにする一連の機能が導入されています。
重要
Azure Databricks は、Azure Archive のアーカイブ サポートのみに対応します。 「ライフサイクル管理によるコストの最適化に関する Azure ドキュメント」を参照してください。
アーカイブ サポートを有効にする必要がある理由
アーカイブ サポートでは、アーカイブ済みファイルに触れることなく正しく応答できるクエリのみが許可されます。 これらのクエリには、次のいずれかが含まれます。
- メタデータに対してのみ実行されるクエリ。
- アーカイブ済みファイルをスキャンする必要のないフィルターがあるクエリ。
アーカイブされたファイル内のデータを必要とするすべてのクエリは失敗します。
重要
Azure Databricks は、正しい結果を返すためにアーカイブされたファイルを必要とするクエリの結果を返しません。
アーカイブ サポートが有効ではない場合、データ ファイルまたはトランザクション ログ ファイルがアーカイブ済みの場所に移動され、クエリの実行時に使用できないため、Delta テーブルに対する操作が中断される可能性があります。 アーカイブ サポートには、可能な場合にアーカイブ済みデータに対するクエリを回避するための最適化が導入されています。 また、クエリを完了するためにアーカイブ ストレージから復元する必要があるファイルを識別するための新しい構文も追加されています。
Azure Databricks でテーブルのアーカイブ サポートを有効にしても、クラウド オブジェクト ストレージ用に定義されたライフサイクル ポリシーは作成または変更されません。 目的の結果を得るには、クラウド ライフサイクル ポリシーと delta.timeUntilArchived
設定が同一である必要があります。
アーカイブされたデータ用に最適化されたクエリ
Azure 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
句を減らします。
アーカイブ サポートを有効にする
Azure Databricks で Delta テーブルのアーカイブ サポートを有効にするには、次の構文例のように、基盤となるクラウド ライフサイクル管理ポリシーで構成されたアーカイブ間隔を手動で指定します。
ALTER TABLE <table_name> SET TBLPROPERTIES(delta.timeUntilArchived = 'X days');
アーカイブ サポートを有効にすると、Azure Databricks に対して、指定した期間よりも古いファイルを無視するように効果的に指示できます。 クラウド オブジェクト ストレージのライフサイクル ポリシーを設定しないでこの設定を有効にした場合でも、Azure Databricks は、この指定されたしきい値に基づいてファイルを無視しますが、データはアーカイブされません。
Delta Lake は、クラウド アカウントで構成されたライフサイクル管理ポリシーと直接やり取りしません。 クラウド アカウントでポリシーを更新する場合は、Delta テーブルのポリシーも更新する必要があります。 「ライフサイクル管理移行ルールの変更」を参照してください。
重要
アーカイブ サポートは、互換性のある Azure Databricks コンピューティング環境に完全に依存しており、Delta テーブルに対してのみ機能します。 アーカイブ サポートを構成しても、OSS Delta Lake クライアントまたは Databricks Runtime 12.2 LTS 以前の動作、互換性、サポートは変更されません。
アーカイブされたファイルを表示する
特定のクエリを完了するために復元する必要があるファイルを特定するには、次の例のように SHOW ARCHIVED FILES
を使用します。
SHOW ARCHIVED FILES FOR table_name [ WHERE predicate ];
この操作は、アーカイブされたファイルの URI を Spark DataFrame として返します。 オブジェクト ストレージ プロバイダーのドキュメントに記載された指示に従って、必要なアーカイブ済みファイルを復元します。 復元されたデータを Azure Databricks で確認する方法の詳細については、「復元されたデータを Azure Databricks でサンプリングする方法」を参照してください。
Note
この操作中、Delta Lake がアクセスできるのは、トランザクション ログに含まれているデータ統計のみです。 既定では、これらは、テーブルの最初の 32 個の列で収集される次の統計情報です。
- 最小値
- 最大値
- null の数
- レコードの数の合計
返されるファイルには、述語を満たすレコードがファイル内に存在するかどうかを判断するために読み取る必要があるすべてのアーカイブ済みファイルが含まれます。 Databricks では、復元する必要があるファイルの数を減らすために、データがパーティション分割、Z オーダー処理、またはクラスター化されるフィールドを含む述語を提供することを推奨しています。
アーカイブされたデータを更新または削除する
アーカイブ済みファイル内のデータに影響を与える MERGE
、UPDATE
、または DELETE
操作を実行すると、操作は失敗します。 これらの操作を実行するには、高速取得をサポートするストレージ層にデータを復元する必要があります。 SHOW ARCHIVED FILES
を使用して、復元する必要があるファイルを決定します。
復元されたデータを Azure Databricks でサンプリングする方法
Azure Databricks は、アーカイブ サポートが有効になっているテーブルのスキャンを準備する際、ファイルが復元されたかどうかを確認するために、クエリで必要な指定された保持期間よりも古いファイルをサンプリングします。
結果が、アーカイブされていると推定されるサンプル ファイルが復元されたことを示す場合、Azure 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 日分のデータが Azure Databricks によってアーカイブ済みと見なされますが、それらはまだクラウド プロバイダーによってアーカイブされていません。 これによりエラーは発生しませんが、クエリが実行される可能性のある一部のデータ ファイルが無視されます。
- 30 日後、
delta.timeUntilArchived
を90 days
に更新します。
- ラグ期間中の現在の間隔を反映するために、設定
delta.timeUntilArchived
を毎日更新できます。- クラウド ポリシーは 90 日に設定されていますが、アーカイブ済みデータの実際の経過期間はリアルタイムで変化します。 たとえば、7 日後に
delta.timeUntilArchived
を67 days
に設定すると、すべてのアーカイブ済みデータ ファイルの経過期間が正確に反映されます。 - このアプローチは、ホット層内のすべてのデータにアクセスする必要がある場合にのみ必要です。
- クラウド ポリシーは 90 日に設定されていますが、アーカイブ済みデータの実際の経過期間はリアルタイムで変化します。 たとえば、7 日後に
Note
delta.timeUntilArchived
の値を更新しても、アーカイブされるデータは変更されません。 Azure Databricks がアーカイブされたものとして扱うデータのみが変更されます。