Ende des Lebenszyklus von Apache Hive: Versionen, Termine und nächste Schritte

Wichtigste Erkenntnisse

• Apache Hive 1.x, 2.x und 3.x haben alle das Ende ihres Lebenszyklus erreicht. Community-Versionen werden nun ausschließlich aus der 4.x-Reihe veröffentlicht, wobei 4.2.0 die aktuelle Version ist.
• Bei einer Hive-Produktreihe, deren Lebenszyklus beendet ist (EOL), werden neu bekannt gewordene CVEs in Hive und den darin enthaltenen Abhängigkeiten von der Community nicht mehr behoben. Dies gilt auch für den Hive Metastore, der die Metadaten enthält, mit denen Ihre sensibelsten Tabellen lokalisiert und deren Zugriff geregelt wird.
• Nicht unterstützte Data-Warehouse-Software birgt konkrete Risiken bei der Revision. Die PCI-DSS-Anforderung 12.3.4 macht dies zu einem dokumentierten, von der Geschäftsleitung genehmigten Korrekturpunkt, und auch HIPAA, SOC 2 sowie ISO/IEC 27001 setzen einen funktionierenden Prozess zum Schwachstellenmanagement voraus, den Sie nachweisen können.
• Drei realistische Vorgehensweisen: Upgrade auf Hive 4.2.0, vollständige Abwanderung von Hive oder die Beschaffung von CVE-Patches von Drittanbietern, um sich ein kontrolliertes Migrationsfenster zu verschaffen.

Wenn Sie Apache Hive 2.3 oder 3.1 in der Produktion einsetzen, wurden die Sicherheitspatches der Community für Ihre Version im Jahr 2024 eingestellt – am 20. Mai für die 2.x-Version und am 8. Oktober für die 3.x-Version. Die Community hat die Versionen 1.x, 2.x und 3.x offiziell für als das Ende ihres Lebenszykluserklärt, sodass neue Community-Veröffentlichungen und Fehlerbehebungen nun ausschließlich für die 4.x-Reihe bereitgestellt werden.

Für Hive ist dies von größerer Bedeutung als für die meisten anderen Datenbanken. Hive bildet die SQL- und Metadatenebene über den Daten aus Data Warehouses – personenbezogene Daten, Finanzdaten, Gesundheitsdaten, einfach alles – und der Hive Metastore enthält die Übersicht darüber, wo sich diese Daten befinden und wer darauf zugreifen darf. In diesem Artikel wird erläutert, welche Versionen nicht mehr unterstützt werden, wie die tatsächlichen Sicherheits- und Compliance-Risiken aussehen und welche drei Lösungsansätze ernsthaft in Betracht gezogen werden sollten.

Ist Apache Hive am Ende seiner Lebensdauer angelangt? Versionen und Daten

Ja. Die Apache-Hive-Community hat beschlossen, die Versionsreihen 1.x, 2.x und 3.x als „End of Life“ zu erklären, was bedeutet, dass es für keine dieser Versionen mehr Community-Releases, Fehlerbehebungen oder Sicherheitspatches geben wird.

Sobald eine Produktlinie als EOL deklariert wurde, wird der Release-Strom eingestellt. Es gibt keine kostenpflichtige Verlängerung durch die ASF und kein reines Sicherheits-Wartungsfenster.

Es ist außerdem erwähnenswert, wie sich die 4.x-Reihe verhält: Fehlerbehebungen werden in der neuesten Minor-Version implementiert, anstatt zurückportiert zu werden. CVE-2025-62728 wurde in 4.2.0 behoben und nie auf 4.1.x zurückportiert, daher sind „auf 4.x“ und „gepatcht“ nicht dasselbe.

 Hinweis: Planen Sie ein Upgrade auf Hive 4.x als reinen Vorwärts-Vorgang. Apache liefert Skripte für das Schema-Upgrade für MySQL, PostgreSQL, Oracle, SQL Server und Derby mit, jedoch keinen dokumentierten Downgrade-Pfad. Ihr Rollback-Plan besteht daher darin, eine Sicherung der Metastore-Datenbank wiederherzustellen, anstatt die vorherigen Binärdateien neu zu installieren. Testen Sie diese Wiederherstellung, bevor Sie sie benötigen.

