Migrar cargas de trabalho do Hive do Azure HDInsight 3.6 para o HDInsight 4.0

  • Artigo

O Microsoft Azure HDInsight 4.0 tem diversas vantagens sobre o Microsoft Azure HDInsight 3.6. Aqui está umresumo do novo Microsoft Azure HDInsight 4.0.

Este artigo inclui as etapas de migrar as cargas de trabalho do Apache Hive da Microsoft Azure HDInsight 3.6 para a Microsoft Azure HDInsight 4.0, incluindo

  • A cópia do metastore do Hive e o esquema de atualização
  • Migração segura de compatibilidade com ACID
  • Preservação de políticas de segurança do Apache Hive

Os novos e antigos clusters do Azure HDInsight devem ter acesso às mesmas Contas de armazenamento.

A migração de tabelas do Apache Hive para uma nova Conta de armazenamento precisa ser feita como uma etapa separada. Consulte migração do Apache Hive entre Contas de armazenamento.

Alterações no Hive 3 e novidades:

Alterações de cliente do Hive

O Hive 3 dá suporte apenas ao cliente fino, Beeline para executar consultas e comandos administrativos do Hive na linha de comando. O Beeline usa uma conexão JDBC com HiveServer para executar todos os comandos. As operações de análise, compilação e execução ocorrem no HiveServer.

Insira os comandos da CLI do Hive com suporte invocando o Beeline usando a palavra-chave do Hive como um usuário do Hive ou invoque um beeline usando beeline -u <JDBC URL>. Você pode obter a URL do JDBC na página do Hive do Ambari.

Screenshot showing JDBC URL output.

Usar o Beeline (em vez da CLI do Hive do cliente espesso, que não tem mais suporte) tem várias vantagens, incluindo:

  • Em vez de manter toda a base de código do Hive, você pode manter apenas o cliente JDBC.
  • A sobrecarga de inicialização é menor usando o Beeline porque toda a base de código do Hive não está envolvida.

Você também pode executar o script do Hive, que está no diretório "/usr/bin", que invoca uma conexão beeline usando a URL do JDBC.

Screenshot showing beeline connection output.

Uma arquitetura de cliente fino facilita a proteção de dados em

  • Estado da sessão, estruturas de dados internas, senhas e assim por diante, residem no cliente em vez do servidor.
  • O pequeno número de daemons necessários para executar consultas simplifica o monitoramento e a depuração.

O HiveServer impõe configurações de lista de permitidos e lista de bloqueios que você pode alterar usando comandos SET. Usando as listas de bloqueio, você pode restringir a configuração de memória para evitar a instabilidade do Servidor Hive. Você pode configurar várias instâncias do HiveServer com listas de permissões e listas de bloqueios diferentes para estabelecer diferentes níveis de estabilidade.

Alterações no Metastore do Hive

O Hive agora dá suporte apenas a um metastore remoto em vez de um metastore inserido (dentro da JVM HS2). O metastore do Hive reside em um nó em um cluster gerenciado pelo Ambari como parte da pilha do HDInsight. Não há suporte para um servidor autônomo fora do cluster. Você não define mais comandos key=value na linha de comando para configurar o Metastore do Hive. Com base no valor configurado em "hive.metastore.uris=' ' " o serviço HMS usado e a conexão estabelecida.

Alteração do mecanismo de execução

O Apache Tez substitui MapReduce como o mecanismo de execução do Hive padrão. O MapReduce foi preterido a partir do Hive 2.0, confira HIVE-12300. Com expressões de grafos direcionados acíclicos (DAGs) e primitivos de transferência de dados, a execução de consultas do Hive no Tez melhora o desempenho. As consultas SQL enviadas ao Hive são executadas da seguinte maneira

  1. O Hive compila a consulta.
  2. O Tez executa a consulta.
  3. O YARN aloca recursos para aplicativos em todo o cluster e habilita a autorização para trabalhos do Hive em filas YARN.
  4. O Hive atualiza os dados no ABFS ou WASB.
  5. O Hive retorna os resultados da consulta em uma conexão JDBC.

Se um script ou aplicativo herdado especificar MapReduce para execução, ocorrerá uma exceção da seguinte maneira

Screenshot showing map reducer exception output.

Observação

A maioria das funções definidas pelo usuário (UDFs) não exige nenhuma alteração para executar no Tez em vez de MapReduce.

Alterações em relação à transação ACID e CBO:

  • Tabelas ACID são o tipo de tabela padrão no HDInsight 4.x sem sobrecarga operacional ou de desempenho.

  • Desenvolvimento simplificado de aplicativos, operações com garantias transacionais mais fortes e semântica mais simples para comandos SQL

  • O Hive interno cuida do bucketing de tabelas ACID no HDInsight 4.1, removendo assim a sobrecarga de manutenção.

  • Otimizações avançadas – atualização no CBO

  • Cache de consulta automática. A propriedade usada para habilitar o cache de consulta é hive.query.results.cache.enabled. Você precisa definir essa propriedade como true. O Hive armazena o cache de resultados da consulta em /tmp/hive/__resultcache__/. Por padrão, o Hive aloca 2 GB para o cache de resultados da consulta. É possível alterar essa configuração configurando o seguinte parâmetro em bytes hive.query.results.cache.max.size.

    Saiba mais sobre os Benefícios de migrar para o Azure HDInsight 4.0.

Resultado da exibição materializada

Para obter mais informações, em Hive – Exibições Materializadas

Alterações após a atualização para o Apache Hive 3

