Teilen über

Migrieren von Azure HDInsight 3.6-Hive-Workloads zu HDInsight 4.0

  • Artikel

HDInsight 4.0 bietet gegenüber HDInsight 3.6 verschiedene Vorteile. Hier finden Sie eine Übersicht über die neuen Funktionen in HDInsight 4.0.

In diesem Artikel werden die Schritte zum Migrieren von Hive-Workloads von HDInsight 3.6 zu 4.0 behandelt, einschließlich:

  • Kopieren des Hive-Metastore und Upgrade des Schemas
  • Sichere Migration für die ACID-Kompatibilität
  • Beibehaltung von Hive-Sicherheitsrichtlinien

Die neuen und alten HDInsight-Cluster müssen Zugriff auf dieselben Speicherkonten haben.

Die Migration von Hive-Tabellen zu einem neuen Speicherkonto muss als separater Schritt durchgeführt werden. Weitere Informationen finden Sie unter Hive-Migration zwischen Speicherkonten.

Änderungen in Hive 3 und Neuerungen:

Änderungen beim Hive-Client

Hive 3 unterstützt nur den Thin-Client sowie Beeline zum Ausführen von Abfragen und Hive-Administratorbefehle über die Befehlszeile. Beeline verwendet eine JDBC-Verbindung mit HiveServer, um alle Befehle auszuführen. Das Parsen, Kompilieren und Ausführen erfolgt in HiveServer.

Sie geben unterstützte Hive-CLI-Befehle durch Aufrufen von Beeline mit dem Hive-Schlüsselwort als Hive-Benutzer ein oder rufen mithilfe von beeline -u <JDBC URL> einen Beeline-Client auf. Sie können die JDBC-URL von der Ambari Hive-Seite abrufen.

Screenshot showing JDBC URL output.

Die Verwendung von Beeline (anstelle der Thick-Client-Hive-CLI, die nicht mehr unterstützt wird) hat mehrere Vorteile, einschließlich:

  • Anstatt die gesamte Hive-Codebasis verwalten zu müssen, verwalten Sie nur den JDBC-Client.
  • Der Aufwand beim Start ist bei Verwendung von Beeline geringer, da nicht die gesamte Hive-Codebasis beteiligt ist.

Sie können auch das Hive-Skript ausführen, das sich im Verzeichnis „/usr/bin“ befindet und unter Verwendung der JDBC-URL eine Beeline-Verbindung aufruft.

Screenshot showing beeline connection output.

Eine Thin-Client-Architektur erleichtert das Sichern von Daten:

  • Sitzungszustand, interne Datenstrukturen, Kennwörter usw. befinden sich auf dem Client und nicht auf dem Server.
  • Die geringe Anzahl von Daemons, die zum Ausführen von Abfragen erforderlich sind, vereinfacht Überwachung und Debuggen.

HiveServer erzwingt Einstellungen von Zulassungs- und Sperrlisten, die Sie mithilfe von SET-Befehlen ändern können. Mithilfe der Sperrlisten können Sie die Arbeitsspeicherkonfiguration einschränken, um eine Instabilität von Hive Server zu verhindern. Sie können mehrere HiveServer-Instanzen mit unterschiedlichen Zulassungs- und Sperrlisten konfigurieren, um unterschiedliche Stabilitätsstufen herzustellen.

Änderungen beim Hive-Metastore

Hive unterstützt jetzt nur einen Remotemetastore anstelle eines eingebetteten Metastores (in der HS2-JVM). Der Hive-Metastore befindet sich auf einem Knoten in einem Cluster, der von Ambari als Teil des HDInsight-Stapels verwaltet wird. Ein eigenständiger Server außerhalb des Clusters wird nicht unterstützt. Sie legen keine key=value-Befehle mehr in der Befehlszeile fest, um den Hive-Metastore zu konfigurieren. Basierend auf dem in „hive.metastore.uris=' ' “ konfigurierten Wert wird der HMS-Dienst verwendet und die Verbindung hergestellt.

Änderung der Ausführungs-Engine

Apache Tez ersetzt MapReduce als standardmäßige Hive-Ausführungs-Engine. MapReduce wird ab Hive 2.0 Refer HIVE-12300 als veraltet markiert. Mit Ausdrücken von gerichteten azyklischen Graphen (Directed Acyclic Graphs, DAGs) und Datenübertragungsprimitiven verbessert die Ausführung von Hive-Abfragen unter Tez die Leistung. SQL-Abfragen, die Sie an Hive übermitteln, werden wie folgt ausgeführt:

  1. Hive kompiliert die Abfrage.
  2. Tez führt die Abfrage aus.
  3. YARN weist Ressourcen für Anwendungen im gesamten Cluster zu und aktiviert die Autorisierung für Hive-Aufträge in YARN-Warteschlangen.
  4. Hive aktualisiert die Daten in ABFS oder WASB.
  5. Hive gibt Abfrageergebnisse über eine JDBC-Verbindung zurück.

Wenn ein Legacyskript oder eine Legacyanwendung MapReduce für die Ausführung angibt, tritt eine Ausnahme wie folgt auf:

Screenshot showing map reducer exception output.

Hinweis

Die meisten benutzerdefinierten Funktionen (User-Defined Functions, UDFs) erfordern keine Änderung, um mit Tez anstatt von MapReduce ausgeführt zu werden.

Änderungen in Bezug auf ACID-Transaktion und CBO:

  • ACID-Tabellen sind der Standardtabellentyp in HDInsight 4.x ohne Leistungs- oder Vorgangsüberladung.

  • Vereinfachte Anwendungsentwicklung, Vorgänge mit stärkeren Transaktionsgarantien und einfachere Semantik für SQL-Befehle.

  • Hive übernimmt intern das Bucketing für ACID-Tabellen in HDInsight 4.1 und beseitigt so den Wartungsaufwand.

  • Erweiterte Optimierungen – Upgrade in CBO.

  • Automatischer Abfragecache. Die für die Aktivierung der Abfragezwischenspeicherung verwendete Eigenschaft ist hive.query.results.cache.enabled. Sie müssen diese Eigenschaft auf „true“ festlegen. Hive speichert den Abfrageergebniscache in /tmp/hive/__resultcache__/. Standardmäßig weist Hive 2 GB für den Abfrageergebniscache zu. Sie können diese Einstellung ändern, indem Sie den folgenden Parameter in Bytes konfigurieren: hive.query.results.cache.max.size.

    Weitere Informationen finden Sie unter Erhebliche Versionsänderungen in HDInsight 4.0 und Vorteile.

