Éviter les affirmations de métadonnées dans Unity Catalog / Blogs / Ferfient

Affirmation des métadonnées dans Catalogue d’unité peut se produire à haut débit Databricks environnements, ralentissement des requêtes utilisateur et impact des performances sur la plate-forme. Notre Stratégie Finops Changements laissés sur les performances. Cependant, nous avons trouvé des scénarios où les clients éprouvent toujours des ralentissements de requête par intermittence et même sur requêtes optimisées. À mesure que l’empreinte Lakehouse de notre client se développe, nous voyons un modèle émergent où le catalogue de stress sur l’unité peut avoir une traînée en aval sur les performances à travers l’espace de travail. Dans certains cas, nous avons identifié des métadonnées dans le catalogue Unity comme un contributeur à des réductions inattendues dans les temps de réponse après avoir contrôlé des optimisations plus ciblées.

Comment les affirmations des métadonnées peuvent ralentir les requêtes des utilisateurs

Lorsque les pipelines d’ingestion et de transformation des données s’appuient sur les changements de métadonnées structurelles, ils introduisent plusieurs points de contrainte à travers l’architecture du catalogue d’unité. Ceux-ci ne sont pas isolés du travail d’ingestion – ils s’rochet à travers le plan de contrôle et affectent tous les utilisateurs.

• Saturation du plan de contrôle – La saturation du plan de contrôle, souvent observée dans des systèmes distribués comme Databricks, fait référence à l’état lorsque les fonctions administratives (comme les mises à jour du schéma, l’application du contrôle d’accès et le suivi de la lignée) submergent leur capacité de traitement. Chaque modification de la table structurelle – en particulier celles via CREATE OR REPLACE TABLE—Add à la charge de transaction de métadonnées dans le catalogue Unity. Cela mène à:
  • Réponses retardées de la API du catalogue
  • La latence accrue dans la résolution de l’autorisation
  • Planification des requêtes plus lents, même pour les requêtes non liées

• Contention de verrouillage Metastore – Chaque création de table ou opération de remplacement nécessite des verrous exclusifs sur les objets Metastore sous-jacents. Lorsque de nombreux emplois tentent simultanément ces opérations:

• Cascade d’invalidation du plan de requête – CREATE OR REPLACE TABLE Invalide le cache de plan logique et physique actuel pour tous les clusters de calcul faisant référence à l’ancienne version. Cela mène à:
  • Augmenté planification des requêtes temps à travers les clusters
  • Performances imprévisibles pour les tableaux de bord ou les charges de travail interactives
  • Réduit utilisation du cache à travers les exécuteurs de Spark

• Propagation du schéma au-dessus – Les modifications structurelles d’un tableau (par exemple, ajouts de colonne, changements de type) doivent se propager à tous les services en s’appuyant sur la cohérence du schéma. Cela comprend:

• Interférence croisée multi-locataire – Le catalogue Unity est un plan de contrôle partagé. Lorsqu’un locataire (ou un ensemble d’emplois) remplace agressivement les tableaux, les opérations de métadonnées peuvent retarder ou bloquer les locataires non apparentés. Cela mène à:
  • Temps de démarrage de requête lente pour les utilisateurs interactifs
  • Retards de rotation du cluster dû à la lenteur des métadonnées
  • Soutenir l’escalade des équipes non liées

La création ou remplacer la réinitialisation

Dans autre blogsJ’ai dit que optimisation prédictive est la récompense pour avoir investi dans les bonnes pratiques de gouvernance avec un catalogue d’unité. L’un des principaux catalyseurs de l’optimzation prédictive est un plan logique et physique actuel, mis en cache. Chaque fois qu’une table est créée, un nouveau plan logique et physique pour cette table et les tables connexes est créé. Cela signifie que jamais le temps que vous exécutez CREATE OR REPLACE TABLEvous êtes de retour à la première étape pour l’optimisation des performances. Le modèle de table DROP + CREATE aura le même résultat net.

Cela ne veut pas dire que CREATE OR REPLACE TABLE est intrinsèquement un anti-motif. Cela ne devient qu’un problème de performance potentiel à des échelles, pense que des milliers d’emplois plutôt que des centaines. Ce n’est pas non plus le seul cuplrit. ALTER TABLE avec les changements structurels ont un effet similaire. CREATE OR REPLACE TABLE est omniprésent dans les pipelines d’ingestion de données et il ne commence pas à provoquer un problème notable jusqu’à ce qu’il soit profondément ancré dans la mémoire musculaire de votre développeur. Il existe cependant des alternatives.

Résumé des alternatives

Il existe différentes techniques que vous pouvez utiliser qui n’invalideront pas le cache de plan.

• Utiliser CREATE TABLE IF NOT EXISTS + INSERT OVERWRITE est probablement mon premier choix car il y a un chemin de migration de code droit.

CREATE TABLE IF NOT EXISTS catalog.schema.table (
id INT,
name STRING
) USING DELTA;
INSERT OVERWRITE catalog.schema.table
SELECT * FROM staging_table;

• Les deux MERGE INTO et COPY INTO Ayez les avantages des métadonnées de la solution antérieure et de l’évolution du schéma de soutien ainsi que l’ingestion de la concurrence.

MERGE INTO catalog.schema.table t
USING (SELECT * FROM staging_table) s
ON t.id = s.id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

COPY INTO catalog.schema.table
FROM '/mnt/source/'
FILEFORMAT = PARQUET
FORMAT_OPTIONS ('mergeSchema' = 'true');

• Déterminez si vous devez persister les données au-delà de la vie du travail. Sinon, envisagez des vues ou des tables temporaires. Cela évitera entièrement le catalogue d’Unity car il n’y a pas de surcharge de métadonnées.

df.createOrReplaceTempView("job_tmp_view")

• Bien que je préfère le catalogue Unity pour gérer les stratégies de partitionnement dans la couche d’argent et d’or, vous pouvez implémenter un schéma de partitionnement avec votre logique d’ingestion pour maintenir les métadonnées stables. Ceci est utile pour les charges de travail à haut niveau.

CREATE TABLE IF NOT EXISTS catalog.schema.import_data (
id STRING,
source STRING,
load_date DATE
) PARTITIONED BY (source, load_date);
INSERT INTO catalog.schema.import_data
PARTITION (source="job_xyz", load_date = current_date())
SELECT * FROM staging;

J’ai résumé les différentes techniques que vous pouvez utiliser pour minimiser l’invalidation du plan. En général, je pense que le remplacement de l’insert fonctionne généralement bien comme un remplacement sans rendez-vous. Vous obtenez l’évolution du schéma avec fusion et copiez. Je suis souvent surpris du nombre de tables qui devraient être considérées comme temporaires sont stockées. Ceci est juste un bon exercice à faire avec votre travail. Enfin, il y a des occasions où le paradigme de partition + d’insertion est préférable pour insérer l’écrasement, en particulier pour les charges de travail à haut niveau.

Conclusion

Le réglage des caractéristiques de performance d’une plate-forme est plus complexe que le réglage des performances à application unique. Les performances distribuées sont encore plus compliquées à grande échelle, les stratégies et les modèles de SCIE peuvent commencer à se décomposer à mesure que le volume et la vitesse augmentent.

Contactez-nous Pour en savoir plus sur la façon d’autonomiser vos équipes avec les bons outils, les processus et la formation pour débloquer le plein potentiel de Databricks dans votre entreprise.