Para localizar e usar suas tabelas do Apache Hive 3 após uma atualização, você precisa entender as alterações que ocorrem durante o processo de atualização. Alterações no gerenciamento e local das tabelas, permissões para diretórios de tabela, tipos de tabela e preocupações de conformidade ACID.

Gerenciamento de Tabelas do Hive

O Hive 3 assume mais controle das tabelas do que o Hive 2 e exige que as tabelas gerenciadas sigam uma definição estrita. O nível de controle que o Hive assume sobre as tabelas é homogêneo para os bancos de dados tradicionais. O Hive reconhece automaticamente as alterações delta nos dados; essa estrutura de controle aprimora o desempenho.

Por exemplo, se o Hive souber que resolver uma consulta não requer verificação de tabelas para novos dados, o Hive retornará os resultados do cache de resultados da consulta hive. Quando os dados subjacentes em uma exibição materializada mudam, o Hive precisa recompilar a exibição materializada. As propriedades ACID revelam exatamente quais linhas foram alteradas e precisam ser processadas e adicionadas à exibição materializada.

Alterações do Hive nas propriedades ACID

O Hive 2.x e o 3.x têm tabelas transacionais (gerenciadas) e não transacionais (externas). As tabelas transacionais têm propriedades atômicas, consistentes, de isolamento e duráveis (ACID). No Hive 2.x, a versão inicial do processamento de transações ACID é ACID v1. No Hive 3.x, as tabelas padrão seriam com ACID v2.

Formatos de armazenamento nativos e não nativos

Os formatos de armazenamento são um fator nas alterações de atualização para tipos de tabela. O Hive 2.x e 3.x dá suporte aos seguintes formatos de armazenamento nativo e não nativo do Hadoop

Nativo: Tabelas com suporte interno no Hive, nos seguintes formatos de arquivo

  • Texto
  • Arquivo de sequência
  • Arquivo RC
  • Arquivo AVRO
  • Arquivo ORC
  • Arquivo Parquet

Não nativo: tabelas que usam um manipulador de armazenamento, como DruidStorageHandler ou HBaseStorageHandler

Alterações de atualização do HDInsight 4.x para tipos de tabela

A tabela a seguir compara os tipos de tabela do Hive e as operações ACID antes de uma atualização do HDInsight 3.x e após uma atualização para o HDInsight 4.x. A propriedade do arquivo de tabela Hive é um fator na determinação de tipos de tabela e operações ACID após a atualização

Comparação de tipos de tabela do HDInsight 3.x e HDInsight 4.x

HDInsight 3.x - - - HDInsight 4.x -
Tipo de tabela ACID v1 Formato Proprietário (usuário) do Arquivo de Tabela do Hive Tipo de tabela ACID v2
Externo Não Nativo ou não nativo Hive ou não Hive Externo Não
Gerenciado Sim ORC Hive ou não Hive Gerenciado, atualizável Sim
Gerenciado Não ORC Hive Gerenciado, atualizável Sim
Gerenciado Não ORC não Hive Externo, com exclusão de dados Não
Gerenciado Não Nativo (mas não ORC) Hive Gerenciado, somente inserção Sim
Gerenciado Não Nativo (mas não ORC) não Hive Externo, com exclusão de dados Não
Gerenciado Não Não nativo Hive ou não Hive Externo, com exclusão de dados Não

Representação do Hive

A representação do Hive foi habilitada por padrão no Hive 2 (doAs=true) e desabilitada por padrão no Hive 3. A representação do Hive executa o Hive como usuário final ou não.

Outras alterações de atualização do HDInsight 4.x

  1. Gerenciadas, as tabelas ACID não pertencentes ao usuário do Hive permanecem como tabelas gerenciadas após a atualização, mas o Hive se torna o proprietário.
  2. Após a atualização, o formato de uma tabela do Hive é o mesmo de antes da atualização. Por exemplo, as tabelas nativas ou não nativas permanecem nativas ou não nativas, respectivamente.

Alterações de local

Após a atualização, o local das tabelas gerenciadas ou partições não é alterado em nenhuma das seguintes condições:

  • O diretório de tabela ou partição antigo não estava em seu local padrão /apps/hive/warehouse antes da atualização.
  • A tabela ou partição antiga está em um sistema de arquivos diferente do novo diretório do warehouse.
  • O diretório de tabela ou partição antigo está em uma zona de criptografia diferente do novo diretório do warehouse.

Caso contrário, o local das tabelas gerenciadas ou partições será alterado. O processo de atualização move arquivos gerenciados para /hive/warehouse/managed. Por padrão, o Hive coloca todas as novas tabelas externas criadas no HDInsight 4.x em /hive/warehouse/external

O /apps/hive directory, que é o local anterior do warehouse Hive 2.x, pode ou não existir no HDInsight 4.x

Os cenários a seguir estão presentes para alterações de localização

Cenário 1

Se a tabela for uma tabela gerenciada no HDInsight-3.x e se ela estiver presente no local /apps/hive/warehouse e for convertida como tabela externa no HDInsight-4.x, o local também será o mesmo /apps/hive/warehouse no HDInsight 4.x. Não altera nenhum local. Após essa etapa, se você estiver executando o comando alter table para convertê-lo como tabela gerenciada (acid) no momento presente no mesmo local /apps/hive/warehouse.

Cenário 2

Se a tabela for uma tabela gerenciada no HDInsight-3.x e se ela estiver presente no local /apps/hive/warehouse e for convertida em tabela gerenciada (ACID) no HDInsight 4.x, o local será /hive/warehouse/managed.

Cenário 3 Se você estiver criando uma tabela externa no HDInsight-4.x sem especificar nenhum local, ela será apresentada no local /hive/warehouse/external.