Neu geschriebene materialisierte Sichten

Weitere Informationen finden Sie unter Hive – Materialized Views.

Änderungen nach dem Upgrade auf Apache Hive 3

Um Ihre Apache Hive 3-Tabellen nach einem Upgrade zu finden und zu verwenden, müssen Sie sich mit den Änderungen vertraut machen, die während des Upgradevorgangs erfolgen. Dies sind insbesondere Änderungen an der Verwaltung und dem Speicherort von Tabellen, an Berechtigungen für Tabellenverzeichnisse, an Tabellentypen und an Aspekten der ACID-Compliance.

Tabellenverwaltung in Hive

Hive 3 übernimmt mehr Kontrolle über Tabellen als Hive 2 und erfordert, dass verwaltete Tabellen eine strikte Definition befolgen. Das Maß an Kontrolle, das Hive für Tabellen übernimmt, entspricht dem herkömmlicher Datenbanken. Hive erkennt selbstständig Deltaänderungen an Daten; dieses Steuerungsframework verbessert die Leistung.

Wenn Hive beispielsweise bekannt ist, dass zum Auflösen einer Abfrage Tabellen nicht auf neue Daten geprüft werden muss, gibt Hive Ergebnisse aus dem Hive-Abfrageergebniscache zurück. Wenn sich die zugrunde liegenden Daten in einer materialisierten Sicht ändern, muss Hive die materialisierte Sicht neu erstellen. ACID-Eigenschaften zeigen genau an, welche Zeilen geändert wurden und verarbeitet und der materialisierten Sicht hinzugefügt werden müssen.

Hive-Änderungen an ACID-Eigenschaften

Hive 2.x und 3.x verfügen sowohl über Transaktionstabellen (verwaltet) als auch über Nichttransaktionstabellen (extern). Transaktionstabellen besitzen ACID-Eigenschaften (Atomic – atomisch, Consistent – konsistent, Isolation – isolationsbezogen und Durable – dauerhaft). In Hive 2.x ist ACID v1 die erste Version der ACID-Transaktionsverarbeitung. In Hive 3.x gilt ACID v2 für die Standardtabellen.

Native und nicht native Speicherformate

Speicherformate sind ein Faktor bei Änderungen an Tabellentypen durch ein Upgrade. Hive 2.x und 3.x unterstützt die folgenden nativen und nicht nativen Hadoop-Speicherformate.

Nativ: Tabellen mit integrierter Unterstützung in Hive in den folgenden Dateiformaten:

  • Text
  • Sequenzdatei
  • RC-Datei
  • AVRO-Datei
  • ORC-Datei
  • Parquet-Datei

Nicht nativ: Tabellen, die einen Speicherhandler verwenden, wie z. B. DruidStorageHandler oder HBaseStorageHandler.

Änderungen an Tabellentypen durch Upgrade auf HDInsight 4.x

In der folgenden Tabelle werden Hive-Tabellentypen und ACID-Vorgänge vor und nach einem Upgrade von HDInsight 3.x auf HDInsight 4.x verglichen. Der Besitz der Hive-Tabellendatei ist ein Faktor bei der Bestimmung von Tabellentypen und ACID-Vorgängen nach dem Upgrade.

Vergleich der Tabellentypen zwischen HDInsight 3.x und HDInsight 4.x

HDInsight 3.x - - - HDInsight 4.x -
Tabellentyp ACID v1 Format Besitzer (Benutzer) der Hive-Tabellendatei Tabellentyp ACID v2
Extern Nein Nativ oder nicht nativ Hive oder nicht Hive Extern Nein
Verwaltet Ja ORC Hive oder nicht Hive Verwaltet, aktualisierbar Ja
Verwaltet Nein ORC Hive Verwaltet, aktualisierbar Ja
Verwaltet Nein ORC Nicht Hive Extern, mit Datenlöschung Nein
Verwaltet Nein Nativ (aber nicht ORC) Hive Verwaltet, nur einfügen Ja
Verwaltet Nein Nativ (aber nicht ORC) Nicht Hive Extern, mit Datenlöschung Nein
Verwaltet Nein Nicht nativ Hive oder nicht Hive Extern, mit Datenlöschung Nein

Hive-Identitätswechsel

Der Identitätswechsel von Hive war in Hive 2 standardmäßig aktiviert (doAs=true) und in Hive 3 standardmäßig deaktiviert. Der Hive-Identitätswechsel führt Hive als Endbenutzer*in oder gar nicht aus.

Andere Änderungen durch Upgrade auf HDInsight 4.x

  1. Verwaltete ACID-Tabellen, die nicht dem Hive-Benutzer gehören, bleiben nach dem Upgrade verwaltete Tabellen, aber Hive wird zum Besitzer.
  2. Nach dem Upgrade ist das Format einer Hive-Tabelle dasselbe wie vor dem Upgrade. Beispielsweise bleiben native oder nicht native Tabellen nativ bzw. nicht nativ.

Änderungen bei Speicherorten

Nach dem Upgrade ändert sich der Speicherort von verwalteten Tabellen oder Partitionen unter den folgenden Bedingungen nicht:

  • Das alte Tabellen- bzw. Partitionsverzeichnis befand sich vor dem Upgrade nicht am Standardspeicherort: /apps/hive/warehouse.
  • Die alte Tabelle oder Partition weist ein anderes Dateisystem auf als das neue Warehouseverzeichnis.
  • Das alte Tabellen- oder Partitionsverzeichnis befindet sich in einer anderen Verschlüsselungszone als das neue Warehouseverzeichnis.

Unter allen anderen Bedingungen ändert sich der Speicherort von verwalteten Tabellen oder Partitionen. Der Upgradeprozess verschiebt verwaltete Dateien nach /hive/warehouse/managed. Standardmäßig platziert Hive von Ihnen erstellte neue externe Tabellen in HDInsight 4.x in /hive/warehouse/external.

/apps/hive directory – der frühere Speicherort des Hive 2.x-Warehouse – kann in HDInsight 4.x vorhanden sein, möglicherweise aber auch nicht.

Bei Speicherortänderungen sind die folgenden Szenarien möglich:

Szenario 1

