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

  • Artigo

O HDInsight 4.0 tem várias vantagens em relação ao HDInsight 3.6. Aqui está uma visão geral das novidades do HDInsight 4.0.

Este artigo aborda as etapas para migrar cargas de trabalho do Hive do HDInsight 3.6 para 4.0, incluindo

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

Os clusters HDInsight novos e antigos devem ter acesso às mesmas Contas de Armazenamento.

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

Alterações no Hive 3 e novidades:

Alterações no cliente do Hive

O Hive 3 suporta apenas o thin client, Beeline para executar consultas e comandos administrativos do Hive a partir da linha de comando. Beeline usa uma conexão JDBC com HiveServer para executar todos os comandos. A análise, compilação e execução de operações ocorrem no HiveServer.

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

Screenshot showing JDBC URL output.

Use Beeline (em vez do cliente espesso Hive CLI, que não é mais suportado) tem várias vantagens, inclui:

  • 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 Beeline porque toda a base de código do Hive não está envolvida.

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

Screenshot showing beeline connection output.

Uma arquitetura de thin client 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 permissões e listas de bloqueio que você pode alterar usando SET comandos. Usando as listas de bloqueio, você pode restringir a configuração de memória para evitar a instabilidade do Hive Server. Você pode configurar várias instâncias do HiveServer com diferentes listas de permissões e listas de bloqueio para estabelecer diferentes níveis de estabilidade.

Alterações no Hive Metastore

O Hive agora suporta apenas um metastore remoto em vez de um metastore incorporado (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 os comandos key=value na linha de comando para configurar o Hive Metastore. Com base no valor configurado em "hive.metastore.uris=' ' " serviço HMS usado e conexão estabelecida.

Mudança no mecanismo de execução

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

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

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

Screenshot showing map reducer exception output.

Nota

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

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

  • As 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 da caçamba para mesas 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. Você pode alterar essa configuração configurando o seguinte parâmetro em bytes hive.query.results.cache.max.size.

    Para obter mais informações, Benefícios da migração para o Azure HDInsight 4.0.

Regravações da vista materializada

Para mais informações, em Hive - Materialized Views

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 localização de tabelas, permissões para diretórios de tabelas, tipos de tabela e preocupações de conformidade com ACID.

Gestão Hive de Tabelas

O Hive 3 assume mais controle das tabelas do que o Hive 2 e requer que as tabelas gerenciadas sigam uma definição rigorosa. O nível de controle que o Hive assume sobre as tabelas é homogêneo em relação aos bancos de dados tradicionais. O Hive é autoconsciente das alterações delta nos dados; Esta estrutura de controlo melhora o desempenho.

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

Alterações das propriedades ACID da colmeia

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 importante nas alterações de atualização dos tipos de tabela. O Hive 2.x e 3.x suporta os seguintes formatos de armazenamento nativos e não nativos do Hadoop:

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

  • Texto
  • Arquivo de seqüência
  • Ficheiro 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 ÁCIDO v1 Formato Proprietário (usuário) do arquivo de tabela do Hive Tipo de tabela ÁCIDO v2
Externo Não Nativo ou não nativo Colmeia ou não-Colmeia Externo Não
Geridas Sim ORC Colmeia ou não-Colmeia Gerenciado, atualizável Sim
Geridas Não ORC Ramo de registo Gerenciado, atualizável Sim
Geridas Não ORC não-colmeia Externo, com exclusão de dados Não
Geridas Não Nativo (mas não ORC) Ramo de registo Gerenciado, inserir somente Sim
Geridas Não Nativo (mas não ORC) não-colmeia Externo, com exclusão de dados Não
Geridas Não Não nativo Colmeia ou não-Colmeia Externo, com exclusão de dados Não

Falsificação de identidade 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 que não pertencem ao usuário do Hive permanecem 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 Hive é o mesmo que antes da atualização. Por exemplo, tabelas nativas ou não nativas permanecem nativas ou não nativas, respectivamente.

Alterações de localização

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

  • A tabela antiga ou o diretório de partição 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 de depósito.
  • A tabela antiga ou o diretório de partição está em uma zona de criptografia diferente do novo diretório de depósito.

Caso contrário, o local das tabelas ou partições gerenciadas será alterado. O processo de atualização move os arquivos gerenciados para o /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 antigo local do armazém do Hive 2.x, pode ou não existir no HDInsight 4.x

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

Cenário 1

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

Cenário 2

Se a tabela for gerenciada no HDInsight-3.x e se estiver presente no local e convertida em tabela gerenciada (ACID) no HDInsight 4.x, o local /apps/hive/warehouse 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 tabelas

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

transaction'='true' and 'EXTERNAL'='false
  • A tabela gerenciada, formato não-ACID, ORC e de propriedade de usuário não-Hive no HDInsight-3.x será convertida em tabela externa não ACID no HDInsight-4.x.
  • Se o usuário deseja mudar a tabela externa (não-ACID) para ACID, então ele deve mudar a tabela externa para gerenciado e ACID também. 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.

Nota

A tabela deve ser uma tabela ORC.

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

  1. Converta tabela externa em gerenciada 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 seguinte comando para a tabela externa, obterá o erro abaixo.

Cenário 1

Considere que a tabela rt é uma tabela externa (não ACID). Se a tabela não for 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)