Conversão de tabela

Após a atualização, para converter uma tabela não transacional em uma tabela transacional ACID v2, use o comando ALTER TABLE e defina as propriedades da tabela como

transaction'='true' and 'EXTERNAL'='false
  • A tabela gerenciada, formato não ACID, ORC e de propriedade do usuário não Hive no HDInsight-3.x será convertida em uma tabela externa não ACID no HDInsight-4.x.
  • Se o usuário quiser alterar a tabela externa (não ACID) para ACID, ele também deverá alterar a tabela externa para gerenciada e ACID. Porque no HDInsight-4.x, todas as tabelas gerenciadas são estritamente ACID por padrão. Não é possível converter as tabelas externas (não ACID) em tabelas ACID.

Observação

A tabela deve ser uma tabela ORC.

Para converter tabela externa (não ACID) em tabela Gerenciada (ACID),

  1. Converta a tabela externa em managed e acid igual a true usando o seguinte comando: 
    alter table <table name> set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
  2. Se você tentar executar o comando a seguir para a tabela externa, receberá o erro abaixo.

Cenário 1

Considere que a tabela rt é uma tabela externa (não ACID). Se a tabela for não ORC,

alter table rt set TBLPROPERTIES ('transactional'='true');
ERROR : FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. The table must be stored using an ACID compliant format (such as ORC): work.rt
The table must be ORC format

Cenário 2

>>>> alter table rt set TBLPROPERTIES ('transactional'='true'); If the table is ORC table.
ERROR:
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. work.rt can't be declared transactional because it's an external table (state=08S01,code=1)

Esse erro está ocorrendo porque a tabela rt é uma tabela externa e você não pode converter a tabela externa em ACID.

Cenário 3

>>>> alter table rt set TBLPROPERTIES ('EXTERNAL'='false');
ERROR:
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. Table work.rt failed strict managed table checks due to the following reason: Table is marked as a managed table but isn't transactional. (state=08S01,code=1)

Aqui, estamos tentando alterar a tabela externa primeiro para a tabela gerenciada. No HDInsight 4.x, ela deve ser uma tabela estritamente gerenciada (o que significa que ela deve ser ACID). Então, aqui você tem um deadlock. A única maneira de converter a tabela externa (NON_ACID) para gerenciada (ACID) é seguir o comando:

alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Sintaxe e semântica

  • Criando uma tabela para melhorar a capacidade de uso e a funcionalidade, o Hive 3 alterou a criação da tabela. O Hive alterou a criação da tabela das seguintes maneiras

    • Cria uma tabela compatível com ACID, que é o padrão no HDP
    • Dá suporte a gravações e inserções simples
    • Grava em várias partições
    • Insere várias atualizações de dados em uma única instrução SELECT
    • Elimina a necessidade de bucketing.

    Se você tiver um pipeline de ETL que cria tabelas no Hive, as tabelas serão criadas como ACID. O Hive agora controla firmemente o acesso e executa a compactação periodicamente nas tabelas

    Antes da atualização No HDInsight 3.x, por padrão CREATE TABLE criou uma tabela não ACID.

    Após a atualização Por padrão, CREATE TABLE cria uma tabela transacional ACID completa no formato ORC.

    Ação necessária Para acessar tabelas ACID do Hive do Spark, conecte-se ao Hive usando o HWC (Hive Warehouse Connector). Para gravar tabelas ACID no Hive do Spark, use o HWC e a API HWC

  • Referências db.table escape

    Você precisa alterar as consultas que usam referências db.table para impedir que o Hive interprete toda a cadeia de caracteres db.table como o nome da tabela. O Hive 3.x rejeita db.table em consultas SQL. Um ponto (.) não é permitido em nomes de tabela. Você inclui o nome do banco de dados e o nome da tabela entre sinais de acento grave. Encontre uma tabela com a referência de tabela problemática. O math.students que aparece em uma instrução CREATE TABLE. Inclua o nome do banco de dados e o nome da tabela entre sinais de acento grave.

    TABLE `math`.`students` (name VARCHAR(64), age INT, gpa DECIMAL(3,2));

  • CARIMBOS DE DATA/HORA DE CONVERSÃO Os resultados de aplicativos que convertem numéricos em carimbos de data/hora diferem do Hive 2 para o Hive 3. O Apache Hive alterou o comportamento do CAST para estar em conformidade com o SQL Standard, que não associa um fuso horário ao tipo TIMESTAMP.

    Antes da atualização A conversão de um valor de tipo numérico em um carimbo de data/hora poderia ser usada para produzir um resultado que refletisse o fuso horário do cluster. Por exemplo, 1597217764557 é 2020-08-12 00:36:04 PDT. A execução da consulta a seguir converte o numérico em um carimbo de data/hora em PDT: SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 00:36:04 |

    Após a atualização Converter um valor de tipo numérico em um carimbo de data/hora produz um resultado que reflete o UTC em vez do fuso horário do cluster. Executar a consulta converte o numérico em um carimbo de data/hora em UTC. SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 07:36:04.557 |

    Ação necessária Alterar aplicativos. Não converta de um numeral para obter um fuso horário local. As funções internas from_utc_timestamp e to_utc_timestamp podem ser usadas para imitar o comportamento antes da atualização.

  • VERIFICANDO A COMPATIBILIDADE DAS ALTERAÇÕES DE COLUNA Uma alteração de configuração padrão pode fazer com que aplicativos que alteram tipos de coluna falhem.

    Antes da atualização No HDInsight 3.x Hive.metastore.disallow.incompatible.col.type.changes é false por padrão para permitir alterações em tipos de coluna incompatíveis. Por exemplo, você pode alterar uma coluna STRING para uma coluna de um tipo incompatível, como MAP<STRING, STRING>. Nenhum erro ocorre.

    Após a atualização O hive.metastore.disallow.incompatible.col.type.changes é verdadeiro por padrão. O Hive impede alterações em tipos de coluna incompatíveis. Alterações de tipo de coluna compatíveis, como INT, STRING, BIGINT, não são bloqueadas.

    Ação necessária Altere os aplicativos para não permitir alterações incompatíveis de tipo de coluna para evitar uma possível corrupção de dados.

  • DESCARTE DE PARTIÇÕES

    As palavras-chave OFFLINE e NO_DROP na cláusula CASCADE para descartar partições causam problemas de desempenho e não têm mais suporte.

    Antes da atualização Você pode usar as palavras-chave OFFLINE e NO_DROP na cláusula CASCADE para impedir que partições sejam lidas ou descartadas.

    Após a atualização OFFLINE e NO_DROP não têm suporte na cláusula CASCADE.

    Ação necessária Altere os aplicativos para remover OFFLINE e NO_DROP da cláusula CASCADE. Use um esquema de autorização, como o Ranger, para impedir que partições sejam descartadas ou lidas.

  • RENOMEAR UMA TABELA Após a atualização, renomear uma tabela gerenciada moverá sua localização somente se a tabela for criada sem uma cláusula LOCATION e estiver sob seu diretório de banco de dados.

