Habilitando análise interativa dos seus dados em um ambiente multi-contas

Por Luiz Yanai, arquiteto especialista sênior em Data & AI na AWS.

Em arquiteturas corporativas baseadas em nuvem muitas vezes trabalha-se com múltiplas contas para oferecer uma melhor segregação entre recursos e aplicações de diferentes unidades de negócio e também como forma de aumentar a segurança. Um ambiente de dados pode apresentar essa segregação, e em situações onde os dados estão distribuídos em múltiplas contas, é essencial adotar soluções que promovam a democratização do acesso a essas informações, eliminando a necessidade de complexos pipelines de integração.

Neste artigo vamos demonstrar como um usuário pode acessar dados disponíveis em uma conta produtora dentro da organização sem ter a necessidade de replicar os dados e os metadados associados.

O motor de busca que se encaixa perfeitamente neste cenário é o Amazon Athena. Athena é um serviço de análise interativo e sem servidor criado em frameworks de código aberto (Trino e Presto) que permite realizar consultas em formatos de arquivos abertos e diferentes fontes de dados. O Athena fornece uma maneira simplificada e flexível de analisar petabytes de dados onde eles residem. Ele oferece funcionalidades para integração entre múltiplas contas AWS além de se integrar com o AWS Lake Formation para permitir uma gestão única das permissões de acesso aos dados da organização.

A figura 1 mostra um exemplo de arquitetura para implementar este tipo de cenário multi-contas. Em nosso cenário fictício de arquitetura, temos um analista de dados que utiliza seu desktop para efetuar suas análises de dados. Ele faz parte da unidade de negócios 2 (UN2), mas deseja utilizar datasets existentes em outra conta da companhia pertencente a unidade de negócios 1 (UN1). Ao invés de ter que replicar os dados e/ou também os metadados da conta UN1 para UN2, os serviços da AWS permitem que o analista faça um acesso direto aos metadados e datasets da UN1, sendo que os custos do motor de consultas (Athena) são contabilizados na UN2.

Fig. 1 – Cenário de compartilhamento de datasets cross account através do AWS Glue Data Catalog e Athena.

Nesta arquitetura destacam-se alguns itens importantes que viabilizam esta integração. São eles:

1. Suporte cross-account do Data Catalog: através de uma resource policy definida para o catálogo de dados na UN1 é possível dar acesso para que um principal (usuário, role, conta) tenha acesso aos metadados registrados no Data Catalog;
2. Data source externo do Athena: além de permitir a análise de petabytes de dados no Amazon S3, o Athena permite consultar data sources externos através da funcionalidade de queries federadas. Entre as fontes de dados suportadas temos armazenamentos de dados na nuvem e on-premises, na AWS ou outra nuvem, e também catálogos de dados de outras contas AWS;
3. Políticas do IAM e bucket policy: o Athena é apenas um meio para se chegar nos dados que estão armazenados em um bucket no S3. Toda a parte de permissionamento precisa ser configurado para que o usuário final tenha acesso ao bucket na conta UN1 e o bucket também precisa que sua bucket policy permita os acessos vindos da conta UN2.

Configurações de permissionamento

Um dos pontos chave para que os dados cheguem ao DBeaver através da conexão JDBC é que toda a questão de segurança esteja configurada. Conforme descrito no item 3 da arquitetura, o usuário/role da conta UN2 precisa ter acesso ao catálogo na conta UN1. A seguinte política do IAM atribuída a um usuário IAM ou a uma role dá acesso aos metadados do catálogo na conta UN1. As operações mínimas necessárias da API do AWS Glue são:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CatalogCrossAccount",
            "Effect": "Allow",
            "Action": [
                "glue:GetDatabases", 
                "glue:GetDatabase", 
                "glue:GetTables", 
                "glue:GetTable"
            ],
            "Resource": [
                "arn:aws:glue:us-east-2:<un1-account-id>:catalog",
                "arn:aws:glue:us-east-2:<un1-account-id>:database/default",
                "arn:aws:glue:us-east-2:<un1-account-id>:database/cross-account-db",
                "arn:aws:glue:us-east-2:<un1-account-id>:table/cross-account-db/sales"
            ]
        }
    ]

