Welche Methode wird empfohlen, um einen DataProc-Cluster zu aktualisieren?

Question

Dataproc scheint als zustandslos/unveränderbar zu gelten. Ist diese Annahme richtig? Sollten wir gerade aufhören, wenn wir ein Hive/Presto Data Warehouse bereitstellen wollen?

Wir haben Schwierigkeiten, eine Dokumentation zu finden, die vorschlägt, wie man sich um einen Cluster kümmern sollte, wenn er einmal bereitgestellt wurde?

• Wie werden Komponenten aktualisiert?
• Wie installiert man Werkzeuge (z. B. Farbton usw.), nachdem ein Cluster erstellt wurde?
• Wie sichere den Zugriff auf Daten + Dienste nach der Bereitstellung?

Die FAQs "Kann ich einen persistenten Cluster ausführen?" adressiere das auch nicht wirklich.

Das Internet schlägt vor, wir sollten nur einen neuen Cluster erstellen, wenn wir ein Problem haben. Als Entwickler bin ich ziemlich glücklich mit dem "Minimize State" -Argument, aber ich arbeite in der Unternehmenswelt wie Lösungen wie Hive (und seinen Metadatenspeicher), Hue und Zeppellin und möchte externe Tools wie Tableau zu einem Cluster verbinden.

Die Dokumentation sollte wirklich deutlich machen, welche Use-Cases dataproc (Batch, on-demand & kurzlebige Workloads) im Vergleich zu Dingen, für die es nicht wirklich entwickelt wurde (z. B. OLAP), ausgezeichnet ist?

Answer 1

Dataproc bietet zwar den größten Nutzen für On-Demand-Anwendungsfälle, dies steht jedoch nicht im Widerspruch zur Verwendung für OLAP. Die Hauptidee ist, dass die statusbehafteten Komponenten alle von den "verarbeitenden" Ressourcen getrennt werden können, so dass Sie Ressourcen zu verschiedenen Zeitpunkten besser an die Bedürfnisse anpassen können.

Die empfohlene Architektur für Ihre Hive-Metadaten besteht darin, Ihr Hive-Metastreed-Back-End vom Cluster fernzuhalten, z. in einer CloudSQL-Instanz; Viele sind in der Lage, Dataproc auf diese Weise mit kurzlebigen oder kurzlebigen Clustern zu nutzen (z. B. einen Pool von Live-Clustern zu halten, aber die ältesten jeden Tag oder jede Woche zu löschen/neu zu erstellen), kombiniert mit Initialisierungsaktionen, die den Hiveserver auf CloudSQL verweisen: https://github.com/GoogleCloudPlatform/dataproc-initialization-actions/tree/master/cloud-sql-proxy

In dieser Welt sind die Stateful Metastore Stücke alle in CloudSQL und Massenspeicher ist alles in GCS. Einige Cluster können aus Performance-Gründen (vor allem wenn HDFS auf lokaler SSD ausgeführt wird) aus GCS mit lokalem HDFS synchronisiert werden, aber selbst für interaktive OLAP-Anwendungsfälle ist dies normalerweise nicht erforderlich. Das Ausführen von Abfragen direkt gegen GCS funktioniert auch. Es gibt zugegebenermaßen einige Performance-Probleme für ältere Formate aufgrund der längeren Round-Trip-Latenz zu GCS, aber ein bisschen Tuning kann es meistens inline bringen; hier ist ein (nicht von Google gehaltener) blog post about Presto on Dataproc, der einige davon durchgeht.

Dies bietet auch viel einfacher Möglichkeiten, traditionelle Cluster-Admin zu behandeln; Bei Upgrades werden nur ganze Cluster ausgetauscht, bei Initialisierungsaktionen sollten zusätzliche Tools verwendet werden, um eine einfache Reproduzierbarkeit für neue Cluster zu gewährleisten, und Sie können Sicherheitsperimeter leichter pro Clustergranularität definieren.