Quand partitionner des tables sur Databricks

remarque

Databricks recommande le clustering liquide pour toutes les tables gérées. Pour les tables gérées utilisant Apache Iceberg, Unity Catalog prend en charge uniquement le clustering liquide et interprète les colonnes PARTITION BY comme des clés de clustering. Voir Convertir une table partitionnée en clustering liquide.

La plupart des tables sur Databricks avec moins de 100 To de données ne nécessitent pas de partitionnement. Databricks utilise Delta Lake pour toutes les tables par default et regroupe automatiquement les données des tables non partitionnées par heure d'ingestion, ce qui vous offre des performances similaires à celles du partitionnement sans réglage manuel. Envisagez une stratégie de partitionnement personnalisée uniquement lorsqu'elle surpasse ces valeurs par défaut. Voir Utiliser le regroupement au moment de l'ingestion.

Stratégies de partitionnement personnalisées

Les utilisateurs avancés d'Apache Spark et de Delta Lake pourraient identifier une stratégie de partitionnement qui surpasse le clustering au moment de l'ingestion default.

attention

Une stratégie de partitionnement inefficace pourrait nuire aux performances des query et nécessiter une réécriture complète des données pour y remédier. Une réécriture complète pourrait être très coûteuse et lente pour les grandes tables.

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

Pour convertir une table Delta Lake partitionnée existante en liquid clustering, utilisez ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY. Le clustering fluide fonctionne pour les colonnes à faible et à forte cardinalité et évite les limites de partition fixes et les problèmes de petits fichiers courants avec le partitionnement statique. Voir Convertir une table partitionnée en clustering liquide.

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
• Horodatage
• TimestampNTZ
• Intervalle
• Chaîne
• Binaire
• Booléen
• Entier, Long, Court, Octet
• Float, Double, Décimal

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

• Types complexes, tels que StructType, MapType, ArrayType, ou VariantType
• Champs de structure, tels que struct_col.field. Delta Lake traite un champ de structure dans PARTITIONED BY comme une expression plutôt qu'une référence de colonne.

Pour organiser une table par un champ struct, utilisez plutôt le groupage liquide, qui reconnaît un champ struct comme clé de groupage. Le clustering liquide est le seul moyen d'ignorer les données sur un champ de structure sans l'extraire d'abord dans une colonne de niveau supérieur. Consultez Utiliser le clustering liquide pour les tables.

Recommandations de taille minimale

Le partitionnement en dessous de ces tailles minimales est susceptible d'affecter négativement les performances des query plutôt que de les améliorer. Prenez en compte les éléments suivants lorsque vous décidez de partitionner une table :

• Pour les tables :

  • 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 du partitionnement. Le partitionnement affecte probablement négativement les performances plus souvent qu'il n'aide.
  • Avec 100 TB ou plus de données, le partitionnement pourrait améliorer les performances, mais Databricks recommande d'utiliser d'abord le clustering liquide et de vérifier les améliorations de performance.

• Pour les partitions, vérifiez que chaque partition contient au moins 1 Go de données. Les tables avec moins de partitions, mais plus grandes, ont tendance à surpasser les tables avec 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 regroupement au moment de l'ingestion. Le moment de l'ingestion améliore les performances des query de manière similaire aux stratégies de partitionnement avec des champs de date et d'heure, sans qu'il soit nécessaire d'optimiser ou d'ajuster manuellement vos données.

remarque

Pour maintenir le clustering temporel d'ingestion lors de l'exécution d'un grand nombre de modifications à l'aide des instructions UPDATE ou MERGE sur une table, Databricks recommande d'utiliser le clustering liquide sur une colonne correspondant à l'ordre d'ingestion, telle qu'un événement Timestamp ou une date de création. Consultez Utiliser le clustering liquide pour les tables.

Compatibilité du partitionnement Delta Lake et Parquet

Delta Lake utilise Parquet pour stocker les données, et certaines tables Delta Lake partitionnées ont des Layout de données similaires à celles des tables Parquet stockées avec Apache Spark. Apache Spark utilise un partitionnement de type Hive lors de l’enregistrement des données au format Parquet. Le partitionnement de type 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'APIs officiellement pris en charge. De nombreuses fonctionnalités de Delta Lake remettent en question les hypothèses concernant le layout des données qui auraient pu être utilisées avec Parquet, Hive, ou même des versions antérieures du protocole Delta Lake.

remarque

Lorsque vous activez le mappage de colonnes pour une table Delta Lake, des préfixes aléatoires remplacent les noms de colonnes dans les répertoires de partition pour le partitionnement de type Hive. Consultez Renommer et supprimer des colonnes avec le mappage de colonnes Delta Lake.

Partitionnement Delta Lake comparé à d'autres data lakes

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

• Les transactions ne sont pas définies par des limites de partition. Étant donné que Delta Lake garantit l'ACID via les Logs de transactions, vous n'avez pas besoin de séparer un batch de données par une partition pour garantir l'atomicité.
• Les clusters de compute Databricks n'ont pas de localité des données liée aux supports physiques. Les données ingérées dans le lakehouse sont stockées dans le stockage d'objets cloud. Pendant que les données sont mises en cache sur le stockage sur disque local lors du traitement des données, Databricks utilise des statistiques basées sur les fichiers pour identifier la quantité minimale de données pour le chargement parallèle.

Z-order et partitions

remarque

Databricks recommande le clustering liquide plutôt que le Z-ordering pour toutes les nouvelles tables. Voir Utiliser le clustering liquide pour les tables.

Vous pouvez utiliser des index Z-order avec des partitions pour accélérer les queries sur de grands datasets. La plupart des tables utilisent le clustering au moment de l'ingestion pour éviter d'avoir à optimiser le Z-order et les partitions.

Gardez les règles suivantes à l'esprit lorsque vous planifiez une stratégie d'optimisation des requêtes basée sur les limites de partition et le Z-order :

• Z-order nécessite la commande OPTIMIZE. Vous ne pouvez pas combiner des fichiers au-delà des limites de partition. Par conséquent, le clustering Z-order ne peut se produire qu’au sein d’une partition. Pour les tables non partitionnées, les fichiers peuvent être combinés sur l'ensemble de la table.
• Le partitionnement fonctionne bien uniquement pour les champs de faible ou de cardinalité connue (par exemple, les champs de date ou les emplacements physiques), mais pas pour les champs à forte cardinalité tels que les Timestamp. Z-order fonctionne pour tous les champs, y compris les champs à cardinalité élevée et les champs qui peuvent croître à l'infini (par exemple, les Timestamps ou l'ID client dans une table de transactions ou de commandes).
• Vous ne pouvez pas appliquer de Z-order sur les champs utilisés pour le partitionnement.

Comment Databricks optimise autour des partitions existantes

De nombreux clients migrent vers Delta Lake à partir de data lakes basés sur Parquet, par exemple en utilisant l'instruction CONVERT TO DELTA pour convertir une table existante basée sur Parquet en table Delta Lake sans réécrire les données existantes. Comme 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 c'est possible, atténuant 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 propose des fonctionnalités qui réduisent la dépendance au partitionnement, la communauté open source pourrait développer de nouvelles fonctionnalités qui ajoutent de la complexité.