Wenn es sich um eine verwaltete Tabelle in HDInsight 3.x handelt, die im Speicherort /apps/hive/warehouse vorhanden ist und in eine externe Tabelle in HDInsight 4.x konvertiert wurde, lautet der Speicherort auch in HDInsight 4.x /apps/hive/warehouse. Der Speicherort ändert sich nicht. Wenn Sie nach diesem Schritt einen ALTER TABLE-Befehl ausführen, um die Tabelle in eine verwaltete Tabelle (ACID) zu konvertieren, ist sie zu diesem Zeitpunkt im selben Speicherort /apps/hive/warehouse vorhanden.

Szenario 2

Wenn es sich um eine verwaltete Tabelle in HDInsight 3.x handelt, die im Speicherort /apps/hive/warehouse vorhanden ist und in eine verwaltete Tabelle (ACID) in HDInsight 4.x konvertiert wurde, lautet der Speicherort /hive/warehouse/managed.

Szenario 3 Wenn Sie in HDInsight 4.x eine externe Tabelle erstellen, ohne einen Speicherort anzugeben, wird die Tabelle hier gespeichert: /hive/warehouse/external.

Tabellenkonvertierung

Um eine Nichttransaktionstabelle nach einem Upgrade in eine ACID v2-Transaktionstabelle zu konvertieren, verwenden Sie den Befehl ALTER TABLE und legen folgende Tabelleneigenschaften fest:

transaction'='true' and 'EXTERNAL'='false
  • Die verwaltete Tabelle – nicht ACID, im ORC-Format und im Besitz eines Nicht-Hive-Benutzers in HDInsight 3.x – wird in HDInsight 4.x in eine externe Nicht-ACID-Tabelle konvertiert.
  • Wenn die externe Tabelle (nicht ACID) in eine ACID-Tabelle geändert werden soll, muss die externe Tabelle sowohl als „verwaltet“ als auch als „ACID“ festgelegt werden. Das ist erforderlich, weil in HDInsight 4.x alle verwalteten Tabellen standardmäßig ACID sind. Sie können externe Tabellen (nicht ACID) nicht in ACID-Tabellen konvertieren.

Hinweis

Die Tabelle muss eine ORC-Tabelle sein.

So konvertieren Sie eine externe Tabelle (nicht ACID) in eine verwaltete Tabelle (ACID):

  1. Konvertieren Sie die externe Tabelle mit dem folgenden Befehl in eine verwaltete ACID-Tabelle: 
    alter table <table name> set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
  2. Wenn Sie versuchen, den folgenden Befehl für eine externe Tabelle auszuführen, erhalten Sie den folgenden Fehler.

Szenario 1

Beispiel: Die Tabelle „rt“ ist eine externe Tabelle (nicht ACID). Wenn die Tabelle keine ORC-Tabelle ist:

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

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

Dieser Fehler tritt auf, weil die Tabelle „rt“ eine externe Tabelle ist und externe Tabellen nicht in ACID konvertiert werden können.

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

Hier versuchen wir, die externe Tabelle zuerst in eine verwaltete Tabelle zu ändern. In HDInsight 4.x sollte es sich um eine strikt verwaltete Tabelle handeln (d. h. sie sollte ACID-Eigenschaften aufweisen). Hier kommt es also zu einem Deadlock. Die einzige Möglichkeit, die externe Tabelle (nicht ACID) in eine verwaltete Tabelle (ACID) zu konvertieren, ist die Ausführung des folgenden Befehls:

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

Syntax und Semantik

  • Erstellen einer Tabelle: Zur Verbesserung von Nutzbarkeit und Funktionalität wurde in Hive 3 die Tabellenerstellung geändert. Die Tabellenerstellung wurde in Hive 3 folgendermaßen geändert:

    • Erstellt eine ACID-konforme Tabelle, die in HDP die Standardeinstellung ist.
    • Unterstützt einfache Schreib- und Einfügevorgänge.
    • Unterstützt Schreibvorgänge in mehrere Partitionen.
    • Fügt mehrere Datenupdates in einer einzigen SELECT-Anweisung ein.
    • Eliminiert die Notwendigkeit des Bucketings.

    Wenn Sie über eine ETL-Pipeline verfügen, die Tabellen in Hive erstellt, werden die Tabellen als ACID erstellt. Hive steuert jetzt den Zugriff strikt und führt in regelmäßigen Abständen eine Komprimierung für die Tabellen durch.

    Vor dem Upgrade: In HDInsight 3.x erstellte CREATE TABLE standardmäßig eine Nicht-ACID-Tabelle.

    Nach dem Upgrade: CREATE TABLE erstellt standardmäßig eine vollständige ACID-Transaktionstabelle im ORC-Format.

    Erforderliche Aktion: Für den Zugriff auf Hive-ACID-Tabellen aus Spark stellen Sie über den Hive Warehouse Connector (HWC) eine Verbindung mit Hive her. Um ACID-Tabellen aus Spark in Hive zu schreiben, verwenden Sie den HWC und die HWC-API.

  • Escapen von db.table-Verweisen

    Sie müssen Abfragen ändern, die db.table-Verweise verwenden, um zu verhindern, dass Hive die gesamte db.table-Zeichenfolge als Tabellennamen interpretiert. Hive 3.x lehnt db.table in SQL-Abfragen ab. Ein Punkt (.) ist in Tabellennamen nicht zulässig. Sie schließen den Datenbanknamen und den Tabellennamen in Backticks ein. Suchen Sie nach einer Tabelle mit dem problematischen Tabellenverweis math.students, der in einer CREATE TABLE-Anweisung enthalten ist. Schließen Sie den Datenbanknamen und den Tabellennamen in Backticks ein.

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

  • Umwandeln von Zeitstempeln: Die Ergebnisse von Anwendungen, die numerische Werte in Zeitstempel umwandeln, unterscheiden sich zwischen Hive 2 und Hive 3. Apache Hive hat das Verhalten von CAST geändert, um dem SQL-Standard zu entsprechen, der dem TIMESTAMP-Typ keine Zeitzone zuordnet.

    Vor dem Upgrade: Durch Umwandeln des Werts eines numerischen Typs in einen Zeitstempel konnte ein Ergebnis erzeugt werden, das die Zeitzone des Clusters widerspiegelte. Beispiel: „1597217764557“ wird zu „2020-08-12 00:36:04 PDT“. Durch Ausführen der folgenden Abfrage wird der numerische Wert in einen Zeitstempel mit der Zeitzone PDT umgewandelt: SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 00:36:04 |

    Nach dem Upgrade: Das Umwandeln des Werts eines numerischen Typs in einen Zeitstempel erzeugt ein Ergebnis, das die Zeitzone UTC anstelle der Zeitzone des Clusters widerspiegelt. Durch Ausführen der Abfrage wird der numerische Wert in einen Zeitstempel mit der Zeitzone UTC umgewandelt. SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 07:36:04.557 |

    Erforderliche Aktion: Ändern Sie Anwendungen. Führen Sie keine Umwandlung aus einem numerischen Wert durch, um eine lokale Zeitzone abzurufen. Die integrierten Funktionen „from_utc_timestamp“ und „to_utc_timestamp“ können verwendet werden, um das Verhalten vor dem Upgrade nachzuahmen.

  • Überprüfen der Kompatibilität von Spaltenänderungen: Eine Standardkonfigurationsänderung kann zu Fehlern bei Anwendungen führen, die Spaltentypen ändern.

    Vor dem Upgrade: In HDInsight 3.x ist „Hive.metastore.disallow.incompatible.col.type.changes“ standardmäßig auf „false“ festgelegt, um Änderungen an inkompatiblen Spaltentypen zuzulassen. Beispielsweise können Sie eine STRING-Spalte in eine Spalte eines inkompatiblen Typs ändern, z. B. MAP<STRING, STRING>. Es tritt kein Fehler auf.

    Nach dem Upgrade: „hive.metastore.disallow.incompatible.col.type.changes“ ist standardmäßig „true“. Hive verhindert Änderungen an inkompatiblen Spaltentypen. Änderungen an kompatible Spaltentypen, z. B. INT, STRING oder BIGINT, werden nicht blockiert.

    Erforderliche Aktion: Ändern Sie Anwendungen so, dass Änderungen an inkompatiblen Spaltentypen nicht zulässig sind, um mögliche Datenbeschädigungen zu verhindern.

  • Löschen von Partitionen

    Die Schlüsselwörter OFFLINE und NO_DROP in der CASCADE-Klausel für das Löschen von Partitionen verursachen Leistungsprobleme und werden nicht mehr unterstützt.

    Vor dem Upgrade: Sie konnten die Schlüsselwörter OFFLINE und NO_DROP in der CASCADE-Klausel verwenden, um zu verhindern, dass Partitionen gelesen oder gelöscht werden.

    After Upgrade OFFLINE und NO_DROP werden in der CASCADE-Klausel nicht unterstützt.

    Erforderliche Aktion: Ändern Sie Anwendungen, und entfernen Sie OFFLINE und NO_DROP aus der CASCADE-Klausel. Verwenden Sie ein Autorisierungsschema, z. B. Ranger, um zu verhindern, dass Partitionen gelöscht oder gelesen werden.

  • Umbenennen einer Tabelle: Nach dem Upgrade: Durch Umbenennen einer verwalteten Tabelle wird ihr Speicherort nur verschoben, wenn die Tabelle ohne LOCATION-Klausel erstellt wurde und sich in ihrem Datenbankverzeichnis befindet.