Limitações em relação ao CBO

  • Vemos que a saída de seleção fornece zeros à direita em poucas colunas. Por exemplo, se tivermos uma coluna de tabela com o tipo de dados como decimal(38,4) e se inserirmos dados como 38, ela adicionará os zeros à direita e fornecerá o resultado como 38.0000 de acordo com https://issues.apache.org/jira/browse/HIVE-12063 e https://issues.apache.org/jira/browse/HIVE-24389, a ideia mantém a escala e a precisão em vez de executar um wrapper em colunas decimais. Esse é o comportamento padrão do Hive 2. Para corrigir esse problema, você pode seguir a opção abaixo.

    1. Modifique o tipo de dados no nível de origem para ajustar a precisão como col1(decimal(38,0)). Esse valor fornece o resultado como 38 sem zeros à direita. Mas se você inserir os dados como 35.0005, ele será .0005 e fornecerá apenas o valor como 38 1. Remova os zeros à direita para as colunas com problema e, em seguida, converta em cadeia de caracteres,
      1. Use selecionar TRIM(cast(<column_name> AS STRING))+0 FROM <table_name>;
      2. Use regex.

  1. A consulta do Hive falha com "Expressão SubQuery sem suporte" quando usamos UNIX_TIMESTAMP na consulta. Por exemplo, se executarmos uma consulta, ela gerará um erro "Expressão SubQuery sem suporte"

    select * from
(SELECT col_1 from table1 where col_2 >= unix_timestamp('2020-03-07','yyyy-MM-dd'));

    O caso raiz desse problema é que a base de código atual do Hive está lançando uma exceção que analisa o UNIX_TIMESTAMP porque não há mapeamento de precisão em HiveTypeSystemImpl.java code para a precisão de UNIX_TIMESTAMP que o Calcite reconhece como BIGINT. Mas a consulta abaixo funciona bem select * from (SELECT col_1 from table1 where col_2 >= 1);

    Esse comando é executado com sucesso, pois col_2 é um inteiro. O problema acima foi corrigido no hdi-3.1.2-4.1.12(pilha 4.1) e hdi-3.1.2-5.0.8(pilha 5.0)

Etapas da atualização

1. Preparar os dados

  • O Apache Azure HDInsight 3.6 por padrão não oferece suporte às tabelas ACID. No entanto, se as tabelas ACID estiverem presentes, execute a compactação ' PRINCIPAL' nelas. Consulte o manual de idioma do Apache Hive para obter detalhes sobre a compactação.

  • Se usar o Azure Data Lake Storage Gen1, os locais da tabela do Apache Hive provavelmente dependerão das configurações do HDFS do cluster. Execute a ação de script seguinte para tornar esses locais portáteis para outros clusters. Aplique uma ação de script a um cluster em execução.

    Propriedade Valor
    URI do script Bash https://hdiconfigactions.blob.core.windows.net/linuxhivemigrationv01/hive-adl-expand-location-v01.sh
    Tipo(s) de nó Head
    Parâmetros

2.Copie o Banco de Dados SQL

  • Se o cluster usar um o metastore do Hive padrão, siga este guia para exportar os metadados para um metastore externo. Em seguida, crie uma cópia do metastore do Hive externo para a atualização.

  • Se o cluster empregar um metastore do Hive externo, crie uma cópia dele. As opções incluem exportar/importar e restauração pontual.

3.Atualizar o esquema do metastore

Esta etapa usa o Hive Schema Tool do Microsoft Azure HDInsight 4,0 para atualizar o esquema do metastore.

Aviso

Essa etapa não é reversível. Execute isso somente numa cópia do metastore.

  1. Crie um cluster do Microsoft Azure HDInsight 4.0 temporário para acessar o Apache Hive 4.0 schematool. Você pode usar o metastore do Hive padrãopara esta etapa.

  2. No cluster do Microsoft Azure HDInsight 4.0, execute schematool para atualizar o destino metastore do Microsoft Azure HDInsight 3.6. Edite o script de shell a seguir para adicionar o nome do servidor SQL, o nome do banco de dados, o nome de usuário e a senha. Abra uma Sessão SSH no nó de cabeçalho e execute-a.

    SERVER='servername.database.windows.net'  # replace with your SQL Server
