Questo documento è rivolto agli operatori e agli amministratori IT che vogliono configurare un accesso sicuro ai dati per gli analisti di dati utilizzando 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 ti aiuta a creare una soluzione end-to-end per consentire agli analisti di dati di accedere in modo sicuro ai dati utilizzando strumenti BI. Questo documento spiega i seguenti concetti:
- Un'architettura proposta.
- Una visione generale dei limiti, delle interazioni e del networking dei componenti nell'architettura.
- una visione ad alto livello dell'autenticazione e dell'autorizzazione nell'architettura.
La seconda parte di questa serie, Connecting your visual software to Hadoop on Google Cloud, ti 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 dell'architettura.
- 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 dell'utente a uno o più cluster di backend. Le route e la configurazione sono definite come topologie personalizzate.
- Un servizio di elaborazione dati, come Apache Hive, rimane in ascolto sul 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 elaborazione batch, query, inserimento di flussi e 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 collegabili per autenticazione, autorizzazione, controllo e altri servizi. I client inviano richieste a Knox e, in base all'URL e ai parametri 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 agli utenti un'autorizzazione granulare per 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 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 un grafico diretto aciclico (DAG) di fasi per l'esecuzione di un motore di elaborazione. Nell'architettura mostrata in questo documento, Hive agisce da punto di traduzione tra le richieste dell'utente. Può anche agire come uno dei vari motori di elaborazione. Apache Hive è onnipresente nell'ecosistema Hadoop e apre le porte ai professionisti che hanno familiarità con SQL standard per eseguire l'analisi dei dati.
- Apache Tez, Apache Tez è il motore di elaborazione responsabile 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 dei 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 supporta il plug-in Ranger ufficiale. Per questo motivo, l'autorizzazione deve essere eseguita tramite gli ACL con granularità approssimativa in Apache Knox anziché utilizzare l'autorizzazione granulare fornita da 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 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.
Questo documento presuppone che le applicazioni client siano esterne a Google Cloud e vengano eseguite in ambienti come una workstation di analisi, on-premise o su un altro cloud. Di conseguenza, la comunicazione tra le applicazioni client e Apache Knox deve essere protetta con un certificato SSL/TLS firmato da CA o autofirmato.
Autenticazione utente e del punto di ingresso
I cluster proxy sono uno o più cluster Dataproc di lunga durata che ospitano il gateway Apache Knox.
Apache Knox agisce da single entry point per le richieste dei 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 una 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.
- Elenchi di controllo dell'accesso (ACL) semplici per l'autorizzazione per servizio.
Knox consente di integrare l'autenticazione con i sistemi di gestione delle identità aziendali e cloud. Per configurare l'autenticazione degli utenti per ogni topologia, puoi usare i provider di autenticazione. Per impostazione predefinita, Knox utilizza Apache Shiro per eseguire l'autenticazione su un server LDAP ApacheDS 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 al di fuori del cluster.
Per informazioni su come connettere Knox a servizi di autenticazione aziendali 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, se Apache Knox agisce da singolo gatekeeper per il proxy e i cluster 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 team di analisti senza riconfigurazione manuale.
Ti consigliamo di utilizzare cluster Dataproc di lunga durata nel backend. I cluster Dataproc di 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, noti anche come cluster temporanei. I cluster temporanei possono anche essere più convenienti di quelli a 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 nodo master del 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, ad esempio 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 architetturale precedente, Spark SQL rappresentato come opzione alternativa per le 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 architetturale 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 diversi cluster di backend. I servizi di backend possono elaborare set di dati diversi. Ad esempio, un'istanza Hive può offrire l'accesso a informazioni che consentono l'identificazione personale (PII) per un insieme limitato di utenti, mentre un'altra istanza Hive può offrire l'accesso a dati non PII per un uso 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 dell'utente e determina se a un utente è consentito eseguire un'azione sui dati Hive, in base ai criteri dei ranger.
In qualità di amministratore, puoi definire i criteri dei ranger utilizzando la pagina Amministratore 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 in caso di eliminazione dei cluster di backend.
- Consente la gestione centralizzata dei criteri per tutti i gruppi o per gruppi personalizzati di cluster di backend.
Per assegnare i criteri Ranger alle identità o ai gruppi utente corretti, devi configurare Ranger in modo che sincronizzi le identità dalla stessa directory a cui è connesso Knox. Per impostazione predefinita, le identità utente utilizzate da Ranger vengono acquisite 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 supporta il plug-in Ranger ufficiale, 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 di 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 una modalità ad alta disponibilità. In questa modalità esistono diverse macchine configurate come nodi master, una delle quali è in stato attivo. Questa modalità consente operazioni YARN e HDFS ininterrotte malgrado errori o riavvii di singoli nodi.
Tuttavia, in caso di errore del nodo master, l'IP esterno del singolo punto di ingresso cambia, quindi 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 al bilanciatore del carico, puoi applicare una tecnica DNS round-robin, ma questo approccio presenta alcuni drawbacks. Queste configurazioni non rientrano nell'ambito di questo documento.
Cloud SQL offre inoltre una modalità ad alta disponibilità, la cui ridondanza dei dati è possibile grazie alla replica sincrona tra le istanze master e le istanze in standby situate in zone diverse. In caso di errore di un'istanza o una zona, questa configurazione riduce il tempo di inattività. Tuttavia, tieni presente che un'istanza configurata ad alta disponibilità ha un costo doppio rispetto a quello 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 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 durante il tutorial. Per ulteriori informazioni sulle
configurazioni di reti a più livelli, consulta le best practice per
la sicurezza di rete VPC
e la panoramica e gli esempi su
come configurare più interfacce di rete.
Passaggi successivi
- Leggi la seconda parte della serie, Collegamento 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.