Share via

Eseguire la migrazione di carichi di lavoro Azure HDInsight 3.6 Hive a HDInsight 4.0

  • Articolo

HDInsight 4.0 offre diversi vantaggi rispetto a HDInsight 3.6. Ecco una panoramica delle novità di HDInsight 4.0.

Questo articolo illustra i passaggi per eseguire la migrazione dei carichi di lavoro Hive da HDInsight 3.6 a 4.0, tra cui

  • Aggiornamento della copia e dello schema del metastore Hive
  • migrazione Cassaforte per la compatibilità ACID
  • Conservazione dei criteri di sicurezza hive

I cluster HDInsight nuovi e precedenti devono avere accesso agli stessi account Archiviazione.

La migrazione delle tabelle Hive a un nuovo account di Archiviazione deve essere eseguita come passaggio separato. Vedere Migrazione hive tra account Archiviazione.

Modifiche in Hive 3 e novità:

Modifiche del client Hive

Hive 3 supporta solo il thin client, Beeline per l'esecuzione di query e comandi amministrativi Hive dalla riga di comando. Beeline usa una connessione JDBC a HiveServer per eseguire tutti i comandi. L'analisi, la compilazione e l'esecuzione di operazioni si verificano in HiveServer.

È possibile immettere i comandi dell'interfaccia della riga di comando di Hive supportati richiamando Beeline usando la parola chiave Hive come utente Hive o richiamando una beeline usando beeline -u <JDBC URL>. È possibile ottenere l'URL JDBC dalla pagina Hive di Ambari.

Screenshot showing JDBC URL output.

