Architettura per la connessione del software di visualizzazione a Hadoop su Google Cloud

Last reviewed 2024-04-17 UTC

Questo documento è rivolto agli operatori e agli amministratori IT che vogliono configurare rendere sicuro l'accesso ai dati per gli analisti di dati utilizzando strumenti di business intelligence (BI) come Tableau e Looker. Non offre indicazioni su come utilizzare la BI o interagire con le API Dataproc.

Questo documento è la prima parte di una serie che ti aiuta a creare un'architettura end-to-end che consente agli analisti di dati di accedere in modo sicuro ai dati utilizzando strumenti BI. Questo documento illustra i seguenti concetti:

  • Un'architettura proposta.
  • Una vista di alto livello dei confini, delle interazioni e della rete dei componenti nell'architettura.
  • Una visione di alto livello dell'autenticazione e dell'autorizzazione nell'architettura.

La seconda parte di questa serie, Connessione del software di visualizzazione a Hadoop su Google Cloud, ti mostra come configurare l'architettura su Google Cloud.

Architettura

Il seguente diagramma mostra l'architettura e il flusso degli eventi che vengono spiegate in questo documento. Per ulteriori informazioni sui prodotti utilizzati in questa architettura, consulta Componenti dell'architettura.

Il flusso degli eventi nell'architettura.

  1. Le applicazioni client si connettono tramite Java Database Connectivity (JDBC) a un singolo punto di ingresso su un cluster Dataproc. Il punto di accesso è fornito da Apache Knox, installato sul nodo master del cluster. La comunicazione con Apache Knox è protetta da TLS.
  2. Apache Knox delega l'autenticazione tramite un provider di autenticazione a un sistema come una directory LDAP.
  3. Dopo l'autenticazione, Apache Knox instrada la richiesta dell'utente a uno o più cluster di backend. Puoi definire le route e la configurazione come le topologie.
  4. Un servizio di elaborazione dei dati, come Apache Hive, ascolta il cluster di backend selezionato e riceve la richiesta.
  5. Apache Ranger intercetta la richiesta e determina se l'elaborazione deve procedere, a seconda che l'utente disponga di un'autorizzazione valida.
  6. Se la convalida ha esito positivo, il servizio di elaborazione dati analizza e restituisce i risultati.

Componenti dell'architettura

L'architettura è composta dai seguenti componenti.

  • La piattaforma Hadoop gestita:
    • Dataproc Dataproc è Apache Spark gestito da Google Cloud, uno Servizio Apache Hadoop che consente di sfruttare i dati open source per l'elaborazione batch, l'esecuzione di query, l'inserimento di flussi e il machine learning. Dataproc è la piattaforma alla base della soluzione descritti in questo documento.
  • Autenticazione e autorizzazione degli utenti:
    • Apache Knox. Apache Knox funge da singolo punto di accesso HTTP per tutti i servizi di base in un cluster Hadoop. Apache Knox è progettato come uno proxy inverso con provider collegabili per l'autenticazione, autorizzazioni, audit e altri servizi. I client inviano richieste a Knox e, in base all'URL e ai parametri della richiesta, Knox instrada la richiesta del servizio Hadoop appropriato. Poiché Knox è un punto di contatto che gestisce in modo trasparente le richieste del client e nasconde la complessità, è al centro dell'architettura.
    • Apache Ranger, Apache Ranger fornisce autorizzazioni granulari per gli utenti eseguire azioni specifiche sui servizi Hadoop. Inoltre, controlla i dati degli utenti e implementano le azioni amministrative.
  • Motori di elaborazione:
    • Apache Hive. Apache Hive è un software di data warehouse che consente l'accesso e la gestione di grandi set di dati che risiedono in uno spazio di archiviazione distribuito tramite SQL. Apache Hive analizza le query SQL, esegue l'analisi semantica e crea grafo diretto aciclico (DAG) di fasi necessarie per l'esecuzione di un motore di elaborazione. Nell'architettura illustrato in questo documento, Hive funge da punto di traduzione tra l'utente richieste. Può anche agire come uno dei vari motori di elaborazione. Apache Hive è onnipresente nell'ecosistema Hadoop e apre le porte a professionisti che hanno familiarità con SQL standard per eseguire l'analisi dei dati.
    • Apache Tez, Apache Tez è il motore di elaborazione incaricato di eseguire i DAG preparati da Hive e di restituire i risultati.
    • Apache Spark. Apache Spark è un motore di analisi unificato e l'elaborazione dei dati su larga scala che supporta l'esecuzione di DAG. L'architettura mostra il componente Spark SQL di Apache Spark per dimostrare la flessibilità dell'approccio presentato in documento. Una restrizione è che Spark SQL non ha Supporto del plug-in Ranger. Per questo motivo, l'autorizzazione deve essere tramite gli ACL meno granulari in Apache Knox anziché utilizzare l'autorizzazione granulare fornita dalla Ranger.

