Categories
NEWS

Ausführen von Apache Hive 3, neue Funktionen sowie Tipps und Tricks

Apache Hive 3 bringt eine Reihe neuer und netter Funktionen in das Data Warehouse. Leider gibt es, wie viele große FOSS-Versionen, einige Fehler und nicht viel Dokumentation. Es ist seit Juli 2018 als Teil von erhältlich HDP3 (Hortonworks Data Platform Version 3).

Ich werde zuerst die neuen Funktionen von Hive 3 überprüfen und dann einige Tipps und Tricks geben, die ich aus der Ausführung in der Produktion für einige Monate gelernt habe. Der erste Teil des Artikels basiert auf dem Vortrag Was ist neu in Apache Hive? gegeben von Jason Dere am DataWorks Summit 2019 Barcelona.

Hive 3 neue Funktionen

In Hive 3 wurden viele Funktionen und Verbesserungen implementiert, wodurch die Anwendungsfälle, die es abdecken kann, erheblich erweitert wurden. Lassen Sie uns diejenigen zusammenfassen, die in HDP3 verfügbar sind (die meisten davon).

Materialisierte Ansichten (MV)

Materialized Views (MV) sind endlich in HDP verfügbar. Sie bringen mehr als traditionelle Ansichten:

  • Lagerung für Zwischenergebnisse: Wie der Name schon sagt, werden materialisierte Ansichtsergebnisse gespeichert, sodass die Rechenkosten gegenseitig verteilt werden können.
  • Inkrementeller Wiederaufbau: Beim Aktualisieren einer materialisierten Ansicht werden nur die Daten berechnet, die seit der letzten Aktualisierung in die Quellentabellen eingefügt wurden.
  • Umschreiben von Abfragen: Gegebenenfalls verwendet der kostenbasierte Optimierer vorhandene materialisierte Ansichten, um Abfragen anstelle der Quellentabellen zu planen, ohne dass der Benutzer davon Kenntnis hat!

Ausführliche Informationen zu materialisierten Ansichten finden Sie im Artikel meines Kollegen Paul-Adrien Cordonnier Beschleunigung der Abfrageverarbeitung mit materialisierten Ansichten in Apache Hive.

SQL-Funktionen

Einschränkungen und Standardwerte

Es ist jetzt möglich zu verwenden UNIQUE und NOT NULL SQL-Einschränkungen zusätzlich zu PRIMARY|FOREIGN KEY (hinzugefügt in Hive 2.1). Darüber hinaus können Sie a angeben DEFAULT Wert für jede Spalte und verwenden Sie diesen Standardwert in INSERT und UPDATE Aussagen.

CREATE TABLE users (
  id INT NOT NULL,
  firstname STRING,
  lastname STRING,
  join_date DATE DEFAULT CURRENT_DATE(),
  PRIMARY KEY (id) DISABLE NOVALIDATE
);
INSERT INTO TABLE users VALUES (1, 'John', 'Doe', DEFAULT);

Tabelleninformationen

Hive 3 ermöglicht eine einfache Erkundung des gesamten Lagers mit information_schema und sys Datenbanken:

SELECT table_schema, table_name
FROM information_schema.columns
WHERE column_name LIKE '%ssn%';

JDBC-, Druiden- und Kafka-Konnektoren

Für externe Tabellen stehen 2 neue Anschlüsse zur Verfügung:

Im Zusammenhang mit letzterem, genau einmalige Einnahme von Kafka zu Druide kann durch Hive erfolgen.

ACID v2

Hive ACID (Atomizität, Konsistenz, Isolation, Haltbarkeit) hat viel zu den Hive-Fähigkeiten für Eimer beigetragen Apache ORC verwaltete Tabellen:

  • Streaming-Aufnahme von Daten;
  • Nahtlos INSERT/.UPDATE/.DELETE Operationen an vorhandenen Tabellen.

