Iceberg-Optimierung: Sortierung und Löschvektoren

Optimierung von Iceberg-Tabellen: Sortierung, Statistiken und Löschvektoren

Das Sortieren von Daten beim Schreiben in Iceberg-Tabellen ermöglicht es Ausführungs-Engines, unnötige Dateien basierend auf Min-/Max-Statistiken in Manifest-Dateien zu überspringen. Ohne Sortierung überlappen sich Wertebereiche in Dateien, was dazu führt, dass alle Daten gelesen werden, selbst bei strenger Filterung.

Beispiel für das Erstellen einer Tabelle und Schreiben ohne Sortierung:

spark.sql("""
CREATE TABLE habr.paper.write_ordered (
  id INT,
  name STRING,
  event STRING
)
USING ICEBERG
""")

data = [(i, f"name_{i}", f"event_{i}") for i in range(1, 1000000)]
df = spark.createDataFrame(data, ["id", "name", "event"]).repartition(16)
df.writeTo("habr.paper.write_ordered").append()

Die Abfrage von Metadaten zeigt chaotische Bereiche:

| id_min | id_max | file_path |

|--------|--------|-----------|

| 2 | 999994 | ... |

| 43 | 999988 | ... |

Ein Filter mit id < 100000 liest alle Dateien.

Aktivierung der Sortierung:

spark.sql("""
ALTER TABLE habr.paper.write_ordered
WRITE ORDERED BY id
""")

Das Umschreiben ergibt sequenzielle Bereiche:

| id_min | id_max | file_path |

|--------|--------|-----------|

| 1 | 196479 | ... |

| 196480 | 395983 | ... |

Jetzt liest ein Filter mit id < 196470 nur eine Datei.

Konfiguration der Spaltenstatistikerfassung

Iceberg erfasst standardmäßig vollständige Min-/Max-/gekürzte Statistiken für alle Spalten, was die Schreibzeit erhöht, ohne Abfragen zu nutzen. In typischen Tabellen erfolgt die Filterung auf 1-2 Spalten, wodurch Statistiken für andere unnötig sind.

Beispiel einer flachen Tabelle mit 10 Spalten:

spark.sql("""
CREATE TABLE habr.paper.typical_flat_table (
  id INT,
  name STRING,
  col_1 STRING,
  col_2 STRING,
  col_3 STRING,
  col_4 STRING,
  col_5 STRING,
  col_6 STRING,
  col_7 STRING,
  col_8 STRING
)
USING ICEBERG
""")

Konfiguration über TBLPROPERTIES:

spark.sql("""
ALTER TABLE habr.paper.typical_flat_table SET TBLPROPERTIES (
    'write.metadata.metrics.default' = 'counts',
    'write.metadata.metrics.column.id' = 'full',
    'write.metadata.metrics.column.col_1' = 'none'
)
""")

• default: 'counts' – nur Zeilenanzahlen für alle Spalten
• full: Min/Max + gekürzt für kritische Filter (id)
• none: deaktiviert für ungenutzte Spalten

Dies reduziert den Schreibaufwand und das Metadatenvolumen, ohne das Überspringen von Daten in Schlüsselfeldern zu verlieren.

Vektorisierte Löschung in MoR

In der Merge-on-Read-Strategie hängt die Leseleistung vom Löschanwendungsmechanismus ab. Klassische Löschdateien erfordern Joins mit Daten.

Arten von Löschdateien:

• Equality delete: Löschregeln (in v3 veraltet)
• Position delete: Zeilenpositionen in Dateien

Mit Iceberg v3 hat sich Position delete zu Löschvektoren basierend auf dem Puffin-Format entwickelt. Ein Löschvektor ist eine Bitmap-Maske, die in einem Zyklus auf eine Datendatei angewendet wird.

Beispiel für Position delete:

| file_path | pos |

|-----------|-----|

| ...parquet | 873 |

| ...parquet | 230 |

Anstatt eines Joins: Bitmap laden + logische UND-Operation. Dies beschleunigt das Lesen von MoR-Tabellen um das 5-10-fache bei hohem Löschanteil.

Löschvektoren sind besonders effektiv für:

• Batch-ETL mit häufigen Updates
• Tabellen mit langsam veränderlichen Dimensionen
• Streaming mit MoR

Wichtige Erkenntnisse

• Sortierung mit WRITE ORDERED BY auf filterbaren Spalten reduziert lesbare Dateien in der Analyse
• Konfiguration von write.metadata.metrics.* minimiert Schreibaufwand und erhält das Überspringen von Daten
• Löschvektoren in Iceberg v3 ersetzen Position delete und beschleunigen MoR-Lesen über Bitmap
• Optimierungen funktionieren ohne Änderung von Abfragen oder ETL-Logik
• Effekte kumulieren: weniger Dateien, weniger Metadaten, reduzierte Objektspeicherlast

— Editorial Team