Quand partitionner des tables sur Azure Databricks ?

Remarque

Databricks recommande un clustering liquide pour toutes les tables managées. Pour les tables managées à l’aide d’Apache Iceberg, Unity Catalog prend uniquement en charge le clustering liquide et interprète les PARTITION BY colonnes comme clés de clustering. Consultez Convertir une table partitionnée en Liquid Clustering.

La plupart des tables sur Azure Databricks avec moins de 100 To de données n'ont pas besoin de partitionnement. Azure Databricks utilise Delta Lake pour toutes les tables par défaut et regroupe automatiquement les données des tables non partitionnées au moment de l’ingestion, ce qui vous permet d’obtenir des performances comparables à celles du partitionnement sans ajustement manuel. Envisagez une stratégie de partitionnement personnalisée uniquement lorsqu’elle dépasse ces valeurs par défaut. Consultez Utiliser le clustering au moment de l’ingestion.

Stratégies de partitionnement personnalisées

Les utilisateurs avancés d’Apache Spark et de Delta Lake peuvent identifier une stratégie de partitionnement plus performante que le partitionnement par heure d’ingestion par défaut.

Warning

Une stratégie de partitionnement inefficace peut affecter négativement les performances des requêtes et nécessiter une réécriture complète des données à corriger. Une réécriture complète peut être très coûteuse et lente pour les grandes tables.

Avant d’utiliser des stratégies de partitionnement personnalisées, Databricks recommande un clustering liquide pour toutes les tables et l’optimisation prédictive pour les tables gérées par le catalogue Unity. Consultez Utiliser le clustering liquide pour les tables et l’optimisation prédictive pour les tables gérées par le catalogue Unity.

Pour convertir une table Delta Lake partitionnée existante en clustering liquide, utilisez ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY. Le clustering liquide fonctionne à la fois pour les colonnes à cardinalité faible et élevée et évite les limites de partition fixes et les problèmes de petit fichier courants avec le partitionnement statique. Consultez Convertir une table partitionnée en Liquid Clustering.

Types de données pris en charge pour les colonnes de partition

Le partitionnement prend en charge ces types de données pour les colonnes de partition :

• Date
• Timestamp
• TimestampNTZ
• Intervalle
• String
• Binary
• Boolean
• Integer, Long, Short, Byte
• Float, Double, Decimal

Les colonnes de partition doivent être des colonnes de niveau supérieur. Vous ne pouvez pas partitionner par l’un des éléments suivants :

• Types complexes, tels que StructType, , MapTypeArrayType, ouVariantType
• Champs de structure, comme struct_col.field. Delta Lake traite un champ de struct dans PARTITIONED BY comme une expression plutôt que comme une référence de colonne.

Pour organiser une table par champ de struct, utilisez plutôt le Liquid Clustering, qui reconnaît un champ de struct comme clé de clustering. Le Liquid Clustering est le seul moyen d’effectuer un saut de données pour un champ de struct sans d’abord l’extraire en colonne de premier niveau. Consultez Utilisation de Liquid Clustering pour les tables.

Recommandations de taille minimale

Le partitionnement en dessous de ces tailles minimales risque d’affecter négativement les performances des requêtes plutôt que de les améliorer. Tenez compte des points suivants lorsque vous décidez de partitionner une table :

• Pour les tableaux :
  • Avec moins de 1 To de données, ne partitionnez pas.
  • Avec plus de 1 To à 100 To de données, utilisez le clustering liquide au lieu de partitionner. Le partitionnement affecte probablement les performances plus souvent qu’il ne l’aide.
  • Avec 100 To ou plus de données, le partitionnement peut améliorer les performances, mais Databricks recommande d’abord d’utiliser le clustering liquide et de vérifier les améliorations des performances.
• Pour les partitions, vérifiez que chaque partition contient au moins 1 Go de données. Les tables avec moins de partitions plus grandes ont tendance à offrir des performances supérieures aux tables ayant de nombreuses partitions plus petites.

Utiliser le clustering au moment de l’ingestion

En utilisant Delta Lake, les tables non partitionnées utilisent automatiquement le clustering selon le temps d’ingestion. Le temps d’ingestion a des améliorations pour les performances des requêtes similaires aux stratégies de partitionnement avec des champs d’horodatage, sans avoir à optimiser ou ajuster manuellement vos données.

Remarque

Pour maintenir le clustering de temps d’ingestion lors de l’exécution d’un grand nombre de modifications à l’aide d’instructions UPDATE ou MERGE sur une table, Databricks recommande d’utiliser le Liquid Clustering sur une colonne qui correspond à l’ordre d’ingestion, tel qu’un horodatage d’événement ou une date de création. Consultez Utilisation de Liquid Clustering pour les tables.