Usare Beeline (anziché l'interfaccia della riga di comando Hive client spessa, che non è più supportata) presenta diversi vantaggi, tra cui:

  • Anziché mantenere l'intera codebase Hive, è possibile gestire solo il client JDBC.
  • Il sovraccarico di avvio è inferiore usando Beeline perché l'intera codebase Hive non è coinvolta.

È anche possibile eseguire lo script Hive, che si trova nella directory "/usr/bin", che richiama una connessione beeline usando l'URL JDBC.

Screenshot showing beeline connection output.

Un'architettura thin client facilita la protezione dei dati in

  • Stato sessione, strutture di dati interne, password e così via, risiedono nel client anziché nel server.
  • Il numero ridotto di daemon necessari per eseguire query semplifica il monitoraggio e il debug.

HiveServer applica le impostazioni allowlist e blocklist che è possibile modificare usando SET i comandi. Usando gli elenchi di blocchi, è possibile limitare la configurazione della memoria per evitare l'instabilità di Hive Server. È possibile configurare più istanze di HiveServer con elenchi di elementi consentiti e elenchi di blocchi diversi per stabilire diversi livelli di stabilità.

Modifiche al metastore Hive

Hive supporta ora solo un metastore remoto anziché un metastore incorporato (all'interno di JVM HS2). Il metastore Hive si trova in un nodo in un cluster gestito da Ambari come parte dello stack HDInsight. Un server autonomo all'esterno del cluster non è supportato. I comandi key=value non vengono più impostati nella riga di comando per configurare Metastore Hive. In base al valore configurato in "hive.metastore.uris=' " servizio HMS usato e stabilito la connessione.

Modifica del motore di esecuzione

Apache Tez sostituisce MapReduce come motore di esecuzione Hive predefinito. MapReduce è deprecato a partire da Hive 2.0 Refer HIVE-12300. Con espressioni di grafici aciclici diretti (DAG) e primitive di trasferimento dei dati, l'esecuzione di query Hive in Tez migliora le prestazioni. Le query SQL inviate a Hive vengono eseguite nel modo seguente

  1. Hive compila la query.
  2. Tez esegue la query.
  3. YARN alloca le risorse per le applicazioni nel cluster e abilita l'autorizzazione per i processi Hive nelle code YARN.
  4. Hive aggiorna i dati in ABFS o WASB.
  5. Hive restituisce i risultati della query su una connessione JDBC.

Se uno script o un'applicazione legacy specifica MapReduce per l'esecuzione, si verifica un'eccezione come indicato di seguito

Screenshot showing map reducer exception output.

Nota

La maggior parte delle funzioni definite dall'utente (UDF) non richiede alcuna modifica per l'esecuzione in Tez anziché in MapReduce.

Modifiche relative alla transazione ACID e al CBO:

  • Le tabelle ACID sono il tipo di tabella predefinito in HDInsight 4.x senza prestazioni o overload operativo.

  • Sviluppo semplificato di applicazioni, operazioni con garanzie transazionali più avanzate e semantica più semplice per i comandi SQL

  • Hive interno si occupa del bucket per le tabelle ACID in HDInsight 4.1, eliminando così il sovraccarico di manutenzione.

  • Ottimizzazioni avanzate : aggiornamento nell'oggetto CBO

  • Cache query automatica. La proprietà utilizzata per abilitare la memorizzazione nella cache delle query è hive.query.results.cache.enabled. È necessario impostare questa proprietà su true. Hive archivia la cache dei risultati della query in /tmp/hive/__resultcache__/. Per impostazione predefinita, Hive alloca 2 GB per la cache dei risultati della query. È possibile modificare questa impostazione configurando il parametro seguente in byte hive.query.results.cache.max.size.

    Per altre informazioni, vantaggi della migrazione ad Azure HDInsight 4.0.

Riscrittura delle visualizzazioni materializzate

Per altre informazioni, vedere Hive - Viste materializzate

Modifiche dopo l'aggiornamento ad Apache Hive 3

Per individuare e usare le tabelle Apache Hive 3 dopo un aggiornamento, è necessario comprendere le modifiche che si verificano durante il processo di aggiornamento. Modifiche alla gestione e alla posizione delle tabelle, alle autorizzazioni per directory di tabella, tipi di tabella e problemi di conformità ACID.

Gestione hive di tabelle

Hive 3 accetta più controllo delle tabelle rispetto a Hive 2 e richiede che le tabelle gestite rispettino una definizione rigorosa. Il livello di controllo che Hive assume le tabelle è omogeneo ai database tradizionali. Hive è consapevole delle modifiche differenziali apportate ai dati; questo framework di controllo migliora le prestazioni.

Ad esempio, se Hive sa che la risoluzione di una query non richiede l'analisi delle tabelle per i nuovi dati, Hive restituisce i risultati dalla cache dei risultati della query Hive. Quando i dati sottostanti in una visualizzazione materializzata cambiano, Hive deve ricompilare la vista materializzata. Le proprietà ACID rivelano esattamente le righe modificate e devono essere elaborate e aggiunte alla vista materializzata.

Modifiche di Hive alle proprietà ACID

Hive 2.x e 3.x hanno tabelle transazionali(gestite) e non transazionali (esterne). Le tabelle transazionali hanno proprietà atomica, coerente, di isolamento e durevole (ACID). In Hive 2.x la versione iniziale dell'elaborazione delle transazioni ACID è ACID v1. In Hive 3.x le tabelle predefinite sono con ACID v2.

Formati di archiviazione nativi e non nativi

Archiviazione formati sono un fattore fondamentale per l'aggiornamento ai tipi di tabella. Hive 2.x e 3.x supporta i formati di archiviazione nativi e non nativi seguenti di Hadoop

Nativo: tabelle con supporto predefinito in Hive, nei formati di file seguenti

  • Testo
  • File di sequenza
  • RC File
  • AVRO File
  • ORC File
  • Parquet File

Non nativo: tabelle che usano un gestore di archiviazione, ad esempio Druid Archiviazione Handler o HBase Archiviazione Handler

Aggiornamento di HDInsight 4.x ai tipi di tabella

La tabella seguente confronta i tipi di tabella Hive e le operazioni ACID prima di un aggiornamento da HDInsight 3.x e dopo un aggiornamento a HDInsight 4.x. La proprietà del file di tabella Hive è un fattore per determinare i tipi di tabella e le operazioni ACID dopo l'aggiornamento

Confronto tra tipi di tabella di HDInsight 3.x e HDInsight 4.x

HDInsight 3.x - - - HDInsight 4.x -
Tipo di tabella ACID v1 Formatta Proprietario (utente) del file di tabella Hive Tipo di tabella ACID v2
Esterna No Nativo o non nativo Hive o non Hive Esterna No
Gestito Sì ORC Hive o non Hive Gestito, aggiornabile Sì
Gestito No ORC Hive Gestito, aggiornabile Sì
Gestito No ORC non Hive Esterno, con eliminazione dei dati NO
Gestito No Nativo (ma non ORC) Hive Gestito, solo inserimento Sì
Gestito No Nativo (ma non ORC) non Hive Esterno, con eliminazione dei dati No
Gestito No Non nativo Hive o non Hive Esterno, con eliminazione dei dati No

Rappresentazione hive

La rappresentazione hive è stata abilitata per impostazione predefinita in Hive 2 (doAs=true) e disabilitata per impostazione predefinita in Hive 3. La rappresentazione hive esegue Hive come utente finale o meno.

Altre modifiche all'aggiornamento di HDInsight 4.x

  1. Le tabelle ACID gestite non di proprietà dell'utente Hive rimangono tabelle gestite dopo l'aggiornamento, ma Hive diventa il proprietario.
  2. Dopo l'aggiornamento, il formato di una tabella Hive è uguale a quello precedente all'aggiornamento. Ad esempio, le tabelle native o non native rimangono rispettivamente native o non native.

Modifiche alla posizione

Dopo l'aggiornamento, il percorso delle tabelle gestite o delle partizioni non cambia in una delle condizioni seguenti:

  • La directory della tabella o della partizione precedente non era nella posizione predefinita /apps/hive/warehouse prima dell'aggiornamento.
  • La tabella o la partizione precedente si trova in un file system diverso rispetto alla nuova directory del warehouse.
  • La directory della tabella o della partizione precedente si trova in una zona di crittografia diversa rispetto alla nuova directory del warehouse.

In caso contrario, la posizione delle tabelle gestite o delle partizioni cambia. Il processo di aggiornamento sposta i file gestiti in /hive/warehouse/managed. Per impostazione predefinita, Hive inserisce tutte le nuove tabelle esterne create in HDInsight 4.x in /hive/warehouse/external

, /apps/hive directoryche è la posizione precedente del warehouse Hive 2.x, potrebbe o non esistere in HDInsight 4.x

Gli scenari seguenti sono presenti per le modifiche alla posizione

Scenario 1

Se la tabella è una tabella gestita in HDInsight-3.x e se è presente nella posizione /apps/hive/warehouse e convertita come tabella esterna in HDInsight-4.x, anche la posizione è la stessa /apps/hive/warehouse in HDInsight 4.x. Non cambia posizione. Dopo questo passaggio, se si esegue il comando alter table per convertirlo come tabella gestita (acid) in quel momento presente nella stessa posizione /apps/hive/warehouse.

Scenario 2

Se la tabella è una tabella gestita in HDInsight-3.x e se è presente nella posizione /apps/hive/warehouse e convertita in tabella gestita (ACID) in HDInsight 4.x, il percorso è /hive/warehouse/managed.

Scenario 3 Se si sta creando una tabella esterna, in HDInsight-4.x senza specificare alcun percorso, viene visualizzato nel percorso /hive/warehouse/external.

Conversione di tabelle

Dopo l'aggiornamento, per convertire una tabella non transazionale in una tabella transazionale ACID v2, usare il ALTER TABLE comando e impostare le proprietà della tabella in

transaction'='true' and 'EXTERNAL'='false
  • La tabella gestita, il formato NON ACID, ORC e di proprietà dell'utente non Hive in HDInsight-3.x verrà convertito in una tabella esterna non ACID in HDInsight-4.x.
  • Se l'utente desidera modificare la tabella esterna (non ACID) in ACID, è necessario modificare anche la tabella esterna in gestita e ACID. Poiché in HDInsight-4.x tutte le tabelle gestite sono rigorosamente ACID per impostazione predefinita. Non è possibile convertire le tabelle esterne (non ACID) nella tabella ACID.

Nota

La tabella deve essere una tabella ORC.

Per convertire una tabella esterna (non ACID) in tabella gestita (ACID),

  1. Convertire una tabella esterna in una tabella gestita e acid uguale a true usando il comando seguente: 
    alter table <table name> set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
  2. Se si tenta di eseguire il comando seguente per la tabella esterna, viene visualizzato l'errore seguente.

Scenario 1

Si consideri la tabella rt esterna (non ACID). Se la tabella è non 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

Scenario 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)

Questo errore si verifica perché la tabella rt è una tabella esterna e non è possibile convertire la tabella esterna in ACID.

Scenario 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)