Este erro está ocorrendo porque a tabela rt é tabela externa e você não pode converter tabela externa para 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 mudar a tabela externa primeiro para a tabela gerenciada. No HDInsight 4.x, deve ser uma tabela estritamente gerenciada (o que significa que deve ser ACID). Então, aqui você tem um impasse. A única maneira de converter a tabela externa (NON_ACID) para gerenciada (ACID) você tem que seguir o comando:

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

Sintaxe e semântica

  • Criando uma tabela Para melhorar a usabilidade e a funcionalidade, o Hive 3 alterou a criação da tabela. O Hive alterou a criação de tabelas das seguintes maneiras:

    • Cria uma tabela compatível com ACID, que é o padrão no HDP
    • Suporta inserções e gravaçõ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 balde.

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

    Antes de atualizar 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 as tabelas ACID do Hive a partir do Spark, conecte-se ao Hive usando o Hive Warehouse Connector (HWC). Para escrever tabelas ACID no Hive a partir do Spark, use a API HWC e HWC

  • Escapando db.table de referências

    Você precisa alterar 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 db.table Hive 3.x rejeita em consultas SQL. Um ponto (.) não é permitido em nomes de tabelas. Coloque o nome do banco de dados e o nome da tabela em backticks. Encontre uma tabela com a referência de tabela problemática. math.students que aparece em uma instrução CREATE TABLE. Coloque o nome do banco de dados e o nome da tabela em backticks.

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

  • CARIMBOS DE DATA/HORA DE TRANSMISSÃO Os resultados de aplicativos que convertem números em carimbos de data/hora diferem do Hive 2 ao 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 no PDT: SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 00:36:04 |

    Após a atualização A conversão de 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. A execução da 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 transmita a partir de um numeral para obter um fuso horário local. Funções internas from_utc_timestamp e to_utc_timestamp podem ser usadas para imitar o comportamento antes da atualização.

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

    Antes da atualização no HDInsight 3.x O 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.> Não ocorre nenhum erro.

    Após a atualização O hive.metastore.disallow.incompatible.col.type.changes é true por padrão. O Hive impede alterações em tipos de coluna incompatíveis. As 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 de tipo de coluna incompatíveis para evitar possíveis corrupção de dados.

  • SOLTANDO PARTIÇÕES

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

    Antes da atualização Você pode usar 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 são suportados 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 evitar que partições sejam descartadas ou lidas.

  • RENOMEANDO UMA TABELA Após a atualização Renomear uma tabela gerenciada move seu local somente se a tabela for criada sem uma LOCATION cláusula e estiver sob seu diretório de banco de dados.

