Fin de la vida útil de Apache Hive: versiones, fechas y próximos pasos

Principales conclusiones

• Las versiones 1.x, 2.x y 3.x de Apache Hive han llegado al final de su ciclo de vida. Las versiones de la comunidad ahora solo se publican en la línea 4.x, cuya versión actual es la 4.2.0.
• En una línea de Hive en fin de vida útil (EOL), las vulnerabilidades CVE recién reveladas en Hive y sus dependencias incluidas no reciben ninguna corrección por parte de la comunidad para esa línea. Esto incluye el Hive Metastore, que almacena los metadatos que localizan y controlan el acceso a tus tablas más sensibles.
• El software de almacén de datos no compatible supone un riesgo concreto en materia de auditoría. El requisito 12.3.4 de la norma PCI DSS lo convierte en una medida correctiva documentada y aprobada por la alta dirección, y las normas HIPAA, SOC 2 e ISO/IEC 27001 exigen un proceso de gestión de vulnerabilidades operativo que se pueda demostrar.
• Tres opciones viables para seguir adelante: actualizar directamente a Hive 4.2.0, migrar por completo fuera de Hive u obtener parches de CVE de terceros para disponer de un plazo de migración controlado.

Si estás utilizando Apache Hive 2.3 o 3.1 en entorno de producción, los parches de seguridad de la comunidad para tu versión dejaron de publicarse en 2024: el 20 de mayo para la línea 2.x y el 8 de octubre para la 3.x. La comunidad ha declarado oficialmente que las líneas 1.x, 2.x y 3.x al final de su ciclo de vida, por lo que las nuevas versiones y correcciones de la comunidad ahora solo proceden de la línea 4.x.

Esto es más importante para Hive que para la mayoría de las bibliotecas. Hive es la capa de SQL y metadatos que se superpone a los datos del almacén —información de carácter personal, registros financieros, datos sanitarios, todo ello— y el Hive Metastore contiene el mapa que indica dónde se encuentran esos datos y quién puede acceder a ellos. En este artículo se analizan las versiones que ya no cuentan con soporte, cuál es la situación real en materia de seguridad y cumplimiento normativo, y las tres vías de actuación que merece la pena considerar seriamente.

¿Ha llegado Apache Hive al final de su ciclo de vida? Versiones y fechas

Sí. La comunidad de Apache Hive votó a favor de declarar el fin de la vida útil de las versiones 1.x, 2.x y 3.x, lo que significa que no habrá más lanzamientos de la comunidad, correcciones de errores ni parches de seguridad para ninguna de ellas.

Una vez que una línea se declara EOL, se interrumpe ese flujo de lanzamientos. La ASF no ofrece ninguna ampliación de pago ni ningún periodo de mantenimiento dedicado exclusivamente a la seguridad.

También conviene señalar cómo se comporta la línea 4.x: las correcciones se incluyen en la versión menor más reciente, en lugar de retroportarse. La vulnerabilidad CVE-2025-62728 se corrigió en la versión 4.2.0 y nunca se retroportó a la 4.1.x, por lo que «en 4.x» y «corregido» no son lo mismo.

 Nota: Planifica la actualización a Hive 4.x como un proceso unidireccional. Apache incluye scripts de actualización de esquemas para MySQL, PostgreSQL, Oracle, SQL Server y Derby, pero no ofrece ninguna guía documentada para volver a una versión anterior; por lo tanto, tu plan de reversión consistirá en restaurar una copia de seguridad de la base de datos Metastore, en lugar de reinstalar los binarios anteriores. Prueba esa restauración antes de que la necesites.

Riesgos de seguridad derivados del uso de Apache Hive en fase de fin de vida útil en entornos de producción

Un CVE de Hive no es un CVE de biblioteca normal. Los brokers de Hive gestionan el acceso a datos de carácter personal, transacciones financieras y historiales médicos, y el Metastore contiene el mapa de acceso a todo ello.

Cuando una vulnerabilidad afecta a una línea de productos en fin de vida útil, no se va a lanzar ninguna nueva versión para esa línea; tus opciones se reducen a mitigarla, aplicar tú mismo la corrección a versiones anteriores o adquirir parches de terceros.

Por qué las vulnerabilidades de Metastore merecen una atención especial

Un atacante que consiga acceder al Metastore puede ejecutar código con los privilegios del servicio Metastore, que es el componente que gestiona el acceso a todo el almacén. HMS cuenta con un historial documentado de hallazgos relacionados tanto con la deserialización como con la inyección.

