Metadaten und Speicher für Apache Iceberg™-Tabellen¶
Snowflake behandelt Metadaten für Apache Iceberg™ Tabellen je nach Art des von Ihnen verwendeten Katalogs (Snowflake oder extern).
Bemerkung
Die Angabe der standardmäßigen Mindestanzahl von Snapshots über die Tabelleneigenschaft history.expire.min-snapshots-to-keep wird für keinen Typ von Iceberg-Tabelle unterstützt.
Tabellen, die Snowflake als Iceberg-Katalog verwenden¶
Snowflake verwaltet den Lebenszyklus der Metadaten für diesen Tabellentyp und löscht alte Metadaten, Manifestlisten und Manifestdateien auf der Grundlage der Aufbewahrungsfrist für die Tabellendaten und Snapshots.
Um die Aufbewahrungsfrist für Tabellendaten und Snapshots festzulegen, setzen Sie den Parameter DATA_RETENTION_TIME_IN_DAYS auf Konto-, Datenbank-, Schema- oder Tabellenebene.
Erstellung¶
Snowflake generiert in regelmäßigen Abständen Metadaten für Version 2 der Apache Iceberg-Spezifikation und schreibt die Metadaten in Dateien auf Ihrem externen Datenträger. Jede neue Metadatendatei enthält alle DML- oder DDL-Änderungen seit der Erstellung der letzten von Snowflake generierten Metadatendatei.
Sie können Metadaten mit der Funktion SYSTEM$GET_ICEBERG_TABLE_INFORMATION auch bei Bedarf erstellen. Eine Anleitung dazu finden Sie unter Snapshots von DML-Änderungen generieren.
Informationen zur Lokalisierung von Dateien mit Metadaten finden Sie unter Daten- und Metadatenverzeichnisse.
Verlauf der Metadatenerstellung anzeigen¶
Um auf einen vollständigen Verlauf der Versuche zur Metadatengenerierung zuzugreifen, rufen Sie den Abfrageverlauf für Ihr Konto auf und filtern Sie die Ergebnisse. Suchen Sie nach dem SYSTEM$GET_ICEBERG_TABLE_INFORMATION Funktionsnamen im SQL-Text.
Snowflake verwendet intern die gleiche Funktion SYSTEM$GET_ICEBERG_TABLE_INFORMATION zur Generierung von Tabellenmetadaten. Die von Snowflake unternommenen Versuche erscheinen im Abfrageverlauf unter dem Benutzer mit der Bezeichnung SYSTEM. Die Spalte STATUS im Abfrageverlauf zeigt an, ob Metadaten erfolgreich generiert wurden.
Informationen zu den Anzeigeoptionen finden Sie unter Abfrageaktivität mit Abfrageverlauf überwachen.
Löschung¶
Snowflake löscht Iceberg-Metadaten aus Ihrem externen Cloudspeicher, wenn die folgenden Ereignisse eintreten:
Nachdem Sie eine Tabelle gelöscht haben
Wenn sich die Iceberg-Metadaten auf abgelaufene Snapshots oder Tabellendaten beziehen
Die Löschung erfolgt nicht unmittelbar nach Ablauf der Datenaufbewahrungsfrist. Daher können für die Speicherung von Metadaten bei Ihrem Cloudspeicheranbieter Kosten anfallen, die über die Lebensdauer einer Tabelle hinausgehen.
Warnung
Snowflake unterstützt kein Fail-safe für Snowflake-verwaltete Iceberg-Tabellen, da sich die Tabellendaten in einem externen Cloudspeicher befinden, den Sie verwalten. Um die Daten der Iceberg-Tabelle zu schützen, müssen Sie die Datensicherung und -wiederherstellung über Ihren Cloudanbieter konfigurieren.
Nach dem Löschen einer Tabelle¶
Wenn Sie eine Tabelle löschen, können Sie den Befehl UNDROP ICEBERG TABLE verwenden, um sie innerhalb der Datenaufbewahrungsfrist wiederherzustellen.
Wenn die Aufbewahrungsfrist abläuft, löscht Snowflake die Tabellenmetadaten und Snapshots, die geschrieben wurden, von Ihrem externen Volume-Speicherort. Die Löschung erfolgt asynchron und kann nach Ablauf der Aufbewahrungsfrist einige Tage in Anspruch nehmen.
Bemerkung
Bei konvertierten Tabellen löscht Snowflake nur Metadaten, die nach der Tabellenkonvertierung erzeugt wurden.
Nach Ablauf von Snapshots¶
Snowflake löscht Iceberg Metadatendateien, die sich auf abgelaufene Snapshots beziehen, nachdem die Datenaufbewahrungsfrist abgelaufen ist. Die Löschung erfolgt in der Regel 7–14 Tage nach Ablauf eines Snapshots.
Nur frühere Tabellen-Snapshots können ablaufen. Snowflake löscht niemals Metadatendateien, die den letzten (aktuellen) Stand einer Tabelle aus Ihrem externen Cloudspeicher darstellen.
Tabellen, die einen externen Katalog verwenden¶
Bei Tabellen, die einen externen Katalog verwenden, verwendet Snowflake den Wert des Parameters DATA_RETENTION_TIME_IN_DAYS, um eine Aufbewahrungsfrist für Snowflake Time Travel und das Wiederherstellen gelöschter Tabellen festzulegen. Wenn die Aufbewahrungsfrist abläuft, löscht Snowflake nicht die Iceberg Metadaten oder Snapshots aus Ihrem externen Cloudspeicher.
Snowflake setzt DATA_RETENTION_TIME_IN_DAYS auf Tabellenebene auf den kleineren der folgenden Werte:
Der Wert von
history.expire.max-snapshot-age-msin der aktuellen Metadaten-Datei. Snowflake rechnet den Wert in Tage um (Abrundung).Der folgende Wert, je nach Edition des Snowflake-Kontos:
Standard Edition: 1 Tag
Enterprise Edition (oder höher): 5 Tage
Sie können den Wert von DATA_RETENTION_TIME_IN_DAYS in Snowflake nicht manuell ändern. Um den Wert zu ändern, müssen Sie history.expire.max-snapshot-age-ms in Ihrer Metadaten-Datei aktualisieren und dann die Tabelle aktualisieren.
Sie können die folgenden Tabellenfunktionen verwenden, um Informationen über die in einer extern verwalteten Iceberg-Tabelle registrierten Dateien oder den letzten Snapshot-Aktualisierungsverlauf abzurufen:
Delta-basierte Tabellen¶
Bemerkung
Wenn Sie Metadaten-Schreibvorgänge für Delta-basierte Iceberg-Tabellen verwenden möchten, darf das 2025_01 Verhaltensänderungs-Bundle in Ihrem Konto nicht deaktiviert sein.
Für Iceberg-Tabellen, die aus Delta-Tabellendateien erstellt wurden, schreibt Snowflake automatisch Iceberg-Metadaten auf Ihren externen Speicher, wenn Sie Ihr externes Volume mit Schreibzugriff konfigurieren (siehe ALLOW_WRITES). Weitere Informationen über den Schreibort finden Sie unter Daten- und Metadatenverzeichnisse.
Um zu verhindern, dass Snowflake Iceberg-Metadaten schreibt, können Sie den Parameter ALLOW_WRITES auf Ihrem externen Volume auf FALSE einstellen, solange keine von Snowflake verwalteten Iceberg-Tabellen dasselbe externe Volume verwenden.
Iceberg-Partitionierung¶
Dieser Abschnitt beschreibt die Iceberg-Partitionierung.
Snowflake unterstützt die folgenden Anwendungsfälle für die Partitionierung:
Lesen von und Schreiben in partitionierte Iceberg-Tabellen.
Erstellen von partitionierten Iceberg-Tabellen, die von Snowflake oder extern in einer katalogverknüpften Datenbank oder extern von einem Iceberg-REST-Katalog verwaltet werden.
Wenn Sie eine partitionierte Iceberg-Tabelle erstellen, können Sie die versteckte Partitionierung oder Partitionierung mit hierarchischen Pfaden, die auch als „Hive-style“-Partitionierung bezeichnet wird, aktivieren.
Partitionierung mit hierarchischen Pfaden¶
Mit dieser Option schreibt Snowflake Daten in partitionierte Iceberg-Tabellen, indem ein hierarchisches Pfad-Layout für Parquet-Datendateien verwendet wird. Partitionierungsinformationen sind in den Dateipfaden enthalten und die Werte basieren auf Transformationen, die Sie beim Erstellen einer Tabelle definieren. Dieses Layout wird auch als „Hive-style“-Partitionierung bezeichnet. Sie können diese Option für die Interoperabilität zwischen Snowflake und externen Engines verwenden, die partitionierte Schreibvorgänge mit hierarchischen Pfaden unterstützen.
Hier ist ein Beispiel für eine Datendatei, die unter einem hierarchischen Pfad gespeichert ist:
s3://my-bucket/iceberg/db_sales/orders/data/country=US/year=2025/month=02/day=21/part-00023.parquet
Weitere Informationen zum Layout der Daten- und Metadatenverzeichnisse von Tabellen, die hierarchische Pfade verwenden, finden Sie unter Dateiverwaltung.
Erstellen einer Tabelle mit hierarchischen Pfaden¶
Um eine partitionierte Iceberg-Tabelle mit einem hierarchischen Pfad-Layout zu erstellen, legen Sie die folgenden Eigenschaften in Ihrer regulären CREATE ICEBERG TABLE-Anweisung fest:
Setzen Sie PATH_LAYOUT = HIERARCHICAL.
Fügen Sie die PARTITION BY-Klausel mit einem oder mehreren Partitionstransformationen hinzu.
Ein Beispiel für das Erstellen einer partitionierten Iceberg-Tabelle mit einem hierarchischen Pfad-Layout in einer katalogverknüpften Datenbank finden Sie unter Iceberg-Tabelle in einer katalogverknüpften Datenbank mit einem hierarchischen Pfad-Layout erstellen.
Supportmatrix für die Partitionierung¶
Die folgende Tabelle zeigt, welche Features und Aktionen für jeden Typ von partitionierter Iceberg-Tabelle unterstützt werden. Sie weist auch auf Compliance mit Version 2 der Apache Iceberg-Spezifikation hin. Die Tabelle zeigt Unterstützung sowohl für die versteckte Partitionierung als auch für die Partitionierung mit hierarchischen Pfaden.
Bemerkung
Die Unterstützung für Version 3 der Apache Iceberg™-Spezifikation ist in der öffentlichen Vorschau. Diese öffentliche Vorschau beinhaltet Unterstützung für die Verwendung von Löschvektoren mit partitionierten Tabellen. Weitere Informationen zu dieser öffentlichen Vorschau finden Sie unter Apache Iceberg™-Tabellen: Unterstützung für Apache Iceberg™ v3 (Vorschau).
CLD steht für die katalogverknüpfte Datenbank.
Von Snowflake verwaltet |
Extern verwaltet (CLD) |
Extern verwaltete (nicht-CLD) |
Kompatibilität mit Iceberg-Spezifikation V2 |
Kommentar |
|
|---|---|---|---|---|---|
COPY-Befehle mit der Option ON_ERROR = ABORT_STATEMENT |
❌ |
❌ |
❌ |
❌ |
|
COPY INTO <Tabelle> |
Eingeschränkte Unterstützung |
Eingeschränkte Unterstützung |
Eingeschränkte Unterstützung |
Eingeschränkte Unterstützung |
Siehe Nutzungshinweise. |
CREATE ICEBERG TABLE … AS SELECT (CTAS) |
✔ |
✔ |
✔ |
✔ |
|
Klonen |
✔ |
✔ |
✔ |
✔ |
Siehe Nutzungshinweise: |
CREATE ICEBERG TABLE … LIKE |
✔ |
✔ |
✔ |
✔ |
Siehe Nutzungshinweise: |
Löschvektoren |
✔ |
✔ |
✔ |
N/A |
Derzeit in der öffentlichen Vorschau. |
Clustering |
❌ |
❌ |
❌ |
❌ |
|
Partitionsentwicklung |
❌ |
Eingeschränkte Unterstützung |
Eingeschränkte Unterstützung |
Eingeschränkte Unterstützung |
Wir unterstützen die Partitionsentwicklung, sofern sie mit einer externen Engine erfolgt. |
Partitionstransformationen |
✔ |
✔ |
✔ |
✔ |
Informationen zu den unterstützten Partitionstransformationen finden Sie unter: |
Positionsbezogene Löschungen |
✔ |
✔ |
✔ |
✔ |
|
Snowpipe |
Eingeschränkte Unterstützung |
Eingeschränkte Unterstützung |
Eingeschränkte Unterstützung |
Eingeschränkte Unterstützung |
|
Snowpipe Streaming |
❌ |
❌ |
❌ |
❌ |
|
Sortieren innerhalb von Partitionen |
❌ |
❌ |
❌ |
❌ |
|
TARGET_FILE_SIZE |
✔ |
✔ |
✔ |
✔ |
Hinweise zur Partitionierung¶
Beachten Sie Folgendes, bevor Sie partitionierte Schreibvorgänge für Iceberg-Tabellen verwenden:
Wenn Sie eine externe Engine verwenden, um ein Partitionsfeld in einer extern verwalteten Tabelle hinzuzufügen, zu löschen oder zu ersetzen, schreibt Snowflake Daten gemäß der neuesten Partitionsspezifikation.
Die Funktion GET_DDL enthält nicht die PARTITION BY-Klausel in ihrer Ausgabe.
Die Summe der Ausgabengrößen für alle Partitionstransformationen darf 1.024 Bytes für eine einzelne Zeile nicht überschreiten.
Da die Partitionsentwicklung für von Snowflake verwaltete Tabellen nicht unterstützt wird, müssen Sie die Tabelle löschen und eine neue Tabelle mit Partitionierung erstellen.
Die Partitionstransformationsparameter DAY(), MONTH(), YEAR(), die Sie in der PARTITION BY-Klausel unter den Tabelleneigenschaften angeben, sind Teil der Iceber-Spezifikation. Bei mehreren Tagen, Monaten oder Jahren gibt der Parameter für den Partitionsausdruck eine Partition für jeden Kalendertag, –monat oder -jahr zurück. Beispiel: Wenn die DAY()-Transformation für eine Zeitstempelspalte verwendet wird, die Daten von 2 Monaten enthält, werden 61 Partitionen erstellt.
Im Gegensatz dazu sind die Funktionen DAY(), MONTH(), YEAR() in Snowflake Teil des SQL-Standards. Bei mehreren Tagen, Monaten oder Jahren extrahieren diese Funktionen den entsprechenden Tag-, Monats- oder Jahresteil aus einem Datum oder Zeitstempel. Beispiel: Wenn die DAY()-Funktion für eine Zeitstempelspalte verwendet wird, die Daten aus mehrere Monaten enthält, gibt diese Funktion einen Tag des Monats im Bereich von 1 bis 31 zurück.
Sie können den Befehl ALTERICEBERGTABLE nicht zum Ändern der PATH_LAYOUT-Eigenschaft für eine bestehende Tabelle verwenden.
Für die Partitionierung mit hierarchischen Pfaden:
Bei
float-Werten verhalten sich Snowflake und externe Engines möglicherweise unterschiedlich.Snowflake kann nicht garantieren, dass die von Snowflake geschriebenen Pfade mit den von externen Abfrage-Engines geschriebenen Pfaden übereinstimmen.
Snowflake kann dies nicht garantieren, da die Abfrage-Engine, wenn sie einen hierarchischen Pfad schreibt, Werte in eine Zeichenfolge serialisieren und den resultierenden Wert in den Pfad einfügen muss. Die Apache-Iceberg-Tabellenspezifikation definiert keine standardisierte Serialisierungsmethode, sodass verschiedene Engines unterschiedliche Implementierungen verwenden können.
Beispielsweise wird das Zeichen
~von Snowflake nicht kodiert, während Apache Spark™ es als%7Ekodiert.Snowflake schreibt die hierarchischen Pfade immer direkt unter dem Verzeichnis
/datain Ihrem externen Cloudspeicher.
Time Travel¶
Mit Snowflake Time Travel können Sie Snowflake verwenden, um historische Daten für eine Tabelle abzufragen.
Sie können auch eine Compute Engine eines Drittanbieters verwenden, um Time Travel-Abfragen auf von Snowflake verwalteten Tabellen durchzuführen, wenn Sie Eine Snowflake-verwaltete Tabelle mit Snowflake Open Catalog synchronisieren oder Snowflake-Katalog SDK verwenden.
Sie können alle Snapshots abfragen, die innerhalb der Datenaufbewahrungsfrist erstellt wurden. Um die Datenaufbewahrungsfrist festzulegen, stellen Sie den Objektparameter DATA_RETENTION_TIME_IN_DAYS ein.
Wenn Sie Tabellendaten oder eine Tabelle löschen, löscht Snowflake die Objekte nach Ablauf der Aufbewahrungsfrist der Tabelle. Dadurch können bei Ihrem Cloudspeicher-Anbieter Kosten entstehen, die über die Lebensdauer der Tabelle hinausgehen.