Este documento destina-se a operadores e administradores de TI que querem configurar o acesso seguro a dados para analistas de dados usando ferramentas de inteligência de negócios (BI, na sigla em inglês), como o Tableau e o Looker. Ele não traz orientações sobre como usar ferramentas de BI ou interagir com APIs do Dataproc.
Este documento é a primeira parte de uma série que ajuda você a criar uma solução completa para fornecer aos analistas de dados acesso seguro aos dados usando ferramentas de BI. Neste documento, explicamos os seguintes conceitos:
- Uma arquitetura proposta.
- Uma visão de alto nível dos limites do componente, das interações e da rede na arquitetura.
- Uma visão de alto nível da autenticação e autorização na arquitetura.
A segunda parte desta série, Como conectar seu software de visualização ao Hadoop no Google Cloud, mostra como configurar a arquitetura no Google Cloud.
Arquitetura
O diagrama a seguir mostra a arquitetura e o fluxo de eventos que são explicados neste documento. Para mais informações sobre os produtos usados nessa arquitetura, consulte Componentes da arquitetura.
- Os aplicativos clientes se conectam pela Java Database Connectivity (JDBC) a um único ponto de entrada em um cluster do Dataproc. O ponto de entrada é fornecido pelo Apache Knox, que é instalado no nó mestre do cluster. A comunicação com o Apache Knox é protegida pelo TLS.
- O Apache Knox delega a autenticação por um provedor de autenticação a um sistema como um diretório LDAP.
- Após a autenticação, o Apache Knox encaminha a solicitação do usuário para um ou mais clusters de back-end. Você define as rotas e a configuração como topologias personalizadas.
- Um serviço de processamento de dados, como o Apache Hive, monitora o cluster de back-end selecionado e aceita a solicitação.
- O Apache Ranger intercepta a solicitação e determina se o processamento deve continuar, caso o usuário tenha ou não uma autorização válida.
- Se a validação for bem-sucedida, o serviço de processamento de dados analisará a solicitação e retornará os resultados.
Componentes da arquitetura
A arquitetura é composta dos seguintes componentes.
- A plataforma Hadoop gerenciada:
- Dataproc. O Dataproc é um serviço do Apache Spark e Apache Hadoop gerenciado pelo Google Cloud que permite aproveitar as ferramentas de dados de código aberto para processamento em lote, consultas, streaming e machine learning. O Dataproc é a plataforma que sustenta a solução descrita neste documento.
- Autenticação e autorização do usuário:
- Apache Knox. O Apache Knox age como um único ponto de acesso HTTP para todos os serviços subjacentes em um cluster do Hadoop. O Apache Knox foi projetado como um proxy reverso com provedores conectáveis para autenticação, autorização, auditoria e outros serviços. Os clientes enviam solicitações para o Knox e, com base no URL e nos parâmetros da solicitação, o Knox encaminha a solicitação para o serviço do Hadoop apropriado. Como o Knox é um ponto de entrada que processa de modo transparente as solicitações dos clientes e oculta a complexidade, ele está no centro da arquitetura.
- Apache Ranger (em inglês). O Apache Ranger oferece autorização detalhada para que os usuários executem ações específicas nos serviços do Hadoop. Ele também faz auditorias do acesso do usuário e implementa ações administrativas.
- Mecanismos de processamento:
- Apache Hive. O Apache Hive é um software de armazenamento de dados que permite acessar e gerenciar grandes conjuntos de dados que residem no armazenamento distribuído usando SQL. O Apache Hive analisa as consultas SQL, realiza análises semânticas e cria um gráfico acíclico direcionado (DAG, na sigla em inglês) de cenários para a execução de um mecanismo de processamento. Na arquitetura mostrada neste documento, o Hive age como o ponto de tradução entre as solicitações do usuário. Também pode atuar como um dos vários mecanismos de processamento. O Apache Hive é onipresente no ecossistema do Hadoop e abre as portas para especialistas familiarizados com o SQL padrão realizarem análises de dados.
- Apache Tez. O Apache Tez é o mecanismo de processamento responsável pela execução dos DAGs preparados pelo Hive e do retorno dos resultados.
- Apache Spark. O Apache Spark é um mecanismo de análise unificado para processamento de dados em grande escala compatível com a execução de DAGs. A arquitetura mostra o componente Spark SQL do Apache Spark para demonstrar a flexibilidade da abordagem apresentada neste documento. Uma restrição é que o Spark SQL não tem suporte oficial do plug-in Ranger. Por esse motivo, a autorização precisa ser feita com ACLs refinadas no Apache Knox, em vez de usar a autorização detalhada fornecida pelo Ranger.
Visão geral dos componentes
Nas seções a seguir, você aprenderá sobre cada um dos componentes em mais detalhes. Você também aprenderá como os componentes interagem uns com os outros.
Aplicativos clientes
Os aplicativos clientes incluem ferramentas que podem enviar solicitações para um endpoint HTTPS REST, mas não são compatíveis necessariamente com a API Dataproc Jobs. As ferramentas de BI, como Tableau e Looker, têm os drivers HiveServer2 (HS2) e JDBC do Spark SQL que podem enviar solicitações por HTTP.
Neste documento, pressupõe-se que os aplicativos clientes são externos ao Google Cloud, executados em ambientes como uma estação de trabalho de analista, no local ou em outra nuvem. Portanto, a comunicação entre os aplicativos clientes e o Apache Knox precisa ser protegida com um certificado SSL/TLS autoassinado ou assinado por uma autoridade de certificação.
Ponto de entrada e autenticação do usuário
Os clusters de proxy são um ou mais clusters do Dataproc de longa duração que hospedam o gateway do Apache Knox.
O Apache Knox atua como um ponto de entrada único para solicitações de clientes. O Knox está instalado no nó mestre do cluster do proxy. O Knox executa o encerramento do SSL, delega a autenticação do usuário e encaminha a solicitação a um dos serviços de back-end.
No Knox, cada serviço de back-end é configurado no que é chamado de topologia. O descritor de topologia define as seguintes ações e permissões:
- Como a autenticação é delegada a um serviço.
- O URI para o qual o serviço de back-end encaminha as solicitações.
- Listas de controle de acesso (ACLs, na sigla em inglês) simples por serviço.
O Knox permite que você integre autenticação aos sistemas de gerenciamento de identidade empresarial e em nuvem. Para configurar a autenticação do usuário para cada topologia, use provedores de autenticação. O Knox usa o Apache Shiro para fazer autenticação em um servidor LDAP de demonstração local do ApacheDS por padrão.
Como alternativa, você pode optar pelo Knox para usar o Kerberos. No diagrama anterior, como exemplo, você vê um servidor do Active Directory hospedado no Google Cloud fora do cluster.
Para informações sobre como conectar o Knox a um serviço de autenticação empresarial, como um servidor do ApacheDS externo ou o Microsoft Active Directory (AD), consulte o artigo Guia do usuário Apache Knox e a documentação Active Directory gerenciado e AD federado do Google Cloud.
Para o caso de uso deste documento, desde que o Apache Knox atue como o único coletor para os clusters de proxy e de back-end, você não precisará usar o Kerberos.
Mecanismos de processamento
Os clusters de back-end são os clusters do Dataproc que hospedam os serviços que processam as solicitações do usuário. Os clusters do Dataproc podem escalonar automaticamente o número de workers para atender à demanda da sua equipe de análises sem reconfiguração manual.
Recomendamos que você use clusters de longa duração do Dataproc no back-end. Os clusters de longa duração do Dataproc permitem que o sistema exiba solicitações dos analistas de dados sem interrupção. Como alternativa, se o cluster precisar veicular solicitações apenas por um breve período, use clusters específicos de job, também conhecidos como clusters efêmeros. Os clusters temporários também podem ser mais econômicos do que os clusters de longa duração.
Se você usar clusters efêmeros, para evitar a modificação da configuração de topologia, recrie os clusters na mesma zona e com o mesmo nome. Usando a mesma zona e nome, o Knox encaminha as solicitações de forma transparente usando o nome de DNS interno do nó mestre quando você recria o cluster efêmero.
O HS2 é responsável por processar consultas de usuários feitas ao Apache Hive. O HS2 pode ser configurado para usar vários mecanismos de execução, como o Hadoop MapReduce (em inglês), o Apache Tez e o Apache Spark. Neste documento, o HS2 está configurado para usar o mecanismo Apache Tez.
O Spark SQL é um módulo do Apache Spark que inclui uma interface JDBC/ODBC para executar consultas SQL no Apache Spark. No diagrama de arquitetura anterior, o Spark SQL é mostrado como uma opção alternativa para processar consultas de usuário.
Um mecanismo de processamento, Apache Tez ou Apache Spark, chama o YARN Resource Manager para executar o DAG do mecanismo nas máquinas do worker do cluster. Por fim, as máquinas do worker do cluster acessam os dados. Para armazenar e acessar os dados em um cluster do Dataproc, use o conector do Cloud Storage em vez do Hadoop Distributed File System (HDFS). Para mais informações sobre os benefícios do uso do conector do Cloud Storage, consulte a documentação do conector do Cloud Storage.
O diagrama de arquitetura anterior mostra uma topologia do Apache Knox que encaminha solicitações para o Apache Hive e outra que encaminha solicitações para o Spark SQL. O diagrama também mostra outras topologias que podem encaminhar solicitações para serviços no mesmo cluster ou em clusters de back-end diferentes. Os serviços de back-end podem processar diferentes conjuntos de dados. Por exemplo, uma instância do Hive pode oferecer acesso a informações de identificação pessoal (PII, na sigla em inglês) para um conjunto restrito de usuários, enquanto outra instância do Hive pode oferecer acesso a dados que não estão na categoria de PII para um consumo mais amplo.
Autorização do usuário
O Apache Ranger (em inglês) pode ser instalado nos clusters de back-end para fornecer uma autorização mais refinada para os serviços do Hadoop. Na arquitetura, um plug-in Ranger para o Hive intercepta as solicitações do usuário e determina se ele tem permissão para executar uma ação nos dados do Hive, com base nas políticas do Ranger.
Como administrador, você define as políticas do Ranger usando a página "Administrador do Ranger". Recomendamos que você configure o Ranger para armazenar essas políticas em um banco de dados externo do Cloud SQL. Esse procedimento tem duas vantagens:
- Ele as torna persistentes caso algum cluster de back-end seja excluído.
- Ele permite que as políticas sejam gerenciadas de maneira central em todos os grupos ou grupos personalizados de clusters de back-end.
Para atribuir políticas do Ranger às identidades de usuário ou grupos corretos, configure o Ranger para sincronizar as identidades do mesmo diretório ao qual o Knox está conectado. Por padrão, as identidades de usuário usadas pelo Ranger são retiradas do sistema operacional.
O Apache Ranger também pode externalizar os registros de auditoria para o Cloud Storage para torná-los permanentes. O Ranger usa o Apache Solr como mecanismo de indexação e consulta para tornar os registros de auditoria pesquisáveis.
Ao contrário do HiveServer2, o Spark SQL não é compatível com o plug-in oficial do Ranger. Portanto, você precisa usar as ACLs refinadas disponíveis no Apache Knox para gerenciar as respectivas autorizações. Para usar essas ACLs, adicione as identidades LDAP que podem usar cada serviço, como o Spark SQL ou o Hive, no descritor de topologia correspondente.
Para mais informações, consulte Práticas recomendadas para usar o Apache Ranger no Dataproc.
Alta disponibilidade
O Dataproc fornece um modo de alta disponibilidade (HA, na sigla em inglês). Nesse modo, há várias máquinas configuradas como nós mestres e um deles está no estado ativo. Esse modo permite operações ininterruptas do YARN e do HDFS, mesmo em caso de falha ou reinicialização de nó único.
No entanto, se o nó mestre falhar, o IP externo do ponto de entrada único mudará, portanto, será necessário reconfigurar a conexão da ferramenta de BI. Ao executar o Dataproc no modo de HA, configure um balanceador de carga HTTP(S) externo como o ponto de entrada. O balanceador de carga encaminha solicitações para um grupo de instâncias não gerenciadas que agrupa os nós mestres do cluster. Como alternativa a um balanceador de carga, é possível aplicar uma técnica de DNS round-robin, mas essa abordagem tem desvantagens. Essas configurações estão fora do escopo deste documento.
O Cloud SQL também fornece um modo de alta disponibilidade, com redundância de dados possibilitada pela replicação síncrona entre instâncias mestres e instâncias em espera localizadas em zonas diferentes. Se houver uma falha na instância ou zona, essa configuração reduzirá o tempo de inatividade. No entanto, uma instância configurada para alta disponibilidade é cobrada ao dobro do preço de uma instância independente.
O Cloud Storage funciona como o armazenamento de dados. Para mais informações sobre a disponibilidade do Cloud Storage, consulte descrições de classe de armazenamento.
Rede
Em uma arquitetura de rede em camadas, os clusters de proxy estão em uma rede de perímetro. Os clusters de back-end estão em uma rede interna protegida por regras de firewall que permitem somente o tráfego de entrada dos clusters de proxy.
Os clusters de proxy estão isolados dos outros clusters porque são expostos a solicitações externas. As regras de firewall só permitem que um conjunto restrito de endereços IP de origem acesse os clusters do proxy. Nesse caso, as regras de firewall permitem apenas solicitações provenientes dos endereços das ferramentas de BI.
A configuração de redes em camadas está fora do escopo deste documento. Em Como conectar seu software de visualização ao Hadoop no Google Cloud, você usará a rede default em todo o tutorial. Para mais informações sobre configurações de rede em camadas, consulte as práticas recomendadas para Segurança de rede VPC, além da visão geral e os exemplos da seção como configurar várias interfaces de rede.
A seguir
- Leia a segunda parte da série, Como conectar seu software de visualização ao Hadoop no Google Cloud e aprenda a configurar a arquitetura no Google Cloud.
- Configure a arquitetura no Google Cloud usando estes arquivos de configuração do Terraform.
- Leia sobre as práticas recomendadas para usar o Apache Ranger no Dataproc.
- Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.