Die zweite Version von ACID enthält mehrere Verbesserungen:

  • Leistung genauso gut wie Nicht-ACID;
  • Transaktionstabellen (Tabellen, die ACID unterstützen) müssen nicht mehr mit Buckets versehen werden.
  • Unterstützung für Nicht-ORC-Formate für INSERT/.SELECT;;
  • Kompatibilität mit Cloud-Speicheranbietern, z. Amazon S3;;
  • Neu HiveStreaming API (v2).

Hortonworks hat beschlossen, ACID standardmäßig in zu aktivieren HDP3. Beispielsweise müssen verwaltete ORC-Tabellen transaktional sein.

Leider kommt das meiste Problem, mit dem ich mit Hive 3 konfrontiert war, von Hive ACID und der HiveStreaming-API, wie wir im zweiten Teil des Artikels sehen werden.

Hive Warehouse Connector für Apache Spark

Ab HDP 3.0 werden alle Interaktionen zwischen Hive und Apache Spark muss durch die gehen Hive Warehouse Connector. Dieser Anschluss nutzt Hive LLAP um Streaming / ACID-Interaktion zwischen Hive und Spark zu ermöglichen. Die Spark-Anwendung muss auf einen Hive Server Interactive (mit aktiviertem LLAP) zugreifen, um von Hive verwaltete Tabellen zu lesen. Sie muss jedoch nicht in von Hive verwaltete Tabellen schreiben oder externe Hive-Tabellen lesen / schreiben. Seien Sie nicht überrascht, wenn die herkömmliche Art des Zugriffs auf Hive-Tabellen von Spark nicht mehr funktioniert!




Hive Warehouse Connector

LLAP-Workload-Management

Das ist großartig neue Funktion verbessert Ihre Kontrolle über Hive LLAP (Lang leben und verarbeiten) in mandantenfähigen Umgebungen mit Ressourcenpläne::

  • Teilen Sie Ihre LLAP-Ressourcen in Pools auf, z. bi (zum Geschäftsanalysen) und etl (zum Transformation extrahieren und laden);
  • Ordnen Sie Anwendungen automatisch Pools zu, z. Tableau zum bi Schwimmbad;
  • Erstellen Sie Trigger, um Anwendungen dynamisch von einem Pool in einen anderen zu verschieben, z. Verschieben Sie lang laufende Abfragen in die etl Schwimmbad;
  • Aktivieren / Deaktivieren Sie Ihre Ressourcenpläne basierend auf den Anforderungen Ihrer Benutzer (jeweils aktiv).
CREATE RESOURCE PLAN my_plan;
CREATE POOL my_plan.bi
WITH ALLOC_FRACTION=70,QUERY_PARALLELISM=4;
CREATE POOL my_plan.etl
WITH ALLOC_FRACTION=30,QUERY_PARALLELISM=10;
CREATE TRIGGER my_plan.slow_query
WHEN execution_time_ms > 60000
DO MOVE TO etl;
ALTER PLAN my_plan SET DEFAULT POOL=bi;
ALTER PLAN my_plan ENABLE ACTIVATE;

Verbesserte Leistung

Basierend auf einem aktuellen TPC-DS Benchmark von der MR3-Team, Hive LLAP 3.1.0 ist das schnellste SQL-on-Hadoop-System, das in HDP 3.0.1 verfügbar ist. Der Benchmark vergleicht alle mit HDP3 sowie Hive on MR3 (einer neuen Ausführungs-Engine für Hadoop und Kubernetes) eingebetteten SQL-Systeme, indem 99 SQL-Abfragen ausgeführt werden.

System Gesamtlaufzeit von TCP-DS (Sekunden)
HDP 3.0.1 LLAP 5516,89
Hive 3.1.0 / MR3 6575.052
HDP 3.0.1 Tez 12227.317
Presto 0.208e 12948,224
Funke 2.3.1 26247.471

