Fin de vie d'Apache Hive : versions, dates et prochaines étapes

Principaux enseignements

• Les versions 1.x, 2.x et 3.x d'Apache Hive ont toutes atteint leur fin de vie. Les versions communautaires proviennent désormais exclusivement de la branche 4.x, dont la version actuelle est la 4.2.0.
• Sur une version de Hive en fin de vie (EOL), les vulnérabilités CVE récemment révélées dans Hive et ses dépendances intégrées ne font l'objet d'aucun correctif communautaire pour cette version. Cela concerne notamment le Hive Metastore, qui contient les métadonnées permettant de localiser vos tables les plus sensibles et d'en contrôler l'accès.
• L'utilisation d'un logiciel d'entrepôt de données non pris en charge engendre un risque concret en matière d'audit. L'exigence 12.3.4 de la norme PCI DSS en fait un point de correction documenté et approuvé par la direction, tandis que les normes HIPAA, SOC 2 et ISO/IEC 27001 exigent toutes la mise en place d'un processus de gestion des vulnérabilités opérationnel dont vous pouvez apporter la preuve.
• Trois pistes réalistes pour aller de l'avant : effectuer une mise à niveau sur place vers Hive 4.2.0, abandonner complètement Hive, ou se procurer des correctifs CVE proposés par des tiers afin de se ménager une période de migration maîtrisée.

Si vous utilisez Apache Hive 2.3 ou 3.1 en production, les correctifs de sécurité fournis par la communauté pour ces versions ont cessé d’être publiés en 2024 – le 20 mai pour la branche 2.x et le 8 octobre pour la branche 3.x. La communauté a officiellement déclaré que les branches 1.x, 2.x et 3.x en fin de vie, de sorte que les nouvelles versions et corrections de la communauté ne concernent désormais plus que la branche 4.x.

Cela revêt davantage d’importance pour Hive que pour la plupart des bases de données. Hive constitue la couche SQL et de métadonnées qui recouvre les données d’entrepôt – informations personnelles identifiables, dossiers financiers, données de santé, etc. – et le Hive Metastore contient la carte indiquant où se trouvent ces données et qui peut y accéder. Cet article présente les versions qui ne sont plus prises en charge, les risques réels en matière de sécurité et de conformité, ainsi que les trois pistes à explorer sérieusement.

Apache Hive a-t-il atteint sa fin de vie ? Versions et dates

Oui. La communauté Apache Hive a voté pour déclarer la fin de vie des versions 1.x, 2.x et 3.x, ce qui signifie qu’il n’y aura plus de nouvelles versions, de corrections de bogues ni de correctifs de sécurité pour aucune d’entre elles.

Dès qu'une ligne est déclarée « EOL », le flux de publication s'arrête. L'ASF ne propose aucune prolongation payante ni aucune période de maintenance dédiée exclusivement à la sécurité.

Il convient également de noter le fonctionnement de la branche 4.x : les correctifs sont intégrés dans la dernière version mineure au lieu d’être rétroportés. La vulnérabilité CVE-2025-62728 a été corrigée dans la version 4.2.0 et n’a jamais été rétroportée vers la branche 4.1.x ; par conséquent, « sur la branche 4.x » et « corrigé » ne sont pas synonymes.

 Remarque : Prévoyez la mise à niveau vers Hive 4.x comme une opération à sens unique. Apache fournit des scripts de mise à niveau du schéma pour MySQL, PostgreSQL, Oracle, SQL Server et Derby, mais aucune procédure de retour en arrière n'est documentée ; votre plan de restauration consiste donc à restaurer une sauvegarde de la base de données Metastore plutôt qu'à réinstaller les binaires précédents. Testez cette restauration avant d'en avoir besoin.

Risques de sécurité liés à l'utilisation d'Apache Hive en fin de cycle de vie (EOL) en environnement de production

Un CVE Hive n'est pas un CVE de bibliothèque classique. Hive gère l'accès aux données à caractère personnel, aux transactions financières et aux dossiers médicaux, et le Metastore contient la structure qui permet d'accéder à l'ensemble de ces données.

