Big Data : la plateforme de développement pour l'analyse in-memory Apache Arrow 1.0.0 est disponible

Et s'accompagne de nombreuses améliorations

De par sa nature même, le Big Data est trop volumineux pour tenir sur une seule machine. Les ensembles de données doivent être partitionnés sur plusieurs machines. Chaque partition est affectée à une machine principale, avec des affectations de sauvegarde facultatives. Par conséquent, chaque machine possède plusieurs partitions. La plupart des frameworks Big Data utilisent une stratégie aléatoire pour attribuer des partitions aux machines. Si chaque travail de calcul utilise une partition, cette stratégie se traduit par une bonne répartition de la charge de calcul sur un cluster. Cependant, si un travail a besoin de plusieurs partitions, il y a de fortes chances qu'il ait besoin de récupérer des partitions à partir d'autres machines. Le transfert de données est toujours une pénalité de performance.

Apache Arrow propose un format de données en mémoire multilangage, multiplateforme et en colonnes pour les données. Il élimine le besoin de sérialisation car les données sont représentées par les mêmes octets sur chaque plateforme et langage de programmation. Ce format commun permet le transfert de données sans copie dans les systèmes Big Data, afin de minimiser les performances du transfert de données.

Apache Arrow est donc une plateforme de développement pour l'analyse in-memory. Une base de données dite « en mémoire » (in-memory), ou IMDB (In Memory DataBase), ou encore MMDB (Main Memory DB), désigne une base de données dont les informations sont stockées en mémoire centrale afin d'accélérer les temps de réponse. Une IMDB constitue un type de base de données analytique, un système qui stocke des données historiques portant sur des mesures destinées à des applications BI/BA (Business Intelligence/Business Analytics), généralement dans le cadre d'un entrepôt ou d'un magasin de données.

Ces systèmes permettent aux utilisateurs d'exécuter des requêtes et de générer des rapports sur les informations renfermées. Celles-ci sont régulièrement mises à jour pour intégrer les données transactionnelles récentes issues des systèmes opérationnels d'une entreprise. Outre le fait qu'elle permet des temps de réponse extrêmement courts, l'analytique en mémoire vive réduit, voire élimine, le recours à l'indexation des données et au stockage de données préagrégées dans des tables d'agrégats ou des cubes OLAP. Cette capacité diminue les coûts informatiques et accélère la mise en œuvre d'applications BI/BA.


Apache Arrow contient un ensemble de technologies qui permettent aux systèmes Big Data de traiter et de déplacer rapidement les données. Il spécifie un format de mémoire en colonnes standardisé indépendant du langage pour les données plates et hiérarchiques, organisé pour des opérations analytiques efficaces sur du matériel moderne.