La vulnerabilidad de deserialización «partition-fetch» CVE-2022-41137 (HIVE-26539) permitía la deserialización de datos arbitrarios, lo que daba lugar a una ejecución remota de código (RCE). Apache la clasificó como de riesgo moderado y la limitó a la versión 4.0.0-alpha-1, anterior a la 4.0.0, por lo que nunca se incluyó en una versión de lanzamiento general (GA) y nunca afectó a las versiones 1.x, 2.x ni 3.x. Considérala como información sobre el componente, no sobre tu versión al final de su ciclo de vida (EOL).

Más recientemente, el CVE-2025-62728 reveló una inyección SQL en la API de HMS Thrift para eliminar estadísticas de columnas. Afectó a las versiones desde la 4.1.0 hasta la 4.2.0 y se corrigió en la 4.2.0; una vez más, no se trata de un fallo en una línea de fin de vida útil, sino de una demostración de que HMS sigue generando hallazgos graves y de que cada corrección llega en forma de nueva versión.

Apache también señala que la ruta vulnerable no es accesible cuando metastore.try.direct.sql está configurado en «false», lo cual es el tipo de medida de mitigación que una línea EOL aún permite aplicar. Vale la pena leer con atención las etiquetas de gravedad en lugar de limitarse a hojearlas, ya que una calificación de la ASF de «moderada» y una puntuación base CVSS pueden apuntar en direcciones diferentes para un mismo hallazgo; a continuación se explica cómo funcionan las puntuaciones CVE y CVSS funcionan, por si no te resulta familiar esa distinción.

Atención: Varias vulnerabilidades CVE de HMS están documentadas como explotables únicamente por usuarios autorizados, y la propia evaluación de Apache es que la mayoría de las implementaciones exponen HMS a solo un puñado de aplicaciones, como HiveServer2. No interpretes esto como que sea automáticamente seguro, ni tampoco como que sea automáticamente alarmante. Averigua qué usuarios y aplicaciones están realmente autorizados a invocar los métodos Thrift afectados, si un HiveServer2 comprometido podría acceder a ellos y si metastore.try.direct.sql está habilitado. Esa respuesta, y no el texto del aviso, es tu nivel de exposición.

Un árbol de dependencias fijo detrás de cada componente

Hive no es un único archivo JAR. Se basa en un amplio árbol de componentes y dependencias: Apache Hadoop, Calcite, Tez, Thrift, DataNucleus, ORC, Parquet, Avro, Kryo, Jackson, Guava y una pila de registro basada en Log4j, entre otros. Cualquiera de ellos puede dar lugar a una vulnerabilidad CVE crítica.

Log4Shell (CVE-2021-44228) es el ejemplo más claro. No se trataba de un fallo de Hive, pero todas las distribuciones de Hive 2.x y 3.x compiladas antes de diciembre de 2021 incluían una versión de Log4j 2 dentro del rango afectado, y la solución consistía en sustituir esa biblioteca integrada.

El hecho de que una implementación concreta fuera realmente vulnerable dependía de la configuración —en concreto, de si los datos controlados por el atacante llegaban a una entrada del registro—, pero, en cualquier caso, la tarea de corrección recaía en los operadores de Hive.

En una línea con soporte técnico, se obtiene una versión que corrige la biblioteca vulnerable. En una línea en fin de vida útil (EOL), esa versión nunca llega, y hay que aplicar parches manualmente a los archivos JAR dentro de una distribución que ya nadie mantiene. Los equipos que han vivido los ciclos de parches de Apache Struts conocen bien este problema: la corrección siempre llega en forma de una nueva versión, y una línea que ya no lanza versiones no tiene forma de acceder a ella.

La exposición de credenciales y las brechas de privilegios que nunca se solucionan

Aquí es donde EOL Hive deja de ser algo teórico. CVE-2024-29869 —calificada como «importante» por Apache y que afecta a las versiones desde la 1.1.0 hasta la 4.0.1— provocaba que Hive escribiera un archivo de credenciales en un directorio temporal con permisos 644 por defecto, legible para cualquier usuario local con acceso a dicho directorio. Se corrigió en la versión 4.0.1. Todas las líneas EOL se ven afectadas y ninguna de ellas puede acceder a la corrección.

CVE-2024-23953, también clasificada como «importante», presenta el mismo problema: una comparación de firmas con tiempo no constante en el firmador LLAP permitía a un usuario autorizado falsificar una firma válida byte a byte. Afectaba a las versiones desde la 2.2.0 hasta la 4.0.0, por lo que tanto la 2.3.x como la 3.1.x se encuentran dentro de ese rango.

Además, existe una vulnerabilidad de autorización anterior a la versión 3.1.3, en la que las operaciones CREATE y DROP de funciones omitían los controles de autorización y un usuario sin los privilegios suficientes podía manipular una función definida por el usuario (UDF) para hacer referencia a un archivo JAR malicioso (CVE-2021-34538). Cabe señalar que los usuarios de la versión 3.1.3 sí recibieron esa corrección concreta, por lo que esta vulnerabilidad afecta con mayor gravedad a las versiones 2.x y anteriores.

En conjunto, estos factores describen dos riesgos permanentes distintos en versiones antiguas —la manipulación no autorizada de UDF y las credenciales legibles— en lugar de una cadena de explotación garantizada. En una línea de productos al final de su ciclo de vida (EOL), ambos son permanentes. Clasificarlos sin una referencia actualizada también consume tiempo real de ingeniería a la hora de distinguir la exposición real del ruido del escáner.

Marcos de cumplimiento afectados por el uso de Apache Hive al final de su ciclo de vida (EOL)

El uso de Hive en fase de fin de vida útil convierte un problema técnico de seguridad en una cuestión de gobernanza y auditoría, ya que muchos almacenes de datos procesan información sujeta a requisitos de seguridad normativos, contractuales o de los clientes.

Los auditores evalúan si las vulnerabilidades identificadas se están corrigiendo o mitigando mediante controles documentados y eficaces; y un componente sin respaldo dificulta la demostración de ello. A modo de referencia, el Informe de IBM sobre el coste de las filtraciones de datos de 2025 sitúa el coste medio global de una filtración en 4,44 millones de dólares, siendo el sector sanitario el más afectado, con 7,42 millones; cabe señalar que la cifra global descendió aproximadamente un 9 % respecto al año anterior, por lo que conviene citarla como contexto y no como una amenaza creciente.

PCI DSS

Si los datos de los titulares de tarjetas se almacenan o se procesan a través de su entorno Hive, es probable que los sistemas Hive y Metastore correspondientes estén sujetos a ámbito de aplicación de la norma PCI DSS . En este caso, se aplican dos requisitos. 

El requisito 6.3.3 exige que los parches críticos y de alta gravedad se apliquen en el plazo de un mes desde su publicación, lo cual resulta difícil de demostrar cuando no existe ningún parche. El requisito 12.3.4, plenamente evaluable a partir del 31 de marzo de 2025, exige que se revise el hardware y el software al menos cada 12 meses, se confirme que cada tecnología sigue recibiendo puntualmente las correcciones de seguridad del proveedor, se documenten los anuncios de fin de vida útil y se disponga de un plan de corrección aprobado por la alta dirección.

EOL Hive no da por fallida automáticamente una evaluación, pero sí se convierte en una deficiencia documentada que la dirección ha aprobado y que un QSA supervisará en los servidores Metastore y HiveServer2. Los controles compensatorios pueden ser viables, pero deben abordar el riesgo específico y, por lo general, se consideran temporales mientras se lleva a cabo una migración activa.

HIPAA

El análisis de datos sanitarios en Hive implica la presencia de ePHI dentro del ámbito de aplicación de la Norma de Seguridad de la HIPAA, que exige un análisis de riesgos y medidas de protección razonables y adecuadas, más que una versión concreta del producto. El software que no pueda recibir actualizaciones de seguridad debe figurar en su análisis de riesgos por su nombre, junto con las medidas de mitigación documentadas y un calendario de migración adjunto. La norma no prohíbe de forma tajante el software al final de su ciclo de vida (EOL), pero un componente que procese ePHI y que no esté documentado, no cuente con medidas de mitigación ni pueda recibir parches supone un punto débil, tanto en la evaluación como posteriormente, si se convierte en la causa principal de una violación de la seguridad.

SOC 2 e ISO/IEC 27001

Para los proveedores de SaaS y de soluciones empresariales, estos son los informes que solicitan los clientes. Ambos esperan un proceso de gestión de vulnerabilidades que funcione: SOC 2, a través de los Criterios de Servicios de Confianza sobre detección y corrección de vulnerabilidades, e ISO/IEC 27001:2022, a través del control 8.8 del Anexo A, «Gestión de vulnerabilidades técnicas». Un almacén de datos sin soporte técnico debilita ese control cuando no existe una fuente fiable de correcciones de seguridad, ni medidas de mitigación documentadas, ni un plan de migración con plazos definidos que lo respalde.

Análisis de la realidad: El hecho de que sea «de uso exclusivamente interno» no excluye automáticamente a Hive del ámbito de la auditoría. Si el sistema almacena, procesa o proporciona acceso a datos regulados, evalúalo según el marco normativo aplicable y los límites documentados de tu sistema. La ubicación en la red puede afectar al ámbito de aplicación y a los controles compensatorios, pero no resuelve la cuestión.

Retos de migración para Apache Hive al final de su ciclo de vida

A la mayoría de los equipos ya se les ha dicho: «Simplemente actualizaos a Hive 4». Ese consejo subestima el trabajo que supone en gran medida. El salto de una versión 2.x o 3.x a la 4.x no es un simple cambio de versión, sino un cambio coordinado que afecta a la JVM, al Metastore y a los motores y aplicaciones posteriores que dependen de Hive.

El cambio de versión de Java

Los entornos heredados de Hive 2 y 3 suelen ejecutarse en Java 8. La tabla de requisitos de Apache indica Java 17 para Hive 4.1.x y Java 21 para 4.2.x, mientras que la última versión que aparece como compatible con Java 8 es la 4.0.1, lo que convierte a la 4.0.1 en un auténtico paso intermedio si tu JVM aún no puede actualizarse, aunque ya no reciba correcciones.

Pasarse directamente a la versión 4.2.0 obliga a actualizar la JVM en todos los nodos de Hadoop, el código de las UDF y cualquier servicio posterior que utilice el mismo entorno de ejecución. El bytecode de Java 8 suele funcionar bien en los JDK más recientes, por lo que el verdadero trabajo consiste en las pruebas de compatibilidad: las UDF y las bibliotecas de apoyo dejan de funcionar cuando dependen de módulos eliminados, de API internas del JDK, del acceso reflexivo o de bibliotecas que nunca fueron compatibles con las versiones 17 o 21. Cualquiera que haya pasado por el fin de vida útil (EOL) de Java 8 o el fin de vida útil de Java 11 sabe que la transición de la JVM suele ser la parte más larga de la migración. Haz primero un inventario de todas las UDF y de todos los servicios que dependen de la JVM; a continuación, planifica la actualización de Java por separado de la actualización de Hive.

Esquema de Metastore y migración de tablas ACID

Hive 4 modifica el esquema de Metastore, por lo que debes ejecutar los scripts de actualización en el orden indicado con una base de datos de soporte compatible. Si tu HMS se ejecuta en una base de datos fuera de ciclo de vida (EOL), te encontrarás con el mismo problema al que se enfrentan los equipos que utilizan PostgreSQL 13, que llegó al final de su vida útil el 13 de noviembre de 2025—, estarás acumulando dos migraciones a la vez.

Las tablas ACID suponen un obstáculo importante, y este requisito es específico de cada versión. Las notas de la versión 3.0.0 de Apache Hive indican que cualquier partición de una tabla ACID en la que se haya ejecutado una instrucción UPDATE, DELETE o MERGE desde su última compactación mayor debe someterse a una compactación mayor antes de la actualización; que no se podrán ejecutar más instrucciones UPDATE, DELETE o MERGE una vez que comience dicha compactación; y que el incumplimiento de esta norma puede provocar la corrupción de los datos. Las tablas que solo contienen resultados de INSERT no se ven afectadas. Un salto de la versión 2.x a la 4.x traspasa ese límite, por lo que debes confirmar cuáles de tus tablas transaccionales son anteriores a Hive 3, en lugar de dar por sentado que la regla es universal. Realiza primero una instantánea de la base de datos Metastore, ejecuta la compactación como paso previo y ensaya la actualización del esquema en un clon antes de intervenir en el entorno de producción. Comprueba la versión actual del esquema, realiza una simulación de la actualización y, a continuación, aplícala:

schematool -dbType postgres -info

schematool -dbType postgres -upgradeSchema -dryRun

schematool -dbType postgres -upgradeSchema

Sustituye «dbType» por el tuyo propio; los datos de conexión proceden de tu configuración de Hive. Si el metastore no tiene ninguna versión de esquema registrada, especifica la fuente de forma explícita con la opción «-upgradeSchemaFrom».

Fallos en el motor y en la integración

Hive 4 establece Tez como motor de ejecución predeterminado, y el motor MapReduce ha quedado obsoleto desde la versión Hive 2, con una advertencia en la documentación de que podría eliminarse sin previo aviso. Cualquier carga de trabajo que siga vinculada a mr —o al motor de ejecución Spark— debe validarse antes de planificar la migración.

La mayor sorpresa se produce en las fases posteriores. La compatibilidad varía en función de las versiones y configuraciones específicas de Spark, Trino, Impala, Iceberg y sus clientes de Metastore, por lo que debes considerar que cada integración no está verificada hasta que la hayas probado, en lugar de dar por sentado que la matriz de versiones es válida. Cuando Spark, Trino e Impala comparten un único Metastore, la actualización se propaga a todos ellos simultáneamente. Identifica todos los consumidores de Metastore antes de programar nada y incluye una prueba de compatibilidad para cada motor en el manual de actualización.

Consejo profesional: Configura un entorno paralelo de Hive 4.2.0 apuntando a un Metastore clonado y ejecuta en él una muestra representativa de consultas de producción. Limpia primero la muestra: los registros de consultas suelen contener identificadores confidenciales y valores literales. Es mejor que los fallos de Spark y Trino salgan a la luz en el entorno de prueba, y no durante la transición a producción, que es donde suelen aparecer.

Opciones tras el fin de la vida útil de Apache Hive

Hay tres vías que abarcan prácticamente todos los equipos, y no son mutuamente excluyentes. La mayoría de las organizaciones acaban ganando tiempo en una de ellas mientras llevan a cabo otra.

Actualización in situ a Hive 4.2.0

Si puedes actualizar las dependencias de tu JVM y del motor y dispones de capacidad de entorno de prueba, la actualización a la versión 4.2.0 es la solución más adecuada a largo plazo. Te pasarás a la línea de versiones actual, adoptarás Java 21 como entorno de ejecución mínimo compatible y te beneficiarás de las mejoras del Metastore 4.2.0 y de Apache Iceberg: compatibilidad ampliada con catálogos, incluido un cliente REST de Iceberg Catalog, compactación automática, vectores de eliminación y valores predeterminados de columnas. Ten en cuenta el salto de versión de Java, la migración del esquema y la comprobación previa de la compactación ACID descrita anteriormente. Si tu pila es pequeña y autónoma, empieza por aquí. Si alimenta a Spark, Trino e Impala a la vez, calcula un tiempo considerablemente mayor del que sugieren los números de versión.

Sustituir Hive por completo

Algunos equipos utilizan el fin de vida útil (EOL) como motivo para abandonar Hive en lugar de actualizarlo. Las arquitecturas modernas de «lakehouse», basadas en Apache Iceberg y consultadas a través de Trino, Spark SQL o una plataforma gestionada, pueden reducir o eliminar la dependencia de la capa de ejecución clásica de Hive, aunque muchos mantienen un catálogo o Metastore compatible con Hive durante la transición. Esta es la opción que requiere mayor esfuerzo y rara vez se completa en el plazo que exige un hallazgo de seguridad en producción, por lo que suele llevarse a cabo en paralelo con el soporte ampliado, que proporciona el margen de tiempo necesario. Si, de todos modos, vas a cambiar de plataforma, esto evita invertir esfuerzos de migración en un motor que tenías previsto retirar.

Asistencia durante todo el ciclo de vida de TuxCare

Si no puedes realizar la migración en el plazo que exigen tus auditores o tu registro de riesgos, el servicio de soporte de ciclo de vida ilimitado (ELS) de TuxCare proporciona parches CVE para Apache Hive 2.3.9 más allá de su fin de vida útil, que se distribuyen a través de su flujo de trabajo de gestión de paquetes existente. La cobertura es específica para cada versión, por lo que debe confirmar su versión exacta en la lista de versiones compatibles antes de planificar nada: si utiliza la 2.3.10, la 3.1.3 u otra línea, consulte con nosotros, ya que TuxCare añade versiones bajo petición. Podrá seguir utilizando la versión de Hive de la que depende su infraestructura de almacén de datos sin tener que apresurar una migración.

Para un equipo que se encuentra en pleno proceso de reescritura de la plataforma, esto supone la diferencia entre una actualización propensa a fallos bajo la presión de una auditoría y una migración planificada según tu calendario. Restablece una fuente actualizada de correcciones de seguridad, que es precisamente la condición que activa el requisito 12.3.4 de la norma PCI DSS, y te proporciona pruebas documentadas y defendibles de las medidas correctivas mientras realizas la transición a Hive 4.2.0, una vez que el trabajo relacionado con Java y el motor esté realmente listo. Por sí solo, no resuelve un hallazgo de auditoría —ningún servicio de aplicación de parches puede hacerlo, ya que eso depende de su alcance, de las pruebas y del auditor—, pero sí cambia lo que puede demostrar.

Protege Apache Hive más allá de su fin de vida útil con TuxCare

El reloj de EOL Hive no se pone a cero. Cualquier CVE recién publicada que afecte a tu versión no recibirá ninguna corrección de la comunidad para esa línea, y en cada ciclo de auditoría se te preguntará qué medidas has tomado al respecto. El procedimiento práctico es el siguiente: primero, restaura una fuente de parches; después, migra a Hive 4.2.0 o abandona Hive por completo siguiendo un calendario que tú mismo controles, en lugar de uno que te imponga un incidente.

Si utilizas una versión de Hive en fase de fin de vida útil (EOL) y aún no estás preparado para migrar este trimestre, el servicio de soporte de ciclo de vida ilimitado de TuxCare puede mantener actualizadas las vulnerabilidades CVE mientras preparas la actualización o la sustitución. Proporciona parches para las vulnerabilidades CVE de Apache Hive 2.3.9 a través de tu flujo de trabajo de gestión de paquetes actual, sin necesidad de un salto de versión obligatorio.

Preguntas frecuentes

¿Qué versiones de Apache Hive siguen siendo compatibles?

Solo la línea 4.x recibe versiones de la comunidad, y la 4.2.0 es la actual. Apache indica Java 17 para la 4.1.x y Java 21 para la 4.2.x. Ten en cuenta que las correcciones se incorporan a la versión menor más reciente en lugar de retroportarse —el CVE-2025-62728 se corrigió en la 4.2.0 y no en la 4.1.x—, por lo que ejecutar la 4.1.0 no es lo mismo que ejecutar una versión parcheada. Las líneas 1.x, 2.x y 3.x han llegado al final de su ciclo de vida.

¿Cuándo dejó de estar disponible Apache Hive 3.x?

La comunidad de Apache Hive declaró el fin de la vida útil de la línea 3.x el 8 de octubre de 2024. La última versión fue la 3.1.3, publicada el 8 de abril de 2022.

¿Puedo seguir utilizando Hive 2.3.x en entorno de producción una vez finalizado su ciclo de vida (EOL)?

Técnicamente sí, pero tendrás que gestionar el riesgo sin contar con las correcciones de la comunidad. La última versión de la serie 2.x fue la 2.3.10, lanzada el 9 de mayo de 2024, y la línea de productos se declaró al final de su ciclo de vida el 20 de mayo de 2024. La comunidad de Apache Hive no publicará ninguna nueva versión 2.3.x para ninguna vulnerabilidad CVE recientemente revelada que afecte a Hive o a sus dependencias integradas. Tus opciones son mantener tus propias adaptaciones a versiones anteriores u obtener soporte comercial independiente, como el de TuxCare ELS.

¿La actualización a Hive 4 afecta a las integraciones con Spark o Trino?

Sí, dependiendo de las versiones exactas y la configuración de cada motor y cliente de Metastore. Prueba todas las integraciones de Spark, Trino, Impala e Iceberg con la versión de Hive de destino en el entorno de prueba antes de realizar cualquier cambio a producción.

¿Tiene el Hive Metastore (HMS) una fecha de fin de vida útil propia?

No. Las versiones de HMS siguen las versiones de Apache Hive. A partir de Hive 4.1.0, el Metastore también se distribuye como un componente independiente en formatos binario e imagen de Docker, y en la versión 4.2.0 se separó el código del cliente del Metastore en su propio módulo; sin embargo, las correcciones de seguridad de la comunidad siguen correspondiendo a las versiones de Hive compatibles. Por lo tanto, una versión de Hive al final de su ciclo de vida (EOL) implica que el Metastore también llega al final de su ciclo de vida.

Resumen

Nombre del artículo

Fin de la vida útil de Apache Hive: versiones, fechas y próximos pasos

Descripción

Apache Hive 1.x, 2.x y 3.x han llegado al final de su ciclo de vida. Consulta las fechas exactas de fin de vida útil, los riesgos reales relacionados con los CVE y el cumplimiento normativo, así como tres vías prácticas para seguir adelante.

Autor

Rohan Timalsina

Nombre del editor

TuxCare

Logotipo de la editorial