Dela via

Migrera Azure HDInsight 3.6 Hive-arbetsbelastningar till HDInsight 4.0

  • Artikel

HDInsight 4.0 har flera fördelar jämfört med HDInsight 3.6. Här är en översikt över nyheter i HDInsight 4.0.

Den här artikeln beskriver steg för att migrera Hive-arbetsbelastningar från HDInsight 3.6 till 4.0, inklusive

  • Kopiering och schemauppgradering av Hive-metaarkiv
  • Valv migrering för ACID-kompatibilitet
  • Bevarande av Hive-säkerhetsprinciper

De nya och gamla HDInsight-klustren måste ha åtkomst till samma lagringskonton.

Migrering av Hive-tabeller till ett nytt lagringskonto måste göras som ett separat steg. Se Hive-migrering mellan lagringskonton.

Ändringar i Hive 3 och nyheter:

Hive-klientändringar

Hive 3 stöder endast den tunna klienten, Beeline för att köra frågor och Administrativa Hive-kommandon från kommandoraden. Beeline använder en JDBC-anslutning till HiveServer för att köra alla kommandon. Parsning, kompilering och körning av åtgärder sker i HiveServer.

Du anger Hive CLI-kommandon som stöds genom att anropa Beeline med hive-nyckelordet som Hive-användare eller anropa en beeline med .beeline -u <JDBC URL> Du kan hämta JDBC-URL:en från Ambari Hive-sidan.

Screenshot showing JDBC URL output.

Använd Beeline (i stället för den tjocka klienten Hive CLI, som inte längre stöds) har flera fördelar, inklusive:

  • I stället för att underhålla hela Hive-kodbasen kan du endast underhålla JDBC-klienten.
  • Startkostnaderna är lägre med hjälp av Beeline eftersom hela Hive-kodbasen inte ingår.

Du kan också köra Hive-skriptet, som finns under katalogen "/usr/bin", som anropar en beeline-anslutning med JDBC URL.

Screenshot showing beeline connection output.

En tunn klientarkitektur underlättar skydd av data i

  • Sessionstillstånd, interna datastrukturer, lösenord och så vidare finns på klienten i stället för på servern.
  • Det lilla antalet daemoner som krävs för att köra frågor förenklar övervakning och felsökning.

HiveServer tillämpar inställningar för tillåtna listor och blocklistor som du kan ändra med hjälp av SET kommandon. Med hjälp av blockeringslisterna kan du begränsa minneskonfigurationen för att förhindra instabilitet i Hive Server. Du kan konfigurera flera HiveServer-instanser med olika tillåtna listor och blocklistor för att upprätta olika stabilitetsnivåer.

Hive Metastore-ändringar

Hive stöder nu endast ett fjärrmetaarkiv i stället för ett inbäddat metaarkiv (inom HS2 JVM). Hive-metaarkivet finns på en nod i ett kluster som hanteras av Ambari som en del av HDInsight-stacken. En fristående server utanför klustret stöds inte. Du ställer inte längre in key=value-kommandon på kommandoraden för att konfigurera Hive-metaarkivet. Baserat på värdet som konfigurerats i "hive.metastore.uris=" " används och upprättas anslutningen.

Ändring av körningsmotor

Apache Tez ersätter MapReduce som standardmotor för Hive-körning. MapReduce är inaktuell med start av Hive 2.0 Se HIVE-12300. Med uttryck för riktade acykliska grafer (DAG:er) och dataöverföringspri primitiver förbättrar körningen av Hive-frågor under Tez prestanda. SQL-frågor som du skickar till Hive körs på följande sätt

  1. Hive kompilerar frågan.
  2. Tez kör frågan.
  3. YARN allokerar resurser för program i klustret och möjliggör auktorisering för Hive-jobb i YARN-köer.
  4. Hive uppdaterar data i ABFS eller WASB.
  5. Hive returnerar frågeresultat via en JDBC-anslutning.

Om ett äldre skript eller program anger MapReduce för körning sker ett undantag på följande sätt

Screenshot showing map reducer exception output.

Kommentar

De flesta användardefinierade funktioner (UDF: er) kräver ingen ändring för att köra på Tez i stället för MapReduce.

Ändringar med avseende på ACID-transaktioner och CBO:

  • ACID-tabeller är standardtabelltypen i HDInsight 4.x utan prestanda eller driftöverbelastning.

  • Förenklad programutveckling, åtgärder med starkare transaktionsgarantier och enklare semantik för SQL-kommandon

  • Hive internal tar hand om bucketing för ACID-tabeller i HDInsight 4.1, vilket tar bort underhållskostnader.

  • Avancerade optimeringar – Uppgradera i CBO

  • Automatisk frågecache. Egenskapen som används för att aktivera cachelagring av frågor är hive.query.results.cache.enabled. Du måste ange den här egenskapen till true. Hive lagrar frågeresultatcachen i /tmp/hive/__resultcache__/. Som standard allokerar Hive 2 GB för frågeresultatcachen. Du kan ändra den här inställningen genom att konfigurera följande parameter i byte hive.query.results.cache.max.size.

    Mer information finns i Fördelarna med att migrera till Azure HDInsight 4.0.