Apache Arrow propose un format de stockage commun sans frais généraux pour de nombreux systèmes Big Data et voudrait devenir un nouveau standard pour le traitement des données en mémoire orienté colonnes. Le projet a été soutenu dès le départ par de nombreux projets Big Data tels que Cassandra, Drill, HBase, Spark et Storm répertoriés sur Apache (notons que des projets en dehors d'Apache tels que Pandas ont également soutenu son développement). Trois mois se sont écoulés depuis la dernière version et les développeurs d'Arrow ont résolu plus de 800 problèmes.

C'est dans un billet de blog que l'équipe a annoncé la disponibilité de la version 1.0.0 : « L'équipe Apache Arrow est heureuse d'annoncer la version 1.0.0. Elle couvre plus de 3 mois de travail de développement et comprend 810 problèmes résolus par 100 contributeurs distincts. Malgré le numéro de version "1.0.0", il s'agit de la 18^ème version majeure d'Apache Arrow et elle vient marquer une transition vers la stabilité binaire du format de colonne (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. »

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 1.0.0 de ce format :

• La version des métadonnées est passé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.


Arrow Flight RPC

Flight propose désormais DoExchange, un point de terminaison de données entièrement bidirectionnel, en plus de DoGet et DoPut, en C++, Java et Python. Les middlewares dans tous les langages exposent désormais des en-têtes à valeur binaire. De plus, les serveurs et les clients peuvent définir les options de lecture / écriture Arrow IPC dans tous les langages, ce qui facilite la compatibilité avec les versions antérieures d'Arrow Flight.

En C++ et Python, Flight expose désormais plus d'options de gRPC, y compris l'adresse du client (sur le serveur) et la possibilité de définir des options de client gRPC de bas niveau. Flight prend également en charge l'authentification TLS mutuelle et la possibilité pour un client de contrôler la taille d'un message de données on wire.

C++

• La prise en charge de la liaison statique avec Arrow a été considérablement améliorée, y compris l'introduction d'une bibliothèque libarrow_bundled_dependencies.a regroupant toutes les dépendances externes créées à partir des sources par le système de construction d'Arrow plutôt qu'installées par un gestionnaire de packages externe. Cela facilite considérablement la création d'applications sans dépendances avec toutes les bibliothèques liées statiquement.
• Suite aux changements de format Arrow, les tableaux Union ne peuvent plus avoir de bitmap de niveau supérieur.
• Un certain nombre d'améliorations ont été apportées pour réduire la taille binaire globale générée dans la bibliothèque Arrow.
• Une API pratique GetBuildInfo permet d'interroger les caractéristiques de la bibliothèque Arrow. L'équipe encourage les développeurs à suggérer tout ajout souhaité aux informations renvoyées.
• Une dépendance facultative a été ajoutée à la bibliothèque utf8proc, utilisée dans plusieurs fonctions de calcul.
• Au lieu de partager les mêmes classes concrètes, les unions clairsemées et denses ont désormais des classes séparées (SparseUnionType et DenseUnionType, ainsi que SparseUnionArray, DenseUnionArray, SparseUnionScalar, DenseUnionScalar).
• Arrow peut maintenant être construit pour iOS en utilisant le bon ensemble d'options CMake, bien qu'il ne le prenne pas officiellement en charge.

Java

• Le package Java introduit un certain nombre de modifications de bas niveau dans cette version. Les plus remarquables sont le travail de prise en charge de l'allocation de grands tampons de flèches et de la suppression de Netty de l'API publique. Les utilisateurs devront mettre à jour leurs dépendances pour utiliser l'un des deux allocateurs pris en charge Netty arrow-memory-netty ou Unsafe (API java interne pour la mémoire directe) arrow-memory-unsafe.
• L'implémentation Java Vector a amélioré son interopérabilité en vérifiant que les types LargeVarChar, LargeBinary, LargeList, Union, Extension et les noms de champs en double dans Structs sont compatibles binaires avec C ++ et la spécification.

Python

• La taille des roues des packages est considérablement réduite, jusqu'à 75 %. Un effet secondaire est que ces roues n'activent plus Gandiva (ce qui nécessite que le runtime LLVM soit lié statiquement). L'équipe se dit plutôt intéressée par la fourniture de Gandiva en tant que add-on séparé à l'avenir.
• La hiérarchie des classes Scalar a été retravaillée pour suivre de plus près son homologue C ++.
• Les certificats TLS CA sont recherchés de manière plus fiable lors de l'utilisation du système de fichiers S3, en particulier avec les roues manylinux.
• Le codage des fichiers CSV peut maintenant être spécifié explicitement, par défaut à UTF8. Les analyseurs d'horodatage personnalisés peuvent désormais être utilisés pour les fichiers CSV.
• Les systèmes de fichiers peuvent désormais être implémentés en Python pur. Par conséquent, les systèmes de fichiers basés sur fsspec peuvent désormais être utilisés dans des ensembles de données.
• parquet.read_table est maintenant soutenu par l'API de l'ensemble de données par défaut, ce qui permet des filtres sur n'importe quelle colonne et un partitionnement plus flexible.

R

Le package R a ajouté la prise en charge de la conversion vers et à partir de nombreux types de flèches supplémentaires. Des tableaux montrant comment les types R sont mappés aux types Flèches et vice versa ont été ajoutés à la vignette d'introduction, et presque tous les types sont gérés. De plus, les attributs R tels que les classes personnalisées et les métadonnées sont désormais préservés lors de la conversion d'un data.frame en tableau fléché et sont restaurés lors de leur chargement dans R.

Fonctions de calcul

La couche du noyau de calcul a été largement retravaillée. Il propose désormais un mécanisme générique de recherche, de répartition et d'exécution des fonctions. De plus, de nouveaux échafaudages internes facilitent considérablement l'écriture de nouveaux noyaux de fonctions, avec de nombreux détails communs tels que la vérification de type et la répartition des fonctions basées sur des combinaisons de types gérées par le framework plutôt que mises en œuvre manuellement par le développeur de fonctions.

Environ 30 nouvelles fonctions de calcul de tableau ont été ajoutées. Par exemple, les prédicats et les transformations compatibles Unicode, tels que les transformations minuscules et majuscules, sont désormais disponibles.

Les fonctions de calcul disponibles sont listées de manière exhaustive dans la documentation générée par Sphinx.

Ensembles de données

Les ensembles de données peuvent désormais être lus à partir de fichiers CSV.

Les ensembles de données peuvent être étendus à leurs fragments de composants, permettant une interopérabilité fine avec d'autres consommateurs de fichiers de données. Le cas échéant, les métadonnées sont disponibles en tant que propriété du fragment, y compris les informations de partition et (pour le format parquet) les statistiques par colonne.

Les ensembles de données de fichiers parquet peuvent désormais être assemblés à partir d'un seul fichier _metadata, comme ceux créés par des systèmes tels que Dask et Spark. _metadata contient les métadonnées de tous les fragments, permettant la construction d'un jeu de données prenant en charge les statistiques avec un seul appel IO.

Source : note de version