DATABASE='database'  # replace with your 3.6 metastore SQL Database
USERNAME='username'  # replace with your 3.6 metastore username
PASSWORD='password'  # replace with your 3.6 metastore password
STACK_VERSION=$(hdp-select status hive-server2 | awk '{ print $3; }')
/usr/hdp/$STACK_VERSION/hive/bin/schematool -upgradeSchema -url "jdbc:sqlserver://$SERVER;databaseName=$DATABASE;trustServerCertificate=false;encrypt=true;hostNameInCertificate=*.database.windows.net;" -userName "$USERNAME" -passWord "$PASSWORD" -dbType "mssql" --verbose

    Observação

    Esse utilitário usa o computador cliente beeline para executar scripts SQL no /usr/hdp/$STACK_VERSION/hive/scripts/metastore/upgrade/mssql/upgrade-*.mssql.sql.

    A sintaxe SQL nesses scripts não é necessariamente compatível com outras ferramentas do cliente. Por exemplo, oSSMS e o Editor de Consultas no Portal do Azure exigem palavra-chave GO após cada comando.

    Se um script falhar devido a capacidade de recurso ou os tempos esgotados de transação, escale o Banco de Dados SQL do Microsoft Azure.

  3. Verifique a versão final da consulta select schema_version from dbo.version.

    A saída deve corresponder ao seguinte comando bash do cluster do Microsoft Azure HDInsight 4.0.

    grep . /usr/hdp/$(hdp-select --version)/hive/scripts/metastore/upgrade/mssql/upgrade.order.mssql | tail -n1 | rev | cut -d'-' -f1 | rev

  4. Exclua o cluster Microsoft Azure do HDInsight 4.0 temporário.

4. Implante novos clusters do Microsoft Azure HDInsight 4.0

Crie um novo cluster do Microsoft Azure HDInsight 4.0,selecionando o metastore do Hive atualizado e as mesmas Contas de Armazenamento.

  • O novo cluster não exige o mesmo sistema de arquivos padrão.

  • Se o metastore contiver as tabelas que residem em várias Contas de Armazenamento, você precisará adicionar estas Contas de Armazenamento ao novo cluster para acessar estas tabelas. Confira Adicionar contas de armazenamento extras ao HDInsight.

  • Se os trabalhos do Apache Hive falharem devido à inacessibilidade do armazenamento, verifique se o local da tabela está em uma Conta de Armazenamento adicionada ao cluster.

    Use o seguinte comando do Apache Hive para identificar o local da tabela:

    SHOW CREATE TABLE ([db_name.]table_name|view_name);

5. Converter as Tabelas em conformidade com ACID

As tabelas gerenciadas devem estar em conformidade com ACID no Microsoft Azure HDInsight 4.0. Execute strictmanagedmigration no Microsoft Azure HDInsight 4.0 para todas as tabelas gerenciadas non-ACID em tabelas externas com a propriedade 'external.table.purge'='true'. Execute o no nó principal:

sudo su - hive
STACK_VERSION=$(hdp-select status hive-server2 | awk '{ print $3; }')
/usr/hdp/$STACK_VERSION/hive/bin/hive --config /etc/hive/conf --service strictmanagedmigration --hiveconf hive.strict.managed.tables=true -m automatic --modifyManagedTables

6. Erro "Classe não encontrada" com MultiDelimitSerDe

Problema

Em algumas situações ao executar uma consulta do Hive, você poderá receber uma java.lang.ClassNotFoundException indicando que a classe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe não foi encontrada. Esse erro ocorre quando o cliente migra do HDInsight 3.6 para o HDInsight 4.0. A classe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe SerDe, que faz parte do hive-contrib-1.2.1000.2.6.5.3033-1.jar no HDInsight 3.6, foi removida, e estamos usando a classe org.apache.hadoop.hive.serde2.MultiDelimitSerDe, que faz parte do hive-exec jar no HDI-4.0. hive-exec jar será carregado para o HS2 por padrão quando iniciarmos o serviço.

ETAPAS PARA SOLUÇÃO DE PROBLEMAS

  1. Verifique se qualquer JAR em uma pasta (provavelmente ele deveria estar na pasta de bibliotecas do Hive, que é /usr/hdp/current/hive/lib no HDInsight) contém essa classe.
  2. Verifique se as classes org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe e org.apache.hadoop.hive.serde2.MultiDelimitSerDe existem, conforme mencionado na solução.

Solução

  1. Embora um arquivo JAR seja um arquivo binário, você ainda pode usar o comando grep com as opções -Hrni abaixo para procurar um nome de classe específico

    grep -Hrni "org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe" /usr/hdp/current/hive/lib

  2. Se ele não tiver encontrado a classe, não retornará nenhuma saída. Se ele encontrar a classe em um arquivo JAR, retornará a saída

  3. Veja abaixo o exemplo extraído do cluster HDInsight 4.x

    sshuser@hn0-alters:~$ grep -Hrni "org.apache.hadoop.hive.serde2.MultiDelimitSerDe" /usr/hdp/4.1.9.7/hive/lib/
Binary file /usr/hdp/4.1.9.7/hive/lib/hive-exec-3.1.0.4.1-SNAPSHOT.jar matches

  4. Na saída acima, podemos confirmar que nenhum JAR contém a classe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe e que o JAR hive-exec contém org.apache.hadoop.hive.serde2.MultiDelimitSerDe.

  5. Tente criar a tabela com o formato de linha DerDe como ROW FORMAT SERDE org.apache.hadoop.hive.serde2.MultiDelimitSerDe

  6. Este comando corrigirá o problema. Se você já criou a tabela, renomeie-a usando os comandos abaixo

    Hive => ALTER TABLE TABLE_NAME SET SERDE 'org.apache.hadoop.hive.serde2.MultiDelimitSerDe'