Panoramica dei componenti

Nelle sezioni seguenti, approfondirai ciascun componente in modo più dettagliato. Imparerai inoltre come interagiscono i componenti.

Applicazioni client

Le applicazioni client includono strumenti in grado di inviare richieste a un REST HTTPS ma non supportano necessariamente API Dataproc Jobs. Gli strumenti BI come Tableau e Looker dispongono di HiveServer2 (HS2) e i driver JDBC Spark SQL che possono inviare richieste tramite HTTP.

Flusso di richiesta da Tableau, Looker e Beeline all'endpoint REST HTTPS.

Questo documento presuppone che le applicazioni client siano esterne in Google Cloud, in esecuzione in ambienti come una workstation di analisi, on-premise o su un altro cloud. Quindi, la comunicazione tra il client delle applicazioni e Apache Knox devono essere protetti con un certificato SSL/TLS autofirmato.

Autenticazione utente e del punto di ingresso

I cluster proxy sono uno o più cluster Dataproc a lunga durata che ospitano il gateway Apache Knox.

I cluster proxy.

Apache Knox funge da singolo punto di accesso per le richieste del client. Knox è installato nodo master del cluster proxy. Knox esegue la terminazione SSL e Delega l'utente dell'autenticazione e inoltra la richiesta a uno dei servizi di backend.

In Knox, ogni servizio di backend è configurato in quello che viene chiamato topologia. Il descrittore della topologia definisce le seguenti azioni e autorizzazioni:

  • La modalità di delega dell'autenticazione per un servizio.
  • L'URI a cui il servizio di backend inoltra le richieste.
  • Elenchi di controllo dell'accesso (ACL) semplici per l'autorizzazione per servizio.

Knox consente di integrare l'autenticazione con le identità aziendali e cloud sistemi di gestione dei dati. Per configurare l'autenticazione utente per ogni topologia, puoi: utilizzare provider di autenticazione. Knox utilizza Apache Shiro per eseguire l'autenticazione contro per impostazione predefinita, un server LDAP ApacheDS di dimostrazione locale.

In alternativa, puoi scegliere che Knox utilizzi Kerberos. Nel diagramma precedente, Ad esempio, puoi vedere un server Active Directory ospitato su Google Cloud all'esterno del cluster.

Per informazioni su come connettere Knox a servizi di autenticazione aziendali come un server ApacheDS esterno o Microsoft Active Directory (AD), consulta Guida dell'utente di Apache Knox e Managed Active Directory di Google Cloud e Federated AD.

Per il caso d'uso in questo documento, purché Apache Knox agisca come singola il gatekeeper al proxy e ai cluster di backend, non devi usare Kerberos.

Motori di elaborazione

I cluster di backend sono i cluster Dataproc che ospitano che elaborano le richieste degli utenti. I cluster Dataproc possono scalabilità automatica il numero di worker per soddisfare la domanda del tuo team di analisti senza dover per eseguire una riconfigurazione.

I cluster di backend Dataproc.

Ti consigliamo di utilizzare cluster Dataproc di lunga durata nel backend. I cluster Dataproc di lunga durata consentono al sistema gestire le richieste degli analisti di dati senza interruzioni. In alternativa, se deve gestire le richieste solo per un breve periodo, puoi usare modelli noti anche come cluster temporanei. I cluster temporanei possono anche essere più convenienti rispetto ai cluster permanenti.

Se utilizzi cluster temporanei, per evitare di modificare configurazione della topologia, assicurati di ricreare i cluster nella stessa zona e con lo stesso nome. Utilizzando lo stesso nome e la stessa zona, Knox può instradare richiede in modo trasparente utilizzando il nodo master nome DNS interno quando ricrei il cluster temporaneo.

HS2 è responsabile della gestione delle query degli utenti effettuate su Apache Hive. HS2 può essere configurato per utilizzare vari motori di esecuzione, come Hadoop Motore MapReduce, Apache Tez e Apache Spark. In questo documento, HS2 è configurato per utilizzare il motore Apache Tez.

Spark SQL è un modulo di Apache Spark che include un'interfaccia JDBC/ODBC per eseguire query SQL su Apache Spark. Nel diagramma dell'architettura precedente, Spark SQL mostrata come opzione alternativa per gestire le query degli utenti.

Un motore di elaborazione, Apache Tez o Apache Spark, chiama il Responsabile delle risorse YARN per eseguire il DAG del motore sulle macchine worker del cluster. Infine, il worker del cluster macchine accedono ai dati. Per l'archiviazione e l'accesso ai dati in un Dataproc, usa il connettore Cloud Storage, non Hadoop HDFS (Distributed File System). Per ulteriori informazioni sui vantaggi dell'utilizzo del connettore Cloud Storage, consulta la documentazione del connettore Cloud Storage.

