S3 での Delta Lake の制限
この記事では、Databricks 上の Delta Lake を使用して S3 に格納されたデータを操作する際に発生する可能性のあるいくつかの制限について詳しく説明します。 Amazon S3で使用される結果整合性モデルは、複数のシステムまたはクラスターが同じテーブル内のデータを同時に変更するときに、潜在的な問題を引き起こす可能性があります。
Databricks と Delta Lake は デフォルト によるマルチクラスター書き込みをサポートしているため、複数のクラスターからテーブルに同時に書き込むクエリによってテーブルが破損することはありません。 S3 に格納されている Delta テーブルの場合、この保証は 1 つの Databricks ワークスペースに制限されます。
データ破損やデータ損失の問題を回避するために、Databricks では、S3 に格納されている同じ Delta テーブルを異なるワークスペースから変更しないことをお勧めします。
バケットのバージョニングと Delta Lake
S3 バケットのバージョニングを使用して、Delta Lake で保存されたデータに追加の冗長性を提供できます。 Databricks では、3 つのバージョンを保持し、バージョン管理が有効になっているすべての S3 バケットのバージョンを 7 日以内保持するライフサイクル管理ポリシーを実装することをお勧めします。
バージョニングが有効になっているバケットに格納されたテーブルでパフォーマンスの低下が発生した場合は、Databricks サポートに連絡する際に、バケットのバージョニングが有効になっていることを示してください。
S3でのマルチクラスター書き込みの制限は何ですか?
このモードで実行している場合、次の機能はサポートされません。
- 顧客提供の暗号化キーによるサーバー側の暗号化
- AWSSecurityS3 トークン サービス にアクセスできないクラスター内の資格情報を持つパス
マルチクラスターの書き込みを無効にするには、 spark.databricks.delta.multiClusterWrites.enabled を falseに設定します。 無効になっている場合、1 つのテーブルへの書き込み は 1 つのクラスターから行う必要があります。
spark.databricks.delta.multiClusterWrites.enabledDelta を無効にし、 複数の クラスターから同じ テーブルを同時に変更すると、データの損失や破損につながる可能性があります。
削除したDelta LakeのデータがS3にまだ保存されているのはなぜですか?
Delta Lake を使用していて、S3 バケットでバケットのバージョニングを有効にしている場合は、テーブルファイルを管理する 2 つのエンティティがあります。 Databricks では、 VACUUM コマンドで未使用のデータ ファイルを効果的に削除できるように、バケットのバージョン管理を無効にすることをお勧めします。
Delta Lake のファイルを rm -rf で削除し、同じ場所に新しいテーブルを作成した後、テーブルに古いデータが表示されるのはなぜですか?
S3 での削除は、結果整合性のみとなります。 したがって、テーブルを削除した後も、古いバージョンのトランザクション ログがしばらくの間表示される場合があります。 これを回避するには、テーブル パスを削除した後で再利用しないでください。 代わりに、 DELETE FROM、 overwrite、 overwriteSchema などのトランザクションメカニズムを使用して、テーブルを削除および更新することをお勧めします。 「テーブルを置き換えるためのベスト プラクティス」を参照してください。