Lorsqu'une vulnérabilité touche une gamme de produits en fin de vie, aucune nouvelle version n'est prévue pour cette gamme : vos options se limitent alors à atténuer le risque, à réintégrer vous-même le correctif ou à acheter des correctifs proposés par des tiers.

Pourquoi les failles de Metastore méritent une attention particulière

Un attaquant qui parvient à accéder au Metastore peut exécuter du code avec les privilèges du service Metastore, qui est le composant gérant l'accès à l'ensemble de l'entrepôt de données. HMS présente un historique documenté de vulnérabilités liées à la désérialisation et à l'injection.

La faille de désérialisation « partition-fetch » CVE-2022-41137 (HIVE-26539) permettait la désérialisation de données arbitraires, entraînant une exécution de code à distance (RCE). Apache l'a classée comme modérée et a limité son champ d'application à la version 4.0.0-alpha-1 antérieure à la version 4.0.0 ; elle n'a donc jamais été intégrée à une version GA et n'a jamais concerné les versions 1.x, 2.x ou 3.x. Considérez cette information comme une preuve concernant le composant, et non votre version en fin de vie (EOL).

Plus récemment, la vulnérabilité CVE-2025-62728 a révélé une faille d’injection SQL dans l’API HMS Thrift lors de la suppression des statistiques de colonnes. Cette faille affectait les versions 4.1.0 à 4.2.0 et a été corrigée dans la version 4.2.0. Là encore, il ne s’agit pas d’une faille liée à la fin de vie (EOL), mais cela démontre que HMS continue de révéler des vulnérabilités graves et que chaque correction est intégrée dans une nouvelle version.

Apache précise également que le chemin vulnérable est inaccessible lorsque metastore.try.direct.sql est défini sur « false », ce qui correspond au type de mesure d’atténuation qu’une ligne EOL vous permet encore d’appliquer. Il est important de lire attentivement les étiquettes de gravité plutôt que de les survoler, car une note « modérée » de l’ASF et un score CVSS de base peuvent donner des indications divergentes pour une même vulnérabilité ; voici comment fonctionnent les notations CVE et CVSS fonctionnent si cette distinction vous est peu familière.

Attention : Plusieurs vulnérabilités CVE de HMS sont répertoriées comme exploitables uniquement par des utilisateurs autorisés, et selon l’évaluation d’Apache, la plupart des déploiements n’exposent HMS qu’à une poignée d’applications telles que HiveServer2. Ne considérez pas pour autant que la situation est automatiquement sûre, ni qu’elle est automatiquement préoccupante. Déterminez quels utilisateurs et quelles applications sont réellement autorisés à appeler les méthodes Thrift concernées, si un HiveServer2 compromis pourrait y accéder, et si la méthode `metastore.try.direct.sql` est activée. C’est cette réponse, et non le libellé de l’avis de sécurité, qui détermine votre niveau d’exposition.

Derrière chaque composant se cache un arbre de dépendances figé

Hive n'est pas un simple fichier JAR. Il s'appuie sur un vaste ensemble de composants et de dépendances : Apache Hadoop, Calcite, Tez, Thrift, DataNucleus, ORC, Parquet, Avro, Kryo, Jackson, Guava, ainsi qu’une pile de journalisation basée sur Log4j, entre autres. N’importe lequel d’entre eux peut être à l’origine d’une vulnérabilité CVE critique.

Log4Shell (CVE-2021-44228) en est l'exemple le plus flagrant. Il ne s'agissait pas d'un bug de Hive, mais toutes les distributions Hive 2.x et 3.x compilées avant décembre 2021 intégraient une version de Log4j 2 appartenant à la plage concernée, et la correction consistait à remplacer cette bibliothèque intégrée.

La possibilité d'exploiter ou non un déploiement donné dépendait de sa configuration – plus précisément, du fait que des données contrôlées par un attaquant aient ou non donné lieu à une entrée dans le journal –, mais dans tous les cas, c'est aux opérateurs Hive qu'il incombait de prendre les mesures correctives.