Backend DB => UPDATE SERDES SET SLIB='org.apache.hadoop.hive.serde2.MultiDelimitSerDe' where SLIB='org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe';

O comando update serve para atualizar os detalhes manualmente no BD de back-end, e o comando alter é usado para alterar a tabela com a nova classe SerDe do Beeline ou do Hive.

Script de comparação de esquema de banco de dados de back-end do Hive

Você pode executar o script a seguir depois de concluir a migração.

Há uma chance de faltar algumas colunas no BD de back-end, o que causa as falhas de consulta. Se a atualização do esquema não tiver ocorrido corretamente, há a possibilidade de atingirmos o problema de nome de coluna inválido. O script abaixo busca o nome da coluna e o tipo de dados do banco de dados de back-end do cliente e fornece a saída se houver alguma coluna ausente ou tipo de dados incorreto.

O caminho a seguir contém o arquivo schemacompare_final.py e test.csv. O script está presente no arquivo "schemacompare_final.py" e o arquivo "test.csv" contém todo o nome da coluna e o tipo de dados para todas as tabelas, que devem estar presentes no BD de back-end do hive.

https://hdiconfigactions2.blob.core.windows.net/hiveschemacompare/schemacompare_final.py

https://hdiconfigactions2.blob.core.windows.net/hiveschemacompare/test.csv

Baixe esses dois arquivos do link. E copie esses arquivos para um dos nós principais em que o serviço hive está em execução.

Etapas para executar o script:

Crie um diretório chamado "schemacompare" no diretório "/tmp".

Coloque "schemacompare_final.py" e "test.csv" na pasta "/tmp/schemacompare". Execute "ls -ltrh /tmp/schemacompare/" e verifique se os arquivos estão presentes.

Para executar o script Python, use o comando "python schemacompare_final.py". Esse script começa a executar o script e leva menos de cinco minutos para ser concluído. O script acima se conecta automaticamente ao banco de dados de back-end e busca os detalhes de cada tabela, que o Hive usa e atualiza os detalhes no novo arquivo csv chamado "return.csv". Depois de criar o arquivo return.csv, ele compara os dados com o arquivo "test.csv" e imprime o nome da coluna ou o tipo de dados se estiver faltando algo no nome da tabela.

Depois de executar o script, você poderá ver as linhas a seguir, que indicam que os detalhes são buscados para as tabelas e o script está em andamento

KEY_CONSTRAINTS
Details Fetched
DELEGATION_TOKENS
Details Fetched
WRITE_SET
Details Fetched
SERDES
Details Fetched

E você pode ver os detalhes da diferença na linha "DETALHES DA DIFERENÇA:". Se houver alguma diferença, ele imprime

PART_COL_STATS;
('difference', ['BIT_VECTOR', 'varbinary'])
The line with semicolon PART_COL_STATS; is the table name. And under the table name you can find the differences as ('difference', ['BIT_VECTOR', 'varbinary']) if there are any difference in column or datatype.

Se não houver diferenças na tabela, a saída será

BUCKETING_COLS;
('difference', [])
PARTITIONS;
('difference', [])

Nessa saída, você pode encontrar os nomes de coluna ausentes ou incorretos. Você pode executar a consulta a seguir no banco de dados de back-end para verificar uma vez se a coluna está ausente ou não.

SELECT * FROM INFORMATION_SCHEMA.columns WHERE TABLE_NAME = 'PART_COL_STATS';

Caso alguma das colunas seja perdida na tabela, por exemplo, se executarmos as consultas como inserir ou inserir substituição, as estatísticas serão calculadas automaticamente e tentarão atualizar a tabela de estatísticas como PART_COL_STATS e TAB_COL_STATS. E se a coluna como "BIT_VECTOR" estiver ausente nas tabelas, ela falhará com o erro "Nome da coluna inválido". Você pode adicionar a coluna conforme mencionado nos comandos a seguir. Como alternativa, você pode desabilitar as estatísticas definindo as propriedades a seguir, que não podem atualizar as estatísticas no Banco de Dados de back-end.

hive.stats.autogather=false;
hive.stats.column.autogather=false;
To Fix this issue, run the following two queries on backend SQL server (Hive metastore DB):

ALTER TABLE PART_COL_STATS ADD BIT_VECTOR VARBINARY(MAX);
ALTER TABLE TAB_COL_STATS ADD BIT_VECTOR VARBINARY(MAX);

Esta etapa evita as falhas de consulta, que falham com o erro "Nome de coluna inválido" uma vez após a migração.

Proteja o Apache Hive em versões do Microsoft Azure HDInsight

O HDInsight se integra opcionalmente ao Microsoft Entra ID usando o Enterprise Security Package (ESP) do HDInsight. O ESP usa a autenticação Kerberos (protocolo) e o Apache Ranger para gerenciar as permissões dos recursos específicos dentro do cluster. As políticas de Apache Ranger implantadas no Apache Hive no Microsoft Azure HDInsight 3.6 podem ser migradas para o Microsoft Azure HDInsight 4.0 com as seguintes etapas:

  1. Navegue até o painel de Service Manager do Ranger no cluster do Microsoft Azure HDInsight 3.6.
  2. Navegue até a política chamada APACHE HIVE e exporte a política para um arquivo json.
  3. Certifique-se de que todos os usuários referenciados no json da política exportada existam no novo cluster. Se um usuário for referenciado na política do arquivo json, mas não existir no novo cluster, adicione o usuário ao novo cluster ou remova a referência da política.
  4. Navegue até o painel de Service Manager do Rangerno cluster do Microsoft Azure HDInsight 4.0.
  5. Navegue até a política chamadaAPACHE HIVE e importe a política da etapa 2 do ranger json.