Materialiserad vyomskrivning

Mer information finns i Hive – Materialiserade vyer

Ändringar efter uppgradering till Apache Hive 3

För att hitta och använda dina Apache Hive 3-tabeller efter en uppgradering måste du förstå de ändringar som sker under uppgraderingsprocessen. Ändringar av hantering och plats för tabeller, behörigheter till tabellkataloger, tabelltyper och ACID-efterlevnadsproblem.

Hive-hantering av tabeller

Hive 3 tar mer kontroll över tabeller än Hive 2 och kräver att hanterade tabeller följer en strikt definition. Kontrollnivån hive tar över tabeller är homogen för de traditionella databaserna. Hive är självmedveten om deltaändringarna i data. det här kontrollramverket förbättrar prestandan.

Om Hive till exempel vet att det inte krävs genomsökningstabeller för nya data för att lösa en fråga returnerar Hive resultat från hive-frågeresultatets cacheminne. När underliggande data i en materialiserad vy ändras måste Hive återskapa den materialiserade vyn. ACID-egenskaper visar exakt vilka rader som har ändrats och måste bearbetas och läggas till i den materialiserade vyn.

Hive-ändringar i ACID-egenskaper

Hive 2.x och 3.x har både transaktionella(hanterade) och icke-transaktionella (externa) tabeller. Transaktionstabeller har egenskaper för atomisk, konsekvent, isolering och varaktig (ACID). I Hive 2.x är den första versionen av ACID-transaktionsbearbetning ACID v1. I Hive 3.x är standardtabellerna med ACID v2.

Interna och icke-inbyggda lagringsformat

Lagringsformat är en faktor vid uppgradering av ändringar i tabelltyper. Hive 2.x och 3.x stöder följande inbyggda och icke-inbyggda Hadoop-lagringsformat

Inbyggt: Tabeller med inbyggt stöd i Hive i följande filformat

  • Text
  • Sekvensfil
  • RC-fil
  • AVRO-fil
  • ORC-fil
  • Parquet-fil

Ej inbyggt: Tabeller som använder en lagringshanterare, till exempel DruidStorageHandler eller HBaseStorageHandler

HDInsight 4.x-uppgradering ändras till tabelltyper

I följande tabell jämförs Hive-tabelltyper och ACID-åtgärder före en uppgradering från HDInsight 3.x och efter en uppgradering till HDInsight 4.x. Ägarskapet för Hive-tabellfilen är en faktor för att fastställa tabelltyper och ACID-åtgärder efter uppgraderingen

Jämförelse av HDInsight 3.x- och HDInsight 4.x-tabelltyp

HDInsight 3.x - - - HDInsight 4.x -
Tabelltyp ACID v1 Format Ägare (användare) av Hive-tabellfil Tabelltyp ACID v2
Externt Inga Inbyggt eller icke-inbyggt Hive eller icke-Hive Externt Inga
Hanterad Ja ORC Hive eller icke-Hive Hanterad, uppdaterad Ja
Hanterad Inga ORC Hive Hanterad, uppdaterad Ja
Hanterad Inga ORC icke-Hive Externt, med databorttagning NEJ
Hanterad Inga Intern (men icke-ORC) Hive Hanterad, infoga endast Ja
Hanterad Inga Intern (men icke-ORC) icke-Hive Externt, med databorttagning Inga
Hanterad Inga Ej inbyggt Hive eller icke-Hive Externt, med databorttagning Inga

Hive-personifiering

Hive-personifiering aktiverades som standard i Hive 2 (doAs=true) och inaktiverades som standard i Hive 3. Hive-personifiering kör Hive som slutanvändare eller inte.

Andra hdinsight 4.x-uppgraderingsändringar

  1. Hanterade ACID-tabeller som inte ägs av Hive-användaren förblir hanterade tabeller efter uppgraderingen, men Hive blir ägare.
  2. Efter uppgraderingen är formatet för en Hive-tabell detsamma som före uppgraderingen. Till exempel förblir interna eller icke-inbyggda tabeller interna respektive icke-inbyggda.

Platsändringar

Efter uppgraderingen ändras inte platsen för hanterade tabeller eller partitioner under något av följande villkor:

  • Den gamla tabellen eller partitionskatalogen fanns inte på standardplatsen /apps/hive/warehouse före uppgraderingen.
  • Den gamla tabellen eller partitionen finns i ett annat filsystem än den nya lagerkatalogen.
  • Den gamla tabellen eller partitionskatalogen finns i en annan krypteringszon än den nya lagerkatalogen.