In questo caso si sta tentando di modificare prima la tabella esterna in tabella gestita. In HDInsight 4.x deve essere una tabella strettamente gestita (il che significa che deve essere ACID). Quindi, qui si ottiene un deadlock. L'unico modo per convertire la tabella esterna (NON_ACID) in gestita (ACID) è necessario seguire il comando :

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

Sintassi e semantica

  • Creazione di una tabella Per migliorare l'usabilità e la funzionalità, la creazione di tabelle modificate di Hive 3. La creazione di tabelle hive è stata modificata nei modi seguenti

    • Crea una tabella conforme a ACID, che è l'impostazione predefinita in HDP
    • Supporta scritture e inserimenti semplici
    • Scritture in più partizioni
    • Inserisce più aggiornamenti dei dati in una singola istruzione edizione Standard LECT
    • Elimina la necessità di bucket.

    Se si dispone di una pipeline ETL che crea tabelle in Hive, le tabelle vengono create come ACID. Hive ora controlla strettamente l'accesso ed esegue periodicamente la compattazione nelle tabelle

    Prima di eseguire l'aggiornamento in HDInsight 3.x, per impostazione predefinita CREATE TABLE ha creato una tabella non ACID.

    Dopo l'aggiornamento per impostazione predefinita CREATE TABLE crea una tabella transazionale ACID completa in formato ORC.

    Azione necessaria per accedere alle tabelle ACID Hive da Spark, connettersi a Hive usando hive Warehouse Connessione or (HWC). Per scrivere tabelle ACID in Hive da Spark, usare l'API HWC e HWC

  • db.table Escape dei riferimenti

    È necessario modificare le query che usano riferimenti db.table per impedire a Hive di interpretare l'intera stringa db.table come nome della tabella. Hive 3.x rifiuta db.table nelle query SQL. Un punto (.) non è consentito nei nomi delle tabelle. Racchiudere il nome del database e il nome della tabella in backticks. Trovare una tabella con riferimento alla tabella problematica. math.students visualizzato in un'istruzione CREATE TABLE. Racchiudere il nome del database e il nome della tabella in backticks.

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

  • Cast dei risultati TIMESTAMPS delle applicazioni che esestituiscono numeri a timestamp differiscono da Hive 2 a Hive 3. Apache Hive ha modificato il comportamento di CAST in modo che sia conforme allo standard SQL, che non associa un fuso orario al tipo TIMESTAMP.

    Prima di eseguire l'aggiornamento del cast di un valore di tipo numerico in un timestamp, è possibile usare per produrre un risultato che riflette il fuso orario del cluster. Ad esempio, 1597217764557 è 2020-08-12 00:36:04 PDT. L'esecuzione della query seguente esegue il cast del valore numerico a un timestamp in PDT: SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 00:36:04 |

    Dopo l'aggiornamento, il cast di un valore di tipo numerico in un timestamp produce un risultato che riflette l'ora UTC anziché il fuso orario del cluster. L'esecuzione della query esegue il cast del valore numerico a un timestamp in formato UTC. SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 07:36:04.557 |

    Azione Richiesta modifica applicazioni. Non eseguire il cast da un numero per ottenere un fuso orario locale. Le funzioni predefinite from_utc_timestamp e to_utc_timestamp possono essere usate per simulare il comportamento prima dell'aggiornamento.

  • VERIFICA DELLA COMPATIBILITÀ DELLE MODIFICHE DI COLONNA Una modifica di configurazione predefinita può causare l'esito negativo delle applicazioni che modificano i tipi di colonna.

    Prima dell'aggiornamento in HDInsight 3.x Hive.metastore.disallow.incompatible.col.type.changes è false per impostazione predefinita per consentire modifiche ai tipi di colonna incompatibili. Ad esempio, è possibile modificare una colonna STRING in una colonna di un tipo incompatibile, ad esempio MAP<STRING, STRING>. Non si verifica alcun errore.

    Dopo l'aggiornamento, hive.metastore.disallow.incompatible.col.type.changes è true per impostazione predefinita. Hive impedisce modifiche ai tipi di colonna incompatibili. Le modifiche ai tipi di colonna compatibili, ad esempio INT, STRING, BIGINT, non vengono bloccate.

    Azione Richiesta Modifica applicazioni per impedire modifiche al tipo di colonna incompatibili per evitare possibili danneggiamenti dei dati.

  • ELIMINAZIONE DI PARTIZIONI

    Le parole chiave OFFLINE e NO_DROP nella clausola CASCADE per l'eliminazione delle partizioni causano problemi di prestazioni e non sono più supportate.

    Prima dell'aggiornamento è possibile usare le parole chiave OFFLINE e NO_DROP nella clausola CASCADE per impedire la lettura o l'eliminazione delle partizioni.

    Dopo l'aggiornamento OFFLINE e NO_DROP non sono supportati nella clausola CASCADE.

    Azione Richiesta modifica applicazioni per rimuovere OFFLINE e NO_DROP dalla clausola CASCADE. Usare uno schema di autorizzazione, ad esempio Ranger, per impedire che le partizioni vengano eliminate o lette.

  • RIDENOMINAZIONE DI UNA TABELLA Dopo che l'aggiornamento Ridenominazione di una tabella gestita sposta la posizione solo se la tabella viene creata senza una LOCATION clausola e si trova nella directory del database.

