Index en parquet
J'aimerais pouvoir faire une requête rapide sur une table de parquet. La quantité de données à renvoyer est très faible par rapport à la taille totale, mais comme une analyse complète des colonnes doit être effectuée, elle est trop lente pour mon cas d'utilisation.
L'utilisation d'un index résoudrait ce problème et j'ai lu que cela devait être ajouté dans Parquet 2.0. Cependant, je ne trouve aucune autre information à ce sujet, donc je suppose que ce n'était pas le cas. Je ne pense pas qu'il y aurait des obstacles fondamentaux empêchant l'ajout d'index (multi-colonnes), si les données étaient triées, ce qui est le cas dans mon cas.
Ma question est: quand les index seront-ils ajoutés à Parquet, et quelle serait la conception de haut niveau pour le faire? Je pense que je serais déjà satisfait d'un index qui indique la bonne partition.
Sincères amitiés,
Sjoerd.
Parquet conserve actuellement des statistiques min/max pour chaque page de données. Une page de données est un groupe de ~ 1 Mo de valeurs (après codage) pour une seule colonne; plusieurs pages sont ce qui compose Morceaux de colonne de Parquet .
Ces valeurs min/max sont utilisées pour filtrer les blocs de colonne et les pages qui composent un bloc. Vous devriez donc être en mesure d'améliorer le temps de votre requête en triant les enregistrements par les colonnes sur lesquelles vous souhaitez filtrer, puis en écrivant les données dans Parquet. De cette façon, vous tirez le meilleur parti du filtrage des statistiques.
Vous pouvez également obtenir un filtrage plus granulaire avec cette technique en diminuant la taille des groupes de pages et de lignes, même si vous échangez ensuite l'efficacité du codage et l'efficacité des E/S.
Mise à jour décembre/2018 :
Parquet Format version 2.5 a ajouté des index de colonne.
https://github.com/Apache/parquet-format/blob/master/CHANGES.md#version-25
Voir https://issues.Apache.org/jira/browse/PARQUET-1201 pour la liste des sous-tâches pour cette nouvelle fonctionnalité.
Notez que cette fonctionnalité vient d'être fusionnée au format Parquet lui-même, il faudra du temps pour que différents backends (Spark, Hive, Impala, etc.) commencent à la prendre en charge.
Cette nouvelle fonctionnalité est appelée Index de colonnes. Fondamentalement, Parquet a ajouté deux nouvelles structures dans la disposition du parquet - Index de colonne et Index de décalage.
Ci-dessous est une explication technique plus détaillée de ce qu'il résout et comment.
Énoncé du problème
Dans le format actuel, les statistiques sont stockées pour ColumnChunks dans ColumnMetaData et pour les pages individuelles dans les structures DataPageHeader. Lors de la lecture des pages, un lecteur doit traiter l'en-tête de page afin de déterminer si la page peut être ignorée en fonction des statistiques. Cela signifie que le lecteur doit accéder à toutes les pages d'une colonne, lisant ainsi probablement la plupart des données de la colonne à partir du disque.
Objectifs
Rendez les analyses de plage et les E/S de recherche de points efficaces en permettant un accès direct aux pages en fonction de leurs valeurs min et max. En particulier:
- Une recherche sur une seule ligne dans un groupe de lignes basé sur la colonne de tri de ce groupe de lignes ne lit qu'une page de données par colonne récupérée. Les analyses de plage sur la colonne de tri n'auront besoin que de lire les pages de données exactes qui contiennent des données pertinentes.
- Rendre d'autres E/S d'analyses sélectives efficaces: si nous avons un prédicat très sélectif sur une colonne non triante, pour les autres colonnes récupérées, nous ne devrions avoir besoin d'accéder qu'aux pages de données qui contiennent des lignes correspondantes.
- Aucun effort de décodage supplémentaire pour les analyses sans prédicats sélectifs, par exemple, les analyses de groupe sur une ligne complète. Si un lecteur détermine qu'il n'a pas besoin de lire les données d'index, il n'encourt pas de surcharge.
- Les pages d'index pour les colonnes triées utilisent un stockage minimal en stockant uniquement les éléments de limite entre les pages.
Non-buts
Prise en charge de l'équivalent des indices secondaires, c'est-à-dire une structure d'index triée sur les valeurs clés sur des données non triées.
Approche technique
Nous ajoutons deux nouvelles structures par colonne aux métadonnées du groupe de lignes: ColumnIndex: cela permet de naviguer vers les pages d'une colonne en fonction des valeurs de la colonne et est utilisé pour localiser les pages de données qui contiennent des valeurs correspondantes pour un prédicat d'analyse OffsetIndex: cela permet la navigation par index de ligne et est utilisé pour récupérer les valeurs des lignes identifiées comme des correspondances via ColumnIndex. Une fois les lignes d'une colonne ignorées, les lignes correspondantes des autres colonnes doivent être ignorées. Par conséquent, les OffsetIndexes pour chaque colonne d'un RowGroup sont stockés ensemble.
Les nouvelles structures d'index sont stockées séparément de RowGroup, près du pied de page, de sorte qu'un lecteur n'a pas à payer les coûts d'E/S et de désérialisation pour les lire s'il ne fait pas de scans sélectifs . L'emplacement et la longueur des structures d'index sont stockés dans ColumnChunk et RowGroup.
L'équipe Impala de Cloudera a effectué quelques tests sur cette nouvelle fonctionnalité (non encore disponible dans le cadre du produit principal Apache Impala). Voici leurs améliorations de performances:
et
Comme vous pouvez le voir, certaines des requêtes ont connu une énorme amélioration à la fois en termes de temps processeur et de quantité de données à lire sur les disques.
Réponse originale de 2016 :
struct IndexPageHeader {
/** TODO: **/
}
L'en-tête de page d'index n'est pas encore implémenté.
Voir le code source du format Parquet ci-dessus. Je ne le vois même pas actuellement dans Parquet 2.0.
Mais oui - excellente réponse de Ryan Blue ci-dessus sur Parquet selon laquelle il a des capacités de pseudo-indexation (filtres de floraison).
Si vous êtes intéressé par plus de détails, je recommande un excellent document sur la façon dont les filtres de floraison de parquet et le travail de push-down prédicat https://www.slideshare.net/RyanBlue3/parquet-performance-tuning-the-missing- guide un document plus technique spécifique à l'implémentation - https://homepages.cwi.nl/~boncz/msc/2018-BoudewijnBraams.pdf