Partitionnement pour les tables Delta

Le partitionnement de style Hive divise une table Delta en sous-répertoires physiques en fonction des valeurs d’une ou plusieurs colonnes de partition. Chaque combinaison unique de valeurs de colonne de partition crée un répertoire distinct. Cette structure permet l’élagage des partitions : le moteur ignore des répertoires entiers lorsqu’une requête filtre sur la colonne de partition.

Quand utiliser le partitionnement

Le cas d’usage principal pour le partitionnement dans Delta Lake permet d’effectuer des opérations d’écriture simultanées qui ne sont pas en conflit. Delta Lake utilise un contrôle d’accès concurrentiel optimiste, et deux opérations qui touchent les mêmes fichiers peuvent entrer en conflit. Le partitionnement permet aux opérations simultanées de cibler des ensembles de fichiers disjoints en fonctionnant sur des partitions distinctes.

Utilisez le partitionnement quand :

• Vous avez des processus d’écriture concurrents qui doivent mettre à jour, supprimer ou fusionner des données dans la même table sans entrer en conflit, par exemple plusieurs pipelines qui traitent simultanément différentes unités commerciales ou régions.
• Votre colonne de partition a une cardinalité faible à modérée (des dizaines à des centaines de valeurs distinctes, et non des milliers). Remarque : les tables plus volumineuses peuvent prendre en charge davantage de partitions. Ciblez au moins 1 Go de données dans chaque partition.
• Les valeurs de partition s’alignent sur vos modèles d’écriture : chaque enregistreur cible naturellement une partition spécifique.

Créer une table partitionnée

CREATE TABLE sales.orders (
    order_id BIGINT,
    order_date DATE,
    region STRING,
    amount DECIMAL(10,2)
)
USING DELTA
PARTITIONED BY (region)

from delta.tables import DeltaTable

DeltaTable.create(spark) \
    .tableName("sales.orders") \
    .addColumn("order_id", "BIGINT") \
    .addColumn("order_date", "DATE") \
    .addColumn("region", "STRING") \
    .addColumn("amount", "DECIMAL(10,2)") \
    .partitionedBy("region") \
    .execute()

import io.delta.tables.DeltaTable

DeltaTable.create(spark)
    .tableName("sales.orders")
    .addColumn("order_id", "BIGINT")
    .addColumn("order_date", "DATE")
    .addColumn("region", "STRING")
    .addColumn("amount", "DECIMAL(10,2)")
    .partitionedBy("region")
    .execute()

Partitionnement et écritures simultanées

Le partitionnement est le mécanisme principal dans Delta Lake pour éviter les conflits entre les opérations d’écriture simultanées. Lorsqu’une table est partitionnée, les opérations qui ciblent différentes partitions fonctionnent sur des ensembles disjoints de fichiers et ne sont pas en conflit entre elles.

Par exemple, deux opérations simultanées MERGE INTO sur une table partitionnée region par n’entrent pas en conflit tant que chaque région cible une région différente, à condition que la colonne de partition soit explicitement incluse dans la condition de fusion :

-- Pipeline A: processes North America only
MERGE INTO sales.orders AS target
USING staged_orders AS source
ON target.order_id = source.order_id
    AND target.region = 'NA'
    AND source.region = 'NA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *

spark.sql("""
MERGE INTO sales.orders AS target
USING staged_orders AS source
ON target.order_id = source.order_id
    AND target.region = 'NA'
    AND source.region = 'NA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
""")

spark.sql("""
MERGE INTO sales.orders AS target
USING staged_orders AS source
ON target.order_id = source.order_id
    AND target.region = 'NA'
    AND source.region = 'NA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
""")

Sans partitionnement ou sans inclure la colonne de partition dans la condition d’opération, ces mêmes opérations peuvent entrer en conflit même si elles modifient logiquement différentes lignes. La colonne de partition doit apparaître dans la condition de fusion elle-même, pas seulement dans les données sources. Sans cela, Delta Lake ne peut pas déterminer au moment de la validation que les deux opérations touchaient des jeux de fichiers disjoints.

Pour un guide complet des types de conflits et des stratégies de résolution, consultez le contrôle de la concurrence.

Pièges courants

• Les colonnes de partition de cardinalité élevée (par exemple, user_id avec des millions de valeurs) créent des milliers de petits répertoires et fichiers, qui dégradent les performances d’écriture et de lecture.
  • Les colonnes de date doivent être choisies avec précaution. Pour de nombreuses tables, le partitionnement par colonne de date entraîne un trop grand nombre de petites partitions. Ciblez au moins 1 Go de données dans chaque partition.
• Les colonnes de partition ne peuvent pas être modifiées après la création de la table sans réécriture de la table entière.
• Le problème de petit fichier est courant avec la diffusion en continu ou les ajouts fréquents dans de nombreuses partitions, car chaque écriture crée au moins un fichier par partition.
• Le partitionnement et le clustering liquide sont incompatibles sur la même table. Vous devez choisir une stratégie.

Comparer le partitionnement et le clustering liquide

Contenu connexe

• Contrôle de la concurrence
• Agrégation liquide
• Z-Order
• Compactage de table
• Saut de fichier
• Ordre en V
• Maintenance de la table Delta