Sicherheitsrisiken beim Einsatz von Apache Hive nach Ablauf der Lebensdauer (EOL) in der Produktion

Ein Hive-CVE ist kein gewöhnliches Bibliotheks-CVE. Hive-Broker ermöglichen den Zugriff auf personenbezogene Daten, Finanztransaktionen und Gesundheitsdaten, und der Metastore enthält die Zuordnung zu all diesen Daten.

Wenn eine Sicherheitslücke eine EOL-Produktreihe betrifft, wird für diese Produktreihe kein neues Release mehr veröffentlicht – Ihnen bleiben dann nur noch folgende Optionen: die Sicherheitslücke abzumildern, den Fix selbst zurückzuportieren oder Patches von Drittanbietern zu erwerben.

Warum Sicherheitslücken in Metastore besondere Aufmerksamkeit verdienen

Ein Angreifer, der Zugriff auf den Metastore erhält, kann Code mit den Berechtigungen des Metastore-Dienstes ausführen – jener Komponente, die den Zugriff auf das gesamte Data Warehouse vermittelt. Bei HMS wurden in der Vergangenheit sowohl Deserialisierungs- als auch Injektionsschwachstellen dokumentiert.

Die Deserialisierungsschwachstelle „Partition-Fetch“ (CVE-2022-41137, HIVE-26539) ermöglichte die Deserialisierung beliebiger Daten, was zu einer Remote-Code-Ausführung (RCE) führte. Apache stufte die Schwere als „moderat“ ein und beschränkte den Betrafbereich auf die Version 4.0.0-alpha-1 vor 4.0.0, sodass die Schwachstelle nie in einer GA-Version enthalten war und die Versionen 1.x, 2.x oder 3.x nicht betraf. Betrachten Sie dies als Hinweis auf die Komponente, nicht auf Ihre EOL-Version.

Vor kurzem wurde durch CVE-2025-62728 bekannt, eine SQL-Injection in der HMS-Thrift-API zum Löschen von Spaltenstatistiken aufgedeckt. Die Schwachstelle betraf die Versionen 4.1.0 bis 4.2.0 und wurde in 4.2.0 behoben – auch hier handelt es sich nicht um einen Fehler in einer EOL-Version, sondern um einen Beweis dafür, dass HMS weiterhin schwerwiegende Sicherheitslücken aufdeckt und dass jeder Fix in Form einer neuen Version veröffentlicht wird.

Apache weist außerdem darauf hin, dass der anfällige Pfad nicht erreichbar ist, wenn „metastore.try.direct.sql“ auf „false“ gesetzt ist – eine Art der Abhilfe, die auch bei einer EOL-Zeile noch angewendet werden kann. Es lohnt sich, die Schweregrad-Bezeichnungen sorgfältig zu lesen, anstatt sie nur zu überfliegen, da eine ASF-Einstufung als „moderat“ und ein CVSS-Basiswert bei ein und demselben Befund in unterschiedliche Richtungen weisen können; und zwar folgendermaßen CVE- und CVSS-Bewertung funktionieren, falls Ihnen dieser Unterschied noch nicht geläufig ist.

Achtung: Mehrere HMS-CVEs sind als nur für autorisierte Benutzer ausnutzbar dokumentiert, und laut Apaches eigener Einschätzung setzen die meisten Installationen HMS nur einer Handvoll Anwendungen wie HiveServer2 aus. Verstehen Sie dies nicht als automatisch sicher, aber auch nicht als automatisch alarmierend. Stellen Sie fest, welche Benutzer und Anwendungen tatsächlich berechtigt sind, die betroffenen Thrift-Methoden aufzurufen, ob ein kompromittierter HiveServer2 diese erreichen könnte und ob „metastore.try.direct.sql“ aktiviert ist. Diese Antwort – und nicht der Wortlaut des Sicherheitshinweises – gibt Aufschluss über Ihr Risiko.

Hinter jeder Komponente verbirgt sich ein feststehender Abhängigkeitsbaum