Limitações em relação à CBO

  • Vemos que a saída select dá zero à direita em poucas colunas. Por exemplo, se tivermos uma coluna de tabela com datatype como decimal(38,4) e se inserirmos dados como 38, ela adicionará o zero à direita e fornecerá resultado como 38,0000 Como por https://issues.apache.org/jira/browse/HIVE-12063 e , a ideia é manter a escala e https://issues.apache.org/jira/browse/HIVE-24389a precisão em vez de executar um wrapper em colunas decimais. Este é 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)). Este valor fornece o resultado como 38 sem ficar à direita de zero. Mas se você inserir os dados como 35.0005, então é .0005 e fornece apenas o valor como 38 1.Remova os zeros à direita para as colunas com problema e, em seguida, converta em string,
      1. Use selecione TRIM(cast(<column_name> AS STRING))+0 DE <table_name>;
      2. Use regex.

  1. A consulta do Hive falha com "Expressão de subconsulta não suportada" quando usamos UNIX_TIMESTAMP na consulta. Por exemplo, se executarmos uma consulta, ela lançará um erro "Expressão de subconsulta 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 para HiveTypeSystemImpl.java code a precisão da UNIX_TIMESTAMP qual o Calcite reconhece como BIGINT. Mas a consulta abaixo funciona bem select * from (SELECT col_1 from table1 where col_2 >= 1);

    Este comando é executado com êxito, uma vez que col_2 é um inteiro. O problema acima foi corrigido em hdi-3.1.2-4.1.12(4.1 stack) e hdi-3.1.2-5.0.8(5.0 stack)

Etapas para atualizar

1. Preparar os dados

  • Por padrão, o HDInsight 3.6 não suporta tabelas ACID. No entanto, se estiverem presentes tabelas ACID, execute a compactação 'MAJOR' nelas. Consulte o Manual de Linguagem do Hive para obter detalhes sobre compactação.

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

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

2. Copie o banco de dados SQL

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

  • Se o cluster usar um metastore externo do Hive, crie uma cópia dele. As opções incluem exportação/importação e restauração point-in-time.

3. Atualize o esquema do metastore

Esta etapa usa o do HDInsight 4.0 para atualizar o Hive Schema Tool esquema de metastore.

Aviso

Esta etapa não é reversível. Execute isso somente em uma cópia do metastore.

  1. Crie um cluster HDInsight 4.0 temporário para acessar o Hive schematool4.0. Você pode usar o metastore padrão do Hive para esta etapa.

  2. No cluster HDInsight 4.0, execute schematool para atualizar o metastore do HDInsight 3.6 de destino. Edite o shell script 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ó principal 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

    Nota

    Este utilitário usa o 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 de cliente. Por exemplo, o SSMS e o Editor de Consultas no Portal do Azure exigem palavra-chave GO após cada comando.

    Se algum script falhar devido à capacidade de recursos ou tempos limite de transação, aumente a escala do Banco de dados SQL.

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

    A saída deve corresponder à do seguinte comando bash do cluster 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 HDInsight 4.0 temporário.

4. Implantar um novo cluster HDInsight 4.0

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

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

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

  • Se os trabalhos do 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 Hive para identificar o local da tabela:

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

5. Converter tabelas para conformidade com ACID

As tabelas gerenciadas devem ser compatíveis com ACID no HDInsight 4.0. Execute strictmanagedmigration no HDInsight 4.0 para converter todas as tabelas gerenciadas não ACID em tabelas externas com propriedade 'external.table.purge'='true'. Execute a partir do 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 de classe não encontrado com MultiDelimitSerDe

Problema

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

ETAPAS PARA SOLUCIONAR PROBLEMAS

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

Solução

  1. Embora um arquivo JAR seja um arquivo binário, você ainda pode usar grep o comando com -Hrni opções como 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 conseguiu encontrar a classe, ele não retornará nenhuma saída. Se ele encontrar a classe em um arquivo JAR, ele retornará a saída

  3. Abaixo está o exemplo obtido 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. A partir da saída acima, podemos confirmar que nenhum jar contém a classe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe e hive-exec jar contém org.apache.hadoop.hive.serde2.MultiDelimitSerDe.

  5. Tente criar a tabela com 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, pode renomeá-la 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 é para atualizar os detalhes manualmente no banco de dados backend e o comando alter é usado para alterar a tabela com a nova classe SerDe de beeline ou Hive.

Esquema de banco de dados de back-end do Hive comparar script

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

Há uma chance de faltar algumas colunas no banco de dados de back-end, o que causa as falhas de consulta. Se a atualização do esquema não tiver acontecido corretamente, há chance de que possamos atingir o problema do nome da coluna inválida. 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 banco de dados de back-end do hive.

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

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