As alterações do Apache Hive no Microsoft Azure HDInsight 4.0 podem exigir alterações no aplicativo

Consulte o Anúncio do HDInsight 4.0 para obter outras alterações.

Após a migração

Siga estas etapas depois de concluir a migração.

Sanidade da Tabela

  1. Recrie tabelas no Hive 3.1 usando CTAS ou IOW para alterar o tipo de tabela em vez de alterar as propriedades da tabela.
  2. Mantenha doAs como false.
  3. Verifique se a propriedade de dados/tabela gerenciada está com o usuário "hive".
  4. Use tabelas ACID gerenciadas se o formato de tabela for ORC e não ACID gerenciado para tipos não ORC.
  5. Regenere estatísticas em tabelas recriadas, pois a migração teria causado estatísticas incorretas.

Integridade do cluster

Se vários clusters compartilharem o mesmo armazenamento e o HMS DB, devemos habilitar threads de compactação/compactação automática apenas em um cluster e desabilitar em todos os outros lugares.

Ajuste o Metastore para reduzir o uso da CPU.

  1. Desabilite ouvintes de eventos transacionais.

    Observação

    Execute as etapas a seguir, somente se o recurso de replicação do hive não for usado.

    1. Na interface do usuário do Ambari, remova o valor de hive.metastore.transactional.event.listeners.
    2. Valor padrão: org.apache.hive.hcatalog.listener.DbNotificationListener
    3. Novo valor: <Empty>

  2. Desabilite o PrivilegeSynchronizer do Hive

    1. Na interface do usuário do Ambari, defina hive.privilege.synchronizer = false.
    2. Valor padrão: true
    3. Novo valor: false

  3. Otimize o recurso de reparo de partição

  4. Desabilite o reparo de partição – esse recurso é usado para sincronizar as partições de tabelas do Hive no local de armazenamento com o metastore do Hive. Você poderá desabilitar esse recurso se "msck repair" for usado após a ingestão de dados.

  5. Para desabilitar o recurso, adicione "discover.partitions=false" nas propriedades da tabela usando ALTER TABLE. OU (se o recurso não puder ser desabilitado)

  6. Aumente a frequência de reparo da partição.

  7. Na interface do usuário do Ambari, aumente o valor de "metastore.partition.management.task.frequency" (em segundos).

    Observação

    Essa alteração pode atrasar a visibilidade de algumas das partições ingeridas no armazenamento.

    1. Valor padrão: 60
    2. Valor proposto: 3600

  8. Otimizações Avançadas: as opções a seguir precisam ser testadas em um ambiente inferior (não prod) antes de serem aplicadas à produção.

    1. Remova o ouvinte relacionado à exibição materializada se a exibição materializada não for usada.
    2. Na interface do usuário do Ambari, adicione uma propriedade personalizada (em hive-site.xml personalizada) e remova os threads de metastore de plano de fundo indesejados.
    3. Nome da propriedade: metastore.task.threads.remote
    4. Valor padrão: N/A (it uses few class names internally)
    5. Novo valor: org.apache.hadoop.hive.metastore.txn.AcidHouseKeeperService,org.apache.hadoop.hive.metastore.txn.AcidOpenTxnsCounterService,org.apache.hadoop.hive.metastore.txn.AcidCompactionHistoryService,org.apache.hadoop.hive.metastore.txn.AcidWriteSetService,org.apache.hadoop.hive.metastore.PartitionManagementTask

  9. Desabilite os threads em segundo plano se a replicação estiver desabilitada.

    1. Na interface do usuário do Ambari, adicione uma propriedade personalizada (em hive-site.xml personalizado) e remova os threads indesejados.
    2. Nome da propriedade: metastore.task.threads.always
    3. Valor padrão: N/A (it uses few class names internally)
    4. Novo valor: org.apache.hadoop.hive.metastore.RuntimeStatsCleanerTask

Ajuste de consulta

  1. Mantenha as configurações padrão do Hive para executar as consultas conforme elas são ajustadas para cargas de trabalho TPC-DS. Só será necessário ajustar o nível de consulta se ele falhar ou ficar lenta.
  2. Verifique se as estatísticas estão atualizadas para evitar planos inválidos ou resultados errados.
  3. Evite misturar tabelas ACID externas e gerenciadas no tipo de junção de consultas. Nesse caso, tente converter a tabela externa para não ACID gerenciada por meio da recriação.
  4. No Hive-3, muito trabalho aconteceu na vetorização, CBO, carimbo de data/hora com zona, etc., que pode ter bugs de produto. Portanto, se qualquer consulta fornecer resultados errados, tente desabilitar a vetorização, CBO, junção de mapa, etc., para ver se isso ajuda.