Ich lade Sie ein, das Ganze vollständig zu lesen Leistungsbewertung von SQL-on-Hadoop-Systemen mithilfe des TPC-DS-Benchmarks und Jason Dere Folien über die Leistung Weitere Informationen darüber, was Hive 3 schneller macht.

Hive 3 Tipps und Tricks

Ich habe eine Instanz von Hive 3 seit mehr als 5 Monaten ausgeführt und gewartet. Während dieser Zeit bin ich auf einige Stabilitätsprobleme gestoßen und habe Lösungen implementiert, die manchmal schwierig sind. Weitere Details zum Hive Konfiguration verwendet werden sind am Ende des Artikels verfügbar.

Wenn Sie Hive 3 ausführen möchten, können Sie Probleme wahrscheinlich identifizieren und beheben, zumindest bevor sie in einer nächsten offiziellen Version behoben werden.

Speicherlecks in der HiveStreaming-API

Die zuvor erwähnte neue HiveStreaming-API hat 2 bekannte Speicherlecks ((HIVE-20979). Dies wirkt sich auf alle Clientanwendungen aus, die die API verwenden und aufgrund von JVM (Java virtuelle Maschine) Problem mit der Heap-Größe.

In meinem Fall war die Client-Anwendung Apache NiFi und sein PutHive3Streaming-Prozessor. Dies ist der offizielle Prozessor, der mit NiFi 1.7.0 zum Schreiben in Hive 3.0+ geliefert wird. Da nutzt es die HiveStreaming API (v2)Mein NiFi-Cluster stürzte nach einigen Stunden immer ab.

Ich habe einige Zeit mit der Fehlerbehebung bei NiFi verbracht und den Prozessor neu geschrieben (NiFi Hive3Streaming behoben). Diese Neuimplementierung bettet die von der Hive-Community bereitgestellten Korrekturen ein (HIVE-20979). Wenn Sie mehr über dieses spezielle NiFi-Problem erfahren möchten, lesen Sie den entsprechenden Artikel Fehlerbehebung bei einer NiFi-HiveStreaming-Pipeline (demnächst).

Wenn Sie sich das genau ansehen HIVE-20979 JIRA Problem, werden Sie sehen, dass das Update in Hive 3.1.1 Version sein soll. Trotzdem ist es nicht… Aber das ist nicht so schlimm, denn selbst wenn es behoben wäre, müssten Sie warten, bis Hortonworks es in Hive 3.1.1 verschiebt und Ihren gesamten Cluster aktualisiert (falls Sie HDP ausführen).

Das Gute an diesem HiveStreaming-Problem ist, dass Sie damit umgehen können. Schauen Sie sich beim Umschreiben des Prozessors die von der Hive-Community bereitgestellten Korrekturen an (HIVE-20979) und binden Sie die betroffenen Java-Klassen in Ihre Anwendung ein. Fühlen Sie sich frei, Teile von mir wiederzuverwenden Code auf GitHub veröffentlicht wenn Sie brauchen!

Probleme mit Hive ACID-Komprimierungen

Wie bereits erwähnt, sind Hive-Tische Transaktion Standardmäßig dürfen in HDP 3 und verwalteten ORC-Tabellen keine Transaktionen durchgeführt werden. Das bedeutet, dass sie ACID-Operationen unterstützen:

  • Atomarität: eine Operation ist entweder erfolgreich oder schlägt fehl;
  • Konsistenz: Sobald eine Operation ausgeführt wurde, werden bei jeder nachfolgenden Operation die Ergebnisse angezeigt.
  • Isolation: Eine unvollständige Operation wirkt sich nicht auf andere Operationen aus.
  • Haltbarkeit: Sobald ein Vorgang abgeschlossen ist, bleibt er auch gegen Maschinen- / Systemausfälle erhalten.

Während dies mehr gibt Funktionalitäten Für Tabellen bringt dies auch neue Herausforderungen mit sich, da der interne Mechanismus von Transaktionstabellen komplexer ist. Ich habe mehrere Probleme mit dem Verdichtungssystem festgestellt.

Was sind Hive-Verdichtungen?

Bevor Sie die Probleme detailliert beschreiben, müssen Sie wissen, was Komprimierungen sind und warum sie benötigt werden Hive ACID.

Um ACID zuzulassen, wird jede Transaktion (INSERT, UPDATE, DELETE) auf einen Eimer erstellt neue darin gespeicherte Dateien delta Verzeichnisse. Jede Tabellenpartition enthält ein Basisverzeichnis und mehrere Delta-Verzeichnisse:

hdfs dfs -ls -R /warehouse/tablespace/managed/hive/d.db/t
drwxr-xr-x   - hive hive     0 2016-06-09 17:03 /warehouse/tablespace/managed/hive/d.db/t/base_0000022
-rw-r--r--   1 hive hive   602 2016-06-09 17:03 /warehouse/tablespace/managed/hive/d.db/t/base_0000022/bucket_00000
drwxr-xr-x   - hive hive     0 2016-06-09 17:06 /warehouse/tablespace/managed/hive/d.db/t/delta_0000023_0000023_0000
-rw-r--r--   1 hive hive   611 2016-06-09 17:06 /warehouse/tablespace/managed/hive/d.db/t/delta_0000023_0000023_0000/bucket_00000
drwxr-xr-x   - hive hive     0 2016-06-09 17:07 /warehouse/tablespace/managed/hive/d.db/t/delta_0000024_0000024_0000
-rw-r--r--   1 hive hive   610 2016-06-09 17:07 /warehouse/tablespace/managed/hive/d.db/t/delta_0000024_0000024_0000/bucket_00000

Wie zu erwarten ist, befinden sich in einer Partition so viele Delta-Verzeichnisse wie getätigte Transaktionen (tatsächlich werden Transaktionen in Stapeln gruppiert und festgeschrieben). Dies kann im Falle einer Streaming-Aufnahme schnell zu einem Problem werden, da Hive bei jeder Anforderung immer mehr Dateien lesen muss.

Um Hive-Leistungen zu sparen, gibt es zwei Arten von Verdichtungen:

  • Kleinere Verdichtungen Zusammenführen der Delta-Dateien eines Buckets zu einer Delta-Datei;
  • Hauptverdichtungen um alle Delta-Dateien eines Buckets mit der vorhandenen Basisdatei dieses Buckets zusammenzuführen.

Standardmäßig soll Hive automatisch Komprimierungen basierend auf einer Reihe von Eigenschaften auslösen (siehe die offizielle Dokumentation). Nach meiner Erfahrung funktioniert dies jedoch nicht wirklich wie erwartet…

Komprimierungen werden nicht ausgelöst

Nachdem ich einige Zeit mit Transaktionstabellen als Senken eines NiFi-Datenflusses gearbeitet hatte, stellte ich fest, dass die Komprimierungen nicht ordnungsgemäß funktionierten. Das Verhalten, das ich beobachtet habe, ist das folgende:

  1. Es wird eine neue Partition erstellt, die weder eine Basis- noch eine Delta-Datei enthält.
  2. Hive prüft diese Partition während ihrer Überprüfungsschleife auf Komprimierungen. Sie können sehen, welche Partitionen in der überprüft werden hivemetastore.log Datei:

    cat /var/log/hive/hivemetastore.log | grep -P 'Checking to see if we should compact'
  3. Da keine Basisdatei vorhanden ist, wird der Schwellenwert zum Erstellen der Basisdatei bei der ersten Überprüfung erreicht (da Delta-Dateien einen unendlichen Prozentsatz der Partitionsgröße darstellen).
  4. Die Hauptkomprimierung wird ausgelöst und die Basisdatei erstellt.
  5. Danach wird die Partition nicht mehr überprüft…

Anscheinend bin ich nicht der einzige, der mit diesem Problem konfrontiert ist (Frage zum Stapelüberlauf), obwohl ich nicht sicher bin, ob sich jeder damit auseinandersetzen wird, und ich habe die Grundursache nicht gefunden.

Nach dem Versuch, die einzustellen hive.compactor.* Parameter ohne Erfolg, schrieb ich schließlich einen automatisierten Workflow mit Apache Oozie um größere Verdichtungen „manuell“ auszulösen. Der Workflow führt auf Datenbankebene alle 10 Minuten Folgendes aus:

  1. Holen Sie sich eine Liste der Delta-Verzeichnisse und Basisverzeichnisse mit einem Bash-Skript:

    
    hdfs dfs -ls -R "/warehouse/tablespace/managed/hive/$target_db.db" 
    | grep 'drwx' | grep -P -o '[^ ]*(delta_d7|base)_d7_*d0,4$' 
  2. Analysieren Sie die Liste und generieren Sie eine Komprimierungsabfrage für jede Partition, die sie benötigt. Ich mache das mit einem Python Skript.
  3. Senden Sie die generierten Abfragen an Hive, was ich mache Beeline das ermöglicht das Senden einer parametrisierten Abfragedatei:

    
    ALTER TABLE target_db.tbl1 PARTITION (col1 = 'value1') COMPACT 'major';

Auf diese Weise können Sie die Leistung von Hive sicherstellen, wenn bei Komprimierungen dieselben Probleme auftreten. Wenn Sie dies tun, achten Sie auf:

  • Das GARN Warteschlange, in der Sie Ihre Komprimierungsabfragen veröffentlichen. Um eine Bestrafung Ihrer Benutzer zu vermeiden und sicherzustellen, dass die Komprimierungen nicht verzögert werden, würde ich vorschlagen, eine Warteschlange einzurichten.
  • Das yarn.scheduler.capacity[.queue].maximum-am-resource-percent Eigenschaft, die standardmäßig 20% ​​beträgt. Jede Komprimierung startet 1 Anwendungsmaster und 1 Kartenaufgabe, daher möchten Sie möglicherweise die erhöhen maximum-am-resource-percent, insbesondere wenn Sie eine Warteschlange reservieren. In diesem Fall können Sie mit dieser Eigenschaft auch steuern, wie viele Komprimierungen parallel ausgeführt werden.
  • Der vom Verdichter verwendete Speicher. Wenn Sie feststellen, dass einige Komprimierungsaufträge zu lange dauern, können Sie die überschreiben compactor.mapreduce.map.memory.mb auf Tabellenebene oder wenn Sie die Komprimierung abfragen:

    ALTER TABLE target_db.tbl1 PARTITION (col1 = 'value1')
    COMPACT 'major'
    WITH OVERWRITE TBLPROPERTIES ('compactor.mapreduce.map.memory.mb' = '3072');
  • Die maximale Anzahl von Delta-Dateien, die gleichzeitig mit dem komprimiert wurden hive.compactor.max.num.delta Eigentum. Dies hilft dabei, die Zeit für Komprimierungen konstanter zu gestalten und Ausnahmen von „OutOfMemory“ zu vermeiden:

    hive.compactor.max.num.delta = 100
  • Die Tabelleneigenschaft NO_AUTO_COMPACTION, das ist false standardmäßig. Wenn Sie nicht möchten, dass Hive Ihre benutzerdefinierte Verdichtungsplanung stört, können Sie diese festlegen true auf bestimmten Tabellen:

    CREATE TABLE target_db.tbl1 (
    ...
    )
    TBLPROPERTIES ('NO_AUTO_COMPACTION' = 'true');

Fehler beim Reinigen des Identitätswechsels

Wenn du benutzt Apache Ranger um Hive-Berechtigungen zu verwalten, die Eigenschaft hive.server2.enable.doAs ist eingestellt auf false Damit wird jeder Vorgang, der über den Hive Server ausgeführt wird, als ausgeführt hive. Das hive Der Benutzer ist daher normalerweise der Eigentümer aller Dateien verwalteter Tabellen.

Wenn Sie jedoch HiveStreaming zum Einfügen von Daten in Tabellen verwenden, sprechen Sie nicht mit dem Hive-Server, sondern direkt mit dem Hive-Metastore! Aus diesem Grund müssen Sie auf die Benutzeranmeldeinformationen achten, die zum Aufrufen der API verwendet werden. Wenn hive ist nicht der Eigentümer der Tabellenpartitionen, möglicherweise tritt dieser Fehler in der auf hivemetastore.log Datei:

2019-03-03T00:00:00,799 ERROR [pool-8-thread-188]: server.TThreadPoolServer (TThreadPoolServer.java:run(297)) - Error occurred during processing of message.
java.lang.RuntimeException: org.apache.thrift.transport.TTransportException: Peer indicated failure: GSS initiate failed
...
Caused by: org.apache.thrift.transport.TTransportException: Peer indicated failure: GSS initiate failed

Wenn Sie den Debug-Modus aktivieren, erhalten Sie den Ursprung des Fehlers:

2019-03-14T12:55:46,299 ERROR [Thread-19]: transport.TSaslTransport (TSaslTransport.java:open(315)) - SASL negotiation failure
javax.security.sasl.SaslException: GSS initiate failed
...
    at java.security.AccessController.doPrivileged(Native Method) [?:1.8.0_112]
    at javax.security.auth.Subject.doAs(Subject.java:422) [?:1.8.0_112]
...
    at org.apache.hadoop.hive.ql.txn.compactor.Cleaner.removeFiles(Cleaner.java:352) [hive-exec-3.1.0.3.0.1.0-187.jar:3.1.0.3.0.1.0-187]
    at org.apache.hadoop.hive.ql.txn.compactor.Cleaner.access$000(Cleaner.java:64) [hive-exec-3.1.0.3.0.1.0-187.jar:3.1.0.3.0.1.0-187]
    at org.apache.hadoop.hive.ql.txn.compactor.Cleaner$1.run(Cleaner.java:304) [hive-exec-3.1.0.3.0.1.0-187.jar:3.1.0.3.0.1.0-187]
    at java.security.AccessController.doPrivileged(Native Method) [?:1.8.0_112]
    at javax.security.auth.Subject.doAs(Subject.java:422) [?:1.8.0_112]
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1730) [hadoop-common-3.1.1.3.0.1.0-187.jar:?]
    at org.apache.hadoop.hive.ql.txn.compactor.Cleaner.clean(Cleaner.java:301) [hive-exec-3.1.0.3.0.1.0-187.jar:3.1.0.3.0.1.0-187]
    at org.apache.hadoop.hive.ql.txn.compactor.Cleaner.run(Cleaner.java:169) [hive-exec-3.1.0.3.0.1.0-187.jar:3.1.0.3.0.1.0-187]
Caused by: org.ietf.jgss.GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)

Dieser Fehler bedeutet, dass die Reiniger, der für das Entfernen veralteter Delta-Dateien verantwortlich ist, konnte sich nicht als Benutzer ausgeben, dem die Partition gehört.

Der einfachste Weg, um dieses Problem zu lösen, besteht darin, den Benutzer zu machen hive Besitzer der Partitionen. In einer kerberisierten Umgebung können Sie die verwenden hive Keytab beim Abfragen der HiveStreaming-API.

Abfragen von Daten während der Komprimierung

Während ACID während garantiert ist INSERT, UPDATE und DELETE Was ich gesehen habe, ist, dass das Starten einer tabellenweiten Operation bei laufenden Komprimierungen zu Fehlern führen kann, da Delta-Dateien gelöscht werden. Um diese Parallelitätsprobleme zu vermeiden, trenne ich das Einfügen von der Abfrage mit der folgenden Architektur:

  • Eine Tabelle wird für ACID-Operationen verwendet, z. Echtzeitaufnahme von NiFi über HiveStreaming;
  • Eine materialisierte Ansicht wird über der Tabelle erstellt und zum Abfragen verwendet.

Um das gleiche Problem wie beim Abfragen zu vermeiden, müssen Komprimierungen während der Neuerstellung der materialisierten Ansicht angehalten werden, was dank der schrittweisen Neuerstellung hoffentlich schnell gehen sollte.