Faça o download desses dois arquivos no link. E copie esses arquivos para um dos nós principais onde o serviço hive está sendo executado.

Etapas para executar o script:

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

Coloque o "schemacompare_final.py" e "test.csv" na pasta "/tmp/schemacompare". Faça "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 executá-lo e leva menos de cinco minutos para ser concluído. O script acima se conecta automaticamente ao seu 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 houver algo faltando sob o tablename.

Uma vez depois de executar o script, você pode ver as seguintes linhas, 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, então a saída é

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

A partir desta saída, você pode encontrar os nomes de coluna que estão faltando ou incorretos. Você pode executar a seguinte consulta em seu banco de dados de back-end para verificar uma vez se a coluna está faltando 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 ele tenta atualizar a tabela de estatísticas como PART_COL_STATS e TAB_COL_STATS. E se a coluna como "BIT_VETOR" estiver faltando nas tabelas, ela falhará com o erro "Nome da coluna inválido". Você pode adicionar a coluna como mencionado nos comandos a seguir. Como solução alternativa, você pode desabilitar as estatísticas definindo as seguintes propriedades, 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 "Nome da coluna inválido" uma vez após a migração.

Proteja o Hive nas versões do HDInsight

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

  1. Navegue até o painel Ranger Service Manager no cluster HDInsight 3.6.
  2. Navegue até a política chamada HIVE e exporte a política para um arquivo json.
  3. Verifique se todos os usuários mencionados no json de política exportado existem no novo cluster. Se um usuário for referido no json da política, 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 Ranger Service Manager no cluster HDInsight 4.0.
  5. Navegue até a política chamada HIVE e importe a política de ranger json da etapa 2.

Alterações do Hive no HDInsight 4.0 que podem exigir alterações no aplicativo

  • Consulte Configuração extra usando o Hive Warehouse Connector para compartilhar o metastore entre o Spark e o Hive para tabelas ACID.

  • O HDInsight 4.0 usa a Autorização Baseada em Armazenamento. Se você modificar as permissões de arquivo ou criar pastas como um usuário diferente do Hive, provavelmente ocorrerá em erros do Hive com base nas permissões de armazenamento. Para corrigir, conceda rw- acesso ao usuário. Consulte o Guia de permissões do HDFS.

  • HiveCLI é substituído por Beeline.

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

Pós-migração

Certifique-se de seguir estas etapas depois de concluir a migração.

Sanidade da mesa

  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 falso.
  3. Certifique-se de que a propriedade da tabela/dados gerenciada esteja com o usuário "colmeia".
  4. Use tabelas ACID gerenciadas se o formato da tabela for ORC e gerenciado não-ACID para tipos não-ORC.
  5. Regenere estatísticas em tabelas recriadas, pois a migração teria causado estatísticas incorretas.

Estado de funcionamento do cluster