Sur une branche prise en charge, vous bénéficiez d’une nouvelle version qui corrige la bibliothèque vulnérable. Sur une branche en fin de vie, cette version n’arrive jamais, et vous vous retrouvez à appliquer manuellement des correctifs aux fichiers JAR d’une distribution que plus personne ne maintient. Les équipes qui ont connu les cycles de correctifs d’Apache Struts savent bien à quoi ressemble ce problème : le correctif arrive toujours sous la forme d’une nouvelle version, et une branche qui ne publie plus de versions n’a aucun moyen d’y accéder.

L'exposition des identifiants et les failles de privilèges qui ne sont jamais corrigées

C'est là qu'EOL Hive cesse d'être une simple théorie. La vulnérabilité CVE-2024-29869 – classée comme « importante » par Apache et affectant les versions 1.1.0 à 4.0.1 – entraînait l’écriture par Hive d’un fichier d’identifiants dans un répertoire temporaire doté par défaut de permissions 644, lisible par tout utilisateur local ayant accès à ce répertoire. Ce problème a été corrigé dans la version 4.0.1. Toutes les instances EOL sont concernées et aucune d’entre elles ne peut bénéficier de ce correctif.

La vulnérabilité CVE-2024-23953, également classée comme « importante », présente le même problème : une comparaison de signatures en temps non constant dans le signataire LLAP permettait à un utilisateur autorisé de falsifier une signature valide octet par octet. Elle concernait les versions 2.2.0 à 4.0.0 ; les versions 2.3.x et 3.1.x se situent donc toutes deux dans cette plage.

Il y a ensuite la faille d'autorisation antérieure à la version 3.1.3, dans laquelle les opérations CREATE et DROP sur les fonctions contournaient les contrôles d'autorisation, ce qui permettait à un utilisateur ne disposant pas des privilèges suffisants de manipuler une fonction définie par l'utilisateur (UDF) pour qu'elle fasse référence à un fichier JAR malveillant (CVE-2021-34538). Il convient de noter que les utilisateurs de la version 3.1.3 ont bien bénéficié de ce correctif spécifique ; cette faille touche donc plus particulièrement les versions 2.x et antérieures.

Pris dans leur ensemble, ces éléments décrivent deux risques permanents distincts liés aux versions plus anciennes – la manipulation non autorisée des UDF et les identifiants lisibles – plutôt qu’une chaîne d’exploitation garantie. Sur une ligne de produits en fin de vie, ces deux risques sont permanents. Leur triage sans référence de référence mise à jour mobilise également un temps d’ingénierie réel pour distinguer les vulnérabilités réelles du bruit généré par les scanners.

Cadres de conformité affectés par l'exécution d'Apache Hive en fin de vie

L'exécution de Hive en fin de vie (EOL) transforme un problème technique de sécurité en un enjeu de gouvernance et d'audit, car de nombreux entrepôts de données traitent des informations soumises à des exigences de sécurité réglementaires, contractuelles ou liées aux clients.

Les auditeurs évaluent si les vulnérabilités identifiées font l'objet de mesures correctives ou d'atténuation grâce à des contrôles documentés et efficaces ; or, un composant non pris en charge rend cette démonstration plus difficile. À titre d'ordre de grandeur, le rapport IBM sur le coût des fuites de données 2025 estime le coût moyen mondial d’une violation à 4,44 millions de dollars, le secteur de la santé affichant le coût le plus élevé avec 7,42 millions de dollars ; notez que le chiffre mondial a baissé d’environ 9 % d’une année sur l’autre, il convient donc de le citer à titre de contexte plutôt que comme une menace croissante.

PCI DSS

Si des données relatives aux titulaires de cartes sont stockées ou traitées au sein de votre environnement Hive, les systèmes Hive et Metastore concernés relèvent probablement de la norme champ d'application de la norme PCI DSS . Deux exigences s’appliquent ici. 