Policy para role A que permite acesso aos catálogos, database e tabelas na outra conta AWS

Na conta UN1 é preciso também dar acesso no recurso específico (Data Catalog) para que o mesmo possa ser acessado pela outra conta UN2. Esta configuração de resource policy pode ser feita via console, linha de comando, etc. Pela console, basta acessar o serviço Data Catalog e clicar em Catalog Settings. Depois inclua a seguinte política liberando o acesso cross account.

{
  "Version" : "2012-10-17",
  "Statement" : [ {
    "Effect" : "Allow",
    "Principal" : {
      "AWS" : "arn:aws:iam::<un2-account-id>:root"
    },
    "Action" : [
           "glue:GetDatabases", 
           "glue:GetDatabase", 
           "glue:GetTables", 
           "glue:GetTable"
     ],
    "Resource" : [ 
        "arn:aws:glue:us-east-2:<un1-account-id>:catalog", 
        "arn:aws:glue:us-east-2:<un1-account-id>:database/cross-account-db", 
        "arn:aws:glue:us-east-2:<un1-account-id>:table/cross-account-db/sales" ]
  } ]
}

Resource Policy que dá a permissão na role para a conta consumidora acessar o catálogo, database e tabelas locais.

Um ponto importante que não pode ser esquecido é que o usuário (analista de dados) somente pode acessar um dataset qualquer via Athena se ele tiver acesso permitido ao bucket que contém os arquivos deste dataset. Portanto, é preciso dar acesso a conta UN2 para obter os objetos do bucket desejado.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "All",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<un2-account-id>:root"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::demo-athena-cross-account",
                "arn:aws:s3:::demo-athena-cross-account/*"
            ]
        }
    ]
}

Bucket Policy que dá permissão para que a Role na conta UN2 acesse os arquivos

Para o Athena enxergar os databases e tabelas cujo acesso foi liberado pelo conjunto das políticas IAM anteriores, deve-se criar um novo data source apontando para a conta AWS onde se encontram os recursos.

Fig. 2 – Menu do Athena para configuração de novos data sources

Os passos para a criação de um novo data source são:

1. No menu lateral da home do Athena, clicar no link Data sources na seção Administration.
2. Por padrão já existe um data source default chamado AwsDataCatalog associado ao Data Catalog local. Vamos criar um novo data source clicando no botão Create data source.
3. O Athena suporta diferentes data sources dentro e fora da AWS incluindo recursos em outras nuvens. Neste nosso cenário vamos escolher a opção S3 – AWS Glue Data Catalog e clicar no botão Next.
4. Para este tipo de data source, podemos configurar o Data Catalog local ou apontar para um existente em outra conta AWS. Selecionar a opção AWS Glue Data Catalog in another account. 
5. Entrar com os detalhes:
   1. Data source name: atribuir um nome que será utilizado na escrita das consultas SQL que desejam acessar as tabelas em outra conta.
   2. Description: campo opcional que deve ser preenchido com informações sobre o data source.
   3. Catalog ID: entrar com o id da conta AWS que contém o Data Catalog que se deseja acessar.
   4. Opcionalmente pode-se adicionar tags ao recurso. Clicar em Next.
6. Revisar os valores preenchidos e se estiver tudo pronto, clicar em Create data source.

Imediatamente após a criação do data source, se as políticas do IAM foram devidamente criadas, já será possível ver a listagem dos databases associados com o data source cujo acesso foi liberado.

Configuração do DBeaver

DBeaver é uma ferramenta cliente para acesso a diferentes bancos de dados que é muito utilizada por usuários técnicos e não técnicos para efetuar análises de dados.

Para este exemplo usaremos a versão da comunidade disponível para download em: https://dbeaver.io/download/