Il diagramma architetturale precedente mostra una topologia Apache Knox che inoltra ad Apache Hive e un'altra che inoltra le richieste a Spark SQL. La mostra anche altre topologie che possono inoltrare richieste ai servizi nel o cluster di backend uguali o diversi. I servizi di backend possono elaborare diverse e set di dati. Ad esempio, un'istanza Hive può offrire l'accesso che consentono l'identificazione personale (PII) per un gruppo limitato di utenti, mentre un'altra istanza Hive può offrire l'accesso a dati non PII per un consumo più ampio.

Autorizzazione utente

Apache Ranger può essere installato sui cluster di backend per fornire un'autorizzazione per i servizi Hadoop. Nell'architettura, un plug-in Ranger per Hive intercetta richiesta dall'utente e determina se all'utente è consentito eseguire un'azione sui dati Hive, in base ai criteri dei ranger.

Autorizzazione granulare dei ranger.

In qualità di amministratore, puoi definire i criteri dei ranger utilizzando il comando Ranger Admin . Ti consigliamo vivamente di configurare Ranger per archiviare questi criteri in un database Cloud SQL esterno. L'esternalizzazione dei criteri prevede due vantaggi:

  • Li rende permanenti nel caso in cui uno qualsiasi dei cluster di backend eliminati.
  • Consente di gestire centralmente i criteri per tutti i gruppi o per personalizzati di cluster di backend.

Per assegnare i criteri Ranger alle identità utente corrette devi configurare Ranger in modo che sincronizzi le identità dalla stessa directory a cui è connesso Knox. Per impostazione predefinita, le identità utente utilizzate dal ranger vengono tratte dal sistema operativo.

Apache Ranger può anche esternalizzare gli audit log a Cloud Storage per e mantienile persistenti. Ranger utilizza Apache Solr come motore di indicizzazione e query per eseguire gli audit log disponibili per la ricerca.

A differenza di HiveServer2, Spark SQL non supporta il plug-in Ranger ufficiale, devi utilizzare gli ACL granulari disponibili in Apache Knox per gestire autorizzazione. Per utilizzare queste ACL, aggiungi le identità LDAP autorizzate a utilizzare ciascun servizio, ad esempio Spark SQL o Hive, nel descrittore della topologia corrispondente per il servizio.

Per saperne di più, consulta le best practice per l'utilizzo di Apache Ranger su Dataproc.

Alta disponibilità

Dataproc offre modalità ad alta disponibilità (HA). In questa modalità sono presenti diverse macchine configurate come master nodi, uno dei quali è in stato attivo. Questa modalità consente YARN e HDFS senza interruzioni nonostante eventuali errori o riavvii a un nodo singolo.

Tuttavia, in caso di errore del nodo master, l'IP esterno del singolo punto di ingresso cambia. devi quindi riconfigurare la connessione dello strumento BI. Quando esegui Dataproc in modalità ad alta disponibilità, devi configurare un bilanciatore del carico HTTP(S) esterno come punto di ingresso. Il bilanciatore del carico instrada le richieste gruppo di istanze non gestite che raggruppa i nodi master del cluster. Come alternativa a un bilanciatore del carico, puoi applicare un DNS round-robin ma ci sono degli drawbacks in questo approccio. Questi non rientrano nell'ambito di questo documento.

Cloud SQL offre inoltre modalità alta disponibilità, con la ridondanza dei dati resa possibile dalla replica sincrona tra il master e quelle in standby, situate in zone diverse. Se esiste un un errore di un'istanza o una zona, questa configurazione riduce il tempo di inattività. Tuttavia, tieni presente il costo di un'istanza configurata ad alta disponibilità è il doppio del prezzo in esecuzione in un'istanza Compute Engine.

Cloud Storage funge da datastore. Per ulteriori informazioni Disponibilità di Cloud Storage, vedi le descrizioni delle classi di archiviazione.

Networking

In un'architettura di rete a più livelli, i cluster proxy si trovano in una rete perimetrale. I cluster di backend si trovano in una rete interna protetta regole firewall che lasciano passare solo il traffico in entrata dai cluster proxy.

I cluster proxy sono isolati dagli altri cluster perché esposto a richieste esterne. Le regole firewall consentono solo un insieme limitato di gli indirizzi IP di origine per accedere ai cluster proxy. In questo caso, le regole firewall consentire solo le richieste provenienti dagli indirizzi dei tuoi strumenti BI.

La configurazione delle reti a più livelli non rientra nell'ambito di questa documento. In Connessione del software di visualizzazione a Hadoop su Google Cloud, userai la rete default per tutto il tutorial. Per ulteriori informazioni configurazioni di rete a più livelli, consulta le best practice Sicurezza di rete VPC oltre alla panoramica e agli esempi come configurare più interfacce di rete.

Passaggi successivi