L'exigence 6.3.3 prévoit que les correctifs critiques et de gravité élevée soient appliqués dans un délai d'un mois à compter de leur publication, ce qui est difficile à démontrer lorsqu'aucun correctif n'existe. L'exigence 12.3.4, pleinement applicable à compter du 31 mars 2025, vous impose de procéder à un examen du matériel et des logiciels au moins tous les 12 mois, de vérifier que chaque technologie continue de bénéficier de correctifs de sécurité rapides de la part des éditeurs, de consigner toute annonce de fin de vie et de disposer d'un plan de remédiation approuvé par la direction générale.

EOL Hive n'entraîne pas automatiquement l'échec d'une évaluation, mais il s'agit d'une lacune documentée qui a été validée par la direction et sur laquelle un QSA effectuera un suivi au niveau des hôtes Metastore et HiveServer2. Des contrôles compensatoires peuvent être envisageables, mais ils doivent répondre au risque spécifique et sont généralement considérés comme temporaires, le temps que la migration en cours soit menée à bien.

HIPAA

L'analyse des données de santé sur Hive concerne les informations de santé protégées (ePHI) relevant du champ d'application de la règle de sécurité de la loi HIPAA, qui exige une analyse des risques ainsi que des mesures de protection raisonnables et appropriées, plutôt qu’une version spécifique d’un produit. Les logiciels ne pouvant plus bénéficier de mises à jour de sécurité doivent être mentionnés nommément dans votre analyse des risques, accompagnés de mesures d’atténuation documentées et d’un calendrier de migration. La règle n’interdit pas purement et simplement les logiciels en fin de vie (EOL), mais un composant non documenté, non sécurisé et ne pouvant pas être corrigé, qui traite des données ePHI, constitue une vulnérabilité – tant lors de l’évaluation qu’ultérieurement, s’il devient la cause première d’une violation.

SOC 2 et ISO/IEC 27001

Pour les fournisseurs de SaaS et les éditeurs de logiciels d’entreprise, ce sont là les rapports que les clients demandent. Les uns comme les autres s’attendent à ce qu’un processus de gestion des vulnérabilités soit mis en place : la norme SOC 2, via les critères des services de confiance relatifs à la détection et à la correction des vulnérabilités, et la norme ISO/IEC 27001:2022, via le contrôle 8.8 de l’annexe A, « Gestion des vulnérabilités techniques ». Un entrepôt de données non pris en charge affaiblit ce contrôle lorsqu’il n’existe aucune source fiable de correctifs de sécurité, aucune mesure d’atténuation documentée et aucun plan de migration assorti d’un calendrier précis.

Réalité : Le fait qu’un système soit « à usage interne uniquement » n’exclut pas automatiquement Hive du périmètre d’audit. Si le système stocke, traite ou donne accès à des données réglementées, évaluez-le au regard du référentiel applicable et des limites documentées de votre système. L’emplacement sur le réseau peut avoir une incidence sur le périmètre et les contrôles compensatoires ; cela ne règle toutefois pas la question.

Défis liés à la migration d'Apache Hive en fin de vie

La plupart des équipes se sont déjà vu dire : « Il suffit de passer à Hive 4. » Ce conseil sous-estime largement l'ampleur du travail à accomplir. Le passage d'une version 2.x ou 3.x à une version 4.x n'est pas un simple changement de version : il s'agit d'une refonte coordonnée de la JVM, du Metastore, ainsi que des moteurs et applications en aval qui dépendent de Hive.

Le changement de version de Java

Les environnements Hive 2 et 3 hérités fonctionnent généralement sous Java 8. Le tableau des configurations requises d’Apache indique Java 17 pour Hive 4.1.x et Java 21 pour la version 4.2.x, tandis que la version 4.0.1 est la dernière à être répertoriée avec Java 8. La version 4.0.1 constitue donc une véritable étape intermédiaire si votre JVM ne peut pas encore être mise à niveau, même si elle ne bénéficie plus de correctifs.