Após instalar o DBeaver no desktop, o usuário deve criar uma conexão usando o wizard na figura abaixo. Como podemos ver na imagem, ele suporta bancos de dados populares tanto relacionais como NoSQL de diferentes fornecedores.

Use o filtro para buscar o Athena e clique em Next.

Fig. 3 – Wizard de criação de conexão para diferentes databases da ferramenta DBeaver.

A próxima tela de configuração deve ser preenchida com a região na qual os recursos foram provisionados e também o bucket que vai armazenar o resultado das consultas do Athena.

O usuário e senha para autenticação (no caso de usuários do IAM) devem ser preenchidos respectivamente com as chaves Access Key e Secret Access Key do usuário do IAM. Uma outra possibilidade de autenticação pode ser via SAML e os passos estão descritos em: https://docs.thinkwithwp.com/athena/latest/ug/security-athena-lake-formation-jdbc.html

Para que seja possível visualizar os databases/tabelas da outra conta AWS é preciso marcar o checkbox Show catalogs para que seja listado tanto os catálogos locais como os catálogos externos registrados anteriormente.

Fig. 4 – Tela com parâmetros de conexão para o Athena

 Caso você não tenha os drivers JDBC do Athena configurados no DBeaver, basta clicar no botão Driver Settings que a seguinte tela será carregada. Nesta tela, selecionando a aba Libraries, é possível ver as bibliotecas necessárias e a opção de fazer o download das mesmas.

Fig. 5 – Tela do DBeaver para configurar bibliotecas JDBC do Athena

Fig. 6 – Catálogos local e externo listados no DBeaver

Finalizada a configuração, os usuários do DBeaver terão acesso para navegar e efetuar consultas usando o Athena e acessando dados tanto na conta local do usuário IAM como em recursos remotos de outras contas da mesma organização.

CONCLUSÃO

Vimos neste artigo que é extremamente simples habilitar o acesso ao catálogo de dados do AWS Glue de contas externas para permitir o acesso transparente a diferentes datasets espalhados em uma organização com múltiplas contas AWS. Por conta da integração e acesso dos serviços de analytics a ambientes complexos, raramente é necessário fazer a cópia de datasets ou metadados entre ambientes evitando assim duplicação de custos e preocupação com rotinas de replicação.

Seguem abaixo algumas referências para:

Configuração de conexão JDBC com o Amazon Athena

https://docs.thinkwithwp.com/athena/latest/ug/connect-with-jdbc.html

Configuração de acesso cross-account do Data Catalog

https://docs.thinkwithwp.com/glue/latest/dg/cross-account-access.html

Fornecendo acesso cross-account para recursos do Data Catalog

https://repost.aws/knowledge-center/glue-data-catalog-cross-account-access

Query cross-account AWS Glue Data Catalogs usando Amazon Athena

https://thinkwithwp.com/blogs/big-data/query-cross-account-aws-glue-data-catalogs-using-amazon-athena/

Sobre o autor

Luiz Yanai é arquiteto especialista sênior em Data & AI na AWS atuando com clientes nativos na nuvem e empresas do ramo financeiro em suas jornadas para se tornarem data-driven. Possui 20 anos de experiência em arquitetura e desenvolvimento de soluções envolvendo sistemas empresariais e de missão crítica sendo que os últimos 5 anos estão focados na nuvem AWS.

Revisores

Gerson Itiro Hidaka atualmente trabalha como Enterprise Solution Architect na AWS e atua no atendimento a clientes da área Financeira no Brasil. Entusiasta de tecnologias como Internet das Coisas (IoT), Drones, Devops e especialista em tecnologias como contêineres, serverless computing e Kubernetes. Trabalha com soluções de TI há mais de 26 anos, tendo experiência em inúmeros projetos de otimização de infraestrutura, redes, migração, disaster recovery e DevOps em seu portifólio.

Carolina Ferreira é arquiteta de soluções na AWS para clientes de vários segmentos, com área de aprofundamento em Analytics.