Fazit

In diesem Artikel haben wir alle neuen Funktionen von Hive 3 besprochen. Es gibt viele davon und sie sind sehr ansprechend. Sie haben jedoch festgestellt, dass es nicht so einfach ist, eine Hive 3-Instanz zu warten. Dies sollte Ihnen einige Vor- und Nachteile geben, um zu entscheiden, ob Sie auf Hive 3 aktualisieren möchten oder nicht.

Bonus-Tipps

Hier sind einige Tipps, mit denen Sie einige Zeit gewinnen können.

Lagerort

In HDP 3 hat sich der Standort des Hive-Lagers geändert. Verwaltete Tabellen finden Sie in HDFS auf dem Weg:

/warehouse/tablespace/managed/hive/

Fehler aufgrund materialisierter Ansichten

Während der Wartung des Lagers kann dieses beunruhigende, mysteriöse Problem auftreten:

DROP TABLE my_table;
...
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. MetaException(message:Couldn't acquire the DB log notification lock because we reached the maximum 

Auch wenn diese Fehlermeldung eine Empfehlung enthält, befolgen Sie sie nicht zu schnell! Überprüfen Sie zunächst die Anmeldungen hivemetastore.log und Sie werden sicherlich Folgendes finden:

2019-04-12T11:17:36,250 INFO  [pool-8-thread-174]: metastore.ObjectStore$RetryingExecutor (ObjectStore.java:run(9928)) - Attempting to acquire the DB log notification lock: 0 out of 5 retries
javax.jdo.JDODataStoreException: Error executing SQL query "select "NEXT_EVENT_ID" from "NOTIFICATION_SEQUENCE" for update".
...
Caused by: java.sql.BatchUpdateException: Batch entry 0 DELETE FROM "TBLS" WHERE "TBL_ID"=1852 was aborted: ERROR: update or delete on table "TBLS" violates foreign key constraint "MV_TABLES_USED_FK2" on table "MV_TABLES_USED"
  Detail: Key (TBL_ID)=(1852) is still referenced from table "MV_TABLES_USED".  Call getNextException to see other errors in the batch.
...
Caused by: org.postgresql.util.PSQLException: ERROR: update or delete on table "TBLS" violates foreign key constraint "MV_TABLES_USED_FK2" on table "MV_TABLES_USED"
  Detail: Key (TBL_ID)=(1852) is still referenced from table "MV_TABLES_USED".

Dies bedeutet im Grunde, dass eine materialisierte Ansicht auf die Tabelle verweist, die Sie löschen möchten, und dass Sie nicht über die Rechte für diese Ansicht verfügen. Stellen Sie die Tabellen- / MV-Berechtigungen entsprechend ein und Sie werden diese seltsame Meldung nicht mehr sehen.

Hive-Setup

Das Hive-Setup des von mir ausgeführten Clusters lautet wie folgt:

  • 2 Hive-Metastores – jeweils 12 GB RAM
  • 1 Hive Server 2 – 6 GB RAM
  • 1 Hive Server Interactive (LLAP) – 6 GB RAM
  • 3 Knoten mit LLAP-Dämonen – 32 GB RAM pro Dämon mit 18 GB für das Caching
  • Der Cluster ist mit Active Directory kerberisiert

Quellen

Leave a Reply

Your email address will not be published. Required fields are marked *