Outras etapas a serem seguidas para corrigir os resultados incorretos e o mau desempenho após a migração

  1. Problema A consulta do Hive fornece o resultado incorreto. Até mesmo a consulta select count(*) fornece o resultado incorreto.

    Causa A propriedade "hive.compute.query.using.stats" é definida como true, por padrão. Se a definirmos como true, ela usará as estatísticas, que são armazenadas no metastore para executar a consulta. Se as estatísticas não estiverem atualizadas, isso resultará em resultados incorretos.

    Resolução colete as estatísticas das tabelas gerenciadas usando o comando alter table <table_name> compute statics; no nível da tabela e no nível da coluna. Link de referência - https://cwiki.apache.org/confluence/display/hive/statsdev#StatsDev-TableandPartitionStatistics

  2. Problema As consultas do Hive estão demorando muito para serem executadas.

    Causa Se a consulta tiver uma condição de junção, o hive criará um plano para usar a junção de mapa ou a junção de mesclagem com base no tamanho da tabela e na condição de junção. Se uma das tabelas contiver um tamanho pequeno, ela carregará essa tabela na memória e executará a operação de junção. Dessa forma, a execução da consulta é mais rápida quando comparada com a junção de mesclagem.

    Resolução Defina a propriedade "hive.auto.convert.join=true", que é o valor padrão. Defini-la como false usa a junção de mesclagem e pode resultar em baixo desempenho. O Hive decide se deseja usar a junção de mapa ou não com base nas propriedades a seguir, que são definidas no cluster

    set hive.auto.convert.join=true;
set hive.auto.convert.join.noconditionaltask=true;
set hive.auto.convert.join.noconditionaltask.size=<value>;
set hive.mapjoin.smalltable.filesize = <value>;

    A junção comum pode ser convertida para a junção de mapa automaticamente, quando hive.auto.convert.join.noconditionaltask=true, se o tamanho estimado de tabelas pequenas for menor que o hive.auto.convert.join.noconditionaltask.size (o valor padrão é 10000000 MB).

    Se você enfrentar algum problema relacionado ao OOM definindo a propriedade hive.auto.convert.join como true, é aconselhável defini-la como false somente para essa consulta específica no nível da sessão e não no nível do cluster. Esse problema pode ocorrer se as estatísticas estiverem erradas e o Hive decidir usar a junção de mapa com base nas estatísticas.

  • Problema A consulta do Hive fornecerá o resultado incorreto se a consulta tiver uma condição de junção e as tabelas envolvidas tiverem valores nulos ou vazios.

    Causa Às vezes, podemos obter um problema relacionado a valores nulos se as tabelas envolvidas na consulta tiverem muitos valores nulos. O Hive executa a otimização de consulta incorretamente com os valores nulos envolvidos, o que resulta em resultados incorretos.

    Resolução Recomendamos tentar definir a propriedade set hive.cbo.returnpath.hiveop=true no nível da sessão se você obtiver resultados incorretos. Essa configuração apresenta a filtragem não nula nas chaves de junção. Se as tabelas tiverem muitos valores nulos, para otimizar a operação de junção entre várias tabelas, poderemos habilitar essa configuração para que ela considere apenas os valores não nulos.

  • Problema A consulta do Hive fornecerá o resultado incorreto se a consulta tiver várias condições de junção.

    Causa Às vezes, o Tez produz planos de runtime inválidos sempre que há as mesmas junções com junções de mapa várias vezes.

    Resolução Há uma chance de obter resultados incorretos quando definimos hive.merge.nway.joins como false. Tente defini-lo como true somente para a consulta que foi afetada. Isso ajuda a consultar com várias junções na mesma condição, mesclar junções em um único operador de junção. Esse método é útil quando houver junções aleatórias grandes para evitar uma fase de reformulação.

  • Problema Há um aumento no tempo da execução da consulta dia após dia em comparação com as execuções anteriores.

    Causa Esse problema poderá ocorrer se houver um aumento no número de arquivos pequenos. Portanto, o hive leva tempo para ler todos os arquivos para processar os dados, o que resulta em aumento no tempo de execução.

    Resolução Execute a compactação com frequência para as tabelas, que são gerenciadas. Esta etapa evita os arquivos pequenos e melhora o desempenho.

    Link de referência: Transações do Hive – Apache Hive – Apache Software Foundation.

  • Problema A consulta do Hive fornece um resultado incorreto quando o cliente está usando uma condição de junção na tabela orc acid gerenciada e na tabela orc não acid gerenciada.

    Causa Do HIVE 3 em diante, é estritamente solicitado manter todas as tabelas gerenciadas como uma tabela acid. E se quisermos mantê-lo como uma tabela acid, o formato de tabela deve ser ORC e esse é o principal critério. Mas se desabilitarmos a propriedade de tabela gerenciada estrita "hive.strict.managed.tables" como false, poderemos criar uma tabela não ACID gerenciada. Em alguns casos, o cliente cria uma tabela ORC externa ou, após a migração, a tabela é convertida em uma tabela externa ele desabilita a propriedade de tabela gerenciada estrita e a converte em tabela gerenciada. Neste ponto, a tabela foi convertida em formato ORC gerenciado não ACID.

    Resolução A otimização do Hive dá errado se você unir uma tabela com uma tabela ORC gerenciada não acid com uma tabela ORC gerenciada acid.

    Se você estiver convertendo uma tabela externa em uma tabela gerenciada,

    1. Não defina a propriedade "hive.strict.managed.tables" como false. Se você definir, poderá criar uma tabela gerenciada não ACID, mas não é solicitado no HIVE-3
    2. Converta a tabela externa em uma tabela gerenciada usando o comando alter a seguir em vez de alter table <table_name> set TBLPROPERTIES ('EXTERNAL'='false');
    alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Guia de Solução de Problemas

O guia de solução de problemas do HDInsight 3.6 para 4.0 para cargas de trabalho do Hive fornece respostas para problemas comuns enfrentados ao migrar cargas de trabalho do Hive do HDInsight 3.6 para o HDInsight 4.0.

Leitura adicional