Quand partitionner des tables sur Azure Databricks ?

Cet article fournit une vue d’ensemble de la façon dont vous pouvez partitionner des tables sur Azure Databricks, ainsi que des recommandations précisant quand utiliser le partitionnement pour les tables soutenues par Delta Lake. En raison des fonctionnalités et optimisations intégrées, la plupart des tables avec moins de 1 To de données ne nécessitent pas de partitions.

Azure Databricks utilise Delta Lake pour toutes les tables par défaut. Les recommandations suivantes partent du principe que vous travaillez avec Delta Lake pour toutes les tables.

Dans Databricks Runtime 11.3 LTS et versions ultérieures, Azure Databricks met automatiquement en cluster les données dans les tables non partitionnés par heure d’ingestion. Consultez Utiliser le clustering au moment de l’ingestion.

Les petites tables doivent-elles être partitionnées ?

Databricks recommande de ne pas partitionner les tables qui contiennent moins d’un téraoctet de données.

Quelle est la taille minimale pour chaque partition d’une table ?

Databricks recommande que toutes les partitions contiennent au moins un gigaoctet 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

Lorsque vous utilisez Delta Lake et Databricks Runtime 11.3 LTS ou version ultérieure, les tables non partitionnées que vous créez bénéficient automatiquement du clustering au moment de l’ingestion. Le moment de l’ingestion offre des avantages de requête similaires aux stratégies de partitionnement basées sur les champs datetime sans avoir besoin d’optimiser ou d’ajuster vos données.

Notes

Pour maintenir le clustering au moment de l’ingestion lorsque vous effectuez un grand nombre de modifications à l’aide d’instructions UPDATE ou MERGE sur une table, Databricks recommande d’exécuter OPTIMIZE avec ZORDER BY à l’aide d’une colonne qui correspond à l’ordre d’ingestion. Par exemple, il peut s’agir d’une colonne contenant un horodatage d’événement ou une date de création.

Les stratégies de partitionnement de Delta Lake et Parquet sont-elles mises en commun ?

Delta Lake utilise Parquet comme format principal pour le stockage des données, et certaines tables Delta avec des partitions spécifiées présentent une organisation similaire 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.

De nombreuses fonctionnalités Delta Lake rompent les hypothèses relatives à la disposition des données qui auraient pu être transférées à partir de Parquet, Hive ou même des versions antérieures du protocole Delta Lake. Vous devez toujours interagir avec les données stockées dans Delta Lake à l’aide de clients et d’API officiellement pris en charge.

En quoi les partitions Delta Lake diffèrent-elles des partitions d’autres lacs de données ?

Alors qu’Azure Databricks et Delta Lake s’appuient sur des technologies open source comme Apache Spark, Parquet, Hive et Hadoop, les motivations et stratégies de partitionnement utiles dans ces technologies ne sont généralement pas vraies pour Azure Databricks. Si vous choisissez de partitionner votre table, tenez compte des faits suivants avant de choisir une stratégie :

• Les transactions ne sont pas définies par les limites de partition. Delta Lake garantit ACID par le biais des journaux des transactions. Vous n’avez donc pas besoin de séparer un lot de données par une partition pour garantir la découverte atomique.
• 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.

Comment l’ordre de plan et les partitions fonctionnent-ils ensemble ?

Vous pouvez utiliser des index d’ordre de plan avec des partitions pour accélérer les requêtes sur des jeux de données volumineux.

Notes

La plupart des tables peuvent tirer parti du clustering au moment de l’ingestion, ce qui vous évite d’avoir à vous soucier de l’ordre de plan et du réglage des partitions.

Il est important de garder à l’esprit les règles suivantes lors de la planification d’une stratégie d’optimisation des requêtes basée sur les limites de partition et l’ordre de plan :

• L’ordre de plan fonctionne en tandem avec la commande OPTIMIZE. Vous ne pouvez pas combiner des fichiers au-delà des limites de partition ; ainsi, le clustering d’ordre de plan 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 de plan fonctionne pour tous les champs, y compris les champs à cardinalité élevée et les champs qui peuvent croître à l’infini (par exemple les horodatages ou l’ID client dans une table de transactions ou de commandes).
• Vous ne pouvez pas organiser selon l’ordre de plan les champs utilisés pour le partitionnement.

Si les partitions sont si mauvaises, pourquoi certaines fonctionnalités Azure Databricks les utilisent-elles ?

Les partitions peuvent être utiles, en particulier pour les tables très volumineuses. De nombreuses améliorations des performances liées au partitionnement sont axées sur les tables très volumineuses (des centaines de téraoctets ou plus).

De nombreux clients migrent vers Delta Lake à partir de lacs de données Parquet. L’instruction CONVERT TO DELTA vous permet de convertir une table Parquet existante en table Delta sans réécrire les données existantes. Par conséquent, de nombreux clients ont des tables volumineuses qui héritent des stratégies de partitionnement précédentes. Certaines optimisations développées par Databricks cherchent à tirer parti de ces partitions dans la mesure du possible, ce qui atténue certains inconvénients potentiels pour les stratégies de partitionnement non optimisées pour Delta Lake.

Delta Lake et Apache Spark sont des technologies open source. Databricks continue d’introduire des fonctionnalités qui réduisent la dépendance envers le partitionnement, et la communauté open source peut continuer à créer de nouvelles fonctionnalités qui ajoutent de la complexité.

Est-il possible de surpasser les optimisations intégrées d’Azure Databricks avec le partitionnement personnalisé ?

Certains utilisateurs expérimentés d’Apache Spark et Delta Lake peuvent être en mesure de concevoir et d’implémenter un modèle qui offre de meilleures performances que le clustering au moment de l’ingestion. L’implémentation d’une stratégie de partitionnement incorrecte peut avoir des répercussions très négatives sur les performances en aval et nécessiter une réécriture complète des données à corriger. Databricks recommande à la plupart des utilisateurs d’utiliser les paramètres par défaut pour éviter d’introduire des inefficacités coûteuses.