Einschränkungen in Bezug auf CBO

  • Die ausgewählte Ausgabe enthält in einigen Spalten Nullen hinter dem Dezimalzeichen. Wenn wir beispielsweise eine Tabellenspalte mit dem Datentyp „Dezimalzahl“ (38,4) haben und die Zahl „38“ einfügen, werden die Nullen hinter dem Dezimalzeichen hinzugefügt und das Ergebnis „38.0000“ angezeigt. Gemäß https://issues.apache.org/jira/browse/HIVE-12063 und https://issues.apache.org/jira/browse/HIVE-24389 steht der Gedanke dahinter, dass Größenordnung und Genauigkeit beibehalten werden, anstatt einen Wrapper in Dezimalspalten auszuführen. Dies ist das Standardverhalten in Hive 2. Um dieses Problem zu beheben, können Sie die folgende Option verwenden.

    1. Ändern Sie den Datentyp auf Quellebene, um die Genauigkeit wie folgt anzupassen: col1(decimal(38,0)). Dieser Wert stellt als Ergebnis die Zahl 38 bereit, ohne Nullen hinter dem Dezimalzeichen. Wenn Sie die Daten jedoch als „38.0005“ einfügen, wird „.0005“ aufgerundet, und es wird nur der Wert „38.1“ angezeigt. Entfernen Sie die Nullen hinter dem Dezimalzeichen für die Spalten, in denen das Problem auftritt, und wandeln Sie die Daten dann in eine Zeichenfolge um.
      1. Verwenden Sie „select TRIM(cast(<Spaltenname> AS STRING))+0 FROM <Tabellenname>;“
      2. Verwenden Sie einen regulären Ausdruck.

  1. Bei der Hive-Abfrage tritt der Fehler „Nicht unterstützter SubQuery-Ausdruck“ auf, wenn wir UNIX_TIMESTAMP in der Abfrage verwenden. Wenn wir beispielsweise eine Abfrage ausführen, wird der Fehler „Nicht unterstützter SubQuery-Ausdruck“ ausgelöst.

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

    Die Ursache dieses Problems ist die Tatsache, dass die aktuelle Hive-Codebasis beim Parsen von UNIX_TIMESTAMP eine Ausnahme auslöst, da es keine Genauigkeitszuordnung in HiveTypeSystemImpl.java code für die Genauigkeit UNIX_TIMESTAMP gibt, die Calcite als BIGINT erkennt. Diese Abfrage funktioniert jedoch gut: select * from (SELECT col_1 from table1 where col_2 >= 1);.

    Dieser Befehl wird erfolgreich ausgeführt, da „col_2“ ein Integer-Wert ist. Das obige Problem wurde in hdi-3.1.2-4.1.12 (Stack 4.1) und hdi-3.1.2-5.0.8 (Stack 5.0) behoben.

Schritte zum Upgrade

1. Aufbereiten der Daten

  • HDInsight 3.6 unterstützt standardmäßig keine ACID-Tabellen. Wenn jedoch ACID-Tabellen vorhanden sind, führen Sie eine MAJOR-Komprimierung für diese aus. Ausführliche Informationen zur Komprimierung finden Sie im Handbuch zur Hive-Sprache.

  • Bei Verwendung von Azure Data Lake Storage Gen1 sind die Speicherorte für Hive-Tabellen wahrscheinlich von den HDFS-Konfigurationen des Clusters abhängig. Führen Sie die folgende Skriptaktion aus, um die Portierung dieser Speicherorte auf andere Cluster zu ermöglichen. Weitere Informationen finden Sie unter Skriptaktion für einen ausgeführten Cluster.

    Eigenschaft Wert
    Bash-Skript-URI https://hdiconfigactions.blob.core.windows.net/linuxhivemigrationv01/hive-adl-expand-location-v01.sh
    Knotentyp(en) Head
    Parameter