Annars ändras platsen för hanterade tabeller eller partitioner. Uppgraderingsprocessen flyttar hanterade filer till /hive/warehouse/managed. Som standard placerar Hive alla nya externa tabeller som du skapar i HDInsight 4.x i /hive/warehouse/external

, /apps/hive directorysom är den tidigare platsen för Hive 2.x-lagret, kanske eller kanske inte finns i HDInsight 4.x

Följande scenarion finns för platsändringar

Scenario 1

Om tabellen är en hanterad tabell i HDInsight-3.x och om den finns på platsen /apps/hive/warehouse och konverteras som en extern tabell i HDInsight-4.x, är platsen densamma /apps/hive/warehouse även i HDInsight 4.x. Den ändrar ingen plats. Efter det här steget, om du utför kommandot alter table för att konvertera den som hanterad tabell (syra) vid den tidpunkten på samma plats /apps/hive/warehouse.

Scenario 2

Om tabellen är en hanterad tabell i HDInsight-3.x och om den finns på platsen /apps/hive/warehouse och konverteras till en hanterad tabell (ACID) i HDInsight 4.x är /hive/warehouse/managedplatsen .

Scenario 3 Om du skapar en extern tabell i HDInsight-4.x utan att ange någon plats visas den på platsen /hive/warehouse/external.

Tabellkonvertering

När du har uppgraderat för att konvertera en icke-transaktionell tabell till en ACID v2-transaktionstabell använder ALTER TABLE du kommandot och anger tabellegenskaper till

transaction'='true' and 'EXTERNAL'='false
  • Den hanterade tabellen, icke-ACID, ORC-format och ägs av icke-Hive-användare i HDInsight-3.x konverteras till extern, icke-ACID-tabell i HDInsight-4.x.
  • Om användaren vill ändra den externa tabellen (icke-ACID) till ACID bör de också ändra den externa tabellen till hanterad och ACID. Eftersom i HDInsight-4.x är alla hanterade tabeller strikt ACID som standard. Du kan inte konvertera de externa tabellerna (icke-ACID) till ACID-tabellen.

Kommentar

Tabellen måste vara en ORC-tabell.

Om du vill konvertera en extern tabell (icke-ACID) till en hanterad tabell (ACID)

  1. Konvertera extern tabell till hanterad och syra är lika med sant med hjälp av följande kommando: 
    alter table <table name> set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
  2. Om du försöker köra följande kommando för den externa tabellen visas felet nedan.

Scenario 1

Överväg att tabell rt är extern tabell (icke-ACID). Om tabellen inte är ORC-tabell,

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)

Det här felet uppstår eftersom tabellen rt är en extern tabell och du inte kan konvertera den externa tabellen till 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)

Här försöker vi först ändra den externa tabellen till en hanterad tabell. I HDInsight 4.x ska den vara strikt hanterad tabell (vilket innebär att den ska vara ACID). Så här får du ett dödläge. Det enda sättet att konvertera den externa tabellen (NON_ACID) till hanterad (ACID) måste du följa kommandot:

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