Hive besteht nicht aus einer einzigen JAR-Datei. Es stützt sich auf einen umfangreichen Komponenten- und Abhängigkeitsbaum: Apache Hadoop, Calcite, Tez, Thrift, DataNucleus, ORC, Parquet, Avro, Kryo, Jackson, Guava sowie einen auf Log4j basierenden Logging-Stack, um nur einige zu nennen. Jede dieser Komponenten kann eine kritische CVE verursachen.

Log4Shell (CVE-2021-44228) ist das deutlichste Beispiel. Es handelte sich zwar nicht um einen Hive-Fehler, aber jede vor Dezember 2021 erstellte Hive-2.x- und 3.x-Distribution enthielt eine Log4j-2-Version aus dem betroffenen Bereich, und zur Behebung des Problems musste diese mitgelieferte Bibliothek ersetzt werden.

Ob eine bestimmte Bereitstellung tatsächlich ausgenutzt werden konnte, hing von der Konfiguration ab – genauer gesagt davon, ob von Angreifern kontrollierte Daten in eine Protokollmeldung gelangten –, doch die Behebung des Problems fiel in jedem Fall den Hive-Betreibern zu.

Bei einer unterstützten Produktlinie erhalten Sie ein Release, das die anfällige Bibliothek aktualisiert. Bei einer EOL-Produktlinie erscheint dieses Release jedoch nie, und Sie müssen JARs in einer Distribution, die niemand mehr pflegt, manuell patchen. Teams, die die Patch-Zyklen von Apache Struts miterlebt haben, kennen dieses Problem nur zu gut: Der Fix erscheint immer als neues Release, und eine Produktlinie, für die keine Releases mehr veröffentlicht werden, hat keinen Zugang dazu.

Offenlegung von Anmeldedaten und Berechtigungslücken, die nie behoben werden

An dieser Stelle ist EOL Hive nicht mehr nur Theorie. CVE-2024-29869 – von Apache als „wichtig“ eingestuft und betrifft die Versionen 1.1.0 bis einschließlich 4.0.1 – führte dazu, dass Hive standardmäßig eine Anmeldedaten-Datei in ein temporäres Verzeichnis mit den Berechtigungen 644 schrieb, die von jedem lokalen Benutzer mit Zugriff auf dieses Verzeichnis gelesen werden konnte. Das Problem wurde in Version 4.0.1 behoben. Alle EOL-Instanzen sind davon betroffen, und keine von ihnen kann die Korrektur erhalten.

Bei CVE-2024-23953, das ebenfalls als „wichtig“ eingestuft wurde, handelt es sich um denselben Fall: Ein Signaturvergleich mit nicht konstanter Laufzeit im LLAP-Signierer ermöglichte es einem autorisierten Benutzer, eine gültige Signatur Byte für Byte zu fälschen. Betroffen waren die Versionen 2.2.0 bis 4.0.0, sodass sowohl 2.3.x als auch 3.1.x in diesen Bereich fallen.

Hinzu kommt die Sicherheitslücke vor Version 3.1.3, bei der die Autorisierungsprüfungen für CREATE- und DROP-Funktionsoperationen umgangen wurden und ein Benutzer mit unzureichenden Berechtigungen eine benutzerdefinierte Funktion (UDF) so manipulieren konnte, dass diese auf eine bösartige JAR-Datei verwies (CVE-2021-34538). Beachten Sie, dass Nutzer von Version 3.1.3 diesen speziellen Fix erhalten haben, sodass diese Sicherheitslücke vor allem Versionen 2.x und früher betrifft.

Insgesamt beschreiben diese zwei unterschiedliche, bei älteren Versionen bestehende Risiken – unbefugte Manipulation von UDFs und lesbare Anmeldedaten – und nicht eine garantierte Exploit-Kette. Bei einer EOL-Produktreihe sind beide Risiken dauerhaft vorhanden. Ihre Einstufung ohne eine gepflegte Referenzbasis kostet zudem wertvolle Entwicklungszeit, da echte Sicherheitslücken von Scanner-Rauschen unterschieden werden müssen.

