Sdílet prostřednictvím

Migrace úloh Azure HDInsight 3.6 Hive do HDInsight 4.0

  • Článek

HDInsight 4.0 má oproti HDInsight 3.6 několik výhod. Tady je přehled novinek ve službě HDInsight 4.0.

Tento článek popisuje postup migrace úloh Hive ze služby HDInsight 3.6 na verzi 4.0, včetně

  • Upgrade kopírování a schématu metastoru Hive
  • Sejf migrace kvůli kompatibilitě ACID
  • Zachování zásad zabezpečení Hive

Nové a staré clustery HDInsight musí mít přístup ke stejným účtům úložiště.

Migraci tabulek Hive do nového účtu úložiště je potřeba provést jako samostatný krok. Viz Migrace Hivu mezi účty úložiště.

Změny v Hivu 3 a novinky:

Změny klienta Hive

Hive 3 podporuje pouze tenkého klienta, Beeline pro spouštění dotazů a příkazů pro správu Hive z příkazového řádku. Beeline ke spuštění všech příkazů používá připojení JDBC k HiveServeru. V HiveServeru dochází k parsování, kompilaci a provádění operací.

Podporované příkazy Rozhraní příkazového řádku Hive zadáte vyvoláním Beeline pomocí klíčového slova Hive jako uživatele Hive nebo vyvoláním beeline pomocí beeline -u <JDBC URL>. Adresu URL JDBC můžete získat ze stránky Ambari Hive.

Screenshot showing JDBC URL output.

Použití Beeline (místo silného rozhraní příkazového řádku Hive klienta, které se už nepodporuje) má několik výhod, mezi které patří:

  • Místo údržby celého základu kódu Hive můžete udržovat pouze klienta JDBC.
  • Režie při spuštění je nižší pomocí Beeline, protože se nezabíjí celý základ kódu Hive.

Můžete také spustit skript Hive, který je pod adresářem /usr/bin, který vyvolá připojení beeline pomocí adresy URL JDBC.

Screenshot showing beeline connection output.

Dynamická klientská architektura usnadňuje zabezpečení dat v

  • Stav relace, interní datové struktury, hesla atd., se nacházejí v klientovi místo na serveru.
  • Malý počet démonů potřebných ke spouštění dotazů zjednodušuje monitorování a ladění.

HiveServer vynucuje nastavení seznamu povolených a blokovaných položek, které můžete změnit pomocí SET příkazů. Pomocí seznamů blokování můžete omezit konfiguraci paměti, abyste zabránili nestabilitě Serveru Hive. Můžete nakonfigurovat více instancí HiveServer s různými seznamy povolených a blokovými seznamy, abyste vytvořili různé úrovně stability.

Změny metastoru Hive

Hive teď podporuje jenom vzdálené metastory místo vloženého metastoru (v prostředí HS2 JVM). Metastor Hive se nachází v uzlu v clusteru spravovaném službou Ambari jako součást zásobníku HDInsight. Samostatný server mimo cluster není podporovaný. Pro konfiguraci metastoru Hive už na příkazovém řádku nenastavíte příkazy key=value. Na základě hodnoty nakonfigurované v hive.metastore.uris=' ' " se používá služba HMS a navázáno připojení.

Změna prováděcího modulu

Apache Tez nahrazuje MapReduce jako výchozí prováděcí modul Hive. MapReduce je zastaralý od spuštění Hive 2.0 Refer HIVE-12300. Díky výrazům směrovaných acyklických grafů (DAG) a primitivních přenosů dat se provádění dotazů Hive v rámci Tez zvyšuje výkon. Dotazy SQL, které odešlete do Hivu, se spustí následujícím způsobem:

  1. Hive zkompiluje dotaz.
  2. Tez spustí dotaz.
  3. YARN přiděluje prostředky pro aplikace v clusteru a umožňuje autorizaci pro úlohy Hive ve frontách YARN.
  4. Hive aktualizuje data v ABFS nebo WASB.
  5. Hive vrátí výsledky dotazu přes připojení JDBC.

Pokud starší verze skriptu nebo aplikace určuje MapReduce pro spuštění, dojde k výjimce následujícím způsobem:

Screenshot showing map reducer exception output.

Poznámka:

Většina uživatelem definovaných funkcí (UDF) nevyžaduje provedení žádné změny v Tez místo MapReduce.

Změny v souvislosti s transakcí ACID a CBO:

  • Tabulky ACID jsou výchozím typem tabulky v HDInsight 4.x bez výkonu nebo provozního přetížení.

  • Zjednodušený vývoj aplikací, operace se silnějšími transakčními zárukami a jednodušší sémantikou pro příkazy SQL

  • Interní Hive se postará o dělení na tabulky ACID v HDInsight 4.1, čímž se odstraní režijní náklady na údržbu.

  • Pokročilé optimalizace – Upgrade v CBO

  • Automatická mezipaměť dotazů Vlastnost použitá k povolení ukládání dotazů do mezipaměti je hive.query.results.cache.enabled. Tuto vlastnost musíte nastavit na true. Hive ukládá mezipaměť výsledků dotazu ve /tmp/hive/__resultcache__/. výchozím nastavení, Hive přidělí pro mezipaměť výsledků dotazu 2 GB. Toto nastavení můžete změnit konfigurací následujícího parametru v bajtech hive.query.results.cache.max.size.

    Další informace najdete v výhodách migrace do Azure HDInsight 4.0.