Se vários clusters compartilharem o mesmo armazenamento e o mesmo banco de dados HMS, 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. Desative ouvintes de eventos transacionais.

    Nota

    Execute as etapas a seguir, somente se o recurso de replicação de 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. Desativar o Hive PrivilegeSynchronizer

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

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

  4. Desativar reparo de partição - Este recurso é usado para sincronizar as partições de tabelas do Hive no local de armazenamento com o metastore do Hive. Você pode desativar esse recurso se "msck repair" for usado após a ingestão de dados.

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

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

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

    Nota

    Esta 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 ao modo de exibição Materializado se o modo de exibição Materializado não for usado.
    2. Na interface do usuário do Ambari, adicione uma propriedade personalizada (em site de colmeia personalizado.xml) e remova os threads indesejados do metastore em segundo plano.
    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. Desative os threads em segundo plano se a replicação estiver desabilitada.

    1. Na interface do usuário do Ambari, adicione uma propriedade personalizada (em site de colmeia personalizado.xml) 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. Precisa de ajuste de nível de consulta somente se ele falhar ou estiver lento.
  2. Certifique-se de que as estatísticas estão atualizadas para evitar planos ruins ou resultados errados.
  3. Evite misturar tabelas ACID externas e gerenciadas em consultas do tipo junto. Nesse caso, tente converter tabela externa para gerenciada não-ACID através de recreação.
  4. No Hive-3, muito trabalho aconteceu em vetorização, CBO, timestamp com zona etc., que pode ter bugs do produto. Então, se alguma consulta der resultados errados, tente desativar a vetorização, CBO, map-join etc., para ver se isso ajuda.

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

  1. A consulta Issue Hive dá o resultado incorreto. Até mesmo a consulta select count(*) dá o resultado incorreto.

    Causa A propriedade "hive.compute.query.using.stats" é definida como true, por padrão. Se o definirmos como true, ele 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 coletar as estatísticas para as tabelas gerenciadas usando alter table <table_name> compute statics; o comando 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. As consultas do Issue Hive estão demorando muito tempo 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. Desta forma, a execução da consulta é mais rápida quando comparada com a junção de mesclagem.

    Resolução Certifique-se de definir a propriedade "hive.auto.convert.join=true", que é o valor padrão. Defini-lo como false usa a junção de mesclagem e pode resultar em baixo desempenho. O Hive decide se deve ou não usar a associação de mapa com base nas seguintes propriedades, 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 em junção de mapa automaticamente, quando hive.auto.convert.join.noconditionaltask=true, se o tamanho estimado da(s) tabela(s) pequena(s) for menor que a colmeia.auto.convert.join.noconditionaltask.size (o valor padrão é 10000000 MB).

    Se você enfrentar qualquer 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 associação de mapas com base nas estatísticas.

  • Problema A consulta Hive fornece 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 ter um problema relacionado a valores nulos se as tabelas envolvidas na consulta tiverem muitos valores nulos. O Hive executa a otimização da consulta incorretamente com os valores nulos envolvidos, o que resulta em resultados incorretos.

    Resolução Recomendamos que tente definir a propriedade set hive.cbo.returnpath.hiveop=true no nível da sessão se obtiver resultados incorretos. Esta configuração introduz filtragem não nula em chaves de junção. Se as tabelas tinham muitos valores nulos, para otimizar a operação de junção entre várias tabelas, podemos habilitar essa configuração para que ela considere apenas os valores não nulos.

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

    Cause Sometime Tez produz planos de tempo de execução ruins sempre que há as mesmas junções várias vezes com map-joins.

    Resolução Há uma chance de obter resultados incorretos quando definimos hive.merge.nway.joins como false. Tente defini-lo como true apenas 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. Este método é útil se um grande shuffle se juntar para evitar uma fase de remodelação.

  • Problema' Há um aumento no tempo de execução da consulta dia a dia em comparação com as execuções anteriores.

    Causa Esse problema pode ocorrer se houver um aumento em mais números de arquivos pequenos. Assim, o hive leva tempo na leitura de todos os arquivos para processar os dados, o que resulta em aumento no tempo de execução.

    Resolução Certifique-se de executar a compactação com freqüência para as tabelas, que são gerenciadas. Esta etapa evita os arquivos pequenos e melhora o desempenho.

    Link de referência: Hive Transactions - Apache Hive - Apache Software Foundation.

  • A consulta Issue 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 A partir do HIVE 3, é estritamente solicitado manter todas as mesas gerenciadas como uma tabela ácida. E se quisermos mantê-lo como uma tabela ácida, então o formato da tabela deve ser orc e este é o principal critério. Mas se desativarmos a propriedade estrita da tabela gerenciada "hive.strict.managed.tables" para false, então podemos criar uma tabela gerenciada não-ACID. Alguns clientes de caso criam uma tabela ORC externa ou, após a migração, a tabela é convertida em uma tabela externa e desativam a propriedade strict managed table e a convertem em tabela gerenciada. Neste ponto, a tabela convertida para o formato orc gerenciado não-ACID.

    A otimização do Hive de resolução dá errado se você unir a tabela com a tabela ORC gerenciada não ACID com a tabela orc gerenciada por ácido.

    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, então você pode criar uma tabela gerenciada não-ACID, mas não é solicitado no HIVE-3
    2. Converta a tabela externa em tabela gerenciada usando o seguinte comando alter em vez de alter table <table_name> set TBLPROPERTIES ('EXTERNAL'='false');
    alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Guia de resolução de problemas

O guia de solução de problemas do HDInsight 3.6 a 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