Limitazioni relative all'oggetto CBO

  • Si noterà che l'output di selezione fornisce zero finale in poche colonne. Ad esempio, se è presente una colonna di tabella con tipo di dati decimal(38,4) e se si inseriscono dati come 38, aggiunge lo zero finale e fornisce il risultato come 38,0000 come per https://issues.apache.org/jira/browse/HIVE-12063 e https://issues.apache.org/jira/browse/HIVE-24389, l'idea viene mantenuta la scala e la precisione invece di eseguire un wrapper nelle colonne decimali. Si tratta del comportamento predefinito di Hive 2. Per risolvere questo problema, è possibile seguire l'opzione seguente.

    1. Modificare il tipo di dati a livello di origine per regolare la precisione come col1(decimal(38,0)). Questo valore fornisce il risultato come 38 senza zero finale. Tuttavia, se si inseriscono i dati come 35.0005, è .0005 e fornisce solo il valore 38 1.Rimuovere gli zeri finali per le colonne con problema e quindi eseguire il cast in stringa,
      1. Usare select TRIM(cast(<column_name> AS STRING)+0 FROM <table_name>;
      2. Usare regex.

  1. La query Hive ha esito negativo con "Espressione SubQuery non supportata" quando si usa UNIX_TIMESTAMP nella query. Ad esempio, se si esegue una query, viene generato un errore "Espressione SubQuery non supportata"

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

    Il caso radice di questo problema è che la codebase Hive corrente genera un'eccezione che analizza il UNIX_TIMESTAMP perché non esiste alcun mapping di precisione per HiveTypeSystemImpl.java code la precisione di UNIX_TIMESTAMP cui Calcite riconosce come BIGINT. Tuttavia, la query seguente funziona correttamente select * from (SELECT col_1 from table1 where col_2 >= 1);

    Questo comando viene eseguito correttamente perché col_2 è un numero intero. Il problema precedente è stato risolto in hdi-3.1.2-4.1.12(stack 4.1) e hdi-3.1.2-5.0.8(stack 5.0)

Passaggi per eseguire l'aggiornamento

1. Preparare i dati

  • HDInsight 3.6 per impostazione predefinita non supporta le tabelle ACID. Se tuttavia sono presenti tabelle ACID, eseguire la compattazione 'MAJOR'. Per informazioni dettagliate sulla compattazione, vedere Manuale del linguaggio Hive.

  • Se si usa Azure Data Lake Archiviazione Gen1, le posizioni delle tabelle Hive dipendono probabilmente dalle configurazioni HDFS del cluster. Eseguire l'azione script seguente per rendere questi percorsi portabili in altri cluster. Vedere Azione script in un cluster in esecuzione.

    Proprietà valore
    URI script Bash https://hdiconfigactions.blob.core.windows.net/linuxhivemigrationv01/hive-adl-expand-location-v01.sh
    Tipo/i di nodo Head
    Parametri

2. Copiare il database SQL

  • Se il cluster usa un metastore Hive predefinito, seguire questa guida per esportare i metadati in un metastore esterno. Creare quindi una copia del metastore esterno per l'aggiornamento.

  • Se il cluster usa un metastore Hive esterno, crearne una copia. Le opzioni includono esportazione/importazione e ripristino temporizzato.

3. Aggiornare lo schema del metastore

Questo passaggio usa da Hive Schema Tool HDInsight 4.0 per aggiornare lo schema del metastore.

Avviso

Questo passaggio non è reversibile. Eseguire questa operazione solo in una copia del metastore.

  1. Creare un cluster HDInsight 4.0 temporaneo per accedere a Hive schematool4.0. Per questo passaggio è possibile usare il metastore Hive predefinito.

  2. Dal cluster HDInsight 4.0 eseguire schematool per aggiornare il metastore HDInsight 3.6 di destinazione. Modificare lo script della shell seguente per aggiungere il nome del server SQL, il nome del database, il nome utente e la password. Aprire una sessione SSH nel nodo head ed eseguirla.

    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

    Questa utilità usa il client beeline per eseguire script SQL in /usr/hdp/$STACK_VERSION/hive/scripts/metastore/upgrade/mssql/upgrade-*.mssql.sql.

    La sintassi SQL in questi script non è necessariamente compatibile con altri strumenti client. Ad esempio, SSMS e Editor di query nel portale di Azure richiedono la parola chiave GO dopo ogni comando.

    Se uno script ha esito negativo a causa di timeout della capacità delle risorse o delle transazioni, aumentare le database SQL.

  3. Verificare la versione finale con la query select schema_version from dbo.version.

    L'output deve corrispondere a quello del comando bash seguente dal 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. Eliminare il cluster HDInsight 4.0 temporaneo.

4. Distribuire un nuovo cluster HDInsight 4.0

Creare un nuovo cluster HDInsight 4.0, selezionando il metastore Hive aggiornato e gli stessi account Archiviazione.

  • Il nuovo cluster non richiede lo stesso file system predefinito.

  • Se il metastore contiene tabelle che risiedono in più account Archiviazione, è necessario aggiungere tali account Archiviazione al nuovo cluster per accedere a tali tabelle. Vedere Aggiungere altri account Archiviazione a HDInsight.

  • Se i processi Hive hanno esito negativo a causa dell'inaccessibilità dell'archiviazione, verificare che la posizione della tabella si trova in un account Archiviazione aggiunto al cluster.

    Usare il comando Hive seguente per identificare la posizione della tabella:

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

5. Convertire le tabelle per la conformità ACID

Le tabelle gestite devono essere conformi a ACID in HDInsight 4.0. Eseguire strictmanagedmigration in HDInsight 4.0 per convertire tutte le tabelle gestite non ACID in tabelle esterne con proprietà 'external.table.purge'='true'. Eseguire dal nodo head:

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. La classe non ha trovato l'errore con MultiDelimitSerDe

Problema

In determinate situazioni durante l'esecuzione di una query Hive, è possibile che venga visualizzato java.lang.ClassNotFoundException un messaggio che indica che org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe la classe non viene trovata. Questo errore si verifica quando il cliente esegue la migrazione da HDInsight 3.6 a HDInsight 4.0. La classe SerDe , che fa parte di hive-contrib-1.2.1000.2.6.5.3033-1.jar in HDInsight 3.6 viene rimossa e viene usata org.apache.hadoop.hive.serde2.MultiDelimitSerDe la classe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe, che fa parte di hive-exec jar HDI-4.0. hive-exec jar verrà caricato in HS2 per impostazione predefinita all'avvio del servizio.

PASSAGGI PER LA RISOLUZIONE DEI PROBLEMI

  1. Controllare se un file JAR in una cartella (probabilmente dovrebbe trovarsi nella cartella delle librerie Hive, che si trova /usr/hdp/current/hive/lib in HDInsight) contiene o meno questa classe.
  2. Controllare la classe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe e org.apache.hadoop.hive.serde2.MultiDelimitSerDe come indicato nella soluzione.

Soluzione

  1. Anche se un file JAR è un file binario, è comunque possibile usare il grep comando con -Hrni opzioni come indicato di seguito per cercare un nome di classe specifico

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

  2. Se non è stato possibile trovare la classe, non restituirà alcun output. Se trova la classe in un file JAR, restituirà l'output

  3. Di seguito è riportato l'esempio preso dal 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. Dall'output precedente è possibile verificare che nessun file JAR contenga la classe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe e il file jar hive-exec contenga org.apache.hadoop.hive.serde2.MultiDelimitSerDe.

  5. Provare a creare la tabella con il formato di riga DerDe come ROW FORMAT SERDE org.apache.hadoop.hive.serde2.MultiDelimitSerDe

  6. Questo comando risolverà il problema. Se la tabella è già stata creata, è possibile rinominarla usando i comandi seguenti

    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';

Il comando di aggiornamento consiste nell'aggiornare manualmente i dettagli nel database back-end e il comando alter viene usato per modificare la tabella con la nuova classe SerDe da beeline o Hive.

Confronto dello schema del database back-end Hive

Dopo aver completato la migrazione, è possibile eseguire lo script seguente.

È possibile che nel database back-end manchino poche colonne, che causano errori di query. Se l'aggiornamento dello schema non è stato eseguito correttamente, è possibile che si verifichi il problema relativo al nome della colonna non valido. Lo script seguente recupera il nome della colonna e il tipo di dati dal database back-end del cliente e fornisce l'output se è presente una colonna mancante o un tipo di dati non corretto.

Il percorso seguente contiene il file schemacompare_final.py e test.csv. Lo script è presente nel file "schemacompare_final.py" e il file "test.csv" contiene tutto il nome della colonna e il tipo di dati per tutte le tabelle, che devono essere presenti nel database back-end hive.

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

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

Scaricare questi due file dal collegamento. Copiare questi file in uno dei nodi head in cui è in esecuzione il servizio Hive.

Passaggi per eseguire lo script:

Creare una directory denominata "schemacompare" nella directory "/tmp".

Inserire "schemacompare_final.py" e "test.csv" nella cartella "/tmp/schemacompare". Eseguire "ls -ltrh /tmp/schemacompare/" e verificare se i file sono presenti.

Per eseguire lo script Python, usare il comando "python schemacompare_final.py". Questo script inizia a eseguire lo script e il completamento richiede meno di cinque minuti. Lo script precedente si connette automaticamente al database back-end e recupera i dettagli da ogni tabella, che Hive usa e aggiorna i dettagli nel nuovo file CSV denominato "return.csv". Dopo aver creato il file return.csv, confronta i dati con il file "test.csv" e stampa il nome della colonna o il tipo di dati se manca qualcosa nel nome tabella.

Dopo aver eseguito lo script, è possibile visualizzare le righe seguenti, che indicano che i dettagli vengono recuperati per le tabelle e lo script è in corso

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

Ed è possibile visualizzare i dettagli della differenza nella riga "DETTAGLI DIFFERENZA:". Se c'è una differenza, stampa

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 non sono presenti differenze nella tabella, l'output è

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

Da questo output è possibile trovare i nomi di colonna mancanti o non corretti. È possibile eseguire la query seguente nel database back-end per verificare una volta se la colonna è mancante o meno.

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

Nel caso in cui una delle colonne non venga rilevata nella tabella, ad esempio, se si eseguono query come insert o insert overwrite, le statistiche verranno calcolate automaticamente e tenta di aggiornare la tabella delle statistiche, ad esempio PART_COL_STATS e TAB_COL_STATS. Se la colonna come "BIT_VECTOR" non è presente nelle tabelle, l'errore "Nome colonna non valido" avrà esito negativo. È possibile aggiungere la colonna come indicato nei comandi seguenti. Come soluzione alternativa è possibile disabilitare le statistiche impostando le proprietà seguenti, che non possono aggiornare le statistiche nel database 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);

Questo passaggio evita gli errori di query, che hanno esito negativo con "Nome colonna non valido" una volta dopo la migrazione.

Proteggere Hive tra le versioni di HDInsight

HDInsight si integra facoltativamente con Microsoft Entra ID usando HDInsight Enterprise Security Package (ESP). ESP usa Kerberos e Apache Ranger per gestire le autorizzazioni di risorse specifiche all'interno del cluster. I criteri ranger distribuiti in Hive in HDInsight 3.6 possono essere migrati in HDInsight 4.0 seguendo questa procedura:

  1. Passare al pannello Ranger Service Manager nel cluster HDInsight 3.6.
  2. Passare al criterio denominato HIVE ed esportare i criteri in un file JSON.
  3. Assicurarsi che tutti gli utenti a cui si fa riferimento nel file JSON dei criteri esportati esistano nel nuovo cluster. Se un utente fa riferimento al codice JSON dei criteri ma non esiste nel nuovo cluster, aggiungere l'utente al nuovo cluster o rimuovere il riferimento dai criteri.
  4. Passare al pannello Ranger Service Manager nel cluster HDInsight 4.0.
  5. Passare al criterio denominato HIVE e importare il file JSON dei criteri ranger dal passaggio 2.

Modifiche di Hive in HDInsight 4.0 che potrebbero richiedere modifiche all'applicazione

  • Vedere Configurazione aggiuntiva con Hive Warehouse Connessione or per la condivisione del metastore tra Spark e Hive per le tabelle ACID.

  • HDInsight 4.0 usa l'autorizzazione basata su Archiviazione. Se si modificano le autorizzazioni per i file o si creano cartelle come utente diverso da Hive, è probabile che si verifichino errori Hive in base alle autorizzazioni di archiviazione. Per risolvere il problema, concedere rw- l'accesso all'utente. Vedere La Guida alle autorizzazioni di HDFS.

  • HiveCLI viene sostituito con Beeline.

Per altre modifiche, vedere Annuncio di HDInsight 4.0.

Dopo la migrazione

Assicurarsi di seguire questi passaggi dopo aver completato la migrazione.

Sanità tabella

  1. Ricreare le tabelle in Hive 3.1 usando CTAS o IOW per modificare il tipo di tabella anziché modificare le proprietà della tabella.
  2. Mantenere i doA come false.
  3. Assicurarsi che la proprietà della tabella/dei dati gestita sia con l'utente "hive".
  4. Usare tabelle ACID gestite se il formato di tabella è ORC e non ACID gestito per i tipi non ORC.
  5. Rigenerare le statistiche sulle tabelle ricreate perché la migrazione avrebbe causato statistiche errate.

Integrità cluster

Se più cluster condividono lo stesso database di archiviazione e HMS, è necessario abilitare i thread di compattazione/compattazione automatica solo in un cluster e disabilitarli ovunque.

Ottimizzare Metastore per ridurre l'utilizzo della CPU.

  1. Disabilitare i listener di eventi transazionali.

    Nota

    Eseguire i passaggi seguenti, solo se la funzionalità di replica hive non viene usata.

    1. Dall'interfaccia utente di Ambari rimuovere il valore per hive.metastore.transactional.event.listener.
    2. Valore predefinito: org.apache.hive.hcatalog.listener.DbNotificationListener
    3. Nuovo valore: <Empty>

  2. Disabilitare Hive PrivilegeSynchronizer

    1. Dall'interfaccia utente di Ambari impostare hive.privilege.synchronizer = false.
    2. Valore predefinito: true
    3. Nuovo valore: false

  3. Ottimizzare la funzionalità di ripristino della partizione

  4. Disabilita ripristino partizione: questa funzionalità viene usata per sincronizzare le partizioni delle tabelle Hive nel percorso di archiviazione con il metastore Hive. È possibile disabilitare questa funzionalità se viene usato "msck repair" dopo l'inserimento dei dati.

  5. Per disabilitare la funzionalità aggiungere "discover.partitions=false" nelle proprietà della tabella tramite ALTER TABLE. OR (se la funzionalità non può essere disabilitata)

  6. Aumentare la frequenza di ripristino della partizione.

  7. Dall'interfaccia utente di Ambari aumentare il valore di "metastore.partition.management.task.frequency" (in secondi).

    Nota

    Questa modifica può ritardare la visibilità di alcune partizioni inserite nell'archiviazione.

    1. Valore predefinito: 60
    2. Valore proposto: 3600

  8. Ottimizzazioni avanzate Le opzioni seguenti devono essere testate in un ambiente inferiore (non prod) prima di applicarle all'ambiente di produzione.

    1. Rimuovere il listener correlato alla visualizzazione materializzata se la visualizzazione materializzata non viene usata.
    2. Dall'interfaccia utente di Ambari aggiungere una proprietà personalizzata (in hive-site.xml personalizzato) e rimuovere i thread del metastore in background indesiderati.
    3. Nome proprietà: metastore.task.threads.remote
    4. Valore predefinito: N/A (it uses few class names internally)
    5. Nuovo valore: 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. Disabilitare i thread in background se la replica è disabilitata.

    1. Dall'interfaccia utente di Ambari aggiungere una proprietà personalizzata (in hive-site.xml personalizzato) e rimuovere i thread indesiderati.
    2. Nome proprietà: metastore.task.threads.always
    3. Valore predefinito: N/A (it uses few class names internally)
    4. Nuovo valore: org.apache.hadoop.hive.metastore.RuntimeStatsCleanerTask

Ottimizzazione query

  1. Mantenere le configurazioni predefinite di Hive per eseguire le query durante l'ottimizzazione per i carichi di lavoro TPC-DS. È necessaria l'ottimizzazione a livello di query solo se ha esito negativo o in esecuzione lenta.
  2. Assicurarsi che le statistiche siano aggiornate per evitare un piano non valido o risultati errati.
  3. Evitare di combinare tabelle ACID esterne e gestite nel tipo di join di query. In tal caso, provare a convertire esterno in tabella non ACID gestita tramite ricreazione.
  4. In Hive-3 è stato eseguito un sacco di lavoro sulla vettorializzazione, CBO, timestamp con zona e così via, che potrebbero avere bug del prodotto. Pertanto, se una query restituisce risultati errati, provare a disabilitare la vettorializzazione, l'oggetto CBO, il mapping-join e così via, per verificare se ciò è utile.

Altri passaggi da seguire per correggere i risultati non corretti e prestazioni scarse dopo la migrazione

  1. Il problema della query Hive restituisce il risultato non corretto. Anche la query select count(*) restituisce il risultato non corretto.

    Causa La proprietà "hive.compute.query.using.stats" è impostata su true per impostazione predefinita. Se viene impostato su true, usa le statistiche archiviate nel metastore per eseguire la query. Se le statistiche non sono aggiornate, vengono restituiti risultati non corretti.

    La risoluzione raccoglie le statistiche per le tabelle gestite usando alter table <table_name> compute statics; il comando a livello di tabella e di colonna. Collegamento di riferimento - https://cwiki.apache.org/confluence/display/hive/statsdev#StatsDev-TableandPartitionStatistics

  2. L'esecuzione di query Hive richiede molto tempo.

    Causa Se la query ha una condizione di join, hive crea un piano se usare mapping join o merge join in base alle dimensioni della tabella e alla condizione di join. Se una delle tabelle contiene una dimensione ridotta, carica tale tabella nella memoria ed esegue l'operazione di join. In questo modo l'esecuzione della query è più veloce rispetto al join di merge.

    Risoluzione Assicurarsi di impostare la proprietà "hive.auto.convert.join=true", ovvero il valore predefinito. L'impostazione su false usa il merge join e può comportare prestazioni scarse. Hive decide se usare o meno il mapping join in base alle proprietà seguenti, impostate nel 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>;

    Common join può convertire automaticamente il join di mapping quando hive.auto.convert.join.noconditionaltask=true, se le dimensioni stimate di tabelle di piccole dimensioni sono inferiori a quelle dell'hive.auto.convert.join.noconditionaltask.size Il valore predefinito è 10000000 MB.

    Se si verifica un problema correlato all'OOM impostando la proprietà hive.auto.convert.join su true, è consigliabile impostarla su false solo per tale query specifica a livello di sessione e non a livello di cluster. Questo problema può verificarsi se le statistiche sono errate e Hive decide di usare il join mappa in base alle statistiche.

  • Il problema della query Hive restituisce il risultato non corretto se la query ha una condizione di join e le tabelle coinvolte hanno valori Null o vuoti.

    Causa A volte è possibile che si verifichi un problema correlato ai valori Null se le tabelle coinvolte nella query hanno un numero elevato di valori Null. Hive esegue l'ottimizzazione della query in modo errato con i valori Null coinvolti che generano risultati non corretti.

    Risoluzione È consigliabile provare a impostare la proprietà set hive.cbo.returnpath.hiveop=true a livello di sessione se si ottengono risultati non corretti. Questa configurazione introduce un filtro null per le chiavi di join. Se le tabelle hanno molti valori Null, per ottimizzare l'operazione di join tra più tabelle, è possibile abilitare questa configurazione in modo che consideri solo i valori non Null.

  • La query Hive genera un risultato errato se la query presenta più condizioni di join.

    Causa Alcuni minuti in cui Tez produce piani di runtime non valido ogni volta che ci sono gli stessi join più volte con i mapping.Cause Sometime Tez produce piani di runtime non valido ogni volta che sono presenti join multipli con i mapping.

    Risoluzione È possibile ottenere risultati non corretti quando si imposta su hive.merge.nway.joins false. Provare a impostarlo su true solo per la query, che è stata influenzata. Ciò consente di eseguire query con più join nella stessa condizione, unire join in un unico operatore join. Questo metodo è utile se join casuali di grandi dimensioni per evitare una fase di rimshuffle.

  • Problema' C'è un aumento del tempo di esecuzione della query giorno per giorno rispetto alle esecuzioni precedenti.

    Causa Questo problema può verificarsi se si verifica un aumento di un numero maggiore di file di piccole dimensioni. Di conseguenza, hive richiede tempo nella lettura di tutti i file per elaborare i dati, con un aumento del tempo di esecuzione.

    Risoluzione Assicurarsi di eseguire spesso la compattazione per le tabelle, gestite. Questo passaggio evita i file di piccole dimensioni e migliora le prestazioni.

    Collegamento di riferimento: Transazioni Hive - Apache Hive - Apache Software Foundation.

  • La query Hive genera un risultato errato quando il cliente usa una condizione di join nella tabella oc acid gestita e nella tabella non ACID gestita.

    Causa Da HIVE 3 in poi, è strettamente richiesto di mantenere tutte le tabelle gestite come tabella acida. E se vogliamo mantenerlo come tabella acida, il formato della tabella deve essere orc e questo è il criterio principale. Tuttavia, se si disabilita la proprietà della tabella gestita strict "hive.strict.managed.tables" su false, è possibile creare una tabella non ACID gestita. In alcuni casi, il cliente crea una tabella ORC esterna o dopo la migrazione della tabella convertita in una tabella esterna e disabilita la proprietà strict della tabella gestita e la converte in tabella gestita. A questo punto, la tabella convertita in formato orc gestito non ACID.

    L'ottimizzazione hive della risoluzione non va correttamente se si unisce la tabella CON tabella ORC gestita non ACID con tabella orc gestita da acid.

    Se si sta convertendo una tabella esterna in tabella gestita,

    1. Non impostare la proprietà "hive.strict.managed.tables" su false. Se si imposta, è possibile creare una tabella gestita non ACID, ma non è richiesta in HIVE-3
    2. Convertire la tabella esterna in tabella gestita usando il comando alter seguente anziché alter table <table_name> set TBLPROPERTIES ('EXTERNAL'='false');
    alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Guida alla risoluzione dei problemi

La guida alla risoluzione dei problemi da HDInsight 3.6 a 4.0 per i carichi di lavoro Hive offre risposte ai problemi comuni riscontrati durante la migrazione dei carichi di lavoro Hive da HDInsight 3.6 a HDInsight 4.0.

Altre risorse