2. Kopieren der SQL-Datenbank

  • Wenn der Cluster einen Standard-Hive-Metastore verwendet, befolgen Sie diese Anleitung, um Metadaten in einen externen Metastore zu exportieren. Erstellen Sie dann eine Kopie des externen Metastores für das Upgrade.

  • Wenn der Cluster einen externen Hive-Metastore verwendet, erstellen Sie eine Kopie davon. Optionen sind u. a. Exportieren/Importieren und Zeitpunktwiederherstellung.

3. Aktualisieren des Metastoreschemas

In diesem Schritt wird das Hive Schema Tool von HDInsight 4.0 verwendet, um das Metastoreschema zu aktualisieren.

Warnung

Dieser Schritt kann nicht rückgängig gemacht werden. Führen Sie diesen Vorgang nur bei einer Kopie des Metastores aus.

  1. Erstellen Sie einen temporären HDInsight 4.0-Cluster, um auf 4.0-Hive-schematool zuzugreifen. Für diesen Schritt können Sie den Standard-Hive-Metastore verwenden.

  2. Führen Sie vom HDInsight 4.0-Cluster schematool aus, um den Ziel-HDInsight 3.6-Metastore zu aktualisieren. Bearbeiten Sie das folgende Shellskript, um Ihren SQL Server-Namen, den Datenbanknamen, den Benutzernamen und das Kennwort hinzuzufügen. Öffnen Sie eine SSH-Sitzung auf dem Hauptknoten, und führen Sie sie aus.

    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

    Hinweis

    Dieses Hilfsprogramm verwendet Client-beeline zum Ausführen von SQL-Skripts in /usr/hdp/$STACK_VERSION/hive/scripts/metastore/upgrade/mssql/upgrade-*.mssql.sql.

    Die SQL-Syntax in diesen Skripts ist nicht unbedingt mit anderen Clienttools kompatibel. Beispielsweise verlangen SSMS und der Abfrage-Editor im Azure-Portal nach jedem Befehl das Schlüsselwort GO.

    Wenn ein Skript aufgrund der Ressourcenkapazität oder von Transaktionstimeouts fehlschlägt, skalieren Sie die SQL-Datenbank hoch.

  3. Überprüfen Sie die endgültige Version mit der Abfrage select schema_version from dbo.version.

    Die Ausgabe sollte dem folgenden bash-Befehl aus dem HDInsight 4.0-Cluster entsprechen.

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

  4. Löschen Sie den temporären HDInsight 4.0-Cluster.

4. Bereitstellen eines neuen HDInsight 4.0-Clusters

Erstellen Sie einen neuen HDInsight 4.0-Cluster, wobei Sie die gleichen Speicherkonten und den aktualisierten Hive-Metastore auswählen.

  • Der neue Cluster muss nicht über das gleiche Standarddateisystem verfügen.

  • Wenn der Metastore Tabellen enthält, die sich in mehreren Speicherkonten befinden, müssen Sie diese Speicherkonten dem neuen Cluster hinzufügen, um auf diese Tabellen zuzugreifen. Weitere Informationen finden Sie unter Hinzufügen zusätzlicher Speicherkonten zu HDInsight.

  • Wenn Hive-Aufträge fehlschlagen, weil kein Zugriff auf den Speicher möglich ist, überprüfen Sie, ob sich der Tabellenspeicherort in einem Speicherkonto befindet, das dem Cluster hinzugefügt wurde.

    Verwenden Sie den folgenden Hive-Befehl zum Ermitteln des Tabellenspeicherorts:

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

5. Konvertieren von Tabellen für die ACID-Konformität

Verwaltete Tabellen müssen für HDInsight 4.0 ACID-kompatibel sein. Führen Sie strictmanagedmigration auf HDInsight 4.0 mit der Eigenschaft 'external.table.purge'='true' aus, um alle nicht per ACID verwalteten Tabellen in externe Tabellen zu konvertieren. Führen Sie folgenden Befehl auf dem Hauptknoten aus:

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. Fehler „Klasse nicht gefunden“ mit MultiDelimitSerDe

Problem

In bestimmten Situationen erhalten Sie beim Ausführen einer Hive-Abfrage eine java.lang.ClassNotFoundException, dass die org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe-Klasse nicht gefunden wurde. Dieser Fehler tritt auf, wenn Kund*innen von HDInsight 3.6 zu HDInsight 4.0 migrieren. Die SerDe-Klasse org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe, die Teil von hive-contrib-1.2.1000.2.6.5.3033-1.jar in HDInsight 3.6 ist, wurde entfernt. Stattdessen wird die org.apache.hadoop.hive.serde2.MultiDelimitSerDe-Klasse verwendet, die ein Teil von hive-exec jar in HDI-4.0 ist. hive-exec jar wird standardmäßig in HS2 geladen, wenn der Dienst gestartet wird.

SCHRITTE ZUR PROBLEMBEHANDLUNG

  1. Überprüfen Sie, ob eine JAR-Datei in einem Ordner (wahrscheinlich unter dem Ordner mit den Hive-Bibliotheken, also /usr/hdp/current/hive/lib in HDInsight) diese Klasse enthält.
  2. Suchen Sie nach den Klassen org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe und org.apache.hadoop.hive.serde2.MultiDelimitSerDe wie in der Lösung beschrieben.

Lösung

  1. Obwohl eine JAR-Datei eine Binärdatei ist, können Sie trotzdem den Befehl grep mit -Hrni-Schaltern wie unten verwenden, um nach einem bestimmten Klassennamen zu suchen.

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

  2. Wenn die Klasse nicht gefunden wurde, wird keine Ausgabe zurückgegeben. Wenn die Klasse in einer JAR-Datei gefunden wird, erfolgt eine Ausgabe.

  3. Nachfolgend finden Sie das Beispiel aus dem HDInsight 4.x-Cluster:

    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. Anhand der obigen Ausgabe können Sie bestätigen, dass keine JAR-Datei die org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe-Klasse und dass hive-exec.jar org.apache.hadoop.hive.serde2.MultiDelimitSerDe enthält.

  5. Versuchen Sie, die Tabelle mit DerDe-Zeilenformat zu erstellen, wie in ROW FORMAT SERDE org.apache.hadoop.hive.serde2.MultiDelimitSerDe.

  6. Dieser Befehl behebt das Problem. Wenn Sie die Tabelle bereits erstellt haben, können Sie sie mithilfe der folgenden Befehle umbenennen.

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

Der update-Befehl dient zum manuellen Aktualisieren der Details in der Back-End-Datenbank, und der alter-Befehl wird verwendet, um die Tabelle mit der neuen SerDe-Klasse von beeline oder Hive zu ändern.

Skript zum Schemavergleich für Hive-Back-End-Datenbanken

Sie können das folgende Skript ausführen, nachdem Sie die Migration abgeschlossen haben.

Es besteht die Möglichkeit, dass in der Back-End-Datenbank einige Spalten fehlen, was zu Abfragefehlern führt. Wenn das Schemaupgrade nicht ordnungsgemäß durchgeführt wurde, kann es passieren, dass ein Problem mit ungültigen Spaltennamen auftritt. Das folgende Skript ruft den Spaltennamen und den Datentyp aus der Back-End-Datenbank des Kunden ab und stellt eine Ausgabe bereit, wenn eine Spalte fehlt oder ein Datentyp falsch ist.

Der folgende Pfad enthält die Dateien „schemacompare_final.py“ und „test.csv“. Das Skript befindet sich in der Datei „schemacompare_final.py“, und die Datei „test.csv“ enthält alle Spaltennamen und Datentypen für alle Tabellen, die in der Hive-Back-End-Datenbank vorhanden sein sollten.

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

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

Laden Sie diese beiden Dateien über den Link herunter. Kopieren Sie diese Dateien auf einen der Hauptknoten, auf denen der Hive-Dienst ausgeführt wird.

Schritte zum Ausführen des Skripts:

Erstellen Sie im Verzeichnis „/tmp“ ein Verzeichnis namens „schemacompare“.

Legen Sie „schemacompare_final.py“ und „test.csv“ im Ordner „/tmp/schemacompare“ ab. Führen Sie „ls -ltrh /tmp/schemacompare/“ aus, und überprüfen Sie, ob die Dateien vorhanden sind.

Verwenden Sie zum Ausführen des Python-Skripts den Befehl „python schemacompare_final.py“. Dieser Befehl führt das Skript aus – dieser Vorgang dauert weniger als fünf Minuten. Dieses Skript stellt automatisch eine Verbindung mit Ihrer Back-End-Datenbank her, ruft die Details aus jeder einzelnen von Hive verwendeten Tabelle ab und aktualisiert die Details in einer neuen CSV-Datei namens „return.csv“. Nach dem Erstellen der Datei „return.csv“ vergleicht das Skript die Daten mit der Datei „test.csv“ und gibt den entsprechenden Spaltennamen oder Datentyp aus, wenn unter dem Tabellennamen etwas fehlt.

Nach dem Ausführen des Skripts sehen Sie die folgenden Zeilen, die angeben, dass die Details für die Tabellen abgerufen werden wurden:

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

Die Details zu den Unterschieden finden Sie unterhalb der Zeile „DIFFERENCE DETAILS:“. Wenn Unterschiede vorhanden sind, wird Folgendes ausgegeben:

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.

Wenn es keine Unterschiede zwischen den Tabellen gibt, lautet die Ausgabe folgendermaßen:

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

In dieser Ausgabe finden Sie die Spaltennamen, die fehlen oder falsch sind. Sie können die folgende Abfrage in Ihrer Back-End-Datenbank ausführen, um zu überprüfen, ob eine Spalte tatsächlich fehlt oder nicht.

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

Falls eine der Spalten in der Tabelle fehlt, z. B. wenn Abfragen wie „insert“ oder „insert overwrite“ ausgeführt werden, werden die Statistiken automatisch berechnet, und es wird versucht, die Statistiktabellen wie „PART_COL_STATS“ und „TAB_COL_STATS“ zu aktualisieren. Wenn eine Spalte wie „BIT_VECTOR“ in den Tabellen fehlt, tritt der Fehler „Ungültiger Spaltenname“ auf. Sie können die Spalte hinzufügen, wie in den folgenden Befehlen zu sehen. Als Problemumgehung können Sie die Statistiken deaktivieren, indem Sie die folgenden Eigenschaften festlegen, die die Statistiken in der Back-End-Datenbank nicht aktualisieren können.

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

Mit diesem Schritt werden Abfragefehler wie „Ungültiger Spaltenname“ nach der Migration vermieden.

Sichern von Hive in verschiedenen HDInsight-Versionen

HDInsight kann optional mit dem HDInsight-Enterprise-Sicherheitspaket (ESP) in Microsoft Entra ID integriert werden. Das Enterprise-Sicherheitspaket verwendet Kerberos und Apache Ranger, um die Berechtigungen bestimmter Ressourcen im Cluster zu verwalten. Für Hive in HDInsight 3.6 bereitgestellte Ranger-Richtlinien können wie folgt zu HDInsight 4.0 migriert werden:

  1. Navigieren Sie in Ihrem HDInsight 3.6-Cluster zum Bereich „Ranger Service Manager“.
  2. Navigieren Sie zur Richtlinie namens HIVE, und exportieren Sie die Richtlinie in eine JSON-Datei.
  3. Stellen Sie sicher, dass alle Benutzer, auf die in der JSON-Datei mit der exportierten Richtlinie verwiesen wird, im neuen Cluster vorhanden sind. Wenn in der JSON-Datei mit der Richtlinie auf einen Benutzer verwiesen wird, der nicht im neuen Cluster vorhanden ist, fügen Sie den Benutzer dem neuen Cluster hinzu, oder entfernen Sie den Verweis aus der Richtlinie.
  4. Navigieren Sie in Ihrem HDInsight 4.0-Cluster zum Bereich Ranger Service Manager.
  5. Navigieren Sie zur Richtlinie namens HIVE, und importieren Sie die in Schritt 2 erstellte JSON-Datei mit der Ranger-Richtlinie.

Änderungen an Hive in HDInsight 4.0, die möglicherweise Änderungen an Anwendungen erfordern

Andere Änderungen finden Sie in der Ankündigung von HDInsight 4.0.

Nach der Migration

Führen Sie diese Schritte nach Abschluss der Migration aus.

Tabellenintegrität

  1. Erstellen Sie Tabellen in Hive 3.1 mithilfe von CTAS oder IOW neu, um den Tabellentyp zu ändern, anstatt die Tabelleneigenschaften zu ändern.
  2. Behalten Sie die Festlegung von „doAs“ als „false“ bei.
  3. Stellen Sie sicher, dass der Besitz der verwalteten Tabellen/Daten beim Benutzer „hive“ liegt.
  4. Verwenden Sie verwaltete ACID-Tabellen, wenn das Tabellenformat ORC ist, und verwaltete Nicht-ACID-Tabellen, wenn es sich nicht um ORC-Typen handelt.
  5. Generieren Sie Statistiken für neu erstellte Tabellen neu, da die Migration vermutlich zu falschen Statistiken führt.

Clusterintegrität

Wenn mehrere Cluster denselben Speicher und dieselbe HMS-Datenbank verwenden, sollten Threads zur (automatischen) Komprimierung nur in einem einzigen Cluster aktiviert und überall sonst deaktiviert werden.

Optimieren Sie den Metastore, um die CPU-Auslastung zu reduzieren.

  1. Deaktivieren Sie Transaktionsereignislistener.

    Hinweis

    Führen Sie die folgenden Schritte nur aus, wenn das Hive-Replikationsfeature nicht verwendet wird.

    1. Auf der Ambari-Benutzeroberfläche: Entfernen Sie den Wert für „hive.metastore.transactional.event.listeners“.
    2. Standardwert: org.apache.hive.hcatalog.listener.DbNotificationListener
    3. Neuer Wert: <Empty>

  2. Deaktivieren Sie den Hive PrivilegeSynchronizer.

    1. Auf der Ambari-Benutzeroberfläche: Legen Sie „hive.privilege.synchronizer=false“ fest.
    2. Standardwert: true
    3. Neuer Wert: false

  3. Optimieren Sie das Partitionsreparaturfeature.

  4. Deaktivieren der Partitionsreparatur: Dieses Feature wird verwendet, um die Partitionen von Hive-Tabellen am Speicherort mit dem Hive-Metastore zu synchronisieren. Sie können dieses Feature deaktivieren, wenn „msck repair“ nach der Datenerfassung verwendet wird.

  5. Zum Deaktivieren des Features fügen Sie „discover.partitions=false“ mithilfe von ALTER TABLE in die Tabelleneigenschaften ein. ODER (wenn das Feature nicht deaktiviert werden kann):

  6. Erhöhen Sie die Frequenz der Partitionsreparatur.

  7. Auf der Ambari-Benutzeroberfläche: Erhöhen Sie den Wert von „metastore.partition.management.task.frequency“ (in Sekunden).

    Hinweis

    Diese Änderung kann die Sichtbarkeit einiger Partitionen verzögern, die im Speicher erfasst werden.

    1. Standardwert: 60
    2. Vorgeschlagener Wert: 3600

  8. Erweiterte Optimierungen: Die folgenden Optionen müssen vor der Anwendung in der Produktion in einer niedrigeren (nicht produktiven) Umgebung getestet werden.

    1. Entfernen Sie den Listener für materialisierte Sichten, wenn keine materialisierte Sichten verwendet werden.
    2. Auf der Ambari-Benutzeroberfläche: Fügen Sie eine benutzerdefinierte Eigenschaft (in einer benutzerdefinierten Datei „hive-site.xml“) hinzu, und entfernen Sie die unerwünschten Hintergrundthreads im Metastore.
    3. Name der Eigenschaft: metastore.task.threads.remote
    4. Standardwert: N/A (it uses few class names internally)
    5. Neuer Wert: 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. Deaktivieren Sie die Hintergrundthreads, wenn die Replikation deaktiviert ist.

    1. Auf der Ambari-Benutzeroberfläche: Fügen Sie eine benutzerdefinierte Eigenschaft (in einer benutzerdefinierten Datei „hive-site.xml“) hinzu, und entfernen Sie die unerwünschten Threads.
    2. Name der Eigenschaft: metastore.task.threads.always
    3. Standardwert: N/A (it uses few class names internally)
    4. Neuer Wert: org.apache.hadoop.hive.metastore.RuntimeStatsCleanerTask

Abfrageoptimierung

  1. Behalten Sie die Standardkonfigurationen von Hive bei, um die Abfragen auszuführen, da sie für TPC-DS-Workloads optimiert sind. Eine Optimierung auf Abfrageebene ist nur erforderlich, wenn Abfragen langsam ausgeführt werden oder zu Fehlern führen.
  2. Stellen Sie sicher, dass die Statistiken auf dem neuesten Stand sind, um einen ungenügenden Plan oder falsche Ergebnisse zu vermeiden.
  3. Vermeiden Sie es, bei Abfragen vom Typ „Join“ externe und verwaltete ACID-Tabellen zu mischen. Versuchen Sie in einem solchen Fall, eine externe Tabelle durch Neuerstellung in eine verwaltete Nicht-ACID-Tabelle zu konvertieren.
  4. In Hive 3 wurde viel Funktionalität über Vektorisierung, CBO, Zeitstempel mit Zeitzonen usw. ausgeführt, was möglicherweise zu Bugs führte. Wenn also eine Abfrage falsche Ergebnisse liefert, versuchen Sie, Vektorisierung, CBO, Zuordnungsjoins usw. zu deaktivieren, um zu sehen, ob dies hilft.