Syntax och semantik

  • Skapa en tabell För att förbättra användningsbarheten och funktionaliteten ändrade Hive 3 tabellskapandet. Hive har ändrat tabellskapandet på följande sätt

    • Skapar ACID-kompatibel tabell, som är standard i HDP
    • Stöder enkla skrivningar och infogningar
    • Skrivningar till flera partitioner
    • Infogar flera datauppdateringar i en enda SELECT-instruktion
    • Eliminerar behovet av bucketing.

    Om du har en ETL-pipeline som skapar tabeller i Hive skapas tabellerna som ACID. Hive kontrollerar nu åtkomsten noggrant och utför komprimering regelbundet på tabellerna

    Före uppgradering i HDInsight 3.x skapade CREATE TABLE som standard en icke-ACID-tabell.

    Efter Uppgradering som standard skapar CREATE TABLE en fullständig ACID-transaktionstabell i ORC-format.

    Åtgärd krävs För att komma åt Hive ACID-tabeller från Spark ansluter du till Hive med Hive Warehouse Anslut or (HWC). Om du vill skriva ACID-tabeller till Hive från Spark använder du HWC- och HWC-API:et

  • Escapeing-referenser db.table

    Du måste ändra frågor som använder db.table-referenser för att förhindra att Hive tolkar hela db.table-strängen som tabellnamn. Hive 3.x avvisar db.table i SQL-frågor. En punkt (.) tillåts inte i tabellnamn. Du omger databasnamnet och tabellnamnet i backticks. Hitta en tabell med den problematiska tabellreferensen. math.students som visas i en CREATE TABLE-instruktion. Omslut databasnamnet och tabellnamnet i backticks.

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

  • CASTING TIMESTAMPS Resultaten av program som gjuter numeriska till tidsstämplar skiljer sig från Hive 2 till Hive 3. Apache Hive ändrade beteendet för CAST för att följa SQL Standard, som inte associerar en tidszon med TIMESTAMP-typen.

    Innan du uppgraderar gjutning kan ett numeriskt typvärde till en tidsstämpel användas för att skapa ett resultat som återspeglade klustrets tidszon. Till exempel är 1597217764557 2020-08-12 00:36:04 PDT. När du kör följande fråga skickas det numeriska till en tidsstämpel i PDT: SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 00:36:04 |

    När du har uppgraderat gjutning av ett numeriskt typvärde till en tidsstämpel genereras ett resultat som återspeglar UTC i stället för klustrets tidszon. När du kör frågan skickas det numeriska till en tidsstämpel i UTC. SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 07:36:04.557 |

    Åtgärd Krävs Ändringsprogram. Kasta inte från ett tal för att hämta en lokal tidszon. Inbyggda funktioner from_utc_timestamp och to_utc_timestamp kan användas för att efterlikna beteende före uppgraderingen.

  • KONTROLLERA KOMPATIBILITETEN FÖR KOLUMNÄNDRINGAR En standardkonfigurationsändring kan leda till att program som ändrar kolumntyper misslyckas.

    Före uppgradering i HDInsight 3.x Hive.metastore.disallow.incompatible.col.type.changes är false som standard för att tillåta ändringar i inkompatibla kolumntyper. Du kan till exempel ändra en STRING-kolumn till en kolumn av en inkompatibel typ, till exempel MAP<STRING, STRING>. Inget fel inträffar.

    Efter uppgraderingen är hive.metastore.disallow.incompatible.col.type.changes true som standard. Hive förhindrar ändringar i inkompatibla kolumntyper. Kompatibla kolumntypsändringar, till exempel INT, STRING, BIGINT, blockeras inte.

    Åtgärd Krävs Ändra program för att inte tillåta inkompatibla kolumntypändringar för att förhindra eventuella skadade data.

  • TA BORT PARTITIONER

    Nyckelorden OFFLINE och NO_DROP i CASCADE-satsen för att släppa partitioner orsakar prestandaproblem och stöds inte längre.

    Före uppgraderingen kan du använda offline- och NO_DROP nyckelord i CASCADE-satsen för att förhindra att partitioner läse eller tas bort.

    Efter uppgradering offline och NO_DROP stöds inte i CASCADE-satsen.

    Åtgärd Krävs Ändra program för att ta bort OFFLINE och NO_DROP från CASCADE-satsen. Använd ett auktoriseringsschema, till exempel Ranger, för att förhindra att partitioner tas bort eller läss.

  • BYT NAMN PÅ EN TABELL Efter uppgraderingen Byter namn på en hanterad tabell flyttas endast dess plats om tabellen skapas utan en LOCATION sats och finns under dess databaskatalog.

Begränsningar med avseende på CBO

  • Vi ser att de valda utdata ger avslutande nollor i några kolumner. Om vi till exempel har en tabellkolumn med datatypen decimal (38,4) och om vi infogar data som 38 lägger den till avslutande nollor och ger resultatet som 38 0000 Per https://issues.apache.org/jira/browse/HIVE-12063 och https://issues.apache.org/jira/browse/HIVE-24389, behålls skalan och precisionen i stället för att köra en omslutning i decimalkolumner. Detta är standardbeteendet från Hive 2. Du kan åtgärda problemet genom att följa nedanstående alternativ.

    1. Ändra datatypen på källnivå för att justera precisionen som col1(decimal(38,0)). Det här värdet ger resultatet som 38 utan att följa nollorna. Men om du infogar data som 35.0005 är det .0005 och ger endast värdet som 38 1.Ta bort avslutande nollor för kolumnerna med problem och casta sedan till strängen.
      1. Använd select TRIM(cast(<column_name> AS STRING))+0 FROM <table_name>;
      2. Använd regex.

  1. Hive-frågan misslyckas med "SubQuery-uttryck som inte stöds" när vi använder UNIX_TIMESTAMP i frågan. Om vi till exempel kör en fråga utlöser den felet "SubQuery-uttryck som inte stöds"

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

    Rotfallet för det här problemet är att den aktuella Hive-kodbasen genererar ett undantag som parsar UNIX_TIMESTAMP eftersom det inte finns någon precisionsmappning för HiveTypeSystemImpl.java code precisionen UNIX_TIMESTAMP som Calcite identifierar som BIGINT. Men frågan nedan fungerar bra select * from (SELECT col_1 from table1 where col_2 >= 1);

    Det här kommandot körs eftersom col_2 är ett heltal. Ovanstående problem har åtgärdats i hdi-3.1.2-4.1.12(4.1 stack) och hdi-3.1.2-5.0.8(5.0 stack)

Steg för att uppgradera

1. Förbereda data

  • HDInsight 3.6 stöder som standard inte ACID-tabeller. Om ACID-tabeller finns kör du dock "MAJOR"-komprimering på dem. Mer information om komprimering finns i Hive Language Manual .

  • Om du använder Azure Data Lake Storage Gen1 är Hive-tabellplatser sannolikt beroende av klustrets HDFS-konfigurationer. Kör följande skriptåtgärd för att göra dessa platser portabla för andra kluster. Se Skriptåtgärd till ett kluster som körs.

    Property Värde
    Bash-skript-URI https://hdiconfigactions.blob.core.windows.net/linuxhivemigrationv01/hive-adl-expand-location-v01.sh
    Nodtyper Head
    Parameters

2. Kopiera SQL-databasen

  • Om klustret använder ett Hive-standardmetaarkiv följer du den här guiden för att exportera metadata till ett externt metaarkiv. Skapa sedan en kopia av det externa metaarkivet för uppgradering.

  • Om klustret använder ett externt Hive-metaarkiv skapar du en kopia av det. Alternativen är export/import och återställning till tidpunkt.

3. Uppgradera metaarkivschemat

Det här steget använder Hive Schema Tool från HDInsight 4.0 för att uppgradera metaarkivschemat.

Varning

Det här steget är inte reversibelt. Kör detta endast på en kopia av metaarkivet.

  1. Skapa ett tillfälligt HDInsight 4.0-kluster för att få åtkomst till 4.0 Hive schematool. Du kan använda hive-standardmetaarkivet för det här steget.

  2. Från HDInsight 4.0-klustret kör du schematool för att uppgradera målets HDInsight 3.6-metaarkiv. Redigera följande gränssnittsskript för att lägga till ditt SQL-servernamn, databasnamn, användarnamn och lösenord. Öppna en SSH-session på huvudnoden och kör den.

    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

    Kommentar

    Det här verktyget använder klienten beeline för att köra SQL-skript i /usr/hdp/$STACK_VERSION/hive/scripts/metastore/upgrade/mssql/upgrade-*.mssql.sql.

    SQL-syntax i dessa skript är inte nödvändigtvis kompatibel med andra klientverktyg. Till exempel kräver SSMS och Power Query-redigeraren på Azure Portal nyckelord GO efter varje kommando.

    Om något skript misslyckas på grund av resurskapacitet eller tidsgränser för transaktioner skalar du upp SQL Database.

  3. Verifiera den slutliga versionen med frågan select schema_version from dbo.version.

    Utdata ska matcha följande bash-kommando från HDInsight 4.0-klustret.

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

  4. Ta bort det tillfälliga HDInsight 4.0-klustret.

4. Distribuera ett nytt HDInsight 4.0-kluster

Skapa ett nytt HDInsight 4.0-kluster och välj det uppgraderade Hive-metaarkivet och samma lagringskonton.

  • Det nya klustret kräver inte samma standardfilsystem.

  • Om metaarkivet innehåller tabeller som finns i flera lagringskonton måste du lägga till dessa lagringskonton i det nya klustret för att få åtkomst till dessa tabeller. Se Lägga till extra lagringskonton i HDInsight.

  • Om Hive-jobb misslyckas på grund av att lagringen inte är tillgänglig kontrollerar du att tabellplatsen finns i ett lagringskonto som har lagts till i klustret.

    Använd följande Hive-kommando för att identifiera tabellplats:

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

5. Konvertera tabeller för ACID-efterlevnad

Hanterade tabeller måste vara ACID-kompatibla i HDInsight 4.0. Kör strictmanagedmigration på HDInsight 4.0 för att konvertera alla icke-ACID-hanterade tabeller till externa tabeller med egenskapen 'external.table.purge'='true'. Kör från huvudnoden:

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. Det gick inte att hitta klassens fel med MultiDelimitSerDe

Problem

I vissa situationer när du kör en Hive-fråga kan du få java.lang.ClassNotFoundException information om att org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe klassen inte hittas. Det här felet uppstår när kunden migrerar från HDInsight 3.6 till HDInsight 4.0. Klassen SerDe org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe, som är en del av hive-contrib-1.2.1000.2.6.5.3033-1.jar i HDInsight 3.6, tas bort och vi använder org.apache.hadoop.hive.serde2.MultiDelimitSerDe klassen, som är en del av hive-exec jar i HDI-4.0. hive-exec jar läses in till HS2 som standard när vi startar tjänsten.

STEG FÖR ATT FELSÖKA

  1. Kontrollera om någon JAR-fil under en mapp (troligtvis ska vara under mappen Hive-bibliotek, som finns /usr/hdp/current/hive/lib i HDInsight) innehåller den här klassen eller inte.
  2. Sök efter klassen org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe och org.apache.hadoop.hive.serde2.MultiDelimitSerDe som nämns i lösningen.

Lösning

  1. Även om en JAR-fil är en binär fil kan du fortfarande använda grep kommandot med -Hrni växlar enligt nedan för att söka efter ett visst klassnamn

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

  2. Om det inte gick att hitta klassen returnerar den inga utdata. Om klassen hittas i en JAR-fil returneras utdata

  3. Nedan visas exemplet från HDInsight 4.x-klustret

    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. Från ovanstående utdata kan vi bekräfta att ingen jar innehåller klassen org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe och hive-exec jar innehåller org.apache.hadoop.hive.serde2.MultiDelimitSerDe.

  5. Försök att skapa tabellen med radformatet DerDe som ROW FORMAT SERDE org.apache.hadoop.hive.serde2.MultiDelimitSerDe

  6. Det här kommandot åtgärdar problemet. Om du redan har skapat tabellen kan du byta namn på den med hjälp av kommandona nedan

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

Uppdateringskommandot är att uppdatera informationen manuellt i serverdelsdatabasen och alter-kommandot används för att ändra tabellen med den nya SerDe-klassen från beeline eller Hive.

Hive Backend DB-schema jämför skript

Du kan köra följande skript när du har slutfört migreringen.

Det finns en risk att det saknas några kolumner i serverdelsdatabasen, vilket orsakar frågefelen. Om schemauppgradering inte utfördes korrekt finns det en risk att vi stöter på det ogiltiga kolumnnamnsproblemet. Skriptet nedan hämtar kolumnnamnet och datatypen från kundens serverdelsdatabas och ger utdata om det saknas en kolumn eller en felaktig datatyp.

Följande sökväg innehåller filen schemacompare_final.py och test.csv. Skriptet finns i filen "schemacompare_final.py" och filen "test.csv" innehåller alla kolumnnamn och datatypen för alla tabeller, som ska finnas i hive-serverdelsdatabasen.

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

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

Ladda ned dessa två filer från länken. Och kopiera dessa filer till en av huvudnoderna där Hive-tjänsten körs.

Steg för att köra skriptet:

Skapa en katalog med namnet "schemacompare" under katalogen "/tmp".

Placera "schemacompare_final.py" och "test.csv" i mappen "/tmp/schemacompare". Gör "ls -ltrh /tmp/schemacompare/" och kontrollera om filerna finns.

Om du vill köra Python-skriptet använder du kommandot "python schemacompare_final.py". Det här skriptet börjar köra skriptet och det tar mindre än fem minuter att slutföra. Skriptet ovan ansluter automatiskt till serverdelsdatabasen och hämtar informationen från varje tabell, som Hive använder och uppdaterar informationen i den nya csv-filen med namnet "return.csv". När du har skapat filen return.csv jämför den data med filen "test.csv" och skriver ut kolumnnamnet eller datatypen om det saknas något under tabellnamnet.

När du har kört skriptet kan du se följande rader, som anger att informationen hämtas för tabellerna och att skriptet pågår

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

Och du kan se skillnadsinformationen under raden "SKILLNADSINFORMATION:". Om det finns någon skillnad skrivs den ut

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.

Om det inte finns några skillnader i tabellen är utdata

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

I de här utdata kan du hitta de kolumnnamn som saknas eller är felaktiga. Du kan köra följande fråga i serverdelsdatabasen för att kontrollera en gång om kolumnen saknas eller inte.

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

Om någon av kolumnerna missas i tabellen, till exempel om vi kör frågor som infoga eller infoga överskrivning, beräknas statistiken automatiskt och försöker uppdatera statistiktabellen som PART_COL_STATS och TAB_COL_STATS. Och om kolumnen som "BIT_VECTOR" saknas i tabellerna misslyckas den med felet "Ogiltigt kolumnnamn". Du kan lägga till kolumnen enligt följande kommandon. Som en lösning kan du inaktivera statistiken genom att ange följande egenskaper, som inte kan uppdatera statistiken i serverdelsdatabasen.

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

Det här steget undviker frågefelen, som misslyckas med "Ogiltigt kolumnnamn" en gång efter migreringen.

Skydda Hive i HDInsight-versioner

HDInsight kan också integreras med Microsoft Entra-ID med HDInsight Enterprise Security Package (ESP). ESP använder Kerberos och Apache Ranger för att hantera behörigheter för specifika resurser i klustret. Ranger-principer som distribueras mot Hive i HDInsight 3.6 kan migreras till HDInsight 4.0 med följande steg:

  1. Gå till panelen Ranger Service Manager i HDInsight 3.6-klustret.
  2. Navigera till principen med namnet HIVE och exportera principen till en json-fil.
  3. Kontrollera att alla användare som refereras till i den exporterade principen json finns i det nya klustret. Om en användare refereras till i principen json men inte finns i det nya klustret lägger du antingen till användaren i det nya klustret eller tar bort referensen från principen.
  4. Gå till panelen Ranger Service Manager i HDInsight 4.0-klustret.
  5. Navigera till principen med namnet HIVE och importera ranger policy json från steg 2.

Hive-ändringar i HDInsight 4.0 som kan kräva programändringar

Se HDInsight 4.0-meddelande för andra ändringar.

Efter migreringen

Följ dessa steg när du har slutfört migreringen.

Table Sanity

  1. Återskapa tabeller i Hive 3.1 med hjälp av CTAS eller IOW för att ändra tabelltyp i stället för att ändra tabellegenskaper.
  2. Behåll doAs som falska.
  3. Se till att hanterad tabell/dataägarskap är med "hive"-användare.
  4. Använd hanterade ACID-tabeller om tabellformatet är ORC och hanteras icke-ACID för icke-ORC-typer.
  5. Återskapa statistik för återskapade tabeller eftersom migrering skulle ha orsakat felaktig statistik.

Klusterhälsa

Om flera kluster delar samma lagring och HMS DB bör vi endast aktivera trådar för automatisk komprimering/komprimering i ett kluster och inaktivera överallt annars.

Justera metaarkivet för att minska processoranvändningen.

  1. Inaktivera transaktionshändelselyssnare.

    Kommentar

    Utför följande steg, endast om hive-replikeringsfunktionen inte används.

    1. Ta bort värdet för hive.metastore.transactional.event.listeners från Ambari-användargränssnittet.
    2. Standardvärdet: org.apache.hive.hcatalog.listener.DbNotificationListener
    3. Nytt värde: <Empty>

  2. Inaktivera Hive PrivilegeSynchronizer

    1. Från Ambari-användargränssnittet anger du hive.privilege.synchronizer = false.
    2. Standardvärdet: true
    3. Nytt värde: false

  3. Optimera partitionsreparationsfunktionen

  4. Inaktivera partitionsreparation – Den här funktionen används för att synkronisera partitionerna av Hive-tabeller på lagringsplatsen med Hive-metaarkivet. Du kan inaktivera den här funktionen om "msck repair" används efter datainmatningen.

  5. Om du vill inaktivera funktionen lägger du till "discover.partitions=false" under tabellegenskaper med hjälp av ALTER TABLE. ELLER (om funktionen inte kan inaktiveras)

  6. Öka reparationsfrekvensen för partitionen.

  7. Från Ambari-användargränssnittet ökar du värdet för "metastore.partition.management.task.frequency" (i sekunder).

    Kommentar

    Den här ändringen kan fördröja synligheten för vissa partitioner som matas in i lagringen.

    1. Standardvärdet: 60
    2. Föreslaget värde: 3600

  8. Avancerade optimeringar Följande alternativ måste testas i en lägre (icke-prod) miljö innan du tillämpar på produktion.

    1. Ta bort den materialiserade vyrelaterade lyssnaren om materialiserad vy inte används.
    2. Från Ambari-användargränssnittet lägger du till en anpassad egenskap (i anpassad hive-site.xml) och tar bort de oönskade metaarkivtrådarna i bakgrunden.
    3. Egenskapsnamn: metastore.task.threads.remote
    4. Standardvärdet: N/A (it uses few class names internally)
    5. Nytt värde: 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. Inaktivera bakgrundstrådarna om replikeringen är inaktiverad.

    1. Från Ambari-användargränssnittet lägger du till en anpassad egenskap (i anpassad hive-site.xml) och tar bort de oönskade trådarna.
    2. Egenskapsnamn: metastore.task.threads.always
    3. Standardvärdet: N/A (it uses few class names internally)
    4. Nytt värde: org.apache.hadoop.hive.metastore.RuntimeStatsCleanerTask

Frågejustering

  1. Behåll standardkonfigurationerna för Hive för att köra frågorna när de är inställda på TPC-DS-arbetsbelastningar. Behöver endast justering på frågenivå om den misslyckas eller körs långsamt.
  2. Se till att statistiken är uppdaterad för att undvika felaktig plan eller felaktiga resultat.
  3. Undvik att blanda externa och hanterade ACID-tabeller i kopplingstyp av frågor. I sådana fall kan du försöka konvertera extern till hanterad icke-ACID-tabell genom rekreation.
  4. I Hive-3 utfördes mycket arbete med vektorisering, CBO, tidsstämpel med zon osv., som kan ha produktbuggar. Så om någon fråga ger fel resultat kan du prova att inaktivera vektorisering, CBO, map-join osv. för att se om det hjälper.

Andra steg som ska följas för att åtgärda felaktiga resultat och dåliga prestanda efter migreringen

  1. Problem hive-frågan ger det felaktiga resultatet. Även frågan select count(*) ger det felaktiga resultatet.

    Orsak Egenskapen "hive.compute.query.using.stats" är inställd på true som standard. Om vi anger det till sant använder det statistiken, som lagras i metaarkivet för att köra frågan. Om statistiken inte är uppdaterad resulterar det i felaktiga resultat.

    Upplösningen samlar in statistik för de hanterade tabellerna med kommandot alter table <table_name> compute statics; på tabellnivå och kolumnnivå. Referenslänk – https://cwiki.apache.org/confluence/display/hive/statsdev#StatsDev-TableandPartitionStatistics

  2. Det tar lång tid att köra Hive-frågor.

    Orsak Om frågan har ett kopplingsvillkor skapar hive en plan om du vill använda mappningskoppling eller sammanslagningskoppling baserat på tabellens storlek och kopplingsvillkor. Om en av tabellerna innehåller en liten storlek läser den in tabellen i minnet och utför kopplingsåtgärden. På så sätt går frågekörningen snabbare jämfört med sammanslagningskopplingen.

    Lösning Se till att ange egenskapen "hive.auto.convert.join=true" som är standardvärdet. Om du ställer in den på false används kopplingskopplingen och kan resultera i dåliga prestanda. Hive avgör om mappning ska användas eller inte baserat på följande egenskaper, som anges i klustret

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

    Gemensam koppling kan konverteras till mappningskoppling automatiskt när hive.auto.convert.join.noconditionaltask=true, om den uppskattade storleken på små tabeller är mindre än hive.auto.convert.join.noconditionaltask.size (standardvärdet är 100000000 MB).

    Om du stöter på problem som rör OOM genom att ställa in egenskapen hive.auto.convert.join på true, bör du ange den till false endast för den specifika frågan på sessionsnivå och inte på klusternivå. Det här problemet kan inträffa om statistiken är fel och Hive bestämmer sig för att använda kartkoppling baserat på statistiken.

  • Problem Hive-frågan ger det felaktiga resultatet om frågan har ett kopplingsvillkor och de aktuella tabellerna har null- eller tomma värden.

    Orsak Ibland kan vi få ett problem som rör null-värden om tabellerna som ingår i frågan har många null-värden. Hive utför frågeoptimeringen felaktigt med de null-värden som ingår, vilket resulterar i felaktiga resultat.

    Lösning Vi rekommenderar att du försöker ställa in egenskapen set hive.cbo.returnpath.hiveop=true på sessionsnivå om du får felaktiga resultat. Den här konfigurationen introducerar inte null-filtrering på kopplingsnycklar. Om tabellerna hade många null-värden kan vi för att optimera kopplingsåtgärden mellan flera tabeller aktivera den här konfigurationen så att den endast tar hänsyn till nullvärdena.

  • Problem hive-frågan ger det felaktiga resultatet om frågan har flera kopplingsvillkor.

    Orsak Ibland skapar Tez felaktiga körningsplaner när det finns samma kopplingar flera gång med map-joins.

    Lösning Det finns en chans att få felaktiga resultat när vi ställer in hive.merge.nway.joins på false. Försök att ställa in det på sant endast för frågan, som påverkades. Detta hjälper till att fråga med flera kopplingar på samma villkor, sammanfogar kopplingar till en enda kopplingsoperator. Den här metoden är användbar om stora shuffle-kopplingar för att undvika en ombildningsfas.

  • Problem: Tiden för frågekörningen ökar dag för dag jämfört med tidigare körningar.

    Orsak Det här problemet kan inträffa om antalet små filer ökar. Hive tar därför tid att läsa alla filer för att bearbeta data, vilket resulterar i ökad körningstid.

    Lösning Se till att köra komprimering ofta för tabellerna som hanteras. Det här steget undviker de små filerna och förbättrar prestandan.

    Referenslänk: Hive-transaktioner – Apache Hive – Apache Software Foundation.

  • Problem Hive-frågan ger ett felaktigt resultat när kunden använder ett kopplingsvillkor i en hanterad acid orc-tabell och en hanterad icke-ACID-orc-tabell.

    Orsak Från HIVE 3 och senare är det strikt begärt att behålla alla hanterade tabeller som en syratabell. Och om vi vill behålla den som en syratabell måste tabellformatet vara orc och detta är huvudkriterierna. Men om vi inaktiverar den strikta egenskapen för hanterade tabeller "hive.strict.managed.tables" till false kan vi skapa en hanterad icke-ACID-tabell. Vissa fall skapar kunden en extern ORC-tabell eller efter migreringen som tabellen konverterade till en extern tabell och inaktiverar den strikta egenskapen för hanterad tabell och konverterar den till en hanterad tabell. I det här läget konverterades tabellen till icke-ACID-hanterat orc-format.

    Hive-optimering för lösning går fel om du kopplar tabellen med en icke-ACID-hanterad ORC-tabell med en syrahanterad orc-tabell.

    Om du konverterar en extern tabell till en hanterad tabell,

    1. Ange inte egenskapen "hive.strict.managed.tables" till false. Om du anger kan du skapa en icke-ACID-hanterad tabell men den begärs inte i HIVE-3
    2. Konvertera den externa tabellen till en hanterad tabell med hjälp av följande alter-kommando i stället för alter table <table_name> set TBLPROPERTIES ('EXTERNAL'='false');
    alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Felsökningsguide

Felsökningsguiden för HDInsight 3.6 till 4.0 för Hive-arbetsbelastningar ger svar på vanliga problem vid migrering av Hive-arbetsbelastningar från HDInsight 3.6 till HDInsight 4.0.

Ytterligare läsning