Blog | Data Strategy & Insights | | 6 min read

Vector dans Hadoop 5.0 - Nouvelles fonctionnalités à prendre en compte

Vecteur dans Hadoop 5.0

Actian Vector a été rebaptisé Actian Analytics Engine en 2026.

Nous annonçons aujourd’hui le lancement de la nouvelle version d’Actian Vector in Hadoop, qui étend notre support Apache Spark pour inclure un accès direct aux formats de fichiers natifs de Hadoop ainsi qu’une intégration plus étroite avec les applications Spark SQL et Spark R. Cette version intègre également des améliorations en termes de performances, une intégration avec frameworks de sécurité Hadoop et des optimisations au niveau de l’administration. Je vais aborder chacun de ces points plus en détail ci-dessous.

Combiner les tables Hadoop natives avec les tables vectorielles

In previous releases, Vector in Hadoop required data to be stored in a proprietary format which optimized analytics performance and delivered great compression to reduce access latency. Vector in Hadoop 5.0 provides the ability to register Hadoop data files (such as Parquet, ORC, and CSV files) as tables in VectorH and to join these external tables with native Vector tables. Vector in Hadoop will provide the fastest analytics execution against data in these formats, even faster than their native query engines. However, query execution will never be as fast with external tables as with native Vector data. If performance matters, we suggest that you load that data into Vector in Hadoop using our high-speed loader.

This feature enables customers who have standardized on a particular file format and who want to avoid copying data into a proprietary format to still get the performance acceleration VectorH offers. The details of the storage benchmark that we conducted as part of our SIGMOD paper showed the Vector file format to be more efficient from a query performance/data read and data compression perspective. See our blog post, which further explains that benchmark.

Une véritable intégration de la sécurité Hadoop en entreprise

A Forrester survey last year indicated that data security is the number one concern with Hadoop deployments. Vector in Hadoop provides the enterprise-grade security natively that one expects in a mature EDW platform, i.e., discretionary access control (control over who can read, write, and update what data in the database), column-level data at rest encryption, data in motion encryption, security auditing with SQL addressable audit logs, and security alarms. For the rest of the Hadoop ecosystem, these concerns have driven the development of Hadoop Security Frameworks, through projects like Apache Knox and Apache Ranger. As we see these frameworks starting to appear on customer RFIs, we’re provided documentation on how to configure VectorH for integration with Apache Knox and Apache Ranger.

Améliorations significatives des performances

Les améliorations de performances qui ont permis à Vector 5.0 d'atteindre les meilleurs résultats au test de performance TPC-H 3000 Go pour les systèmes non clusterisés sont désormais disponibles dans Vector in Hadoop 5.0, où l'on observe généralement évolutivité linéaire, voire supérieure à la linéarité.

Génération automatique d'histogrammes

Les plans requête de base de données reposent largement sur la connaissance des données sous-jacentes ; en l'absence de statistiques, le système doit émettre des hypothèses sur distribution des données exemple, il supposera que tous les codes postaux correspondent au même nombre d'habitants, ou que les noms de famille des clients ont autant de chances de commencer par un X que par un M. VectorH 5.0 intègre une fonctionnalité de génération automatique de statistiques et d'histogrammes pour les tables Vector. Cela se traduit par la création automatique d'histogrammes et leur mise en cache en mémoire lorsqu'une requête une référence à une colonne dans une clause WHERE, HAVING ou ON sans histogramme explicitement créé (par optimizedb ou CREATE STATISTICS).

Accélérer le démarrage et l'arrêt grâce au journal d'écriture anticipée distribué

Dans les versions précédentes de Vector in Hadoop, le fichier de journalisation des écritures anticipées (WAL), qui contient les détails des mises à jour du système, était géré sur le nœud leader de VectorH. Ce fichier de journalisation, résidant en mémoire, occupait une grande partie de la mémoire du nœud leader et constituait un goulot d'étranglement lors du démarrage, car il devait être relu au cours de cette opération, ce qui pouvait prendre plusieurs minutes. Dans VectorH 5.0, nous avons mis en place un fichier WAL (Write Ahead Log) distribué, dans lequel chaque nœud dispose d'un WAL local. Cela allège la charge sur la mémoire, améliore nos temps de démarrage et, par conséquent, accélère considérablement le traitement des COMMIT.

Accélérer les requêtes grâce aux index distribués

Dans les versions précédentes, le nœud leader de VectorH était chargé de gérer les index min-max automatiques pour toutes les partitions. Pour rappel, l’index min-max répertorie les valeurs minimales et maximales stockées dans un bloc de données ; cet index interne nous permet d’identifier rapidement les blocs qui participeront au traitement d’une requête ceux qui n’ont pas besoin d’être lus. Cet index réside en mémoire et est construit au démarrage du serveur. Dans VectorH 5.0, chaque nœud est chargé de gérer sa propre partie de l'index, ce qui allège la charge sur la mémoire du nœud leader, améliore nos temps de démarrage en répartissant la charge de travail et accélère les requêtes DML.

Gestion simplifiée des partitions grâce à la spécification des partitions

Nous avons constaté que plusieurs clients de VectorH rencontraient des problèmes de performances parce qu’ils ne savaient pas qu’il fallait inclure la clause PARTITION lors de la création de tables, en particulier lorsqu’ils utilisaient CREATE TABLE AS SELECT (CTAS). Imaginons qu'ils disposaient d'une table existante répartie sur 15 partitions et qu'ils souhaitaient créer une nouvelle table basée sur cette table d'origine. Ils partaient du principe que celle-ci comporterait également 15 partitions, mais ce n'est pas ce que prévoit la norme SQL, et dans ce cas précis, le respect de la norme SQL nous a causé du tort. Pour remédier à cela, nous avons ajouté un paramètre de configuration qui peut être défini pour exiger l'utilisation de NOPARTITION ou de PARTITION= lors de la création d'une table vectorielle, que ce soit explicitement ou via CTAS.

Simplifiez la sauvegarde et la restauration grâce au clonage de bases de données

VectorH 5.0 introduit un nouvel utilitaire, clonedb, qui permet aux utilisateurs de créer une copie exacte de leur base de données dans une instance Vector distincte, par exemple pour transférer une base de données de production vers un environnement de développement à des fins de test. Cette fonctionnalité, qui avait été demandée par l'un de nos clients existants, a été très bien accueillie par l'ensemble des utilisateurs de Vector et VectorH.

Des exportations plus rapides grâce au déchargement parallèle de Spark Connector

Le connecteur Vector Spark permet désormais de décharger de grands volumes de données en parallèle sur tous les nœuds.

Chargement simplifié grâce à la syntaxe SQL pour vwload

VectorH 5.0 permet d'utiliser vwload avec l'instruction SQL COPY pour un chargement parallèle rapide des données depuis SQL.

Création simplifiée d'exportations CSV à partir de SQL

VectorH 5.0 permet d'exporter des données au format CSV à partir de SQL en utilisant la syntaxe suivante :

INSERT INTO EXTERNAL CSV 'nom_fichier' SELECT ... [WITH NULL_MARKER='NULL', FIELD_SEPARATOR=',', enregistrement]

Prochaines étapes

Pour en savoir plus, demandez une démonstration ou une version d'essai de VectorH afin de le tester au sein de votre Cluster Hadoop. Vous pouvez également découvrir la version mono-serveur d'Actian Vector fonctionnant sous Linux, distribuée gratuitement sous forme d'édition communautaire et disponible en téléchargement.