Que fait MSCK REPAIR TABLE dans les coulisses et pourquoi c'est si lent?
Je le sais MSCK REPAIR TABLE met à jour le métastore avec les partitions actuelles d'une table externe.
Pour ce faire, il vous suffit de faire ls sur le dossier racine de la table (étant donné que la table est partitionnée par une seule colonne), et d'obtenir toutes ses partitions, clairement une opération <1s.
Mais en pratique, l'opération peut prendre un temps très long pour s'exécuter (ou même timeout si exécuté sur AWS Athena ).
Donc ma question est, qu'est-ce que MSCK REPAIR TABLE fait en coulisses et pourquoi?
Comment MSCK REPAIR TABLE trouve-t-il les partitions?
Données supplémentaires en cas de pertinence:
Nos données sont toutes sur S3, elles sont à la fois lentes lors de l'exécution sur EMR (Hive) ou Athena (Presto), il y a environ 450 partitions dans la table, chaque partition a environ 90 fichiers, en général 3 gigaoctets pour une partition, les fichiers sont en Format parquet Apache
Vous avez raison dans le sens où il lit la structure du répertoire, en crée des partitions, puis met à jour le métastore Hive. En fait, plus récemment, la commande a été améliorée pour supprimer également les partitions non existantes du métastore. L'exemple que vous donnez est très simple car il n'a qu'un seul niveau de clés de partition. Considérez la table avec plusieurs clés de partition (2-3 clés de partition sont courantes dans la pratique). msck repair devra parcourir l'arborescence complète de tous les sous-répertoires du répertoire de la table, analyser les noms de fichiers, s'assurer que les noms de fichiers sont valides, vérifier si la partition existe déjà dans le métastore, puis ajouter le uniquement les partitions qui ne sont pas présentes dans le métastore. Notez que chaque liste sur le système de fichiers est un RPC pour le namenode (dans le cas de HDFS) ou un appel de service Web dans le cas de S3 ou ADLS, ce qui peut ajouter beaucoup de temps. De plus, afin de déterminer si la partition est déjà présente dans la métastore ou non, elle doit faire une liste complète de toutes les partitions que la métastore connaît pour la table. Ces deux étapes peuvent potentiellement augmenter le temps nécessaire à la commande sur les grandes tables. Les performances de la table de réparation msck ont été considérablement améliorées récemment Hive 2.3.0 (voir Hive-15879 pour plus de détails). Vous voudrez peut-être régler Hive.metastore.fshandler.threads et Hive.metastore.batch.retrieve.max pour améliorer les performances de la commande.