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でのマルチクラスター書き込みの制限は何ですか?

このモードで実行している場合、次の機能はサポートされません。

マルチクラスター書き込みを無効にするには、 spark.databricks.delta.multiClusterWrites.enabled を falseに設定します。 無効になっている場合、1 つのテーブルへの書き込みは 1 つのクラスターから開始 する必要があります 。

警告

spark.databricks.delta.multiClusterWrites.enabled を無効にし、 複数の クラスターから同じ Delta テーブルを同時に変更すると、データの損失や破損が発生する可能性があります。

削除した Delta Lake データが S3 に保存されているのはなぜですか?

Delta Lake を使用していて、S3 バケットでバケットのバージョニングを有効にしている場合は、テーブルファイルを管理する 2 つのエンティティがあります。 Databricks では、 VACUUM コマンドで未使用のデータ ファイルを効果的に削除できるように、バケットのバージョン管理を無効にすることをお勧めします。

rm -rf で Delta Lake ファイルを削除し、同じ場所に新しいテーブルを作成した後、テーブルに古いデータが表示されるのはなぜですか?

S3 での削除は、結果的にのみ一貫性があります。 したがって、テーブルを削除した後も、古いバージョンのトランザクションログがしばらく表示される場合があります。 これを回避するには、テーブル パスを削除した後に再利用しないでください。 代わりに、 DELETE FROM、 overwrite、 overwriteSchema などのトランザクションメカニズムを使用して、テーブルを削除および更新することをお勧めします。 「 テーブルを置き換えるためのヒント集」を参照してください。