Passer directement à la version 4.2.0 implique une mise à jour de la JVM sur tous vos nœuds Hadoop, de votre code UDF et de tout service en aval utilisant le même environnement d'exécution. Le bytecode Java 8 s'exécute souvent sans problème sur les JDK plus récents ; le véritable travail réside donc dans les tests de compatibilité : les UDF et les bibliothèques associées cessent de fonctionner lorsqu'elles dépendent de modules supprimés, d'API JDK internes, d'un accès réflexif ou de bibliothèques qui n'ont jamais pris en charge les versions 17 ou 21. Quiconque a déjà vécu fin de vie de Java 8 ou fin de vie de Java 11 sait que la transition de la JVM constitue généralement la partie la plus longue de la migration. Commencez par recenser toutes les UDF et tous les services dépendants de la JVM, puis organisez la mise à niveau de Java séparément de celle de Hive.

Schéma Metastore et migration des tables ACID

Hive 4 modifie le schéma du Metastore ; vous devez donc exécuter les scripts de mise à niveau dans l'ordre sur une base de données de support prise en charge. Si votre HMS fonctionne sur une base de données en fin de vie (EOL), vous rencontrerez le même problème que les équipes utilisant PostgreSQL 13, qui a atteint sa fin de vie le 13 novembre 2025 –, vous devez effectuer deux migrations simultanément.

Les tables ACID posent un problème particulier, et cette exigence est spécifique à la version. Les notes de mise à jour d’Apache Hive 3.0.0 précisent que toute partition de table ACID sur laquelle une instruction UPDATE, DELETE ou MERGE a été exécutée depuis sa dernière compaction majeure doit faire l’objet d’une compaction majeure avant la mise à niveau, qu’aucune autre instruction UPDATE/DELETE/MERGE ne peut être exécutée une fois cette compaction lancée, et que le non-respect de cette consigne peut entraîner une corruption des données. Les tables ne contenant que des résultats d’INSERT ne sont pas concernées. Le passage de la version 2.x à la version 4.x franchit cette limite ; veillez donc à vérifier quelles sont vos tables transactionnelles antérieures à Hive 3 plutôt que de considérer cette règle comme universelle. Effectuez d’abord un instantané de la base de données Metastore, lancez la compaction en tant qu’étape préliminaire, puis testez la mise à niveau du schéma sur un clone avant d’intervenir sur l’environnement de production. Vérifiez la version actuelle du schéma, effectuez un test à blanc de la mise à niveau, puis appliquez-la :

schematool -dbType postgres -info

schematool -dbType postgres -upgradeSchema -dryRun

schematool -dbType postgres -upgradeSchema

Remplacez « dbType » par votre propre valeur ; les informations de connexion proviennent de votre configuration Hive. Si le métastore ne contient aucune version de schéma enregistrée, spécifiez explicitement la source à l'aide de l'option -upgradeSchemaFrom.

Pannes du moteur et de l'intégration

Hive 4 fait de Tez le moteur d'exécution par défaut, et le moteur MapReduce est obsolète depuis la version Hive 2 ; la documentation indique d'ailleurs qu'il pourrait être supprimé sans préavis. Toute charge de travail encore liée à mr – ou au moteur d'exécution Spark – doit être validée avant de planifier une migration.

La plus grande surprise se trouve en aval. La compatibilité varie en fonction des versions et configurations spécifiques de Spark, Trino, Impala, Iceberg et de leurs clients Metastore ; il convient donc de considérer chaque intégration comme non vérifiée tant qu’elle n’a pas été testée, plutôt que de partir du principe qu’une matrice de versions est valable. Lorsqu’un même Metastore est partagé simultanément par Spark, Trino et Impala, la mise à niveau se répercute sur l’ensemble de ces composants en même temps. Répertoriez tous les consommateurs Metastore avant de planifier quoi que ce soit, et intégrez un test de compatibilité pour chaque moteur dans le guide de mise à niveau.