Compliance-Rahmenwerke, die durch den Betrieb von Apache Hive nach Ablauf der Lebensdauer (EOL) beeinträchtigt werden

Der Betrieb von EOL Hive macht aus einem technischen Sicherheitsproblem ein Problem im Bereich Governance und Revision, da viele Data Warehouses Informationen verarbeiten, die regulatorischen, vertraglichen oder kundenspezifischen Sicherheitsanforderungen unterliegen.

Prüfer beurteilen, ob identifizierte Schwachstellen durch dokumentierte, wirksame Kontrollmaßnahmen behoben oder gemindert werden – und eine nicht unterstützte Komponente erschwert den Nachweis dafür. Zum Vergleich: Der IBM-Bericht „Cost of a Data Breach Report 2025“ die weltweiten Durchschnittskosten einer Datenschutzverletzung auf 4,44 Millionen US-Dollar, wobei der Gesundheitssektor mit 7,42 Millionen US-Dollar den höchsten Wert aufweist; beachten Sie, dass der weltweite Wert im Jahresvergleich um etwa 9 % gesunken ist; führen Sie ihn daher eher als Kontextangabe an und nicht als Zeichen einer eskalierenden Bedrohung.

PCI DSS

Wenn Karteninhaberdaten in Ihrer Hive-Umgebung gespeichert oder über diese verarbeitet werden, fallen die entsprechenden Hive- und Metastore-Systeme wahrscheinlich unter Geltungsbereich des PCI DSS . Hier gelten zwei Anforderungen. 

Anforderung 6.3.3 sieht vor, dass Patches für kritische und schwerwiegende Sicherheitslücken innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen, was jedoch schwer nachzuweisen ist, wenn kein Patch vorliegt. Anforderung 12.3.4, die ab dem 31. März 2025 vollständig überprüfbar ist, verlangt, dass Sie Hardware und Software mindestens alle 12 Monate überprüfen, sicherstellen, dass für jede Technologie weiterhin zeitnahe Sicherheitspatches vom Hersteller bereitgestellt werden, Ankündigungen zum Ende des Lebenszyklus dokumentieren und über einen von der Geschäftsleitung genehmigten Abhilfemaßnahmenplan verfügen.

EOL Hive führt nicht automatisch zum Nichtbestehen einer Bewertung, wird jedoch als dokumentierte Lücke erfasst, die von der Geschäftsleitung genehmigt wurde und von einem QSA auf den Metastore- und HiveServer2-Hosts weiterverfolgt wird. Ausgleichsmaßnahmen können sinnvoll sein, müssen jedoch auf das spezifische Risiko ausgerichtet sein und werden in der Regel als vorübergehende Lösung betrachtet, solange die Migration noch im Gange ist.

HIPAA

Gesundheitsanalysen auf Hive bedeuten ePHI im Sinne der HIPAA-Sicherheitsvorschrift, die eine Risikoanalyse sowie angemessene und geeignete Sicherheitsmaßnahmen vorschreibt, anstatt eine bestimmte Produktversion vorzuschreiben. Software, für die keine Sicherheitsupdates mehr bereitgestellt werden, sollte in Ihrer Risikoanalyse namentlich aufgeführt werden, zusammen mit dokumentierten Abhilfemaßnahmen und einem Zeitplan für die Migration. Die Vorschrift verbietet EOL-Software nicht gänzlich, doch eine undokumentierte, ungesicherte und nicht mehr zu patchene Komponente, die ePHI verarbeitet, stellt eine Schwachstelle dar – sowohl bei der Bewertung als auch im Nachhinein, falls sie zur Ursache eines Datenschutzverstoßes wird.

SOC 2 und ISO/IEC 27001

Für SaaS- und Unternehmensanbieter sind dies die Berichte, die Kunden anfordern. Beide erwarten einen funktionierenden Prozess zum Schwachstellenmanagement – SOC 2 gemäß den Trust Services Criteria zur Erkennung und Behebung von Schwachstellen sowie ISO/IEC 27001:2022 gemäß Anhang A, Kontrollmaßnahme 8.8, „Management technischer Schwachstellen“. Ein nicht unterstütztes Data Warehouse schwächt diese Kontrollmaßnahme, wenn keine zuverlässige Quelle für Sicherheitspatches, keine dokumentierten Abhilfemaßnahmen und kein zeitgebundener Migrationsplan dahinterstehen.

