Questo documento è destinato agli operatori e agli amministratori IT che vogliono configurare un 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 usare gli strumenti BI o interagire con le API Dataproc.
Questo documento è la prima parte di una serie che aiuta a creare una soluzione end-to-end per consentire agli analisti di dati di accedere in modo sicuro ai dati utilizzando gli strumenti BI. Questo documento spiega i seguenti concetti:
- Un'architettura proposta.
- una visione d'insieme dei confini, delle interazioni e del networking dei componenti nell'architettura.
- una visione d'insieme dell'autenticazione e dell'autorizzazione nell'architettura.
La seconda parte di questa serie, Connessione del software di visualizzazione a Hadoop su Google Cloud, mostra come configurare l'architettura su Google Cloud.
Architettura
Il seguente diagramma mostra l'architettura e il flusso degli eventi descritti in questo documento. Per ulteriori informazioni sui prodotti utilizzati in questa architettura, consulta Componenti architettonici.
- Le applicazioni client si connettono tramite Java Database Connectivity (JDBC) a un singolo punto di ingresso su un cluster Dataproc. Il punto di ingresso è fornito da Apache Knox, installato sul nodo master del cluster. La comunicazione con Apache Knox è protetta tramite TLS.
- Apache Knox delega l'autenticazione tramite un provider di autenticazione a un sistema come una directory LDAP.
- Dopo l'autenticazione, Apache Knox instrada la richiesta utente a uno o più cluster di backend. L'utente definisce le route e la configurazione come topologie personalizzate.
- Un servizio di elaborazione dati, come Apache Hive, rimane in ascolto del cluster di backend selezionato e accetta la richiesta.
- Apache Ranger intercetta la richiesta e determina se l'elaborazione deve andare avanti, a seconda che l'utente disponga di un'autorizzazione valida.
- Se la convalida ha esito positivo, il servizio di elaborazione dati analizza la richiesta 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, un servizio Apache Hadoop che consente di sfruttare strumenti di dati open source per l'elaborazione batch, l'esecuzione di query, il flusso di dati e il machine learning. Dataproc è la piattaforma alla base della soluzione descritta in questo documento.
- Autenticazione e autorizzazione degli utenti:
- Apache Knox Apache Knox funge da singolo punto di accesso HTTP per tutti i servizi sottostanti in un cluster Hadoop. Apache Knox è progettato come proxy inverso con provider modulari per autenticazione, autorizzazione, controllo e altri servizi. I client inviano le richieste a Knox e, in base ai parametri e all'URL della richiesta, Knox instrada la richiesta al servizio Hadoop appropriato. Poiché Knox è un punto di ingresso che gestisce in modo trasparente le richieste dei client e nasconde la complessità, è al centro dell'architettura.
- Apache Ranger. Apache Ranger fornisce un'autorizzazione granulare agli utenti per eseguire azioni specifiche sui servizi Hadoop. Controlla inoltre l'accesso degli utenti e implementa 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 presenti in uno spazio di archiviazione distribuito tramite SQL. Apache Hive analizza le query SQL, esegue un'analisi semantica e crea un grafo diretto aciclico (DAG) delle fasi per l'esecuzione di un motore di elaborazione. Nell'architettura mostrata in questo documento, Hive funge da punto di traduzione tra le richieste degli utenti. Può anche fungere da uno dei vari motori di elaborazione. Apache Hive è onnipresente nell'ecosistema Hadoop e apre le porte ai professionisti che hanno familiarità con il linguaggio SQL standard per eseguire l'analisi dei dati.
- Apache Tez Apache Tez è il motore di elaborazione incaricato dell'esecuzione dei DAG preparati da Hive e della restituzione dei risultati.
- Apache Spark. Apache Spark è un motore di analisi unificato per 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 questo documento. Una restrizione è che Spark SQL non dispone del supporto ufficiale dei plug-in di Ranger. Per questo motivo, l'autorizzazione deve essere eseguita tramite gli ACL granulari in Apache Knox anziché tramite l'autorizzazione granulare fornita da Ranger.
Panoramica dei componenti
Nelle sezioni seguenti approfondirai ciascuno dei componenti in modo più dettagliato. Imparerai anche in che modo 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 BI come Tableau e Looker sono dotati di driver JDBC HiveServer2 (HS2) e Spark SQL che possono inviare richieste tramite HTTP.
Questo documento presuppone che le applicazioni client siano esterne a Google Cloud, in esecuzione 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 autofirmato o firmato da un'autorità di certificazione.
Punto di ingresso e autenticazione utente
I cluster proxy sono uno o più cluster Dataproc di lunga durata che ospitano il gateway Apache Knox.
Apache Knox funge da singolo punto di ingresso per le richieste del client. Knox è installato sul nodo master del cluster proxy. Knox esegue la terminazione SSL, delega l'autenticazione utente e inoltra la richiesta a uno dei servizi di backend.
In Knox, ogni servizio di backend è configurato in quella che viene definita topologia. Il descrittore della topologia definisce le azioni e le autorizzazioni seguenti:
- Modalità di delega dell'autenticazione per un servizio.
- L'URI a cui il servizio di backend inoltra le richieste.
- Semplici elenchi di controllo dell'accesso (ACL) all'autorizzazione per servizio.
Knox consente di integrare l'autenticazione con sistemi di gestione delle identità aziendali e cloud. Per configurare l'autenticazione utente per ogni topologia, puoi utilizzare i provider di autenticazione. Knox utilizza Apache Shiro per eseguire l'autenticazione a fronte di un server LDAP ApacheDS dimostrativo locale per impostazione predefinita.
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 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 Managed Active Directory e Federated AD di Google Cloud.
Per il caso d'uso in questo documento, finché Apache Knox funge da singolo gatekeeper dei cluster di proxy e di backend, non è necessario utilizzare Kerberos.
Motori di elaborazione
I cluster di backend sono 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 tuo team di analisti senza riconfigurazione manuale.
Ti consigliamo di utilizzare cluster Dataproc di lunga durata nel backend. I cluster Dataproc a lunga durata consentono al sistema di gestire le richieste degli analisti di dati senza interruzioni. In alternativa, se il cluster deve gestire le richieste solo per un breve periodo di tempo, puoi utilizzare cluster specifici del job, chiamati anche cluster temporanei. I cluster temporanei possono anche essere più convenienti rispetto a quelli di lunga durata.
Se utilizzi cluster temporanei, 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 instradare le richieste in modo trasparente utilizzando il nome DNS interno del nodo master quando ricrei il cluster temporaneo.
HS2 è responsabile della gestione delle query degli utenti effettuate ad Apache Hive. HS2 può essere configurato per l'utilizzo di vari motori di esecuzione, ad esempio il motore Hadoop 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 l'esecuzione di query SQL su Apache Spark. Nel diagramma dell'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 YARN Resource Manager per eseguire il DAG del motore sulle macchine worker del cluster. Infine, le macchine worker del cluster accedono ai dati. Per l'archiviazione e l'accesso ai dati in un cluster Dataproc, utilizza il connettore Cloud Storage, non Hadoop File System distribuito (HDFS). Per ulteriori informazioni sui vantaggi dell'utilizzo del connettore Cloud Storage, consulta la documentazione del connettore Cloud Storage.
Il diagramma dell'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 richieste ai servizi nello stesso cluster di backend o in cluster di backend diversi. I servizi di backend possono elaborare set di dati diversi. Ad esempio, un'istanza di Hive può consentire l'accesso a informazioni che consentono l'identificazione personale (PII) per un insieme limitato di utenti, mentre un'altra istanza di Hive può offrire 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 granulare per i servizi Hadoop. Nell'architettura, un plug-in Ranger per Hive intercetta le richieste degli utenti e determina se un utente può eseguire un'azione sui dati di Hive, in base ai criteri dei ranger.
In qualità di amministratore, puoi definire i criteri dei ranger utilizzando la pagina di amministrazione dei ranger. Ti consigliamo vivamente di configurare Ranger per archiviare questi criteri in un database Cloud SQL esterno. L'esternalizzazione dei criteri presenta due vantaggi:
- Li rende permanenti nel caso in cui uno qualsiasi dei cluster di backend venga eliminato.
- I criteri possono essere gestiti centralmente per tutti i gruppi o per i gruppi personalizzati di cluster di backend.
Per assegnare i criteri Ranger alle identità utente o ai gruppi corretti, devi configurare Ranger per sincronizzare le identità dalla stessa directory a cui è connesso Knox. Per impostazione predefinita, le identità utente utilizzate dai ranger vengono recuperate dal sistema operativo.
Apache Ranger può anche esternalizzare gli audit log a Cloud Storage per renderli permanenti. Ranger utilizza Apache Solr come motore di indicizzazione e query per rendere gli audit log disponibili per la ricerca.
A differenza di HiveServer2, Spark SQL non dispone del supporto ufficiale per i plug-in Ranger, quindi devi utilizzare gli ACL granulari disponibili in Apache Knox per gestirne l'autorizzazione. Per utilizzare questi 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 ulteriori informazioni, consulta le best practice per l'utilizzo di Apache Ranger su Dataproc.
Alta disponibilità
Dataproc offre una modalità ad alta disponibilità. In questa modalità esistono diverse macchine configurate come nodi master, uno dei quali è in stato attivo. Questa modalità consente operazioni YARN e HDFS ininterrotte nonostante eventuali errori o riavvii di un singolo nodo.
Tuttavia, in caso di errore del nodo master, l'IP esterno del singolo punto di ingresso cambia e, di conseguenza, devi 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 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 DNS round robin, ma questo approccio comporta dei drawbacks. Queste configurazioni non rientrano nell'ambito di questo documento.
Cloud SQL fornisce inoltre una modalità ad alta disponibilità, con la ridondanza dei dati resa possibile dalla replica sincrona tra istanze master e istanze in standby situate in zone diverse. In caso di errore di un'istanza o di una zona, questa configurazione riduce i tempi di inattività. Tuttavia, tieni presente che per un'istanza con configurazione ad alta disponibilità 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 lasciano passare solo il 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 firewall consentono solo le richieste provenienti dagli indirizzi dei tuoi strumenti 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,
utilizzi la rete default per tutto il tutorial. Per ulteriori informazioni sulle configurazioni della rete a livelli, consulta le best practice relative alla sicurezza di rete VPC, la panoramica e gli esempi su come configurare più interfacce di rete.
Passaggi successivi
- Leggi la seconda parte della serie, Connessione del software di visualizzazione a Hadoop su Google Cloud, e scopri come configurare l'architettura su Google Cloud.
- Imposta l'architettura su Google Cloud utilizzando questi file di configurazione Terraform.
- Leggi le best practice per l'utilizzo di Apache Ranger su Dataproc.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.