Transactionele schrijfgegevens naar cloudopslag met DBIO

Het Databricks DBIO-pakket biedt transactionele schrijftaken naar cloudopslag voor Apache Spark taken. Hiermee lost u een aantal prestatie- en juistheidsproblemen op die zich voordoen wanneer Spark wordt gebruikt in een cloudeigen instelling (bijvoorbeeld door rechtstreeks naar opslagservices te schrijven).

Belangrijk

Het commit-protocol wordt niet in acht genomen wanneer u toegang krijgt tot gegevens via paden die eindigen op * . Lezen retourneerde bijvoorbeeld alleen doorgevoerde wijzigingen, terwijl lezen de inhoud van alle gegevensbestanden in de map retourneerde, ongeacht of de inhoud is doorgevoerd dbfs://my/path dbfs://my/path/* of niet. Dit is een verwacht gedrag.

Bij transactionele DBIO-door commit worden metagegevensbestanden die beginnen met en _started_<id> _committed_<id> de bijbehorende gegevensbestanden die zijn gemaakt door Spark-taken, bijgevoegd. Over het algemeen moet u deze bestanden niet rechtstreeks wijzigen. In plaats daarvan moet u de VACUUM opdracht gebruiken om ze op te schonen.

Niet-opgenomen bestanden ops schonen

Als u niet-doorgestuurde bestanden wilt ops schonen die overblijft van Spark-taken, gebruikt u VACUUM de opdracht om ze te verwijderen. Normaal VACUUM gesproken gebeurt dit automatisch nadat Spark-taken zijn voltooid, maar u kunt deze ook handmatig uitvoeren als een taak wordt afgebroken.

Hiermee verwijdert u VACUUM ... RETAIN 1 HOUR bijvoorbeeld niet-opgenomen bestanden ouder dan één uur.

Belangrijk

  • Vermijd vacuuming met een horizon van minder dan één uur. Dit kan leiden tot inconsistentie van gegevens.

Zie ook Vacuum.

SQL

-- recursively vacuum an output path
VACUUM '/path/to/output/directory' [RETAIN <N> HOURS]

-- vacuum all partitions of a catalog table
VACUUM tableName [RETAIN <N> HOURS]

Scala

// recursively vacuum an output path
spark.sql("VACUUM '/path/to/output/directory' [RETAIN <N> HOURS]")

// vacuum all partitions of a catalog table
spark.sql("VACUUM tableName [RETAIN <N> HOURS]")