Realitätscheck: „Es ist nur für den internen Gebrauch bestimmt“ bedeutet nicht automatisch, dass Hive aus dem Prüfungsumfang ausgeschlossen ist. Wenn das System regulierte Daten speichert, verarbeitet oder Zugriff darauf gewährt, bewerten Sie es anhand des geltenden Regelwerks und Ihrer dokumentierten Systemgrenzen. Die Platzierung im Netzwerk kann sich auf den Umfang und die Ausgleichskontrollen auswirken; sie klärt die Frage jedoch nicht endgültig.

Herausforderungen bei der Migration von Apache Hive am Ende des Lebenszyklus

Den meisten Teams wurde bereits geraten: „Führt einfach ein Upgrade auf Hive 4 durch.“ Dieser Ratschlag unterschätzt den Arbeitsaufwand bei weitem. Der Sprung von einer 2.x- oder 3.x-Version auf 4.x ist kein bloßer Versionssprung – es handelt sich um eine koordinierte Umstellung, die die JVM, den Metastore sowie die nachgelagerten Engines und Anwendungen, die auf Hive angewiesen sind, betrifft.

Der Versionssprung bei Java

Ältere Hive-2- und -3-Umgebungen laufen in der Regel unter Java 8. In der Anforderungstabelle von Apache wird für Hive 4.1.x Java 17 und für 4.2.x Java 21 aufgeführt, während 4.0.1 als letzte Version unter Java 8 aufgeführt ist – was 4.0.1 zu einem echten Zwischenschritt macht, falls Ihre JVM noch nicht umgestellt werden kann, auch wenn für diese Version keine Fehlerbehebungen mehr bereitgestellt werden.

Ein vollständiges Upgrade auf 4.2.0 erfordert eine Umstellung der JVM auf allen Hadoop-Knoten, in Ihrem UDF-Code sowie bei allen nachgelagerten Diensten, die dieselbe Laufzeitumgebung nutzen. Java-8-Bytecode läuft oft problemlos auf neueren JDKs, daher besteht die eigentliche Arbeit in Kompatibilitätstests: UDFs und unterstützende Bibliotheken funktionieren nicht mehr, wenn sie von entfernten Modulen, internen JDK-APIs, reflektivem Zugriff oder Bibliotheken abhängen, die Java 17 oder 21 nie unterstützt haben. Jeder, der bereits das Ende der Lebensdauer (EOL) von Java 8 oder Java 11 EOL durchgemacht hat, weiß, dass die JVM-Umstellung in der Regel den zeitaufwändigsten Teil der Migration ausmacht. Erfassen Sie zunächst alle UDFs und JVM-abhängigen Dienste und führen Sie das Java-Upgrade dann getrennt vom Hive-Upgrade durch.

Metastore-Schema und ACID-Tabellenmigration

Hive 4 ändert das Metastore-Schema, daher müssen Sie die Upgrade-Skripte der Reihe nach auf einer unterstützten Basisdatenbank ausführen. Wenn Ihr HMS auf einer EOL-Datenbank läuft, besteht dasselbe Problem, mit dem Teams bei PostgreSQL 13, das am 13. November 2025 das Ende seiner Lebensdauer erreicht hat – müssen Sie zwei Migrationen gleichzeitig durchführen.