Conseil de pro : Mettez en place un environnement Hive 4.2.0 parallèle pointant vers un Metastore cloné, puis exécutez-y un échantillon représentatif de requêtes de production. Nettoyez d’abord cet échantillon : les journaux de requêtes contiennent souvent des identifiants sensibles et des valeurs littérales. Il est préférable que les dysfonctionnements de Spark et Trino apparaissent lors des tests de préproduction, et non lors de la mise en production, moment où ils ont tendance à se manifester.

Options après la fin de vie d'Apache Hive

Il existe trois voies possibles pour presque toutes les équipes, et celles-ci ne s'excluent pas mutuellement. La plupart des organisations finissent par gagner du temps sur l'une d'entre elles tout en mettant en œuvre une autre.

Mise à niveau sur place vers Hive 4.2.0

Si vos dépendances JVM et moteur peuvent être migrées et que vous disposez d’une capacité de staging, la mise à niveau vers la version 4.2.0 constitue la solution la plus appropriée à long terme. Vous passez ainsi à la branche de version actuelle, adoptez Java 21 comme environnement d’exécution minimum pris en charge et bénéficiez des améliorations apportées au Metastore 4.2.0 et à Apache Iceberg : prise en charge étendue des catalogues, notamment un client REST pour le catalogue Iceberg, compactage automatique, vecteurs de suppression et valeurs par défaut des colonnes. Tenez compte du saut de version Java, de la migration du schéma et de la vérification préalable de la compaction ACID décrite ci-dessus. Si votre pile est petite et autonome, commencez par là. Si elle alimente à la fois Spark, Trino et Impala, prévoyez nettement plus de temps que ne le laissent supposer les numéros de version.

Remplacer entièrement Hive

Certaines équipes se servent de la fin de vie (EOL) comme motif pour abandonner Hive plutôt que de le mettre à niveau. Les architectures « lakehouse » modernes, construites autour d’Apache Iceberg et interrogées via Trino, Spark SQL ou une plateforme gérée, peuvent réduire, voire supprimer, la dépendance à la couche d’exécution classique de Hive, bien que beaucoup conservent un catalogue ou un Metastore compatible avec Hive pendant la transition. Il s’agit de la voie la plus exigeante en termes d’efforts et elle aboutit rarement dans les délais imposés par une faille de sécurité active ; elle est donc généralement mise en œuvre en parallèle d’un support prolongé qui offre une marge de manœuvre. Si vous procédez de toute façon à une refonte de votre plateforme, cela vous évite de consacrer des efforts de migration à un moteur que vous aviez prévu de retirer.

TuxCare, un soutien sans faille tout au long du cycle de vie

Si vous ne pouvez pas effectuer la migration dans les délais exigés par vos auditeurs ou votre registre des risques, le service service « Endless Lifecycle Support » (ELS) de TuxCare vous fournit des correctifs CVE pour Apache Hive 2.3.9 au-delà de sa fin de vie, livrés via votre workflow de gestion de paquets existant. La couverture est spécifique à chaque version ; veillez donc à vérifier votre version exacte par rapport à la liste des versions prises en charge avant de planifier quoi que ce soit. Si vous utilisez la version 2.3.10, 3.1.3 ou une autre branche, n’hésitez pas à nous contacter, car TuxCare ajoute des versions sur demande. Vous pouvez ainsi conserver la version de Hive dont dépend votre infrastructure d’entrepôt de données sans avoir à précipiter une migration.

Pour une équipe en pleine refonte de sa plateforme, cela fait la différence entre une mise à niveau sujette aux dysfonctionnements, effectuée sous la pression d’un audit, et une migration planifiée selon votre calendrier. Cela rétablit une source maintenue de correctifs de sécurité, ce qui correspond exactement à la condition requise par l’exigence 12.3.4 de la norme PCI DSS, et vous fournit des preuves documentées et défendables des mesures correctives mises en œuvre pendant votre migration vers Hive 4.2.0, une fois que les travaux sur Java et le moteur seront réellement prêts. Cela ne permet pas à lui seul de clore une non-conformité d’audit – aucun service de correctifs ne le peut, car cela dépend de votre périmètre, de vos preuves et de votre auditeur –, mais cela modifie ce que vous êtes en mesure de présenter.