Compatibilité du partitionnement Delta Lake et Parquet

Delta Lake utilise Parquet pour stocker des données, et certaines tables Delta Lake partitionnée ont des dispositions de données similaires aux tables Parquet stockées avec Apache Spark. Apache Spark utilise le partitionnement de style Hive lors de l’enregistrement de données au format Parquet. Le partitionnement de style Hive ne fait pas partie du protocole Delta Lake et les charges de travail ne doivent pas s’appuyer sur cette stratégie de partitionnement pour interagir avec les tables Delta Lake.

Databricks vous recommande d’interagir avec les données stockées dans Delta Lake à l’aide de clients et d’API officiellement pris en charge. De nombreuses fonctionnalités Delta Lake interrompent les hypothèses relatives à la disposition des données qui ont pu être utilisées avec Parquet, Hive ou même les versions antérieures du protocole Delta Lake.

Remarque

Lorsque vous activez le mappage de colonnes pour une table Delta Lake, les préfixes aléatoires remplacent les noms de colonnes dans les répertoires de partition pour le partitionnement de style Hive. Cf. Renommage et suppression des colonnes avec le mappage de colonnes Delta Lake.

Le partitionnement dans Delta Lake comparé aux autres lacs de données

Les techniques de partitionnement utiles dans d’autres technologies open source (telles qu’Apache Spark, Parquet, Hive et Hadoop) ne s’appliquent pas toujours à Azure Databricks. Si vous choisissez de partitionner votre table, tenez compte des éléments suivants :

• Les transactions ne sont pas définies par les limites de partition. Étant donné que Delta Lake garantit ACID par le biais des journaux de transactions, vous n’avez pas besoin de séparer un lot de données par une partition pour garantir l’atomicité.
• Les clusters de calcul Azure Databricks n’ont pas de localité de données liée à un média physique. Les données ingérées dans le lakehouse sont stockées dans le stockage d’objets cloud. Alors que les données sont mises en cache dans le stockage sur disque local pendant le traitement des données, Azure Databricks utilise des statistiques basées sur des fichiers pour identifier la quantité minimale de données pour le chargement parallèle.

Ordre Z et partitions

Remarque

Databricks recommande un Liquid Clustering sur le classement Z pour toutes les nouvelles tables. Consultez Utilisation de Liquid Clustering pour les tables.

Vous pouvez utiliser les index Z-order avec des partitions pour accélérer les interrogations sur des ensembles de données volumineux. La plupart des tables utilisent le clustering au moment de l’ingestion pour éviter d’avoir à ajuster l'index d’ordre de plan et les partitions.

Gardez à l’esprit les règles suivantes lorsque vous planifiez une stratégie d’optimisation des requêtes en fonction des limites de partition et de l’ordre Z :

• L’ordre Z nécessite la OPTIMIZE commande. Vous ne pouvez pas combiner des fichiers au-delà des limites de partition, donc le clustering Z-order ne peut se produire qu’au sein d’une partition. Pour les tables non partitionnés, les fichiers peuvent être combinés sur l’ensemble de la table.
• Le partitionnement fonctionne bien uniquement pour les champs de cardinalité faible ou connue (par exemple les champs de date ou les emplacements physiques), mais pas pour les champs à cardinalité élevée comme les horodatages. L'ordre Z fonctionne pour tous les champs, y compris ceux à haute cardinalité et ceux qui peuvent croître indéfiniment (par exemple, les horodatages ou l'ID client dans une table de transactions ou de commandes).
• Il n'est pas possible d'ordonner selon l'ordre Z les champs utilisés pour le partitionnement.

Comment Azure Databricks optimise les partitions existantes

De nombreux clients migrent vers Delta Lake depuis des lacs de données basés sur Parquet, par exemple en utilisant l’instruction CONVERT TO DELTA pour convertir une table Parquet existante en une table Delta Lake sans réécrire les données existantes. Étant donné que la conversion ne réécrit pas les données existantes, les grandes tables peuvent hériter des stratégies de partitionnement précédentes.

Certaines optimisations Databricks utilisent ces partitions lorsque cela est possible, ce qui atténue les effets négatifs sur les performances pour les stratégies de partitionnement qui ne sont pas optimisées pour Delta Lake.

Delta Lake et Apache Spark sont des technologies open source. Bien que Databricks dispose de fonctionnalités qui réduisent la dépendance au partitionnement, la communauté open source peut créer de nouvelles fonctionnalités qui ajoutent de la complexité.