ACID-Tabellen stellen eine besondere Herausforderung dar, und die Anforderung ist versionsspezifisch. In den Versionshinweisen zu Apache Hive 3.0.0 heißt es, dass jede ACID-Tabellenpartition, auf der seit der letzten umfassenden Komprimierung ein UPDATE-, DELETE- oder MERGE-Befehl ausgeführt wurde, vor dem Upgrade einer umfassenden Komprimierung unterzogen werden muss, dass nach Beginn dieser Komprimierung keine weiteren UPDATE-/DELETE-/MERGE-Befehle ausgeführt werden dürfen und dass die Nichtbeachtung dieser Vorgabe zu Datenkorruption führen kann. Tabellen, die ausschließlich INSERT-Ergebnisse enthalten, sind davon nicht betroffen. Ein Sprung von Version 2.x auf 4.x überschreitet diese Grenze; überprüfen Sie daher, welche Ihrer transaktionalen Tabellen bereits vor Hive 3 erstellt wurden, anstatt die Regel als allgemeingültig anzusehen. Erstellen Sie zunächst einen Snapshot der Metastore-Datenbank, führen Sie die Komprimierung als Vorbereitungsschritt durch und testen Sie das Schema-Upgrade auf einem Klon, bevor Sie die Produktionsumgebung berühren. Überprüfen Sie die aktuelle Schema-Version, führen Sie das Upgrade im Testmodus durch und wenden Sie es anschließend an:

schematool -dbType postgres -info

schematool -dbType postgres -upgradeSchema -dryRun

schematool -dbType postgres -upgradeSchema

Ersetzen Sie „dbType“ durch Ihren eigenen Wert; die Verbindungsdaten stammen aus Ihrer Hive-Konfiguration. Wenn für den Metastore keine Schemaversion hinterlegt ist, geben Sie die Quelle explizit mit „-upgradeSchemaFrom“ an.

Fehler in der Engine und bei der Integration

Ab Hive 4 ist Tez die Standard-Ausführungsengine, und die MapReduce-Engine ist bereits seit der Hive-2-Reihe veraltet, wobei in der Dokumentation darauf hingewiesen wird, dass sie ohne weitere Ankündigung entfernt werden kann. Alle Workloads, die noch an „mr“ – oder an die Spark-Ausführungsengine – gebunden sind, müssen vor der Planung einer Umstellung überprüft werden.

Die größere Überraschung erwartet Sie im weiteren Verlauf. Die Kompatibilität hängt von den jeweiligen Versionen und Konfigurationen von Spark, Trino, Impala, Iceberg und deren Metastore-Clients ab. Behandeln Sie daher jede Integration so lange als ungeprüft, bis Sie sie getestet haben, anstatt davon auszugehen, dass eine Versionsmatrix gilt. Wenn ein einzelner Metastore gleichzeitig von Spark, Trino und Impala genutzt wird, wirkt sich das Upgrade gleichzeitig auf alle drei aus. Ordnen Sie jeden Metastore-Konsumenten zu, bevor Sie irgendetwas planen, und integrieren Sie einen Kompatibilitätstest für jede Engine in das Upgrade-Runbook.

Profi-Tipp: Richten Sie eine parallele Hive 4.2.0-Umgebung ein, die auf einen geklonten Metastore verweist, und führen Sie darin eine repräsentative Stichprobe von Produktionsabfragen durch. Bereinigen Sie die Stichprobe zuvor – Abfrageprotokolle enthalten häufig sensible Identifikatoren und Literalwerte. Sie möchten, dass Fehler in Spark und Trino bereits in der Staging-Umgebung zutage treten und nicht erst während der Umstellung auf die Produktionsumgebung, wo sie andernfalls meist auftreten.

Möglichkeiten nach dem Ende des Lebenszyklus von Apache Hive

Es gibt drei Wege, die fast jedes Team abdecken, und sie schließen sich nicht gegenseitig aus. Die meisten Organisationen gewinnen letztendlich Zeit auf einem dieser Wege, während sie einen anderen umsetzen.

Upgrade auf Hive 4.2.0 ohne Systemneustart

