Optimisation Iceberg : tri et vecteurs de suppression

Optimisation des tables Iceberg : Tri, statistiques et vecteurs de suppression

Le tri des données lors de l'écriture dans les tables Iceberg permet aux moteurs d'exécution d'ignorer les fichiers inutiles grâce aux statistiques min/max dans les fichiers manifeste. Sans tri, les plages de valeurs dans les fichiers se chevauchent, ce qui oblige à lire toutes les données même avec un filtrage strict.

Exemple de création d'une table et d'écriture sans tri :

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()

L'interrogation des métadonnées montre des plages chaotiques :

| id_min | id_max | file_path |

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

| 2 | 999994 | ... |

| 43 | 999988 | ... |

Un filtre avec id < 100000 lira tous les fichiers.

Activation du tri :

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

La réécriture donne des plages séquentielles :

| id_min | id_max | file_path |

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

| 1 | 196479 | ... |

| 196480 | 395983 | ... |

Maintenant, un filtre avec id < 196470 ne lit qu'un seul fichier.

Configuration de la collecte de statistiques par colonne

Iceberg collecte par défaut des statistiques complètes min/max/tronquées pour toutes les colonnes, ce qui augmente le temps d'écriture sans bénéficier aux requêtes. Dans les tables typiques, le filtrage se fait sur 1-2 colonnes, rendant les statistiques inutiles pour les autres.

Exemple d'une table plate avec 10 colonnes :

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
""")

Configuration via 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' — uniquement le nombre de lignes pour toutes les colonnes
• full : min/max + tronqué pour les filtres critiques (id)
• none : désactivé pour les colonnes inutilisées

Cela réduit la surcharge d'écriture et le volume des métadonnées sans perdre le saut de données sur les champs clés.

Suppression vectorisée en MoR

Dans la stratégie Merge-on-Read, les performances de lecture dépendent du mécanisme d'application des suppressions. Les fichiers de suppression classiques nécessitent des jointures avec les données.

Types de fichiers de suppression :

• Suppression par égalité : règles de suppression (obsolète en v3)
• Suppression par position : positions des lignes dans les fichiers

Avec Iceberg v3, la suppression par position a évolué en vecteurs de suppression basés sur le format Puffin. Un vecteur de suppression est un masque bitmap appliqué en un cycle à un fichier de données.

Exemple de suppression par position :

| file_path | pos |

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

| ...parquet | 873 |

| ...parquet | 230 |

Au lieu d'une jointure : charger le bitmap + opération logique ET. Cela accélère la lecture des tables MoR de 5 à 10 fois avec un pourcentage élevé de suppressions.

Les vecteurs de suppression sont particulièrement efficaces pour :

• L'ETL par lots avec mises à jour fréquentes
• Les tables avec dimensions à évolution lente
• Le streaming avec MoR

Points clés à retenir

• Le tri avec WRITE ORDERED BY sur les colonnes filtrables réduit les fichiers lisibles dans l'analyse
• La configuration de write.metadata.metrics.* minimise la surcharge d'écriture tout en préservant le saut de données
• Les vecteurs de suppression dans Iceberg v3 remplacent la suppression par position, accélérant la lecture MoR via bitmap
• Les optimisations fonctionnent sans modifier les requêtes ou la logique ETL
• Les effets s'accumulent : moins de fichiers, moins de métadonnées, charge réduite sur le stockage objet

— Editorial Team