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

Last reviewed 2024-04-17 UTC

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

Questo documento è la prima parte di una serie che ti aiuta a creare una soluzione end-to-end per offrire ai data analyst l'accesso sicuro ai dati utilizzando gli strumenti di 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 visualizzazione 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, spiega come configurare l'architettura su Google Cloud.

Architettura

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

Il flusso di eventi nell'architettura.

  1. Le applicazioni client si connettono tramite JDBC (Java Database Connectivity) a un singolo punto di contatto in un cluster Dataproc. Il punto di contatto viene fornito da Apache Knox, che è 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 inoltra la richiesta dell'utente a uno o più cluster di backend. Definisci le route e la configurazione come topia personalizzate.
  4. Un servizio di elaborazione dei dati, come Apache Hive, ascolta il cluster di backend selezionato e accetta la richiesta.
  5. Apache Ranger intercetta la richiesta e determina se l'elaborazione deve essere eseguita, a seconda che l'utente disponga di un'autorizzazione valida.
  6. Se la convalida va a buon fine, il servizio di elaborazione dei dati analizza la richiesta e restituisce i risultati.

Componenti dell'architettura

L'architettura è composta dai seguenti componenti.

  • La piattaforma Hadoop gestita:
    • Dataproc. Dataproc è un servizio Apache Spark Google Cloudgestito, un servizio Apache Hadoop che ti consente di sfruttare gli strumenti per i dati open source per elaborazione batch, query, streaming e machine learning. Dataproc è la piattaforma alla base della soluzione descritta in questo documento.
  • Autenticazione e autorizzazione utente:
    • 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 reverse proxy con fornitori plug-in per autenticazione, autorizzazione, controllo e altri servizi. I client inviano richieste a Knox, e, in base all'URL e ai parametri della richiesta, Knox inoltra la richiesta al servizio Hadoop appropriato. Poiché Knox è un punto di contatto che gestisce in modo trasparente le richieste dei client e nasconde la complessità, è al centro dell'architettura.
    • Apache Ranger. Apache Ranger fornisce autorizzazioni granulari per consentire agli utenti di eseguire azioni specifiche sui servizi Hadoop. Controlla inoltre l'accesso degli utenti e implementa le azioni amministrative.
  • Motori di elaborazione:
    • Apache Hive. Apache Hive è un software di data warehouse che consente di accedere e gestire grandi set di dati residenti in uno spazio di archiviazione distribuito utilizzando SQL. Apache Hive analizza le query SQL, esegue l'analisi semantica e crea un grafo aciclico diretto (DAG) di fasi da eseguire da un motore di elaborazione. Nell'architettura mostrata in questo documento, Hive funge da punto di traduzione tra le richieste dell'utente. Può anche fungere da uno dei più motori di elaborazione. Apache Hive è onnipresente nell'ecosistema Hadoop e consente agli professionisti che hanno dimestichezza con SQL standard di 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 per l'elaborazione di 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 questo documento. Una limitazione è che Spark SQL non ha il supporto ufficiale del plug-in Ranger. Per questo motivo, l'autorizzazione deve essere eseguita tramite le ACL a granularità elevata in Apache Knox anziché utilizzare l'autorizzazione a granularità fine fornita da Ranger.

Panoramica dei componenti

Nelle sezioni seguenti scoprirai di più su ciascun componente. Scoprirai anche come i componenti interagiscono tra loro.

Applicazioni client

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

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

Questo documento presuppone che le applicazioni client siano esterne aGoogle Cloude vengano eseguite in ambienti come una workstation di analisi, on-premise o su un altro cloud. Pertanto, la comunicazione tra le applicazioni client e Apache Knox deve essere protetta con un certificato SSL/TLS firmato da una CA o autofirmato.

Punto di contatto e autenticazione utente

I cluster proxy sono uno o più cluster Dataproc a lungo termine che ospitano Apache Knox Gateway.

I cluster proxy.

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

In Knox, ogni servizio di backend è configurato in quella che viene definita una 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 ti consente di integrare l'autenticazione con i sistemi di gestione dell'identità aziendale e cloud. Per configurare l'autenticazione utente per ogni topologia, puoi utilizzare i provider di autenticazione. Per impostazione predefinita, Knox utilizza Apache Shiro per eseguire l'autenticazione in un server LDAP ApacheDS di dimostrazione locale.

In alternativa, puoi scegliere di utilizzare Kerberos per Knox. Nel diagramma precedente, come esempio, puoi vedere un server Active Directory ospitato su Google Cloud al di fuori del cluster.

Per informazioni su come collegare Knox a un servizio di autenticazione aziendale, come un server ApacheDS esterno o Microsoft Active Directory (AD), consulta la guida dell'utente di Apache Knox e la documentazione di Google Cloud Managed Active Directory e Federated AD.