Wenn Ihre JVM- und Engine-Abhängigkeiten verschoben werden können und Sie über Staging-Kapazitäten verfügen, ist ein Upgrade auf 4.2.0 die saubere, langfristige Lösung. Sie wechseln zur aktuellen Release-Reihe, übernehmen Java 21 als minimal unterstützte Laufzeitumgebung und profitieren von den Neuerungen des 4.2.0-Metastores und von Apache Iceberg – erweiterte Katalogunterstützung einschließlich eines Iceberg-REST-Katalog-Clients, automatische Komprimierung, Löschvektoren und Spalten-Standardwerte. Berücksichtigen Sie dabei den Sprung in der Java-Version, die Schemamigration und die oben beschriebene Vorabprüfung der ACID-Komprimierung. Wenn Ihr Stack klein und in sich geschlossen ist, beginnen Sie hier. Wenn er gleichzeitig Spark, Trino und Impala versorgt, planen Sie deutlich mehr Zeit ein, als die Versionsnummern vermuten lassen.

Hive vollständig ersetzen

Einige Teams nutzen das EOL als Anlass, Hive aufzugeben, anstatt es zu aktualisieren. Moderne Lakehouse-Architekturen, die auf Apache Iceberg basieren und über Trino, Spark SQL oder eine verwaltete Plattform abgefragt werden, können die Abhängigkeit von der klassischen Hive-Ausführungsschicht verringern oder beseitigen, auch wenn viele während der Übergangsphase einen Hive-kompatiblen Katalog oder Metastore beibehalten. Dies ist der aufwendigste Weg und wird selten innerhalb des Zeitrahmens abgeschlossen, den ein akuter Sicherheitsbefund erfordert; daher läuft er in der Regel parallel zu einem erweiterten Support, der die nötige Atempause bietet. Wenn Sie ohnehin eine Umstellung auf eine neue Plattform vornehmen, vermeiden Sie so, Migrationsaufwand in eine Engine zu stecken, die Sie ohnehin auslaufen lassen wollten.

TuxCare's unendlicher Lebenszyklus-Support

Falls Sie die Migration nicht innerhalb des Zeitrahmens durchführen können, den Ihre Auditoren oder Ihr Risikoregister vorschreiben, bietet TuxCare „Endless Lifecycle Support“ (ELS) CVE-Patches für Apache Hive 2.3.9 auch nach Ablauf der Lebensdauer bereit, die über Ihren bestehenden Paketverwaltungs-Workflow bereitgestellt werden. Der Support ist versionsspezifisch. Überprüfen Sie daher vor Ihrer Planung anhand der Liste der unterstützten Versionen, um welche Version es sich bei Ihrer Installation genau handelt – sollten Sie 2.3.10, 3.1.3 oder eine andere Version verwenden, fragen Sie nach, da TuxCare auf Anfrage weitere Versionen hinzufügt. Sie bleiben bei der Hive-Version, auf die Ihre Data-Warehouse-Infrastruktur angewiesen ist, ohne eine Migration überstürzt vornehmen zu müssen.

Für ein Team, das gerade mitten in einer Neuprogrammierung der Plattform steckt, ist dies der Unterschied zwischen einem fehleranfälligen Upgrade unter Prüfungsdruck und einer geplanten Migration nach Ihrem eigenen Zeitplan. Es stellt eine gepflegte Quelle für Sicherheitskorrekturen wieder her – genau die Voraussetzung, die die PCI-DSS-Anforderung 12.3.4 erfüllt – und liefert Ihnen dokumentierte, vertretbare Nachweise für die Behebung von Mängeln, während Sie auf Hive 4.2.0 umsteigen, sobald die Arbeiten an Java und der Engine tatsächlich abgeschlossen sind. Es schließt einen Audit-Befund nicht von selbst – das kann kein Patching-Service, da dies von Ihrem Prüfungsumfang, Ihren Nachweisen und Ihrem Prüfer abhängt –, aber es verändert, was Sie nachweisen können.

Sichern Sie Apache Hive auch nach Ablauf der Supportfrist mit TuxCare

Die Uhr bei EOL Hive läuft weiter. Für jede neu bekannt gewordene CVE, die Ihre Version betrifft, wird es keinen Community-Fix für diese Produktlinie geben, und bei jedem Audit-Zyklus werden Sie gefragt, welche Maßnahmen Sie diesbezüglich ergriffen haben. Die praktische Vorgehensweise: Stellen Sie zunächst die Patch-Quelle wieder her und migrieren Sie dann auf Hive 4.2.0 oder verlassen Sie Hive ganz – und zwar nach einem Zeitplan, den Sie selbst bestimmen, anstatt sich von einem Vorfall dazu zwingen zu lassen.

