Stockage Apache Iceberg et Pandas Analytics : Partie 1

J'aime généralement essayer de nouvelles choses, et la technologie ne fait pas exception. J'ai donc décidé d'approfondir mes recherches sur les mécanismes d'Apache Iceberg, et plus particulièrement sur l'implémentation Python, PyIceberg.

Apache Iceberg with Industrial Piping

J'ai spécifiquement examiné certains éléments clés qui font généralement partie des pratiques de gestion des données, quelle que soit la technologie :

• Contrôles de qualité des données : puis-je valider les schémas au minimum avec le typage des données, mais de préférence avec l'inspection des valeurs.

  
  

• Intégrité des données : pouvez-vous empêcher les doublons, appliquer des clés et maintenir un certain niveau d'intégrité référentielle lorsque les données sont liées entre les structures de données ?

  
  

  
  

  
  

  
  

• Accès aux données : pouvez-vous gérer la sécurité avec un accès au niveau des lignes, et le temps d'accès est-il robuste afin que les récupérations et les chargements soient raisonnables, c'est-à-dire les attentes moyennes pour les utilisateurs, les services et les applications ?

  
  

• Gestion des métadonnées : puis-je avoir des schémas qui peuvent évoluer à travers plusieurs versions et peut-être me donner la possibilité d'annuler les modifications.

Si vous débutez avec PyIceberg, sachez qu'il s'agit d'une implémentation Python d'Apache Iceberg sans JVM. Open source, le dépôt GitHub de PyIceberg est disponible ici et le support communautaire est disponible ici . Le projet a débuté comme une extension pour Apache Spark, puis pour Flink et Hive.

Fondation Apache Arrow

Ses mécanismes d'E/S de données reposent sur Apache Arrow , un projet lancé pour définir une spécification pour les données tabulaires et leur échange entre systèmes, notamment dans le domaine de l'analyse en mémoire. Arrow a été initialement écrit en C, puis porté vers plusieurs autres langages (voir « Implémentations » sur la page d'accueil, ci-dessus).

En bas de la page d'accueil, vous trouverez des liens supplémentaires vers des livres de recettes pour C++ , Java , Python et R , pour vous aider à démarrer rapidement avec ces implémentations. Le portage vers des langages et boîtes à outils populaires tels que C#, Rust, Ruby et MATLAB est également disponible.

Si vous utilisez actuellement ou prévoyez d'utiliser les formats Apache Parquet ou ORC, vous constaterez probablement que les bibliothèques des fournisseurs de cloud ou des moteurs de requête sourcent et encapsulent les bibliothèques Arrow comme base de départ pour les extensions spécifiques de chaque fournisseur.

Extensions IA/ML

Il existe des extensions CUDA pour la communauté AI/ML, mais nous espérons que vous éviterez d'effectuer des transformations et des manipulations de données sur des ressources GPU coûteuses, vous serez plus rentable et plus efficace en termes de traitement.

Je pense que le manque de séparation des préoccupations pour ces tâches axées sur les données est l'un des moteurs de la demande de GPU, ainsi que la faible consommation de CPU pour l'entraînement et l'exécution des modèles d'IA/ML. Ce n'est pas tant un manque de reconnaissance de la nécessité de cette séparation, mais plutôt le temps nécessaire à sa conception et à sa mise en œuvre ; autrement dit, elle n'est pas toujours assurée.

Les GPU ne sont pas des processeurs polyvalents, contrairement aux CPU, et sont davantage adaptés (du moins jusqu'à présent) aux calculs algorithmiques et à la visualisation. Ils ont été inventés pour calculer des points sur un triangle en parallèle pour l'affichage graphique. NVIDIA propose une introduction aux performances des GPU . Voici un aperçu des processeurs cellulaires (dont les GPU sont une forme) réalisé par l'Ohio Supercomputing Lab (2007) :

2007_tech_notes_jun_jul.pdf

Télécharger PDF • 196KB

Les cas d'utilisation spécifiques des processeurs cellulaires constituent l'élément clé à retenir, car en matière de développement, la plupart des ingénieurs ont une carrière axée sur un seul processeur et non sur plusieurs. Les compétences en matière de séparation des charges de travail pour des ressources de calcul spécifiques doivent être développées et perfectionnées (fin de l'interlude).

Apache Iceberg sous les couvertures

L'approche globale des métadonnées et du stockage des données vise à garantir l'immuabilité, ce qui constitue un atout majeur. Pourquoi ? En résumé, la simultanéité et les performances d'accès aux données s'améliorent avec les implémentations d'immuabilité (lorsqu'elles sont bien réalisées), tout en assurant la traçabilité à mesure que le schéma et les données évoluent. Si vous utilisez des SGBDR, le problème courant de fragmentation des données (métadonnées) et des index peut nécessiter des cycles de vigilance et de maintenance. Ce problème est particulièrement important dans les cas d'analyse (ROLAP) ou hybrides (OLTP + historique long), mais il disparaît avec les implémentations d'immuabilité.

Comme indiqué ou sous-entendu ci-dessus, Iceberg encapsule et utilise plusieurs bibliothèques issues de projets Apache tels qu'Arrow, Parquet, ORC et AVRO. Ces bibliothèques sont principalement dédiées aux opérations d'E/S, qu'elles soient en mémoire ou basées sur des fichiers. Iceberg utilise également largement Pydantic pour l'implémentation des métadonnées en Python.

Les « modèles » des structures de schéma sont créés et validés avec Pydantic, et les objets de métadonnées sont stockés dans un catalogue via un stockage persistant. Ce stockage persistant est accessible via REST, un SGBD SQL, un stockage en mémoire, Apache Hive, AWS Glue ouun environnement personnalisé . La présentation ci-dessous, tirée de https://iceberg.apache.org/spec/ , vous donne un aperçu de son organisation. La figure ci-dessous présente quelques détails supplémentaires : le fichier de métadonnées est un fichier Apache AVRO et les listes de manifestes sont au format JSON. Les propriétés de validation du schéma associées à Pydantic expliquent probablement ce choix.

Métadonnées et qualité des données

L'organisation des métadonnées commence au niveau de l'espace de noms, et consiste en une séparation logique ou contextuelle des données. Vous pouvez effectuer des références inter-espaces de noms lors de l'accès aux données si nécessaire. Les objets table sont créés « sous » un espace de noms et fournissent les types d'implémentation des schémas que vous trouverez ici . Si vous devez stocker des données géospatiales, Iceberg prend en charge les types géométriques et géographiques, et offre la prise en charge du système de référence de coordonnées (CRS) et de l'interpolation d'arêtes dans la couche de métadonnées. Le partitionnement des données et le lignage des lignes sont également disponibles, et le nombre d'enregistrements conservés pour détailler le lignage peut être défini lors de la création du catalogue.

Pour mieux illustrer le schéma ci-dessus, j'ai inclus la sortie du fichier console des tables Iceberg que j'ai créées pour l'exemple d'implémentation de la partie II. J'ai créé un dossier « entrepôt » sur mon appareil, et le listing commence sous l'espace de noms « docs ». Il explore en détail les données et métadonnées de « prévision ».

Namespace and Table Organization

Data and Metadata for Forecasts Object

L'implémentation de Pydantic, notamment en mode « strict » (métadonnées et données), couvre les points « Métadonnées » et « Qualité des données » mentionnés au début de l'article. Vous bénéficiez également de contrôles de version de schéma dans les métadonnées, jusqu'au niveau des colonnes, et de mécanismes très efficaces pour faciliter l'évolution des schémas. Les métadonnées Iceberg offrent de nombreuses variantes implémentées à l'aide de l'équivalent SGBDR des « contraintes » (et non du DDL de table littéral). Vous bénéficiez de la validation de type, de la désignation des champs obligatoires et de l'inspection de la taille et de la précision. L'application d'une liste de valeurs personnalisée à des champs spécifiques est toutefois absente.

D'après mon expérience, l'utilisation de listes de valeurs est plus courante dans les modèles de conception OLTP que dans les cas OLAP (analytique) pour un SGBDR. Apache Iceberg est clairement conçu pour les cas d'utilisation analytiques et non pour le traitement transactionnel. Globalement, c'est un bon point de départ pour la qualité des données et les métadonnées. Les attributs de valeurs par défaut permettent d'implémenter une clé de substitution équivalente ou d'utiliser des identifiants de champ .

Il n'offre pas d'équivalent à une clé primaire ou unique, qui est un type de contrainte de base de données garantissant l'unicité, quel que soit l'index associé. Il n'y a pas non plus d'indexation gérée par l'utilisateur, mais si vous utilisez déjà l'un des formats de fichier mentionnés précédemment, ce n'est pas nouveau et il n'est pas attendu. La garantie de l'unicité appartient à l'utilisateur. Vous pouvez par exemple imposer l'unicité au sein d'une structure, mais c'est à vous de la fournir ; Iceberg ne le fera pas pour vous.

Sécurité au niveau des lignes

Les points les plus difficiles pour Apache Iceberg sont la sécurité d'accès au niveau des lignes (RWA) et l'intégrité des données. J'évalue ce qui est « intégré » aux bibliothèques, et non la manière dont il est possible de construire une solution pour résoudre ces problèmes à l'aide d'outils supplémentaires.

La sécurité RWA n'est pas intégrée aux bibliothèques. Des fonctionnalités de lignage pour les lignes et les métadonnées sont très utiles pour diagnostiquer les problèmes de qualité des données et permettre des modifications au fil du temps. Ces dernières peuvent s'avérer très utiles dans le cas d'une utilisation de séries chronologiques. Cependant, la sécurité RWA est généralement une exigence de sécurité des entreprises ; il est à espérer que l'intégration LDAP sera bientôt disponible pour permettre cette intégration.

Intégrité des données

Les capacités d'intégrité des données ne sont pas vraiment mises en avant par Iceberg, peut-être parce que la tendance en matière d'accès aux données IA/ML est de dénormaliser les tables de données, rendant inutiles les clés étrangères, qui se résument à une seule grande table. Ce point est toutefois abordé dans les cas d'analyse plus traditionnels, où plusieurs tables nécessitent des liens relationnels (physiques ou virtuels). Ce serait donc un ajout utile dans ces cas-là. Même si le suivi des métadonnées est purement informatif, il améliore la validation. C'est un aspect négligé par Iceberg.

Accès aux données

Les utilisateurs qui utilisent actuellement l'un des formats Apache Arrow mentionnés précédemment savent à quoi s'attendre. Pour le stockage de données volumineuses, Parquet est fréquemment utilisé pour les ensembles de données volumineux, voire très volumineux, notamment si un partitionnement est nécessaire pour garantir des temps de réponse raisonnables. J'ai réalisé une petite implémentation, détaillée dans la deuxième partie de cet article, où des temps de réponse simples sont enregistrés. Mais comme beaucoup le savent, Parquet, surtout s'il est bien partitionné, est très réactif aux requêtes. Son format en colonnes est particulièrement bien conçu pour s'adapter aux cas d'utilisation analytiques.

Pour la partie suivante de l’article, je vais parcourir une implémentation simple utilisant Apache Iceberg et des données financières avec quelques agrégations Python.