Materializované zobrazení přepíše

Další informace o Hive – materializovaná zobrazení

Změny po upgradu na Apache Hive 3

Pokud chcete po upgradu vyhledat a používat tabulky Apache Hive 3, musíte porozumět změnám, ke kterým dochází během procesu upgradu. Změny správy a umístění tabulek,oprávněních

Správa tabulek Hive

Hive 3 přebírá větší kontrolu nad tabulkami než Hive 2 a vyžaduje, aby spravované tabulky dodržovaly striktní definici. Úroveň řízení Hive přebírá tabulky homogenní pro tradiční databáze. Hive si uvědomuje rozdílové změny dat; tato řídicí architektura zvyšuje výkon.

Pokud například Hive ví, že překlad dotazu nevyžaduje prohledávání tabulek pro nová data, Vrátí Hive výsledky z mezipaměti výsledků dotazu Hive. Když se podkladová data v materializovaném zobrazení změní, Musí Hive znovu sestavit materializované zobrazení. Vlastnosti ACID přesně odhalí, které řádky se změnily, a je potřeba je zpracovat a přidat do materializovaného zobrazení.

Změny vlastností ACID v Hivu

Hive 2.x a 3.x mají transakční (spravované) i netransakční (externí) tabulky. Transakční tabulky mají atomické, konzistentní, izolované a odolné vlastnosti (ACID). V Hive 2.x je počáteční verze zpracování transakce ACID ACID v1. V Hive 3.x by výchozí tabulky byly s ACID v2.

Nativní formáty úložiště a jiné než nativní formáty úložiště

Formáty úložiště jsou faktorem při upgradu změn typů tabulek. Hive 2.x a 3.x podporuje následující nativní formáty úložiště Hadoop a jiné než nativní formáty úložiště

Nativní: Tabulky s integrovanou podporou Hive v následujících formátech souborů

  • Text
  • Sekvenční soubor
  • RC Soubor
  • Soubor AVRO
  • Soubor ORC
  • Soubor Parquet

Ne nativní: Tabulky, které používají obslužnou rutinu úložiště, například DruidStorageHandler nebo HBaseStorageHandler

Upgrade změn v typech tabulek ve službě HDInsight 4.x

Následující tabulka porovnává typy tabulek Hive a operace ACID před upgradem z HDInsight 3.x a po upgradu na HDInsight 4.x. Vlastnictví souboru tabulky Hive je faktorem při určování typů tabulek a operací ACID po upgradu.

Porovnání typů tabulek HDInsight 3.x a HDInsight 4.x

HDInsight 3.x - - - HDInsight 4.x -
Typ tabulky ACID v1 Formát Vlastník (uživatel) souboru tabulky Hive Typ tabulky ACID v2
Externí No Nativní nebo ne nativní Hive nebo jiné než Hive Externí No
Spravované Ano ORC Hive nebo jiné než Hive Spravované, aktualizovatelné Ano
Spravované No ORC Hive Spravované, aktualizovatelné Ano
Spravované No ORC jiné než Hive Externí s odstraněním dat NE
Spravované No Nativní (ale bez ORC) Hive Spravováno, vložení pouze Ano
Spravované No Nativní (ale bez ORC) jiné než Hive Externí s odstraněním dat No
Spravované No Ne nativní Hive nebo jiné než Hive Externí s odstraněním dat No

Zosobnění Hivu

Zosobnění Hive bylo ve výchozím nastavení povolené v Hive 2 (doAs=true) a ve výchozím nastavení je v Hive 3 zakázáno. Zosobnění Hive spouští Hive jako koncový uživatel, nebo ne.

Další změny upgradu HDInsight 4.x

  1. Spravované, tabulky ACID, které nevlastní uživatel Hive, zůstávají spravované tabulky po upgradu, ale Hive se stane vlastníkem.
  2. Po upgradu je formát tabulky Hive stejný jako před upgradem. Například nativní nebo ne nativní tabulky zůstávají nativní nebo ne nativní, v uvedeném pořadí.

Změny umístění

Po upgradu se umístění spravovaných tabulek nebo oddílů nezmění za žádné z následujících podmínek:

  • Původní adresář tabulky nebo oddílu nebyl před upgradem ve výchozím umístění /apps/hive/warehouse.
  • Stará tabulka nebo oddíl je v jiném systému souborů než nový adresář skladu.
  • Starý adresář tabulky nebo oddílu je v jiné zóně šifrování než nový adresář skladu.

Jinak se umístění spravovaných tabulek nebo oddílů změní. Proces upgradu přesune spravované soubory do /hive/warehouse/managed. Ve výchozím nastavení Hive umístí všechny nové externí tabulky, které vytvoříte ve službě HDInsight 4.x. /hive/warehouse/external

, /apps/hive directorycož je bývalé umístění skladu Hive 2.x, může nebo nemusí existovat ve službě HDInsight 4.x.

Změny umístění jsou k dispozici v následujícím scénáři.

Scénář 1

Pokud je tabulka spravovanou tabulkou v HDInsight-3.x a pokud se nachází v umístění /apps/hive/warehouse a převede se jako externí tabulka v HDInsight-4.x, umístění je stejné /apps/hive/warehouse i ve službě HDInsight 4.x. Nezmění se žádné umístění. Pokud po tomto kroku provádíte příkaz alter table a převedete ji jako spravovanou (acid) tabulku v té době, která se nachází ve stejném umístění /apps/hive/warehouse.

Scénář 2

Pokud je tabulka spravovanou tabulkou v HDInsight-3.x a pokud je v umístění /apps/hive/warehouse a převedena na spravovanou tabulku (ACID) v HDInsight 4.x, umístění je /hive/warehouse/managed.

Scénář 3 : Pokud vytváříte externí tabulku, v HDInsight-4.x bez zadání umístění se zobrazí v umístění /hive/warehouse/external.

Převod tabulky

Po upgradu převedete netransakční tabulku na transakční tabulku ACID v2 pomocí ALTER TABLE příkazu a nastavíte vlastnosti tabulky na .

transaction'='true' and 'EXTERNAL'='false
  • Spravovaná tabulka, jiný než ACID, formát ORC a vlastněný uživatelem bez Hivu v HDInsight-3.x se převede na externí tabulku bez ACID v HDInsight-4.x.
  • Pokud si uživatel přeje změnit externí tabulku (jiné než ACID) na ACID, měli by také změnit externí tabulku na spravovanou a ACID. Vzhledem k tomu, že ve službě HDInsight-4.x jsou všechny spravované tabulky ve výchozím nastavení výhradně ACID. Externí tabulky (jiné než ACID) nemůžete převést na tabulku ACID.

Poznámka:

Tabulka musí být tabulka ORC.

Chcete-li převést externí tabulku (jiné než ACID) na tabulku Managed (ACID),

  1. Pomocí následujícího příkazu převeďte externí tabulku na spravovanou a kyselinu rovno hodnotě true: 
    alter table <table name> set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
  2. Pokud se pokusíte spustit následující příkaz pro externí tabulku, zobrazí se následující chyba.

Scénář 1

Představte si, že tabulka rt je externí tabulka (jiná než ACID). Pokud tabulka není tabulka 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

Scénář 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)

K této chybě dochází, protože tabulka rt je externí tabulka a nemůžete převést externí tabulku na ACID.

Scénář 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)

Snažíme se nejdřív změnit externí tabulku na spravovanou tabulku. V HDInsight 4.x by měla být přísně spravovaná tabulka (což znamená, že by měla být ACID). Takže sem dostaneš zablokování. Jediný způsob, jak převést externí tabulku (NON_ACID) na spravovanou (ACID), musíte postupovat podle příkazu:

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

Syntaxe a sémantika

  • Vytvoření tabulky Za účelem zlepšení použitelnosti a funkčnosti změnilo Vytvoření tabulky Hive 3. Hive změnil vytváření tabulek následujícími způsoby:

    • Vytvoří tabulku kompatibilní s acid, což je výchozí hodnota v HDP.
    • Podporuje jednoduché zápisy a vkládání.
    • Zápisy do více oddílů
    • Vloží více aktualizací dat do jednoho příkazu SELECT.
    • Eliminuje potřebu dělení na kontejnery.

    Pokud máte kanál ETL, který vytváří tabulky v Hivu, tabulky se vytvoří jako ACID. Hive teď pevně řídí přístup a pravidelně provádí komprimace tabulek.

    Před upgradem v HDInsight 3.x ve výchozím nastavení create TABLE vytvořil tabulku, která není acid.

    Po upgradu Ve výchozím nastavení CREATE TABLE vytvoří úplnou transakční tabulku ACID ve formátu ORC.

    Akce Požadovaná pro přístup k tabulkám Hive ACID ze Sparku se připojíte k Hivu pomocí Připojení oru Hive Warehouse (HWC). K zápisu tabulek ACID do Hivu ze Sparku použijete rozhraní HWC a HWC API.

  • Escaping db.table References

    Je potřeba změnit dotazy, které používají odkazy db.table, aby Hive interpretovat celý řetězec db.table jako název tabulky. Hive 3.x odmítne db.table v dotazech SQL. V názvech tabulek není povolená tečka (.). Název databáze a název tabulky uzavřete do backticks. Najděte tabulku s problematickým odkazem na tabulku. math.students který se zobrazí v příkazu CREATE TABLE. Uzavřete název databáze a název tabulky do backticks.

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

  • CASTING TIMESTAMPS Results of applications that cast numerics to timestamps differ from Hive 2 to Hive 3. Apache Hive změnil chování CAST tak, aby vyhovovalo standardu SQL, což nepřidružuje časové pásmo k typu TIMESTAMP.

    Před upgradem přetypování číselného typu do časového razítka lze vytvořit výsledek, který odráží časové pásmo clusteru. Například 1597217764557 je 2020-08-12 00:36:04 PDT. Spuštěním následujícího dotazu přetypuje číslo na časové razítko v PDT: SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 00:36:04 |

    Po upgradu přetypování číselného typu do časového razítka vznikne výsledek, který místo časového pásma clusteru odráží utc. Spuštění dotazu přetypuje číslo na časové razítko ve standardu UTC. SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 07:36:04.557 |

    Akce Požadovaná změna aplikací Nepřetypovávejte z číslic pro získání místního časového pásma. Předdefinované funkce from_utc_timestamp a to_utc_timestamp lze použít k napodobení chování před upgradem.

  • KONTROLA KOMPATIBILITY ZMĚN SLOUPCŮ A výchozí změna konfigurace může způsobit selhání aplikací, které mění typy sloupců.

    Před upgradem v HDInsight 3.x Hive.metastore.disallow.incompatible.col.type.changes je ve výchozím nastavení false, aby bylo možné změny v nekompatibilních typech sloupců. Sloupec STRING můžete například změnit na sloupec nekompatibilního typu, například MAP<STRING nebo STRING>. Nedojde k žádné chybě.

    Po upgradu hive.metastore.disallow.incompatible.col.type.changes je ve výchozím nastavení true. Hive zabraňuje změnám nekompatibilních typů sloupců. Kompatibilní změny typu sloupce, například INT, STRING, BIGINT, nejsou blokované.

    Akce Požadovaná změna aplikací pro zakázání nekompatibilních změn typu sloupce, aby se zabránilo možnému poškození dat

  • VYŘAZENÍ ODDÍLŮ

    Klíčová slova OFFLINE a NO_DROP v klauzuli CASCADE pro vyřazení oddílů způsobují problémy s výkonem a už se nepodporují.

    Před upgradem můžete použít klíčová slova OFFLINE a NO_DROP v klauzuli CASCADE, aby se zabránilo čtení nebo vyřazení oddílů.

    Po upgradu OFFLINE a NO_DROP nejsou v klauzuli CASCADE podporovány.

    Akce Požadovaná změna aplikací pro odebrání OFFLINE a NO_DROP z klauzule CASCADE Pokud chcete zabránit vyřazení nebo čtení oddílů, použijte schéma autorizace, jako je Ranger.

  • PŘEJMENOVÁNÍ TABULKY po upgradu Přejmenování spravované tabulky přesune jeho umístění pouze v případě, že je tabulka vytvořena bez LOCATION klauzule a je pod jejím databázovým adresářem.

Omezení týkající se CBO

  • Vidíme, že výběr výstupu dává koncové nule v několika sloupcích. Pokud například máme sloupec tabulky s datovým typem jako desetinné číslo(38;4) a pokud vložíme data jako 38, přidáme koncové nuly a výsledek zadáme jako 38,0000 Podle a https://issues.apache.org/jira/browse/HIVE-12063https://issues.apache.org/jira/browse/HIVE-24389, myšlenka se zachová měřítko a přesnost místo spuštění obálky v desítkových sloupcích. Toto je výchozí chování z Hivu 2. Pokud chcete tento problém vyřešit, můžete postupovat podle následující možnosti.

    1. Upravte datový typ na úrovni zdroje a upravte přesnost jako sloupec1(decimal(38;0)). Tato hodnota poskytuje výsledek jako 38 bez koncové nuly. Pokud ale vložíte data jako 35,0005, je to 0005 a poskytne pouze hodnotu 38 1.Odeberte koncové nuly sloupců s problémem a pak přetypujte na řetězec,
      1. Použití příkazu TRIM(cast(<column_name> AS STRING)+0 FROM <table_name>;
      2. Použijte regulární výraz.

  1. Dotaz Hive selže s výrazem Nepodporovaný poddotaz, když v dotazu použijeme systém UNIX_TIMESTAMP. Pokud například spustíme dotaz, vyvolá chybu Nepodporovaný výraz poddotazového dotazu.

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

    Kořenovým případem tohoto problému je, že aktuální základ kódu Hive vyvolává výjimku, která parsuje systém UNIX_TIMESTAMP, protože neexistuje žádné mapování HiveTypeSystemImpl.java code přesnosti pro přesnostUNIX_TIMESTAMP, kterou Calcite rozpozná jako BIGINT. Následující dotaz ale funguje správně. select * from (SELECT col_1 from table1 where col_2 >= 1);

    Tento příkaz se úspěšně spustí, protože col_2 je celé číslo. Výše uvedený problém byl opraven v hdi-3.1.2-4.1.12(zásobník 4.1) a hdi-3.1.2-5.0.8(5.0 stack)

Postup upgradu

1. Příprava dat

  • HDInsight 3.6 ve výchozím nastavení nepodporuje tabulky ACID. Pokud jsou však k dispozici tabulky ACID, spusťte na nich komprimace MAJOR. Podrobnosti o komprimování najdete v jazykové příručce Hive.

  • Pokud používáte Azure Data Lake Storage Gen1, umístění tabulek Hive pravděpodobně závisí na konfiguracích HDFS clusteru. Spuštěním následující akce skriptu proveďte přenosná umístění do jiných clusterů. Viz akce skriptu pro spuštěný cluster.

    Vlastnost Hodnota
    Identifikátor URI skriptu Bash https://hdiconfigactions.blob.core.windows.net/linuxhivemigrationv01/hive-adl-expand-location-v01.sh
    Typy uzlů Head
    Parametry

2. Kopírování databáze SQL

  • Pokud cluster používá výchozí metastore Hive, postupujte podle tohoto průvodce a exportujte metadata do externího metastoru. Potom vytvořte kopii externího metastoru pro upgrade.

  • Pokud cluster používá externí metastore Hive, vytvořte jeho kopii. Mezi možnosti patří export/import a obnovení k určitému bodu v čase.

3. Upgrade schématu metastoru

Tento krok používá Hive Schema Tool k upgradu schématu metastoru ze služby HDInsight 4.0.

Upozorňující

Tento krok není nevratný. Spusťte tento příkaz pouze na kopii metastoru.

  1. Vytvořte dočasný cluster HDInsight 4.0 pro přístup k Hivu schematool4.0 . Pro tento krok můžete použít výchozí metastore Hive.

  2. Z clusteru HDInsight 4.0 spusťte schematool upgrade cílového metastoru HDInsight 3.6. Upravte následující skript prostředí a přidejte název serveru SQL, název databáze, uživatelské jméno a heslo. Otevřete relaci SSH na hlavním uzlu a spusťte ji.

    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

    Poznámka:

    Tento nástroj používá klienta beeline ke spouštění skriptů SQL v /usr/hdp/$STACK_VERSION/hive/scripts/metastore/upgrade/mssql/upgrade-*.mssql.sql.

    Syntaxe SQL v těchto skriptech nemusí být nutně kompatibilní s jinými klientskými nástroji. Například SSMS a Editor Power Query na webu Azure Portal vyžadují po každém příkazu klíčové slovoGO.

    Pokud některý skript selže kvůli vypršení časového limitu kapacity prostředků nebo transakce, vertikálně navyšte kapacitu služby SQL Database.

  3. Ověřte konečnou verzi s dotazem select schema_version from dbo.version.

    Výstup by se měl shodovat s následujícím příkazem Bash z clusteru 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. Odstraňte dočasný cluster HDInsight 4.0.

4. Nasazení nového clusteru HDInsight 4.0

Vytvořte nový cluster HDInsight 4.0, vyberte upgradovaný metastore Hive a stejné účty úložiště.

  • Nový cluster nevyžaduje stejný výchozí systém souborů.

  • Pokud metastor obsahuje tabulky umístěné ve více účtech úložiště, musíte tyto účty úložiště přidat do nového clusteru, abyste k těmto tabulkám měli přístup. Viz přidání dalších účtů úložiště do SLUŽBY HDInsight.

  • Pokud úlohy Hive selžou kvůli nedostupnosti úložiště, ověřte, že je umístění tabulky v účtu úložiště přidaném do clusteru.

    K identifikaci umístění tabulky použijte následující příkaz Hive:

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

5. Převod tabulek pro dodržování předpisů ACID

Spravované tabulky musí být kompatibilní s ACID ve službě HDInsight 4.0. Spusťte strictmanagedmigration v HDInsight 4.0 a převeďte všechny nespravované tabulky ACID na externí tabulky s vlastností 'external.table.purge'='true'. Spusťte z hlavního uzlu:

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. Chyba třídy nebyla nalezena s MultiDelimitSerDe

Problém

V některých situacích při spuštění dotazu Hive se může zobrazit java.lang.ClassNotFoundException oznámení, že org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe třída nebyla nalezena. K této chybě dochází, když zákazník migruje z HDInsight 3.6 do HDInsight 4.0. Třída org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDeSerDe, která je součástí hive-contrib-1.2.1000.2.6.5.3033-1.jar HDInsight 3.6, je odebrána a používáme org.apache.hadoop.hive.serde2.MultiDelimitSerDe třídu, která je součástí hive-exec jar HDI-4.0. hive-exec jar při spuštění služby se ve výchozím nastavení načte do HS2.

POSTUP ŘEŠENÍ POTÍŽÍ

  1. Zkontrolujte, jestli nějaký soubor JAR ve složce (pravděpodobně má být ve složce knihoven Hive, která je /usr/hdp/current/hive/lib ve službě HDInsight), obsahuje tuto třídu nebo ne.
  2. Zkontrolujte třídu org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe a org.apache.hadoop.hive.serde2.MultiDelimitSerDe jak je uvedeno v řešení.

Řešení

  1. I když je soubor JAR binárním souborem, můžete stále použít grep příkaz s -Hrni přepínači, jak je uvedeno níže, a vyhledat konkrétní název třídy.

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

  2. Pokud se třída nenašla, nevrátí žádný výstup. Pokud najde třídu v souboru JAR, vrátí výstup.

  3. Níže je uvedený příklad, který pochází z clusteru 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. Z výše uvedeného výstupu můžeme potvrdit, že žádný soubor JAR neobsahuje třídu org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe a soubor jar hive-exec obsahuje org.apache.hadoop.hive.serde2.MultiDelimitSerDe.

  5. Pokuste se vytvořit tabulku s formátem řádků DerDe jako ROW FORMAT SERDE org.apache.hadoop.hive.serde2.MultiDelimitSerDe

  6. Tento příkaz problém vyřeší. Pokud jste tabulku už vytvořili, můžete ji přejmenovat pomocí následujících příkazů.

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

Příkaz update slouží k ruční aktualizaci podrobností v back-endové databázi a příkaz alter se používá ke změně tabulky s novou třídou SerDe z beeline nebo Hive.

Porovnání skriptu schématu back-endové databáze Hive

Po dokončení migrace můžete spustit následující skript.

Existuje šance, že v back-endové databázi chybí několik sloupců, což způsobuje selhání dotazů. Pokud k upgradu schématu nedošlo správně, je možné, že dojde k problému s neplatným názvem sloupce. Následující skript načte název sloupce a datový typ z databáze back-endu zákazníka a poskytne výstup, pokud chybí nějaký sloupec nebo nesprávný datový typ.

Následující cesta obsahuje soubor schemacompare_final.py a test.csv. Skript se nachází v souboru "schemacompare_final.py" a soubor "test.csv" obsahuje název sloupce a datový typ pro všechny tabulky, které by měly být přítomné v back-endové databázi Hive.

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

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

Stáhněte si tyto dva soubory z odkazu. Tyto soubory zkopírujte do jednoho z hlavních uzlů, kde je spuštěná služba Hive.

Postup spuštění skriptu:

V adresáři /tmp vytvořte adresář s názvem schemacompare.

Do složky /tmp/schemacompare vložte "schemacompare_final.py" a "test.csv". Proveďte "ls -ltrh /tmp/schemacompare/" a ověřte, jestli jsou soubory k dispozici.

Pokud chcete spustit skript Pythonu, použijte příkaz Python schemacompare_final.py. Tento skript spustí skript a dokončení tohoto skriptu trvá méně než pět minut. Výše uvedený skript se automaticky připojí k back-endové databázi a načte podrobnosti z každé a každé tabulky, kterou Hive používá, a aktualizuje podrobnosti v novém souboru CSV s názvem return.csv. Po vytvoření souboru return.csv porovná data se souborem "test.csv" a vytiskne název sloupce nebo datový typ, pokud v názvu tabulky chybí něco.

Jakmile po spuštění skriptu uvidíte následující řádky, které označují, že se podrobnosti načítají pro tabulky a skript probíhá.

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

A podrobnosti o rozdílu můžete zobrazit na řádku "PODROBNOSTI ROZDÍLU:". Pokud je nějaký rozdíl, vytiskne se

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.

Pokud v tabulce nejsou žádné rozdíly, je výstup

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

V tomto výstupu můžete najít názvy sloupců, které chybí nebo nejsou správné. V back-endové databázi můžete spustit následující dotaz, abyste ověřili, jestli sloupec chybí nebo ne.

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

V případě, že některý ze sloupců v tabulce chybí, například když spustíme dotazy, jako je vložení nebo vložení, přepíšeme, statistiky se vypočítají automaticky a pokusí se aktualizovat tabulku statistik, jako je PART_COL_STATS a TAB_COL_STATS. A pokud v tabulkách chybí sloupec jako "BIT_VECTOR", dojde k chybě Neplatný název sloupce. Sloupec můžete přidat, jak je uvedeno v následujících příkazech. Jako alternativní řešení můžete statistiky zakázat nastavením následujících vlastností, které nemůžou aktualizovat statistiky v back-endové databázi.

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

Tento krok zabraňuje selháním dotazů, které po migraci selžou s chybou Neplatný název sloupce.

Zabezpečení Hivu napříč verzemi HDInsight

HDInsight se volitelně integruje s ID Microsoft Entra pomocí balíčku zabezpečení HDInsight Enterprise (ESP). ESP ke správě oprávnění konkrétních prostředků v clusteru používá Kerberos a Apache Ranger. Zásady Rangeru nasazené pro Hive ve službě HDInsight 3.6 je možné migrovat do HDInsight 4.0 pomocí následujících kroků:

  1. V clusteru HDInsight 3.6 přejděte na panel Ranger Service Manager.
  2. Přejděte na zásadu s názvem HIVE a exportujte ji do souboru JSON.
  3. Ujistěte se, že v novém clusteru existují všichni uživatelé odkazovaní na json exportovaných zásad. Pokud se uživatel odkazuje v kódu JSON zásad, ale v novém clusteru neexistuje, přidejte uživatele do nového clusteru nebo odeberte odkaz ze zásad.
  4. V clusteru HDInsight 4.0 přejděte na panel Ranger Service Manager .
  5. Přejděte na zásadu s názvem HIVE a importujte json zásad rangeru z kroku 2.

Změny Hivu ve službě HDInsight 4.0, které můžou vyžadovat změny aplikace

  • Viz Extra konfigurace pomocí Připojení oru Hive Warehouse ke sdílení metastoru mezi Sparkem a Hivem pro tabulky ACID.

  • HDInsight 4.0 používá autorizaci na základě úložiště. Pokud upravíte oprávnění k souborům nebo vytvoříte složky jako jiný uživatel než Hive, pravděpodobně dojde k chybám Hive na základě oprávnění úložiště. Pokud chcete tento problém vyřešit, udělte rw- uživateli přístup. Viz Průvodce oprávněními HDFS.

  • HiveCLI je nahrazena znakem Beeline.

Další změny najdete v oznámení HDInsight 4.0.

Po migraci

Po dokončení migrace nezapomeňte postupovat podle těchto kroků.

Sanita tabulky

  1. Znovu vytvořte tabulky v Hive 3.1 pomocí CTAS nebo IOW a změňte typ tabulky místo změny vlastností tabulky.
  2. Ponechte hodnoty doA jako false.
  3. Ujistěte se, že vlastnictví spravovaných tabulek nebo dat je u uživatele hive.
  4. Používejte spravované tabulky ACID, pokud je formát tabulky ORC a spravovaný jiný než ACID pro jiné typy než ORC.
  5. Opětovné vygenerování statistik u znovu vytvořených tabulek, protože migrace by způsobila nesprávné statistiky.

Stav clusteru

Pokud více clusterů sdílí stejné úložiště a databázi HMS, měli bychom povolit automaticky komprimační/komprimační vlákna pouze v jednom clusteru a zakázat všude jinde.

Vylaďte metastore, abyste snížili využití procesoru.

  1. Zakažte naslouchací procesy transakčních událostí.

    Poznámka:

    Následující kroky proveďte pouze v případě, že se nepoužívá funkce replikace Hive.

    1. Z uživatelského rozhraní Ambari odeberte hodnotu hive.metastore.transactional.event.listeners.
    2. Výchozí hodnota: org.apache.hive.hcatalog.listener.DbNotificationListener
    3. Nová hodnota: <Empty>

  2. Zakázání Hive PrivilegeSynchronizer

    1. V uživatelském rozhraní Ambari nastavte hive.privilege.synchronizer = false.
    2. Výchozí hodnota: true
    3. Nová hodnota: false

  3. Optimalizace funkce opravy oddílů

  4. Zakázat opravu oddílů – Tato funkce slouží k synchronizaci oddílů tabulek Hive v umístění úložiště s metastorem Hive. Tuto funkci můžete zakázat, pokud se po příjmu dat použije oprava msck.

  5. Pokud chcete funkci zakázat , přidejte do vlastností tabulky příkaz discover.partitions=false pomocí příkazu ALTER TABLE. NEBO (pokud tuto funkci nejde zakázat)

  6. Zvyšte frekvenci oprav oddílů.

  7. V uživatelském rozhraní Ambari zvyšte hodnotu metastore.partition.management.task.frequency (v sekundách).

    Poznámka:

    Tato změna může zpozdit viditelnost některých oddílů přijatých do úložiště.

    1. Výchozí hodnota: 60
    2. Navrhovaná hodnota: 3600

  8. Pokročilé optimalizace: Před použitím na produkční prostředí je potřeba otestovat následující možnosti v nižším (neprodukčním) prostředí.

    1. Pokud se materializované zobrazení nepoužívá, odeberte naslouchací proces související s materializovaným zobrazením.
    2. Z uživatelského rozhraní Ambari přidejte vlastní vlastnost (ve vlastním hive-site.xml) a odeberte nežádoucí vlákna metastoru na pozadí.
    3. Název vlastnosti: metastore.task.threads.remote
    4. Výchozí hodnota: N/A (it uses few class names internally)
    5. Nová hodnota: 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. Pokud je replikace zakázaná, zakažte vlákna na pozadí.

    1. Z uživatelského rozhraní Ambari přidejte vlastní vlastnost (ve vlastním hive-site.xml) a odeberte nežádoucí vlákna.
    2. Název vlastnosti: metastore.task.threads.always
    3. Výchozí hodnota: N/A (it uses few class names internally)
    4. Nová hodnota: org.apache.hadoop.hive.metastore.RuntimeStatsCleanerTask

Ladění dotazů

  1. Ponechte výchozí konfigurace Hivu pro spouštění dotazů, protože jsou vyladěné pro úlohy TPC-DS. Potřebujete ladění na úrovni dotazu jenom v případě, že selže nebo běží pomalu.
  2. Ujistěte se, že jsou statistiky aktuální, abyste se vyhnuli špatným plánům nebo nesprávným výsledkům.
  3. Vyhněte se kombinování externích a spravovaných tabulek ACID v typu spojení dotazů. V takovém případě se pokuste převést externí na spravovanou tabulku, která není acid, prostřednictvím rekreačního prostředí.
  4. V Hive-3 se hodně práce stalo s vektorizací, CBO, časovým razítkem se zónou atd., což může mít chyby produktu. Pokud tedy některý dotaz vrátí nesprávné výsledky, zkuste zakázat vektorizaci, CBO, připojení map atd., abyste zjistili, jestli to pomůže.

Další kroky, které je potřeba provést k opravě nesprávných výsledků a nízkého výkonu po migraci

  1. Dotaz Hive vydá nesprávný výsledek. I výběrový dotaz (*) vrátí nesprávný výsledek.

    Příčina Vlastnost hive.compute.query.using.stats je ve výchozím nastavení nastavená na hodnotu true. Pokud nastavíme hodnotu true, použije statistiky uložené v metastoru ke spuštění dotazu. Pokud statistiky nejsou aktuální, výsledkem jsou nesprávné výsledky.

    Řešení shromažďuje statistiky spravovaných tabulek pomocí alter table <table_name> compute statics; příkazu na úrovni tabulky a na úrovni sloupce. Odkaz na odkaz – https://cwiki.apache.org/confluence/display/hive/statsdev#StatsDev-TableandPartitionStatistics

  2. Provádění dotazů Hive trvá dlouho.

    Příčina: Pokud dotaz obsahuje podmínku spojení, hive vytvoří plán, jestli se má použít připojení k mapování nebo sloučení spojení na základě velikosti tabulky a podmínky spojení. Pokud jedna z tabulek obsahuje malou velikost, načte tuto tabulku do paměti a provede operaci spojení. Tímto způsobem je provádění dotazu rychlejší v porovnání s slučovacím spojením.

    Řešení Nezapomeňte nastavit vlastnost hive.auto.convert.join=true, což je výchozí hodnota. Když ho nastavíte na false, použije se spojení sloučení a může dojít k nízkému výkonu. Hive se rozhodne, jestli se má použít připojení k mapě nebo ne, na základě následujících vlastností, které jsou nastavené v clusteru.

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

    Běžné spojení se může automaticky převést na mapování spojení, pokud hive.auto.convert.join.noconditionaltask=trueje odhadovaná velikost malých tabulek menší než podregistr.auto.convert.join.noconditionaltask.size (výchozí hodnota je 10000000 MB).

    Pokud se setkáte s jakýmkoli problémem souvisejícím s OOM nastavením vlastnosti hive.auto.convert.join na hodnotu true, doporučujeme ji nastavit na false pouze pro konkrétní dotaz na úrovni relace a ne na úrovni clusteru. K tomuto problému může dojít v případě, že jsou statistiky chybné a Hive se rozhodne použít připojení k mapě na základě statistik.

  • Problém s dotazem Hive vrátí nesprávný výsledek, pokud má dotaz podmínku spojení a příslušné tabulky mají hodnoty null nebo prázdné.

    Příčina Někdy může dojít k problému souvisejícímu s hodnotami null, pokud tabulky zahrnuté v dotazu obsahují velké množství hodnot null. Hive provede optimalizaci dotazu nesprávně s hodnotami null, které mají za následek nesprávné výsledky.

    Řešení Doporučujeme zkusit nastavit vlastnost set hive.cbo.returnpath.hiveop=true na úrovni relace, pokud se zobrazí nesprávné výsledky. Tato konfigurace zavádí nenulové filtrování pro klíče spojení. Pokud mají tabulky mnoho hodnot null pro optimalizaci operace spojení mezi více tabulkami, můžeme tuto konfiguraci povolit, aby se zvažuje pouze hodnoty null.

  • Problém s dotazem Hive vrátí nesprávný výsledek, pokud má dotaz více podmínek spojení.

    Příčina Sometime Tez vytváří chybné plány modulu runtime pokaždé, když jsou stejná spojení s map-joins více času.

    Řešení má šanci získat nesprávné výsledky, když nastavíme hive.merge.nway.joins hodnotu false. Zkuste ho nastavit na true jenom pro dotaz, který to ovlivnilo. To pomáhá dotazovat se více spojeními ve stejné podmínce a sloučit spojení dohromady do jednoho operátoru spojení. Tato metoda je užitečná, pokud se velké shuffle spojí, aby se zabránilo reshuffle fáze.

  • Problém: V porovnání s předchozími spuštěními dochází ke zvýšení doby provádění dotazu o den.

    Příčinou tohoto problému může být zvýšení většího počtu malých souborů. Hive tedy potřebuje čas při čtení všech souborů ke zpracování dat, což vede ke zvýšení doby provádění.

    Řešení : Nezapomeňte často spouštět komprimace pro tabulky, které jsou spravovány. Tento krok zabrání malým souborům a zlepší výkon.

    Referenční odkaz: Transakce Hive – Apache Hive – Apache Software Foundation.

  • Problém s dotazem Hive dává nesprávný výsledek, když zákazník používá podmínku spojení u spravované tabulky acid orc a spravovanou tabulku bez ACID orc.

    Příčina Od HIVE 3 je přísně požadována, aby všechny spravované tabulky zůstaly jako acid table. A pokud ji chceme zachovat jako kyselinovou tabulku, musí být formát tabulky orc a to je hlavní kritéria. Pokud ale zakážeme vlastnost striktní spravované tabulky hive.strict.managed.tables na false, můžeme vytvořit spravovanou tabulku, která není acid. V některých případech zákazník vytvoří externí tabulku ORC nebo po migraci převedenou na externí tabulku a zakáže striktní vlastnost spravované tabulky a převede ji na spravovanou tabulku. V tomto okamžiku se tabulka převedla na nespravovaný formát orc bez acid.

    Optimalizace Hivu řešení se pokazí, pokud připojíte tabulku s tabulkou, která není spravovaná pomocí ACID spravované tabulky ORC s tabulkou orc spravovanou kyselinou.

    Pokud převádíte externí tabulku na spravovanou tabulku,

    1. Nenastavujte vlastnost hive.strict.managed.tables na false. Pokud nastavíte, můžete vytvořit tabulku, která není spravovaná službou ACID, ale není požadována v HIVE-3.
    2. Místo následujícího příkazu alter převeďte externí tabulku na spravovanou tabulku. alter table <table_name> set TBLPROPERTIES ('EXTERNAL'='false');
    alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Příručka pro řešení problémů

Průvodce odstraňováním potíží se službou HDInsight 3.6 až 4.0 pro úlohy Hive poskytuje odpovědi na běžné problémy při migraci úloh Hive ze služby HDInsight 3.6 do HDInsight 4.0.

Další texty