Weitere Schritte zum Korrigieren falscher Ergebnisse und schwacher Leistung nach der Migration

  1. Problem: Hive-Abfrage führt zu falschem Ergebnis. Selbst die Abfrage „select count(*)“ gibt ein falsches Ergebnis zurück.

    Ursache: Die Eigenschaft „hive.compute.query.using.stats“ ist standardmäßig auf „true“ festgelegt. Bei Festlegung auf „true“ werden die Statistiken verwendet, die im Metastore gespeichert sind, um die Abfrage auszuführen. Wenn die Statistiken nicht auf dem neuesten Stand sind, führt dies zu falschen Ergebnissen.

    Lösung: Erfassen Sie die Statistiken für verwaltete Tabellen mit dem Befehl alter table <table_name> compute statics; auf Tabellen- und auf Spaltenebene. Link zur Referenz: https://cwiki.apache.org/confluence/display/hive/statsdev#StatsDev-TableandPartitionStatistics

  2. Problem: Die Ausführung von Hive-Abfragen dauert lange.

    Ursache: Wenn die Abfrage eine Joinbedingung enthält, erstellt Hive basierend auf der Tabellengröße und der Joinbedingung einen Plan, ob „map join“ oder „merge join“ verwendet werden sollen. Wenn eine der Tabellen klein ist, lädt Hive diese Tabelle in den Arbeitsspeicher und führt den Joinvorgang aus. Auf diese Weise erfolgt die Abfrageausführung im Vergleich zu einem Mergejoin schneller.

    Lösung: Stellen Sie sicher, dass die Eigenschaft „hive.auto.convert.join=true“ auf festgelegt ist – den Standardwert. Bei Festlegung auf „false“ wird ein Mergejoin verwendet, was zu einer schwachen Leistung führen kann. Hive entscheidet anhand der folgenden Eigenschaften, die im Cluster festgelegt sind, ob ein Zuordnungsjoin verwendet werden soll oder nicht.

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

    Ein allgemeiner Joinvorgang kann automatisch in einen Zuordnungsjoin konvertiert werden, wenn hive.auto.convert.join.noconditionaltask=true festgelegt ist und die geschätzte Größe der kleinen Tabellen kleiner ist als Hive.auto.convert.join.noconditionaltask.size (Standardwert: 10.000.000 MB).

    Wenn durch Festlegen der Eigenschaft hive.auto.convert.join auf „true“ ein Problem in Bezug auf OOM auftritt, ist es ratsam, die Eigenschaft auf Sitzungsebene (nicht auf Clusterebene) nur für diese spezielle Abfrage auf „false“ festzulegen. Dieses Problem kann auftreten, wenn die Statistiken falsch sind und Hive sich entscheidet, basierend auf den Statistiken einen Zuordnungsjoin zu verwenden.

  • Problem: Eine Hive-Abfrage gibt das falsche Ergebnis zurück, wenn die Abfrage eine Joinbedingung enthält und die beteiligten Tabellen NULL-Werte oder leere Werte aufweisen.

    Ursache: Zuweilen kann ein Problem in Bezug auf NULL-Werte auftreten, wenn die beteiligten Tabellen viele NULL-Werte aufweisen. Hive führt die Abfrageoptimierung fälschlicherweise mit den beteiligten NULL-Werten aus, was zu falschen Ergebnissen führt.

    Lösung: Versuchen Sie, die Eigenschaft set hive.cbo.returnpath.hiveop=true auf Sitzungsebene festzulegen, wenn Sie falsche Ergebnisse erhalten. Diese Konfiguration führt keine NULL-Filterung für Joinschlüssel ein. Wenn die Tabellen viele NULL-Werte enthalten, können Sie diese Konfiguration zum Optimieren des Joinvorgangs zwischen mehreren Tabellen aktivieren, sodass nur die Nicht-NULL-Werte berücksichtigt werden.

  • Problem: Eine Hive-Abfrage gibt das falsche Ergebnis zurück, wenn sie mehrere Joinbedingungen enthält.

    Ursache: Zuweilen erzeugt Tez ungenügende Laufzeitpläne, wenn dieselben Joins mehrmals mit Zuordnungsjoins vorhanden sind.

    Lösung: Beim Festlegen von hive.merge.nway.joins auf „false“ können falsche Ergebnisse zurückgegeben werden. Versuchen Sie, die Einstellung nur für die betroffene Abfrage auf „true“ festzulegen. Dies hilft bei Abfragen mit mehreren Joins unter derselben Bedingung. Mergen Sie Joins zu einem einzigen Joinoperator. Diese Methode ist nützlich, wenn große Shufflejoins durchgeführt werden, um eine Reshufflingphase zu vermeiden.

  • Problem: Tägliche Abfrageausführungen dauern länger im Vergleich zu früheren Ausführungen.

    Ursache: Dieses Problem kann auftreten, wenn mehr kleine Dateien vorhanden sind. Hive benötigt Zeit zum Lesen aller Dateien, um die Daten zu verarbeiten, was die Ausführungszeit verlängert.

    Lösung: Führen Sie häufig eine Komprimierung der Tabellen aus, die verwaltet werden. Mit diesem Schritt vermeiden Sie die Anhäufung kleiner Dateien und verbessern die Leistung.

    Referenzlink: Hive Transactions – Apache Hive – Apache Software Foundation.

  • Problem: Hive-Abfragen führen zu falschen Ergebnissen, wenn der Kunde eine Joinbedingung in einer verwalteten ACID-ORC-Tabelle oder einer verwalteten Nicht-ACID-ORC-Tabelle verwendet.

    Ursache: Ab Hive 3 ist es unbedingt erforderlich, alle verwalteten Tabellen als ACID-Tabellen einzurichten. Wenn Tabellen als ACID-Tabellen beibehalten werden sollen, muss das Tabellenformat ORC sein – das ist das wichtigste Kriterium. Wenn Sie jedoch die Eigenschaft „hive.strict.managed.tables“ für strikt verwaltete Tabellen mit „false“ deaktivieren, können Sie eine verwaltete Nicht-ACID-Tabelle erstellen. In manchen Fällen erstellen Kunden eine externe ORC-Tabelle oder konvertieren eine Tabelle nach der Migration in eine externe Tabelle, und die Kunden deaktivieren die Eigenschaft für strikt verwaltete Tabellen und konvertieren die Tabelle in eine verwaltete Tabelle. An diesem Punkt wird die Tabelle in ein verwaltetes Nicht-ACID-ORC-Format konvertiert.

    Lösung: Die Hive-Optimierung funktioniert falsch, wenn Sie einen Tabellenjoin einer verwalteten Nicht-ACID-ORC-Tabelle mit einer verwalteten ACID-ORC-Tabelle ausführen.

    Wenn Sie eine externe Tabelle in eine verwaltete Tabelle konvertieren:

    1. Legen Sie die Eigenschaft „hive.strict.managed.tables“ nicht auf „false“ fest. Wenn Sie diese Eigenschaft festlegen, können Sie eine verwaltete Nicht-ACID-Tabelle erstellen, dies ist in Hive 3 jedoch nicht erforderlich.
    2. Konvertieren Sie die externe Tabelle in eine verwaltete Tabelle, indem Sie statt alter table <table_name> set TBLPROPERTIES ('EXTERNAL'='false'); den folgenden ALTER-Befehl verwenden:
    alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Handbuch zur Problembehandlung

Das HDInsight 3.6 zu 4.0-Handbuch zur Problembehandlung bei Hive-Workloads enthält Lösungen für häufige Probleme bei der Migration von Hive-Workloads von HDInsight 3.6 zu HDInsight 4.0.

Weitere Informationsquellen