La nouvelle version d'Apache Arrow 1.0.0 est enfin sorti

L’équipe Apache Arrow est heureuse d’annoncer la version 1.0.0. Cela couvre plus de 3 mois de travail de développement et comprend 810 problèmes résolus par 100 contributeurs distincts . Consultez la page
d’installation pour savoir comment obtenir les bibliothèques pour votre plate-forme.

Malgré une version «1.0.0», il s’agit de la 18e version majeure d’ApacheArrow et marque une transition vers la stabilité binaire du format colonnaire (qui était déjà informellement rétrocompatible depuis décembre 2017) et une transition vers le versionnage sémantique pour les bibliothèques de logiciels Arrow.

Les notes de publication ci-dessous ne sont pas exhaustives et n’exposent que les faits saillants sélectionnés de la version. De nombreuses autres corrections de bugs et améliorations ont été apportées: nous vous renvoyons au changelog complet. 1.0.0 Format de colonne et garanties de stabilité La version 1.0.0 indique que le format de colonne Arrow est déclaré stable, avec des garanties de compatibilité ascendante et descendante. Le format de colonne Arrow a reçu plusieurs modifications et ajouts récents, menant à la version au format 1.0.0:

La version des métadonnées a été transférée à une nouvelle version V5, indiquant un changement incompatible dans la disposition de la mémoire tampon des types Union. Tous les autres types conservent la même disposition que dans la V4. La version 5 inclut également des ajouts de format pour faciliter la compatibilité ascendante (détection des modifications non prises en charge envoyées par les futures versions de la bibliothèque). Les bibliothèques restent rétrocompatibles avec les données générées par toutes les bibliothèques depuis la version 0.8.0 (décembre 2017) et les bibliothèques Java et C ++ sont capables de
générer des messages compatibles V4 (pour envoyer des données à des applications utilisant 0.8.0 à 0.17.1).

Les index de dictionnaire sont désormais autorisés à être des entiers non signés plutôt que seulement des entiers signés. L’utilisation d’UInt64 est toujours déconseillée en raison d’une mauvaise prise en charge de Java. Une énumération «Feature» a été ajoutée pour annoncer l’utilisation de fonctionnalités optionnelles spécifiques dans un flux IPC, comme la compression de tampon. Ce nouveau champ n’est encore utilisé par aucune implémentation. La compression de tampon facultative utilisant LZ4 ou ZStandard a été ajoutée au format IPC.

Les types décimaux ont maintenant un champ optionnel «bitWidth», par défaut à 128.Cela permettra la prise en charge future d’autres largeurs décimales telles que 32 et 64 bits. Le tampon de bitmap de validité a été supprimé des types Union. La nullité d’un emplacement dans un tableau Union est déterminée exclusivement par les tableaux constitutifs formant l’union.

Les tests d’intégration ont été étendus pour tester les types d’extensions et les dictionnaires imbriqués. Voir la matrice d’implémentation pour plus de détails.

La suite c’est par ICI