Sécurisez Apache Hive au-delà de sa fin de vie (EOL) avec TuxCare

Le compteur d'EOL de Hive ne se remet pas à zéro. Tout nouveau CVE divulgué affectant votre version ne fera l'objet d'aucun correctif communautaire pour cette branche, et à chaque cycle d'audit, on vous demandera quelles mesures vous avez prises à ce sujet. La marche à suivre concrète est la suivante : commencez par restaurer une source de correctifs, puis migrez vers Hive 4.2.0 ou abandonnez complètement Hive selon un calendrier que vous contrôlez vous-même, plutôt que selon celui que vous imposerait un incident.

Si vous utilisez une version de Hive en fin de vie (EOL) et que vous n'êtes pas prêt à migrer ce trimestre, le service de support à cycle de vie illimité de TuxCare peut vous permettre de corriger les vulnérabilités CVE pendant que vous préparez la mise à niveau ou le remplacement. Ce service fournit des correctifs CVE pour Apache Hive 2.3.9 via votre workflow de gestion de paquets existant, sans changement de version imposé.

FAQ

Quelles sont les versions d'Apache Hive encore prises en charge ?

Seule la branche 4.x bénéficie de versions communautaires, dont la version actuelle est la 4.2.0. Apache indique Java 17 pour la branche 4.1.x et Java 21 pour la branche 4.2.x. Sachez que les correctifs sont intégrés dans la version mineure la plus récente plutôt que d’être rétroportés – la vulnérabilité CVE-2025-62728 a été corrigée dans la version 4.2.0 et non dans la version 4.1.x – ; par conséquent, utiliser la version 4.1.0 n’équivaut pas à utiliser une version corrigée. Les séries 1.x, 2.x et 3.x sont toutes en fin de vie.

À quelle date Apache Hive 3.x a-t-il atteint sa fin de vie ?

La communauté Apache Hive a annoncé la fin de vie de la version 3.x le 8 octobre 2024. La dernière version publiée était la 3.1.3, sortie le 8 avril 2022.

Puis-je continuer à utiliser Hive 2.3.x en production après la fin de vie du produit ?

Techniquement oui, mais vous devrez gérer les risques sans bénéficier des correctifs fournis par la communauté. La dernière version de la branche 2.x était la 2.3.10, publiée le 9 mai 2024, et cette branche a été déclarée en fin de vie le 20 mai 2024. La communauté Apache Hive ne publiera pas de nouvelle version 2.3.x pour les CVE récemment divulgués affectant Hive ou ses dépendances intégrées. Vous avez le choix entre maintenir vos propres rétroportages ou faire appel à un support commercial indépendant tel que TuxCare ELS.

La mise à niveau vers Hive 4 perturbe-t-elle les intégrations avec Spark ou Trino ?

C'est possible, en fonction des versions exactes et de la configuration de chaque moteur et client Metastore. Testez chaque intégration Spark, Trino, Impala et Iceberg avec la version cible de Hive dans un environnement de préproduction avant toute mise en production.

Le Hive Metastore (HMS) a-t-il sa propre date de fin de vie ?

Non. Les versions HMS suivent les versions d’Apache Hive. À partir de Hive 4.1.0, le Metastore est également distribué en tant que composant autonome sous forme de fichiers binaires et d’images Docker, et la version 4.2.0 a séparé le code client du Metastore dans son propre module – mais les correctifs de sécurité fournis par la communauté continuent de suivre les versions prises en charge de Hive. Une version de Hive en fin de vie (EOL) implique donc une fin de vie (EOL) du Metastore.

Résumé

Nom de l'article

Fin de vie d'Apache Hive : versions, dates et prochaines étapes

Description

Les versions 1.x, 2.x et 3.x d'Apache Hive ont atteint leur fin de vie. Découvrez les dates exactes de fin de vie, les risques réels liés aux vulnérabilités CVE et à la conformité, ainsi que trois pistes concrètes pour aller de l'avant.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur