Apache Hive in Dataproc verwenden

Last reviewed 2023-05-08 UTC

In dieser Referenzarchitektur werden die Vorteile der Verwendung von Apache Hive in Dataproc auf effiziente und flexible Weise durch das Speichern von Hive-Daten in Cloud Storage und das Hosten des Hive-Metaspeichers in einer MySQL-Datenbank in Cloud SQL beschrieben.

Dieses Dokument richtet sich an Cloud-Architekten und Data Engineers, die Apache Hive auf Dataproc und den Hive-Metaspeicher in Cloud SQL bereitstellen möchten.

Architektur

Das folgende Diagramm zeigt den Lebenszyklus einer Hive-Abfrage.

Diagramm einer Architektur mit einer einzigen Region

Im Diagramm sieht der Lebenszyklus einer Hive-Abfrage folgendermaßen aus:

  1. Der Hive-Client sendet eine Abfrage an einen Hive-Server, der in einem sitzungsspezifischen Dataproc-Cluster ausgeführt wird.
  2. Der Hive-Server verarbeitet die Abfrage und fordert Metadaten aus dem Metaspeicherdienst an.
  3. Der Metaspeicherdienst ruft die Hive-Metadaten über den Cloud SQL-Proxy aus Cloud SQL ab.
  4. Der Hive-Server lädt Daten aus dem Hive-Warehouse in einem regionalen Bucket in Cloud Storage.
  5. Der Server gibt das Ergebnis an den Client zurück.

Designalternativen

Im folgenden Abschnitt wird eine mögliche Designalternative für diese Architektur vorgestellt.

Multiregionale Architektur

Sie können eine multiregionale Architektur in Betracht ziehen, wenn Sie Hive-Server an verschiedenen geografischen Regionen ausführen müssen. Erstellen Sie in diesem Fall separate Dataproc-Cluster, in denen der Metaspeicherdienst gehostet wird und die sich in derselben Region wie die Cloud SQL-Instanz befinden.

Der Metaspeicherdienst kann große Anfragenmengen an die MySQL-Datenbank senden. Deshalb ist es sehr wichtig, dass er sich in geografischer Nähe zu der MySQL-Datenbank befindet, um die Leistungseinbußen möglichst gering zu halten. Im Vergleich dazu sendet der Hive-Server normalerweise wesentlich weniger Anfragen an den Metaspeicherdienst. Daher kann es trotz der höheren Latenz eher akzeptabel sein, wenn sich der Hive-Server und der Metaspeicherdienst in verschiedenen Regionen befinden.

Der Metaspeicherdienst kann nur auf Dataproc-Masterknoten und nicht auf Worker-Knoten ausgeführt werden. Dataproc erzwingt mindestens 2 Worker-Knoten in Standardclustern und in Hochverfügbarkeits-Clustern.

Sie können stattdessen einen Cluster mit einem einzigen Knoten für den Metaspeicherdienst erstellen, um keine Ressourcen für nicht verwendete Worker-Knoten zu vergeuden. Erstellen Sie mehrere Cluster mit einem einzigen Knoten, wenn Sie eine Hochverfügbarkeit erzielen möchten.

Der Cloud SQL-Proxy muss nur auf den Metaspeicherdienst-Clustern installiert werden, da nur die Metaspeicherdienst-Cluster eine direkte Verbindung mit der Cloud SQL-Instanz benötigen. Die Hive-Server verweisen dann auf die Metadatenspeicher-Cluster, indem das hive.metastore.uris-Attribut auf die durch Kommas getrennte Liste der URIs gesetzt wird. Beispiel:

thrift://metastore1:9083,thrift://metastore2:9083

Sie können auch die Verwendung eines Buckets mit zwei oder mehreren Regionen in Betracht ziehen, wenn auf die Hive-Daten von Hive-Servern an mehreren Standorten zugegriffen werden muss. Ob ein Bucket-Standort ausgewählt wird, hängt vom jeweiligen Anwendungsfall ab. Sie müssen die Latenz, Verfügbarkeit und Kosten gegeneinander abwägen.

Das folgende Diagramm zeigt ein Beispiel für eine multiregionale Architektur.

Diagramm einer multiregionalen Hive-Architektur

Wie Sie sehen können, ist das multiregionale Szenario etwas komplexer und viel robuster. Im Bereitstellungsleitfaden für diese Referenzarchitektur wird ein Szenario mit einer einzelnen Region verwendet.

Vorteile einer multiregionalen Architektur

Die Trennung von Rechen- und Speicherressourcen bietet einige Vorteile:

  • Flexibilität: Sie können Clusterkonfigurationen auf bestimmte Hive-Arbeitslasten ausrichten und die Cluster unabhängig voneinander nach Bedarf skalieren.
  • Kosteneinsparungen: Sie können einen sitzungsspezifischen Cluster erstellen, sobald Sie einen Hive-Job ausführen müssen, und ihn wieder löschen, wenn er abgeschlossen ist. Die von den Jobs benötigten Ressourcen sind nur aktiv, wenn sie verwendet werden, sodass Sie nur für die tatsächliche Nutzung bezahlen. Außerdem können Sie für die Verarbeitung nicht kritischer Daten VMs auf Abruf verwenden oder sehr große Cluster mit niedrigeren Gesamtkosten erstellen.
  • Ausfallsicherheit: Der Einfachheit halber wird in dieser Referenzarchitektur nur eine Masterinstanz verwendet. Zum Erhöhen der Ausfallsicherheit in einer Produktionsumgebung empfiehlt es sich, mithilfe des Hochverfügbarkeitsmodus von Dataproc einen Cluster mit drei Master-Instanzen zu erstellen.

Kostenoptimierung

Für diese Referenzarchitektur und Bereitstellung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

  • Dataproc
  • Cloud Storage
  • Cloud SQL

Mit dem Preisrechner können Sie eine Kostenschätzung für die geplante Nutzung durchführen.

Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Bereitstellung

Informationen zum Bereitstellen dieser Architektur finden Sie unter Apache Hive in Dataproc bereitstellen.

Nächste Schritte