Per il caso d'uso descritto in questo documento, se Apache Knox funge da unico gatekeeper per i cluster proxy e di backend, non è necessario utilizzare Kerberos.

Motori di elaborazione

I cluster di backend sono i cluster Dataproc che ospitano i servizi che elaborano le richieste degli utenti. I cluster Dataproc possono scalare automaticamente il numero di worker per soddisfare la domanda del team di analisti senza riconfigurazione manuale.

I cluster di backend Dataproc.

Ti consigliamo di utilizzare cluster Dataproc a vita lunga nel backend. I cluster Dataproc a lungo termine consentono al sistema di rispondere alle richieste degli analisti dei dati senza interruzioni. In alternativa, se il cluster deve gestire le richieste solo per un breve periodo di tempo, puoi utilizzare cluster specifici per job, noti anche come cluster temporanei. I cluster temporanei possono anche essere più convenienti rispetto ai cluster permanenti.

Se utilizzi cluster effimeri, per evitare di modificare la configurazione della topologia, assicurati di ricreare i cluster nella stessa zona e con lo stesso nome. L'utilizzo della stessa zona e dello stesso nome consente a Knox di inoltrare le richieste in modo trasparente utilizzando il nome DNS interno del nodo principale quando viene ricreato 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 il motore Hadoop MapReduce, Apache Tez e Apache Spark. In questo documento, HS2 è configurato in modo da 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 di architettura precedente, Spark SQL è mostrato come opzione alternativa per la gestione delle query degli utenti.

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

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

Autorizzazione utente

Apache Ranger può essere installato sui cluster di backend per fornire un'autorizzazione granulare per i servizi Hadoop. Nell'architettura, un plug-in Ranger per Hive intercetta le richieste degli utenti e determina se un utente è autorizzato a eseguire un'azione sui dati di Hive, in base alle norme di Ranger.

L'autorizzazione granulare di Ranger.

In qualità di amministratore, definisci i criteri di Ranger utilizzando la pagina di amministrazione di Ranger. Ti consigliamo vivamente di configurare Ranger per archiviare questi criteri in un database Cloud SQL esterno. L'esternalizzazione delle norme presenta due vantaggi:

  • In questo modo, vengono conservati nel caso in cui uno dei cluster di backend venga eliminato.
  • Consente di gestire i criteri in modo centralizzato per tutti i gruppi o per gruppi personalizzati di cluster di backend.

Per assegnare i criteri di Ranger alle identità o ai gruppi di utenti corretti, devi configurare Ranger per sincronizzare le identità dalla stessa directory a cui è connesso Knox. Per impostazione predefinita, le identità utente utilizzate da Ranger vengono prese dal sistema operativo.

Apache Ranger può anche esternalizzare i propri audit log in Cloud Storage per farli diventare permanenti. Ranger utilizza Apache Solr come motore di indicizzazione e query per rendere i log di controllo disponibili per la ricerca.

A differenza di HiveServer2, Spark SQL non supporta il plug-in Ranger ufficiale, pertanto devi utilizzare le ACL a granularità grossolana disponibili in Apache Knox per gestire la relativa 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 fornisce una modalità ad alta disponibilità (HA). In questa modalità, sono presenti diverse macchine configurate come nodi master, una delle quali è in stato attivo. Questa modalità consente operazioni YARN e HDFS senza interruzioni anche in caso di errori o riavvii a livello di singolo nodo.

Tuttavia, se il nodo principale non funziona, l'IP esterno del punto di contatto singolo cambia, quindi devi ricollegare lo strumento BI. Quando esegui Dataproc in modalità HA, devi configurare un bilanciatore del carico HTTP(S) esterno come punto di contatto. Il bilanciatore del carico instrada le richieste a un gruppo di istanze non gestite che raggruppa i nodi master del cluster. In alternativa a un bilanciatore del carico, puoi applicare una tecnica di DNS round-robin, ma questo approccio presenta svantaggi. Queste configurazioni non rientrano nell'ambito di questo documento.

Cloud SQL fornisce anche una modalità di alta disponibilità, con la ridondanza dei dati resa possibile dalla replica sincrona tra le istanze master e le istanze di standby situate in zone diverse. Se si verifica un errore di un'istanza o di una zona, questa configurazione riduce il tempo di riposo. Tuttavia, tieni presente che per un'istanza configurata per l'HA viene addebitato il doppio del prezzo di un'istanza autonoma.

Cloud Storage funge da datastore. Per ulteriori informazioni sulla disponibilità di Cloud Storage, consulta 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 da regole firewall che consentono il passaggio solo del traffico in entrata dai cluster proxy.

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

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

Passaggi successivi