Falls Sie eine Hive-Produktreihe nutzen, deren Lebenszyklus endet (EOL), und noch nicht bereit sind, in diesem Quartal zu migrieren, bietet TuxCare „Endless Lifecycle Support“ von TuxCare dafür sorgen, dass CVEs gepatcht werden, während Sie das Upgrade oder den Austausch vorbereiten. Der Service stellt CVE-Patches für Apache Hive 2.3.9 über Ihren bestehenden Paketverwaltungs-Workflow bereit, ohne dass ein Versionssprung erforderlich ist.

FAQs

Welche Apache-Hive-Versionen werden noch unterstützt?

Nur die 4.x-Reihe erhält Community-Releases, wobei 4.2.0 die aktuelle Version ist. Apache gibt Java 17 für 4.1.x und Java 21 für 4.2.x an. Beachten Sie, dass Fehlerbehebungen in der neuesten Minor-Version erscheinen und nicht zurückportiert werden – CVE-2025-62728 wurde in 4.2.0 behoben und nicht in 4.1.x –, sodass der Einsatz von 4.1.0 nicht mit dem Einsatz einer gepatchten Version gleichzusetzen ist. Die Versionsreihen 1.x, 2.x und 3.x sind alle nicht mehr unterstützt.

Wann wurde der Support für Apache Hive 3.x eingestellt?

Die Apache-Hive-Community hat am 8. Oktober 2024 das Ende des Lebenszyklus der 3.x-Reihe erklärt. Die letzte Version war 3.1.3, die am 8. April 2022 veröffentlicht wurde.

Kann ich Hive 2.3.x nach Ablauf der Supportfrist weiterhin in der Produktion einsetzen?

Technisch gesehen ja, aber Sie müssen das Risiko ohne Community-Korrekturen selbst bewältigen. Die letzte 2.x-Version war 2.3.10 vom 9. Mai 2024, und die Produktreihe wurde am 20. Mai 2024 als „End of Life“ deklariert. Die Apache-Hive-Community wird keine neue 2.3.x-Version für neu bekannt gewordene CVEs veröffentlichen, die Hive oder die darin enthaltenen Abhängigkeiten betreffen. Ihre Optionen sind die Pflege eigener Backports oder die Inanspruchnahme unabhängigen kommerziellen Supports wie beispielsweise TuxCare ELS.

Führt ein Upgrade auf Hive 4 zu Problemen bei den Spark- oder Trino-Integrationen?

Das ist möglich, abhängig von den genauen Versionen und der Konfiguration der jeweiligen Engine und des Metastore-Clients. Testen Sie jede Spark-, Trino-, Impala- und Iceberg-Integration vor der Umstellung auf die Produktionsumgebung in einer Staging-Umgebung mit Ihrer Zielversion von Hive.

Gibt es für den Hive Metastore (HMS) ein eigenes Ablaufdatum?

Nein. Die HMS-Versionen orientieren sich an den Apache Hive-Veröffentlichungen. Ab Hive 4.1.0 wird der Metastore auch als eigenständige Komponente im Binär- und Docker-Image-Format bereitgestellt, und ab Version 4.2.0 wurde der Metastore-Client-Code in ein eigenes Modul ausgelagert – Sicherheitskorrekturen der Community orientieren sich jedoch weiterhin an den unterstützten Hive-Versionen. Eine Hive-Version, deren Lebenszyklus beendet ist (EOL), bedeutet daher auch das Ende des Lebenszyklus für den Metastore.

Zusammenfassung

Artikel Name

Ende des Lebenszyklus von Apache Hive: Versionen, Termine und nächste Schritte

Beschreibung

Apache Hive 1.x, 2.x und 3.x haben das Ende ihrer Lebensdauer erreicht. Hier finden Sie die genauen EOL-Daten, Informationen zu den tatsächlichen CVE-Risiken und Compliance-Risiken sowie drei praktische Lösungsansätze für die Zukunft.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers