Fim do ciclo de vida do Apache Hive: versões, datas e próximos passos

Principais conclusões

• O Apache Hive 1.x, 2.x e 3.x chegaram ao fim do ciclo de vida. As versões da comunidade agora são lançadas apenas na linha 4.x, sendo que a 4.2.0 é a versão atual.
• Em uma linha do Hive em fim de vida útil (EOL), as vulnerabilidades CVE recém-divulgadas no Hive e em suas dependências integradas não recebem correções da comunidade para essa linha. Isso inclui o Hive Metastore, que armazena os metadados responsáveis por localizar e controlar o acesso às suas tabelas mais confidenciais.
• O uso de software de data warehouse não compatível gera riscos concretos de auditoria. O requisito 12.3.4 do PCI DSS transforma isso em um item de correção documentado e aprovado pela alta administração, e as normas HIPAA, SOC 2 e ISO/IEC 27001 exigem um processo de gerenciamento de vulnerabilidades em funcionamento que possa ser comprovado.
• Três caminhos realistas a seguir: atualizar diretamente para o Hive 4.2.0, migrar completamente do Hive ou obter patches de CVE de terceiros para ganhar um prazo controlado para a migração.

Se você estiver executando o Apache Hive 2.3 ou 3.1 em produção, os patches de segurança da comunidade para essas versões foram interrompidos em 2024 — em 20 de maio para a linha 2.x e em 8 de outubro para a 3.x. A comunidade declarou formalmente que as linhas 1.x, 2.x e 3.x como tendo chegado ao fim de vida; portanto, novos lançamentos e correções da comunidade agora vêm apenas da linha 4.x.

Isso é mais importante para o Hive do que para a maioria das bibliotecas. O Hive é a camada de SQL e metadados sobre os dados do data warehouse — informações de identificação pessoal (PII), registros financeiros, dados de saúde, tudo isso — e o Hive Metastore contém o mapa que indica onde esses dados estão armazenados e quem pode acessá-los. Este artigo aborda quais versões não têm suporte, como se apresenta a exposição real em termos de segurança e conformidade e os três caminhos a seguir que merecem ser considerados com seriedade.

O Apache Hive chegou ao fim de sua vida útil? Versões e datas

Sim. A comunidade do Apache Hive votou para declarar o fim do ciclo de vida das versões 1.x, 2.x e 3.x, o que significa que não haverá mais lançamentos da comunidade, correções de bugs ou patches de segurança para nenhuma delas.

Assim que uma linha é declarada como EOL, o fluxo de lançamentos é interrompido. Não há extensão paga por parte da ASF nem janela de manutenção dedicada exclusivamente à segurança.

Também vale a pena observar como a linha 4.x se comporta: as correções são incluídas na versão secundária mais recente, em vez de serem portadas para versões anteriores. A vulnerabilidade CVE-2025-62728 foi corrigida na versão 4.2.0 e nunca foi portada para a linha 4.1.x; portanto, “na linha 4.x” e “corrigido” não são a mesma coisa.

 Observação: Planeje a atualização para o Hive 4.x como uma mudança apenas para a frente. O Apache fornece scripts de atualização de esquema para MySQL, PostgreSQL, Oracle, SQL Server e Derby, mas não há um caminho documentado para o downgrade; portanto, seu plano de reversão consiste em restaurar um backup do banco de dados do Metastore, em vez de reinstalar os binários anteriores. Teste essa restauração antes que seja necessário utilizá-la.

Riscos de segurança decorrentes da execução do Apache Hive em fim de vida útil (EOL) em ambiente de produção

Um CVE do Hive não é um CVE comum de biblioteca. Os brokers do Hive controlam o acesso a informações de identificação pessoal (PII), transações financeiras e registros de saúde, e o Metastore contém o mapa de acesso a tudo isso.

Quando uma vulnerabilidade afeta uma linha de produtos em fim de vida (EOL), não haverá mais nenhuma nova versão para essa linha — suas opções se limitam a mitigá-la, fazer você mesmo o backport da correção ou adquirir patches de terceiros.

Por que as vulnerabilidades do Metastore merecem atenção especial

Um invasor que consiga acessar o Metastore pode executar código com os privilégios do serviço Metastore, que é o componente responsável por mediar o acesso a todo o data warehouse. O HMS possui um histórico documentado de descobertas relacionadas tanto à deserialização quanto à injeção de código.

A falha de deserialização “partition-fetch”, CVE-2022-41137 (HIVE-26539), permitia a deserialização de dados arbitrários, levando à execução remota de código (RCE). O Apache classificou-a como moderada e limitou seu escopo à versão 4.0.0-alpha-1, anterior à 4.0.0; portanto, ela nunca foi incluída em uma versão GA e nunca afetou as versões 1.x, 2.x ou 3.x. Considere isso como uma informação sobre o componente, e não sobre sua versão em fim de vida (EOL).

Mais recentemente, a vulnerabilidade CVE-2025-62728 revelou uma injeção de SQL na API HMS Thrift para a exclusão de estatísticas de colunas. A vulnerabilidade afetou as versões 4.1.0 até 4.2.0 e foi corrigida na versão 4.2.0 — mais uma vez, não se trata de uma falha na linha de fim de vida (EOL), mas uma demonstração de que o HMS continua gerando descobertas graves e de que cada correção chega como uma nova versão.

O Apache também observa que o caminho vulnerável fica inacessível quando metastore.try.direct.sql está definido como false, o que é o tipo de medida de mitigação que uma linha EOL ainda permite aplicar. Vale a pena ler atentamente as classificações de gravidade, em vez de apenas dar uma olhada rápida, pois uma classificação “moderada” da ASF e uma pontuação base do CVSS podem indicar orientações diferentes para a mesma descoberta; veja como a pontuação do CVE e do CVSS funcionam, caso essa distinção não seja familiar.

Atenção: Várias vulnerabilidades (CVEs) do HMS estão documentadas como exploráveis apenas por usuários autorizados, e a própria avaliação do Apache é de que a maioria das implantações expõe o HMS a apenas algumas aplicações, como o HiveServer2. Não interprete isso como automaticamente seguro, nem como automaticamente alarmante. Verifique quais usuários e aplicativos estão realmente autorizados a chamar os métodos Thrift afetados, se um HiveServer2 comprometido poderia acessá-los e se o metastore.try.direct.sql está habilitado. Essa resposta, e não o texto do comunicado, é o que indica o seu nível de exposição.

Uma árvore de dependências fixa por trás de cada componente

O Hive não é um único arquivo JAR. Ele depende de uma ampla árvore de componentes e dependências: Apache Hadoop, Calcite, Tez, Thrift, DataNucleus, ORC, Parquet, Avro, Kryo, Jackson, Guava e uma pilha de registro baseada em Log4j, entre outros. Qualquer um deles pode gerar uma vulnerabilidade CVE crítica.

O Log4Shell (CVE-2021-44228) é o exemplo mais claro. Não se tratava de um bug do Hive, mas todas as distribuições do Hive 2.x e 3.x compiladas antes de dezembro de 2021 incluíam uma versão do Log4j 2 dentro do intervalo afetado, e a correção exigia a substituição dessa biblioteca integrada.

O fato de uma determinada implantação ser realmente vulnerável dependia da configuração — especificamente, se os dados controlados pelo invasor chegavam a uma entrada de log —, mas, de qualquer forma, o trabalho de correção recaía sobre os operadores do Hive.

Em uma linha com suporte, você recebe uma versão que corrige a biblioteca vulnerável. Em uma linha em fim de vida (EOL), essa versão nunca chega, e você acaba aplicando patches manualmente em JARs dentro de uma distribuição que ninguém mantém. As equipes que passaram pelos ciclos de patch do Apache Struts conhecem bem esse problema: a correção sempre chega na forma de uma nova versão, e uma linha que não lança mais versões não tem como acessá-la.

Exposição de credenciais e falhas de privilégios que nunca são corrigidas

É aqui que o EOL Hive deixa de ser apenas teoria. CVE-2024-29869 – classificada como importante pela Apache e afetando as versões 1.1.0 até 4.0.1 – fazia com que o Hive gravasse um arquivo de credenciais em um diretório temporário com permissões 644 por padrão, legível por qualquer usuário local com acesso a esse diretório. A falha foi corrigida na versão 4.0.1. Todas as instâncias EOL são afetadas e nenhuma delas pode receber a correção.

A vulnerabilidade CVE-2024-23953, também classificada como “importante”, segue o mesmo padrão: uma comparação de assinatura com tempo não constante no signatário LLAP permitiu que um usuário autorizado falsificasse uma assinatura válida, byte por byte. Ela afetou as versões 2.2.0 até 4.0.0; portanto, tanto a 2.3.x quanto a 3.1.x estão dentro desse intervalo.

Além disso, há a falha de autorização anterior à versão 3.1.3, na qual as operações CREATE e DROP de funções ignoravam as verificações de autorização, e um usuário sem privilégios suficientes poderia manipular uma função definida pelo usuário (UDF) para fazer referência a um arquivo JAR malicioso (CVE-2021-34538). Observe que os usuários da versão 3.1.3 receberam essa correção específica; portanto, essa vulnerabilidade afeta mais fortemente as versões 2.x e anteriores.

Em conjunto, esses fatores descrevem dois riscos permanentes distintos em versões mais antigas — manipulação não autorizada de UDFs e credenciais legíveis —, em vez de uma cadeia de exploração garantida. Em uma linha de produtos com fim de vida útil (EOL), ambos são permanentes. Avaliá-los sem uma linha de base atualizada também consome tempo real de engenharia, necessário para separar a exposição genuína do ruído do scanner.

Estruturas de conformidade afetadas pela execução do Apache Hive em fim de vida útil (EOL)

A execução do Hive em fim de vida útil (EOL) transforma uma questão técnica de segurança em uma preocupação de governança e auditoria, pois muitos data warehouses processam informações regidas por requisitos regulatórios, contratuais ou de segurança do cliente.

Os auditores avaliam se as vulnerabilidades identificadas estão sendo corrigidas ou mitigadas por meio de controles documentados e eficazes — e um componente sem suporte torna mais difícil comprovar isso. Para se ter uma ideia da magnitude, o Relatório da IBM sobre o Custo de uma Violação de Dados de 2025 estimou o custo médio global de uma violação em US$ 4,44 milhões, sendo o setor de saúde o mais alto, com US$ 7,42 milhões; observe que o valor global caiu cerca de 9% em relação ao ano anterior, portanto, cite-o como contexto, e não como uma ameaça crescente.

PCI DSS

Se os dados dos titulares de cartões forem armazenados ou processados no seu ambiente Hive, é provável que os sistemas Hive e Metastore relevantes estejam sujeitos à escopo do PCI DSS . Dois requisitos se aplicam a esse caso. 

O requisito 6.3.3 exige que patches críticos e de alta gravidade sejam aplicados no prazo de um mês após o lançamento, o que é difícil de comprovar quando não há nenhum patch disponível. O requisito 12.3.4, totalmente avaliável a partir de 31 de março de 2025, exige que você revise o hardware e o software pelo menos a cada 12 meses, confirme se cada tecnologia ainda recebe correções de segurança imediatas do fornecedor, documente quaisquer anúncios de fim de vida útil e mantenha um plano de correção aprovado pela alta administração.

O EOL Hive não reprova automaticamente uma avaliação, mas a falha passa a ser registrada como uma lacuna documentada, aprovada pela liderança, e um QSA fará o acompanhamento nos hosts do Metastore e do HiveServer2. Controles compensatórios podem ser viáveis, mas devem abordar o risco específico e são geralmente tratados como temporários enquanto uma migração ativa está em andamento.

HIPAA

A análise de dados da área da saúde no Hive envolve ePHI dentro do escopo da Regra de Segurança da HIPAA, que exige análise de risco e medidas de proteção razoáveis e adequadas, em vez de qualquer versão específica de produto. Softwares que não possam receber atualizações de segurança devem constar em sua análise de risco por nome, com medidas de mitigação documentadas e um cronograma de migração anexado. A regra não proíbe totalmente o uso de softwares em fim de vida (EOL), mas um componente que processe ePHI sem documentação, sem medidas de mitigação e sem possibilidade de correção representa um ponto fraco — tanto na avaliação quanto posteriormente, caso se torne a causa principal de uma violação.

SOC 2 e ISO/IEC 27001

Para fornecedores de SaaS e de soluções empresariais, esses são os relatórios solicitados pelos clientes. Ambos esperam um processo de gerenciamento de vulnerabilidades em funcionamento – a norma SOC 2, por meio dos Critérios de Serviços de Confiança relativos à detecção e correção de vulnerabilidades, e a norma ISO/IEC 27001:2022, por meio do controle 8.8 do Anexo A, “Gerenciamento de vulnerabilidades técnicas”. Um data warehouse sem suporte enfraquece esse controle quando não há uma fonte confiável de correções de segurança, nenhuma mitigação documentada e nenhum plano de migração com prazos definidos por trás dele.

Análise da realidade: A afirmação “É de uso exclusivamente interno” não exclui automaticamente o Hive do escopo da auditoria. Se o sistema armazena, processa ou fornece acesso a dados regulamentados, avalie-o de acordo com a estrutura aplicável e os limites documentados do seu sistema. A localização na rede pode afetar o escopo e os controles compensatórios; isso não resolve a questão.

Desafios de migração para o Apache Hive em fim de vida útil

A maioria das equipes já recebeu a orientação de que “basta atualizar para o Hive 4”. Esse conselho subestima o trabalho envolvido em grande medida. A transição da linha 2.x ou 3.x para a 4.x não é apenas um aumento de versão — trata-se de uma mudança coordenada que abrange a JVM, o Metastore e os mecanismos e aplicativos a jusante que dependem do Hive.

A mudança de versão do Java

Os ambientes legados do Hive 2 e 3 geralmente são executados no Java 8. A tabela de requisitos do Apache indica o Java 17 para o Hive 4.1.x e o Java 21 para o 4.2.x, enquanto a versão 4.0.1 é a última listada como Java 8 — o que torna a versão 4.0.1 um verdadeiro passo intermediário caso sua JVM ainda não possa ser atualizada, embora ela já não receba mais correções.

A atualização direta para a versão 4.2.0 obriga uma mudança da JVM em todos os seus nós do Hadoop, no seu código de UDF e em qualquer serviço a jusante que utilize o mesmo ambiente de execução. O bytecode do Java 8 geralmente funciona bem em JDKs mais recentes; portanto, o verdadeiro trabalho está nos testes de compatibilidade: as UDFs e as bibliotecas de suporte deixam de funcionar quando dependem de módulos removidos, APIs internas do JDK, acesso reflexivo ou bibliotecas que nunca ofereceram suporte às versões 17 ou 21. Qualquer pessoa que já tenha passado por pelo fim da vida útil (EOL) do Java 8 ou pelo fim da vida útil (EOL) do Java 11 sabe que a transição da JVM geralmente se torna a parte mais demorada da migração. Faça primeiro um inventário de todas as UDFs e serviços dependentes da JVM e, em seguida, planeje a atualização do Java separadamente da atualização do Hive.

Esquema do Metastore e migração de tabelas ACID

O Hive 4 altera o esquema do Metastore; portanto, é necessário executar os scripts de atualização na ordem correta em um banco de dados de suporte compatível. Se o seu HMS estiver rodando em um banco de dados em fim de vida (EOL) — o mesmo problema enfrentado pelas equipes no PostgreSQL 13, que atingiu o fim da vida útil em 13 de novembro de 2025 –, você estará realizando duas migrações ao mesmo tempo.

As tabelas ACID representam um ponto crítico, e essa exigência é específica da versão. As notas de lançamento do Hive 3.0.0 da Apache afirmam que qualquer partição de tabela ACID na qual tenha sido executada uma instrução UPDATE, DELETE ou MERGE desde sua última compactação principal deve passar por uma compactação principal antes da atualização; que nenhuma outra instrução UPDATE/DELETE/MERGE poderá ser executada assim que essa compactação for iniciada; e que o não cumprimento dessa regra pode levar à corrupção de dados. Tabelas que contêm apenas resultados de INSERT não são afetadas. Uma atualização direta da versão 2.x para a 4.x ultrapassa esse limite; portanto, verifique quais das suas tabelas transacionais são anteriores ao Hive 3, em vez de tratar a regra como universal. Faça primeiro um snapshot do banco de dados Metastore, execute a compactação como etapa prévia e teste a atualização do esquema em um clone antes de mexer na produção. Verifique a versão atual do esquema, faça um teste simulado da atualização e, em seguida, aplique-a:

schematool -dbType postgres -info

schematool -dbType postgres -upgradeSchema -dryRun

schematool -dbType postgres -upgradeSchema

Substitua por seu próprio dbType; os detalhes da conexão vêm da sua configuração do Hive. Se o metastore não tiver uma versão de esquema registrada, especifique a fonte explicitamente com a opção -upgradeSchemaFrom.

Falhas no mecanismo e na integração

O Hive 4 define o Tez como o mecanismo de execução padrão, e o mecanismo MapReduce está obsoleto desde a versão Hive 2, com a documentação alertando que ele poderá ser removido sem aviso prévio. Qualquer carga de trabalho ainda vinculada ao mr — ou ao mecanismo de execução do Spark — precisa ser validada antes de você planejar uma migração.

A maior surpresa está na fase posterior. A compatibilidade varia de acordo com as versões e configurações específicas do Spark, Trino, Impala, Iceberg e seus clientes do Metastore; portanto, considere toda integração como não verificada até que você a tenha testado, em vez de presumir que uma matriz de versões seja válida. Quando um único Metastore é compartilhado pelo Spark, Trino e Impala ao mesmo tempo, a atualização se reflete em todos eles simultaneamente. Mapeie todos os consumidores do Metastore antes de agendar qualquer coisa e inclua um teste de compatibilidade para cada mecanismo no manual de atualização.

Dica profissional: Configure um ambiente paralelo do Hive 4.2.0 apontado para um Metastore clonado e execute nele uma amostra representativa das consultas de produção. Limpe a amostra primeiro – os logs de consulta geralmente contêm identificadores confidenciais e valores literais. É importante que as falhas do Spark e do Trino sejam detectadas no ambiente de teste, e não durante a migração para a produção, que é onde elas tendem a ocorrer.

Opções após o fim do ciclo de vida do Apache Hive

Existem três caminhos que abrangem praticamente todas as equipes, e eles não são mutuamente exclusivos. A maioria das organizações acaba ganhando tempo em um deles enquanto executa outro.

Atualização direta para o Hive 4.2.0

Se as dependências da sua JVM e do mecanismo puderem ser migradas e você tiver capacidade de teste, a atualização para a versão 4.2.0 é a solução mais adequada a longo prazo. Você migra para a linha de versões atual, adota o Java 21 como o ambiente de execução mínimo suportado e passa a utilizar os recursos do Metastore 4.2.0 e do Apache Iceberg — suporte ampliado ao catálogo, incluindo um cliente REST do Iceberg Catalog, compactação automática, vetores de exclusão e valores padrão de colunas. Leve em conta a mudança de versão do Java, a migração do esquema e a verificação prévia da compactação ACID descrita acima. Se sua pilha for pequena e autônoma, comece por aqui. Se ela alimentar o Spark, o Trino e o Impala ao mesmo tempo, reserve um tempo significativamente maior do que os números das versões sugerem.

Substituir o Hive por completo

Algumas equipes utilizam o EOL como motivo para abandonar o Hive, em vez de atualizá-lo. Arquiteturas modernas de “lakehouse”, construídas em torno do Apache Iceberg e consultadas por meio do Trino, do Spark SQL ou de uma plataforma gerenciada, podem reduzir ou eliminar a dependência da camada de execução clássica do Hive, embora muitas mantenham um catálogo ou Metastore compatível com o Hive durante a transição. Esse é o caminho que exige maior esforço e raramente é concluído dentro do prazo exigido por uma descoberta de segurança em produção; por isso, geralmente é executado em paralelo com o suporte estendido, que fornece o prazo necessário. Se você estiver trocando de plataforma de qualquer maneira, isso evita desperdiçar esforços de migração em um mecanismo que você já planejava descontinuar.

Suporte ao ciclo de vida ilimitado da TuxCare

Caso você não consiga realizar a migração dentro do prazo exigido por seus auditores ou pelo seu registro de riscos, o Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare fornece patches para CVEs do Apache Hive 2.3.9 após o fim do ciclo de vida, entregues por meio do seu fluxo de trabalho de gerenciamento de pacotes já existente. A cobertura é específica para cada versão; portanto, confirme sua versão exata na lista de versões suportadas antes de planejar suas ações — se você estiver na versão 2.3.10, 3.1.3 ou em outra linha, entre em contato, pois a TuxCare adiciona versões mediante solicitação. Você permanece na versão do Hive da qual sua infraestrutura de data warehouse depende, sem precisar apressar uma migração.

Para uma equipe que está no meio de uma reformulação da plataforma, essa é a diferença entre uma atualização propensa a falhas, realizada sob pressão de auditoria, e uma migração planejada de acordo com seu cronograma. Isso restaura uma fonte mantida de correções de segurança, que é exatamente a condição que o Requisito 12.3.4 do PCI DSS exige, e fornece evidências documentadas e defensáveis de correção enquanto você migra para o Hive 4.2.0, assim que o trabalho com Java e o mecanismo estiverem realmente prontos. Isso por si só não encerra uma constatação de auditoria — nenhum serviço de aplicação de patches pode fazer isso, já que isso depende do seu escopo, das evidências e do avaliador —, mas altera o que você é capaz de apresentar.

Proteja o Apache Hive após o fim da vida útil (EOL) com a TuxCare

O prazo no EOL Hive não é reiniciado. Qualquer CVE recém-divulgado que afete sua versão não receberá correção da comunidade para essa linha, e a cada ciclo de auditoria será perguntado o que você fez a respeito. A sequência prática: primeiro, restaure a fonte do patch; depois, migre para o Hive 4.2.0 ou abandone completamente o Hive, seguindo um cronograma que você mesmo controle, em vez de um que um incidente venha a lhe impor.

Se você estiver utilizando uma versão do Hive em fim de vida útil (EOL) e não estiver pronto para migrar neste trimestre, o Suporte de Ciclo de Vida Ilimitado da TuxCare pode manter as vulnerabilidades CVE corrigidas enquanto você se prepara para a atualização ou substituição. Ele fornece correções para vulnerabilidades CVE do Apache Hive 2.3.9 por meio do seu fluxo de trabalho de gerenciamento de pacotes existente, sem a necessidade de um salto de versão forçado.

Perguntas frequentes

Quais versões do Apache Hive ainda são suportadas?

Apenas a linha 4.x recebe versões da comunidade, e a 4.2.0 é a versão atual. O Apache indica o Java 17 para a 4.1.x e o Java 21 para a 4.2.x. Esteja ciente de que as correções são incorporadas à versão secundária mais recente, em vez de serem portadas para versões anteriores – o CVE-2025-62728 foi corrigido na versão 4.2.0 e não na 4.1.x –, portanto, executar a versão 4.1.0 não é o mesmo que executar uma versão corrigida. As linhas 1.x, 2.x e 3.x estão todas fora de suporte.

Quando o Apache Hive 3.x chegou ao fim de sua vida útil?

A comunidade do Apache Hive declarou o fim do ciclo de vida da linha 3.x em 8 de outubro de 2024. A versão final foi a 3.1.3, lançada em 8 de abril de 2022.

Posso continuar usando o Hive 2.3.x em ambiente de produção após o fim do suporte (EOL)?

Tecnicamente, sim, mas você estará gerenciando o risco sem contar com correções da comunidade. A última versão da série 2.x foi a 2.3.10, lançada em 9 de maio de 2024, e a linha foi declarada em fim de vida útil em 20 de maio de 2024. A comunidade do Apache Hive não lançará uma nova versão 2.3.x para nenhum CVE recém-divulgado que afete o Hive ou suas dependências integradas. Suas opções são manter seus próprios backports ou obter suporte comercial independente, como o TuxCare ELS.

A atualização para o Hive 4 prejudica as integrações com o Spark ou o Trino?

Isso é possível, dependendo das versões exatas e da configuração de cada mecanismo e cliente do Metastore. Teste todas as integrações com o Spark, Trino, Impala e Iceberg em relação à versão do Hive de destino no ambiente de teste antes de qualquer migração para produção.

O Hive Metastore (HMS) tem uma data de fim de vida útil própria?

Não. As versões do HMS acompanham as versões do Apache Hive. A partir do Hive 4.1.0, o Metastore também é distribuído como um componente independente nos formatos binário e de imagem do Docker, e a versão 4.2.0 separou o código do cliente do Metastore em um módulo próprio — mas as correções de segurança da comunidade ainda seguem as versões do Hive com suporte. Portanto, uma versão do Hive com fim de vida útil (EOL) significa que o Metastore também chega ao fim de vida útil.

Resumo

Nome do artigo

Fim do ciclo de vida do Apache Hive: versões, datas e próximos passos

Descrição

O Apache Hive 1.x, 2.x e 3.x chegaram ao fim da vida útil. Confira as datas exatas do fim da vida útil, os riscos reais relacionados a CVE e à conformidade, além de três caminhos práticos a seguir.

Autor

Rohan Timalsina

Nome da editora

TuxCare

Logotipo da editora