Dieses Dokument richtet sich an Operatoren und IT-Administratoren, die einen sicheren Datenzugriff für Datenanalysten mithilfe von BI-Tools (Business Intelligence) wie Tableau und Looker einrichten möchten. Sie bietet keine Anleitung zur Verwendung von BI-Tools oder zur Interaktion mit Dataproc-APIs.
Dieses Dokument ist der erste Teil einer Reihe, mit der Sie eine End-to-End-Lösung erstellen können, um Datenanalysten sicheren Zugriff auf Daten mit BI-Tools zu ermöglichen. In diesem Dokument werden die folgenden Konzepte erläutert:
- Eine vorgeschlagene Architektur.
- Eine allgemeine Ansicht der Komponentenbeschränkungen, Interaktionen und Netzwerke in der Architektur.
- Eine allgemeine Übersicht über Authentifizierung und Autorisierung in der Architektur.
Im zweiten Teil dieser Reihe, Visualisierungssoftware mit Hadoop in Google Cloud verbinden, erfahren Sie, wie Sie die Architektur in Google Cloud einrichten.
Architektur
Das folgende Diagramm zeigt die Architektur und den in diesem Dokument erläuterten Ereignisfluss. Weitere Informationen zu den in dieser Architektur verwendeten Produkten finden Sie unter Architekturkomponenten.
- Clientanwendungen stellen über Java-Datenbankkonnektivität (JDBC) eine Verbindung zu einem einzelnen Einstiegspunkt in einem Dataproc-Cluster her. Der Einstiegspunkt wird von Apache Knox bereitgestellt, das auf dem Clustermasterknoten installiert ist. Die Kommunikation mit Apache Knox ist durch TLS geschützt.
- Apache Knox delegiert die Authentifizierung über einen Authentifizierungsanbieter an ein System wie ein LDAP-Verzeichnis.
- Nach der Authentifizierung leitet Apache Knox die Nutzeranfrage an einen oder mehrere Back-End-Cluster weiter. Sie legen die Routen und die Konfiguration als benutzerdefinierte Topologien fest.
- Ein Datenverarbeitungsdienst wie Apache Hive überwacht den ausgewählten Back-End-Cluster und übernimmt die Anfrage.
- Apache Ranger fängt die Anfrage ab und bestimmt, ob die Verarbeitung erfolgen soll, abhängig davon, ob der Nutzer eine gültige Autorisierung hat.
- Wenn die Validierung erfolgreich ist, analysiert der Datenverarbeitungsdienst die Anfrage und gibt die Ergebnisse zurück.
Architekturkomponenten
Die Architektur setzt sich aus den folgenden Komponenten zusammen:
- Verwaltete Hadoop-Plattform:
- Dataproc. Dataproc ist Apache Spark, ein von Google Cloud verwalteter Apache Hadoop-Dienst, mit dem Sie Open-Source-Datentools für Batchverarbeitung, Abfragen, Streaming und maschinelles Lernen verwenden können. Dataproc ist die Plattform, die der in diesem Dokument beschriebene Lösung zugrunde liegt.
- Nutzerauthentifizierung und -autorisierung:
- Apache Knox. Apache Knox dient als einzelner HTTP-Zugangspunkt für alle zugrunde liegenden Dienste in einem Hadoop-Cluster. Apache Knox ist ein umgekehrter Proxy mit Plug-in-Anbietern für die Authentifizierung, Autorisierung, Prüfung und andere Dienste. Clients senden Anfragen an Knox. Basierend auf der Anfrage-URL und den Parametern leitet Knox die Anfrage an den entsprechenden Hadoop-Dienst weiter. Da Knox ein Einstiegspunkt ist, mit dem Clientanfragen transparent verarbeitet und die Komplexität minimiert wird, befindet sich Knox im Mittelpunkt der Architektur.
- Apache Ranger. Apache Ranger bietet eine differenzierte Autorisierung für Nutzer zum Durchführen bestimmter Aktionen in Hadoop-Diensten. Es prüft außerdem den Nutzerzugriff und implementiert administrative Maßnahmen.
- Verarbeitungssysteme:
- Apache Hive. Apache Hive ist eine Data-Warehouse-Software, die den Zugriff und die Verwaltung großer Datasets im verteilten Speicher mit SQL ermöglicht. Apache Hive parst die SQL-Abfragen, führt eine semantische Analyse durch und erstellt einen gerichteten azyklischen Graphen (Directed Acyclic Graph, DAG) für Phasen zur Ausführung einer Verarbeitungs-Engine. In der in diesem Dokument dargestellten Architektur fungiert Hive als Übersetzungspunkt zwischen den Nutzeranfragen. Es kann auch als eine der zahlreichen Verarbeitungs-Engines eingesetzt werden. Apache Hive ist in der Hadoop-Umgebung allgegenwärtig und ermöglicht Mitarbeitern, die mit Standard-SQL vertraut sind, Datenanalysen durchzuführen.
- Apache Tez. Apache Tez ist das Verarbeitungsmodul, das für die Ausführung der von Hive vorbereiteten DAGs und der Rückgabe der Ergebnisse zuständig ist.
- Apache Spark. Apache Spark ist eine einheitliche Analyse-Engine für die Verarbeitung großer Datenmengen, die die Ausführung von DAGs unterstützen. Die Architektur zeigt die Spark SQL-Komponente von Apache Spark, um die Flexibilität des in diesem Dokument vorgestellten Ansatzes zu demonstrieren. Eine Einschränkung besteht darin, dass Spark SQL keine offizielle Unterstützung für das Ranger-Plug-in bietet. Aus diesem Grund muss die Autorisierung über die weniger detaillierten ACLs in Apache Knox erfolgen, anstatt die detailgenaue Autorisierung von Ranger zu verwenden.
Komponenten – Übersicht
In den folgenden Abschnitten erhalten Sie weitere Informationen zu den einzelnen Komponenten. Sie erfahren auch, wie die Komponenten miteinander interagieren.
Clientanwendungen
Clientanwendungen umfassen Tools, die Anfragen an einen HTTPS-REST-Endpunkt senden können, aber nicht unbedingt die Dataproc Jobs API unterstützen. BI-Tools wie Tableau und Looker haben HiveServer2 (HS2)- und Spark SQL-JDBC-Treiber, die Anfragen über HTTP senden können.
In diesem Dokument wird davon ausgegangen, dass Clientanwendungen außerhalb von Google Cloud und in Umgebungen wie einer Analyst-Workstation, lokal oder in einer anderen Cloud ausgeführt werden. Daher muss die Kommunikation zwischen den Clientanwendungen und Apache Knox mit einem von einer Zertifizierungsstelle oder einem selbst signierten SSL/TLS-Zertifikat gesichert sein.
Einstiegspunkt und Nutzerauthentifizierung
Die Proxycluster sind ein oder mehrere langlebige Dataproc-Cluster, die das Apache Knox Gateway hosten.
Apache Knox fungiert als einzelner Einstiegspunkt für Clientanfragen. Knox wird auf dem Masterknoten des Proxy-Clusters installiert. Knox führt SSL-Beendigung durch, delegiert die Nutzerauthentifizierung und leitet die Anfrage an einen der Back-End-Dienste weiter.
In Knox wird jeder Back-End-Dienst in einer sogenannten Topologie konfiguriert. Der Topologie-Deskriptor definiert die folgenden Aktionen und Berechtigungen:
- Wie die Authentifizierung für einen Dienst delegiert wird.
- Den URI, an den der Back-End-Dienst weitergeleitet wird.
- Einfache Access Control Lists (ACLs) für einzelne Dienste.
Knox ermöglicht die Einbindung von Authentifizierung in Enterprise- und Cloud Identity-Verwaltungssysteme. Sie können Authentifizierungsanbieter verwenden, um die Nutzerauthentifizierung für jede Topologie zu konfigurieren. Knox verwendet Apache Shiro, um sich standardmäßig bei einem lokalen ApacheDS-LDAP-Demoserver zu authentifizieren.
Alternativ können Sie festlegen, dass Knox Kerberos verwenden soll. Im obigen Diagramm wird ein Active Directory-Server beispielsweise außerhalb des Clusters in Google Cloud gehostet.
Informationen zum Verbinden von Knox an Enterprise-Authentifizierungsdienste wie einen externen ApacheDS-Server oder Microsoft Active Directory (AD) finden Sie im Apache Knox-Nutzerhandbuch sowie in Google Cloud Managed Active Directory und der Federated AD-Dokumentation.
Für den Anwendungsfall in diesem Dokument gilt, dass Apache Knox als einzelner Gatekeeper für den Proxy und die Back-End-Cluster dient, müssen Sie Kerberos nicht verwenden.
Verarbeitungssysteme
Die Back-End-Cluster sind die Dataproc-Cluster, in denen die Dienste gehostet werden, die Nutzeranfragen verarbeiten. Dataproc-Cluster können die Anzahl der Worker automatisch skalieren, um den Bedarf Ihres Analystenteams ohne manuelle Neukonfiguration zu erfüllen.
Es wird empfohlen, langlebige Dataproc-Cluster im Back-End zu verwenden. Langlebige Dataproc-Cluster ermöglichen es dem System, Anfragen von Datenanalysten ohne Unterbrechung zu verarbeiten. Wenn der Cluster nur Anfragen für kurze Zeit verarbeiten muss, können Sie jobspezifische Cluster verwenden, die auch als sitzungsspezifische Cluster bezeichnet werden. Sitzungsspezifische Cluster können auch kosteneffizienter sein als langlebige Cluster.
Wenn Sie sitzungsspezifische Cluster verwenden, ändern Sie die Cluster in derselben Zone und unter demselben Namen, damit Sie die Topologiekonfiguration nicht ändern können. Wenn Sie dieselbe Zone und denselben Namen verwenden, kann Knox die Anfragen mithilfe des internen DNS-Namens des Masterknotens transparent weiterleiten, wenn Sie den sitzungsspezifischen Cluster neu erstellen.
HS2 ist für die Verarbeitung von Nutzeranfragen an Apache Hive zuständig. HS2 kann so konfiguriert werden, dass es verschiedene Ausführungs-Engines wie Hadoop MapReduce, Apache Tez und Apache Spark verwendet. In diesem Dokument ist HS2 für die Verwendung der Apache Tez-Engine konfiguriert.
Spark SQL ist ein Modul von Apache Spark, das eine JDBC-/ODBC-Schnittstelle enthält, mit der SQL-Abfragen auf Apache Spark ausgeführt werden können. Im obigen Architekturdiagramm wird Spark SQL als alternative Option zum Verarbeiten von Nutzerabfragen angezeigt.
Ein Verarbeitungs-Engine, entweder Apache Tez oder Apache Spark, ruft den YARN Resource Manager auf, um den Engine-DAG auf den Cluster-Worker-Maschinen auszuführen. Schließlich rufen die Cluster-Worker-Computer die Daten auf. Verwenden Sie zum Speichern und Zugreifen auf die Daten in einem Dataproc-Cluster den Cloud Storage-Connector und nicht das Hadoop Distributed File System (HDFS). Weitere Informationen zu den Vorteilen von Cloud Storage-Connector finden Sie in der Dokumentation zu Cloud Storage-Connectors.
Das obige Architekturdiagramm zeigt eine Apache Knox-Topologie, die Anfragen an Apache Hive weiterleitet, und eine weitere, die Anfragen an Spark SQL weiterleitet. Das Diagramm zeigt auch andere Topologien, die Anfragen an Dienste im selben oder in verschiedenen Back-End-Clustern weiterleiten können. Die Back-End-Dienste können verschiedene Datasets verarbeiten. Beispielsweise kann eine Hive-Instanz für einen eingeschränkten Satz von Nutzern Zugriff auf personenidentifizierbare Informationen (PII) gewähren, während eine andere Hive-Instanz Zugriff auf nicht personenidentifizierbare Informationen für eine umfassendere Nutzung bietet.
Nutzerautorisierung
Apache Ranger kann auf den Back-End-Clustern installiert werden, um eine detaillierte Autorisierung für Hadoop-Dienste zu ermöglichen. In der Architektur fängt ein Ranger-Plug-in für Hive die Nutzeranfragen ab und bestimmt, ob ein Nutzer aufgrund von Ranger-Richtlinien eine Aktion für Hive-Daten ausführen darf.
Als Administrator definieren Sie die Ranger-Richtlinien auf der Ranger-Admin-Seite. Es wird dringend empfohlen, Ranger so zu konfigurieren, dass diese Richtlinien in einer externen Cloud SQL-Datenbank gespeichert werden. Die Externalisierung der Richtlinien hat zwei Vorteile:
- Sie bleiben auch bestehen, wenn einer der Back-End-Cluster gelöscht wird.
- Dadurch können die Richtlinien zentral für alle Gruppen oder für benutzerdefinierte Gruppen von Back-End-Clustern verwaltet werden.
Um Ranger-Richtlinien den richtigen Nutzeridentitäten oder -gruppen zuzuweisen, müssen Sie Ranger so konfigurieren, dass die Identitäten aus dem Verzeichnis synchronisiert werden, mit dem Knox verbunden ist. Standardmäßig werden die von Ranger verwendeten Nutzeridentitäten aus dem Betriebssystem übernommen.
Apache Ranger kann die Audit-Logs auch mit Cloud Storage externalisieren, um sie dauerhaft zu erstellen. Ranger verwendet Apache Solr als Indexierungs- und Abfrage-Engine, damit die Audit-Logs durchsucht werden können.
Im Gegensatz zu HiveServer2 bietet Spark SQL keine offizielle Unterstützung für das Ranger-Plug-in. Sie müssen daher die groben ACLs in Apache Knox verwenden, um die Autorisierung zu verwalten. Fügen Sie dem jeweiligen Topologiedeskriptor die LDAP-Identitäten hinzu, die die einzelnen Dienste verwenden dürfen, z. B. Spark SQL oder Hive, um diese ACLs zu verwenden.
Weitere Informationen finden Sie unter Best Practices für die Verwendung von Apache Ranger auf Dataproc.
Hochverfügbarkeit
Dataproc bietet einen Modus für hohe Verfügbarkeit (HA). In diesem Modus sind mehrere Maschinen als Masterknoten konfiguriert, von denen eine aktiv ist. Dieser Modus ermöglicht unterbrechungsfreie YARN- und HDFS-Vorgänge trotz möglicher Ausfälle oder Neustarts einzelner Knoten.
Wenn der Masterknoten jedoch ausfällt, ändert sich die externe IP-Adresse des Einstiegspunkts, sodass Sie die BI-Toolverbindung neu konfigurieren müssen. Wenn Sie Dataproc im Hochverfügbarkeitsmodus ausführen, sollten Sie einen externen HTTP(S)-Load-Balancer als Einstiegspunkt konfigurieren. Der Load-Balancer leitet Anfragen an eine nicht verwaltete Instanzgruppe weiter, die Ihre Cluster-Master-Knoten gruppiert. Alternativ zu einem Load-Balancer können Sie auch eine Round-Robin-DNS-Technik anwenden. Es gibt jedoch Draftbacks für diesen Ansatz. Diese Konfigurationen werden in diesem Dokument nicht behandelt.
Cloud SQL bietet auch einen Modus für hohe Verfügbarkeit mit Datenredundanz, die durch die synchrone Replikation zwischen Masterinstanzen und Standby-Instanzen in verschiedenen Zonen ermöglicht werden. Wenn eine Instanz oder Zone ausfällt, reduziert diese Konfiguration die Ausfallzeit. Beachten Sie jedoch, dass für eine Instanz, die für hohe Verfügbarkeit konfiguriert ist, der Preis für eine eigenständige Instanz doppelt berechnet wird.
Cloud Storage fungiert als Datenspeicher. Weitere Informationen zur Verfügbarkeit von Cloud Storage finden Sie unter Beschreibung der Speicherklasse.
Netzwerk
In einer mehrstufigen Netzwerkarchitektur befinden sich die Proxycluster in einem Perimeter-Netzwerk. Die Back-End-Cluster befinden sich in einem internen Netzwerk, das durch Firewallregeln geschützt ist, die nur eingehenden Traffic von den Proxyclustern zulassen.
Die Proxycluster sind von den anderen Clustern isoliert, da sie für externe Anfragen bereitgestellt werden. Firewallregeln erlauben nur einem eingeschränkten Set von Quell-IP-Adressen den Zugriff auf die Proxycluster. In diesem Fall lassen die Firewallregeln nur Anfragen zu, die von den Adressen Ihrer BI-Tools stammen.
Die Konfiguration von mehrstufigen Netzwerken wird in diesem Dokument nicht behandelt. Wenn Sie Ihre Visualisierungssoftware mit Hadoop in Google Cloud verbinden möchten, verwenden Sie in der gesamten Anleitung das Netzwerk default. Weitere Informationen zur Einrichtung von Netzwerken mit mehreren Ebenen finden Sie in den Best Practices für die VPC-Netzwerksicherheit und in der Übersicht sowie in den Beispielen zum Konfigurieren mehrerer Netzwerkschnittstellen.
Nächste Schritte
- Lesen Sie den zweiten Teil der Reihe Visualisierungssoftware mit Hadoop in Google Cloud verbinden und lernen Sie, wie Sie die Architektur in Google Cloud einrichten.
- Architektur in Google Cloud mithilfe dieser Terraform-Konfigurationsdateien einrichten.
- Best Practices für die Verwendung von Apache Ranger auf Dataproc.
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center