Data Mesh Corporativo: Descentralização de Domínios Analíticos com AWS Lake Formation
O artigo orienta engenheiros e arquitetos de dados na aplicação dos princípios de Domain-Driven Design (DDD) aos dados analíticos utilizando o AWS Lake Formation, Amazon S3 e Amazon Athena. O material detalha o provisionamento de Data Products autônomos, o compartilhamento intercontas sem replicação física (Zero-ETL) através do AWS RAM e a imposição matemática de políticas de acesso em nível de linha e coluna (Cell-Level Security), garantindo governança federada e agilidade analítica em hiperescala.
Arquiteturas monolíticas de dados (Data Lakes centralizados) transformam equipes de engenharia de infraestrutura em gargalos operacionais críticos. Quando todos os domínios de negócios corporativos despejam dados brutos em um repositório único gerenciado por uma equipe isolada, a latência para construir pipelines de transformação e extrair valor analítico estende-se por meses. Esse acoplamento arquitetônico destrói a agilidade organizacional e frequentemente converte lagos de dados em pântanos obscuros e não governados, com linhagem de dados fragmentada e segurança inconsistente. A adoção do paradigma Data Mesh resolve esta falha estrutural aplicando os princípios de descentralização do Domain-Driven Design (DDD) diretamente à camada analítica (Dehghani, 2022). Ao orquestrar o AWS Lake Formation, o Amazon S3 e o AWS Glue, as corporações delegam a propriedade do dado, tratando-o como um produto autônomo (Data Product) gerenciado estritamente pelas equipes que o geram. Esta topologia assegura governança de segurança global com execução federada, eliminando silos centralizados e viabilizando o consumo transversal de inteligência sem mover fisicamente um único byte entre os limites das contas corporativas.
Pré-requisitos
O provisionamento desta topologia analítica federada exige domínio estrito sobre o AWS Organizations e as mecânicas de delegação de acesso entre contas (Cross-Account). A infraestrutura necessita de orquestração imutável via Terraform versão 1.7.0 ou superior e o provedor HashiCorp AWS versão 5.40.0. A camada de engenharia de dados focada na geração do produto requer o Python 3.12 acoplado à biblioteca
boto3 versão 1.34.0 e ao pacote awswrangler (AWS SDK for pandas) versão 3.6.0 para transformações eficientes de matrizes em formato Parquet. Privilégios administrativos no AWS Resource Access Manager (RAM) são imperativos para estabelecer os vínculos topológicos de confiança entre a conta AWS produtora do domínio e as múltiplas contas consumidoras.Passo a Passo
Instanciando o Produto de Dados do Domínio
A materialização de um Data Mesh exige a criação de um limite físico e lógico para o Produto de Dados dentro da conta AWS pertencente ao domínio produtor. A justificativa técnica subjacente dita que o plano operacional (bancos de dados transacionais como Aurora ou DynamoDB) nunca deve ser impactado por consultas analíticas pesadas. O domínio de Faturamento (Billing), por exemplo, extrai continuamente seu estado transacional e o persiste no Amazon S3 em um formato colunar altamente compactado, como o Apache Parquet. Utilizamos o AWS Glue Data Catalog para mapear a semântica destes arquivos estáticos, criando um banco de dados e tabelas lógicas que definem o contrato de dados (Data Contract). Para garantir que a engine de governança assuma o controle sobre este repositório, revogamos as permissões arcaicas do
IAMAllowedPrincipals, forçando todas as avaliações de acesso a passarem exclusivamente pelo motor de políticas do AWS Lake Formation.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
resource "aws_s3_bucket" "billing_data_product" {
bucket = "enterprise-billing-data-product-prod"
}
resource "aws_glue_catalog_database" "billing_domain" {
name = "billing_domain_db"
description = "Produto de dados gerido pela equipe de Faturamento"
}
# Revogação do acesso IAM legado para impor governança estrita via Lake Formation
resource "aws_lakeformation_permissions" "revoke_legacy_iam" {
principal = "IAMAllowedPrincipals"
permissions = ["ALL"]
database {
name = aws_glue_catalog_database.billing_domain.name
}
}
resource "aws_lakeformation_resource" "billing_s3_registration" {
arn = aws_s3_bucket.billing_data_product.arn
}
Como compartilhamos este produto de dados recém-criado com outros domínios de negócios adjacentes através dos limites da conta AWS sem replicar fisicamente os terabytes de arquivos Parquet e incorrer em custos draconianos de armazenamento duplicado?
Governança Federada e Compartilhamento Intercontas
Compartilhamos o Produto de Dados orquestrando concessões (grants) intercontas nativas do AWS Lake Formation integradas ao AWS Resource Access Manager (RAM). A descentralização exige que o domínio produtor mantenha o controle absoluto sobre a custódia do arquivo, autorizando apenas a visibilidade do catálogo lógico para assinantes legítimos. O Lake Formation automatiza a criação de um recurso compartilhado (Resource Share) no AWS RAM apontando para a conta AWS consumidora (por exemplo, o domínio de Ciência de Dados). O raciocínio arquitetônico para suprimir o uso de políticas de bucket S3 excessivamente permissivas (Bucket Policies) é a auditoria. O Lake Formation centraliza o log de concessões e acessos, permitindo que o domínio produtor revogue a leitura de uma tabela analítica em milissegundos, propagando a negação de acesso instantaneamente para todos os consumidores, independentemente de quais serviços analíticos eles estejam utilizando.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
resource "aws_lakeformation_permissions" "cross_account_grant" {
principal = var.data_science_account_id
permissions = ["DESCRIBE", "SELECT"]
permissions_with_grant_option = []
table {
database_name = aws_glue_catalog_database.billing_domain.name
name = "monthly_invoices"
wildcard = false
}
}
# A aceitação do compartilhamento na conta consumidora é exigida para materializar o link
provider "aws" {
alias = "consumer"
profile = "data_science_account"
}
resource "aws_ram_resource_share_accepter" "accept_billing_data" {
provider = aws.consumer
share_arn = var.ram_share_arn_from_producer
}
Se o domínio consumidor agora possui acesso integral à infraestrutura de tabelas do catálogo federado, como o domínio produtor assegura matematicamente a ofuscação de Informações Pessoalmente Identificáveis (PII), limitando a exposição de colunas confidenciais sem criar visões (views) materializadas e redundantes no armazenamento?
Segurança Granular com Filtros de Célula (Cell-Level Security)
Asseguramos o isolamento de dados sensíveis aplicando Filtros de Dados (Data Filters) no Lake Formation, estabelecendo políticas dinâmicas de segurança em nível de linha e coluna (Cell-Level Security). A arquitetura moderna repudia a clonagem de dados para propósitos de ofuscação. Em vez de construir pipelines complexos que geram tabelas derivadas mascaradas para analistas juniores, o engenheiro produtor define uma política matemática acoplada ao catálogo. Quando um cientista de dados na conta consumidora tenta realizar um
SELECT, o motor de acesso do Lake Formation avalia o filtro em tempo de execução. Se a identidade do chamador não possuir privilégios de alto escalão, o Lake Formation instruirá o motor de consulta subjacente a excluir colunas sensíveis (como credit_card_hash) e filtrar linhas transacionais (permitindo, por exemplo, a visualização apenas de transações cujo país de origem seja correspondente ao território de atuação do analista).1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
import boto3
from aws_lambda_powertools import Logger
logger = Logger(service="LakeFormationGovernance")
lf_client = boto3.client('lakeformation')
class DataGovernanceAdapter:
def create_pii_obfuscation_filter(self, db_name: str, table_name: str, filter_name: str):
logger.info(f"Estabelecendo filtro Cell-Level na tabela {table_name}")
# Criação de um filtro que exclui colunas PII e restringe linhas por região
lf_client.create_data_cells_filter(
TableData={
'DatabaseName': db_name,
'Name': table_name,
'CatalogId': boto3.client('sts').get_caller_identity()['Account']
},
DataCellsFilter={
'TableCatalogId': boto3.client('sts').get_caller_identity()['Account'],
'DatabaseName': db_name,
'TableName': table_name,
'Name': filter_name,
'RowFilter': {
'FilterExpression': "region = 'US'"
},
'ColumnWildcard': {
'ExcludedColumnNames': ['customer_tax_id', 'credit_card_hash']
}
}
)
def grant_filtered_access(self, target_account: str, db_name: str, table_name: str, filter_name: str):
lf_client.grant_permissions(
Principal={'DataLakePrincipalIdentifier': target_account},
Resource={
'DataCellsFilter': {
'TableCatalogId': boto3.client('sts').get_caller_identity()['Account'],
'DatabaseName': db_name,
'TableName': table_name,
'Name': filter_name
}
},
Permissions=['SELECT']
)
Uma vez que a segurança matemática em nível de célula está imposta e os dados permanecem imutáveis na origem, qual mecanismo a conta consumidora utiliza para agregar estas fatias lógicas distribuídas e executar consultas analíticas complexas sem provisionar clusters computacionais massivos de longo prazo?
Consumo Analítico Federado com Amazon Athena
A conta consumidora executa agregações sobre os produtos de dados federados adotando o Amazon Athena como motor de processamento Serverless. O Athena integra-se nativamente ao AWS Lake Formation e compreende o Catálogo de Dados do Glue (Data Catalog) de contas externas através de links de recursos locais (Resource Links). O paradigma de descentralização culmina nesta camada de consumo. O domínio analítico submete uma consulta SQL ANSI padrão; o Athena resolve os links intercontas de forma invisível, autentica a execução contra os filtros de célula (Cell-Level Security) da conta produtora e escaneia diretamente os arquivos Parquet no S3 de origem. Este processamento Massively Parallel Processing (MPP) opera sob um modelo estrito de faturamento por terabyte escaneado, eliminando os custos ociosos de armazéns de dados relacionais e finalizando a separação arquitetônica absoluta entre armazenamento e computação.
Solução de Problemas Comuns
A adversidade mais paralisante durante a orquestração do Lake Formation envolve o diagnóstico de erros
Insufficient Lake Formation Permission quando as políticas do AWS IAM anexadas ao usuário consumidor aparentam fornecer acesso total (s3:* e glue:*). A resolução requer a compreensão da dualidade de acesso na AWS. O Lake Formation atua como uma malha de negação implícita sobre o IAM. Mesmo possuindo credenciais de administrador (AdministratorAccess), se a identidade analítica não for explicitamente listada na aba de Data Lake Permissions do Lake Formation associada ao banco de dados ou tabela alvo, a consulta no Athena será sumariamente bloqueada. A correção exige a inserção do ARN da função consumidora nas permissões SELECT granulares do Lake Formation da conta gestora do recurso.Um segundo gargalo técnico grave é materializado pela falha
HIVE_PARTITION_SCHEMA_MISMATCH no Athena durante a execução sobre Data Products em evolução. Esse sintoma surge quando o domínio produtor adiciona novas colunas transacionais aos arquivos Parquet mais recentes, fragmentando a integridade estrutural do diretório do S3 contra a definição de tabela previamente registrada no Glue Catalog. O domínio produtor deve mitigar a quebra de contrato de dados mantendo ativamente as partições mapeadas e configurando rastreadores do AWS Glue (Glue Crawlers) operando em gatilhos orientados a eventos para atualizar os metadados do catálogo de forma síncrona com os arquivos físicos.Conclusão
A transição para um Data Mesh governado pelo AWS Lake Formation dissipa os estrangulamentos operacionais dos lagos de dados monolíticos. Ao consagrar domínios orientados por produtos, separar o armazenamento via S3 da computação sob demanda no Athena, e aplicar ofuscação não-destrutiva de nível de célula, as corporações democratizam o acesso seguro aos dados e aceleram iniciativas de aprendizado de máquina. Como direcionamento de maturidade organizacional, a engenharia de dados corporativa deve automatizar a criação dessas estruturas de compartilhamento intercontas através de portais de autoatendimento (Data Catalogs customizados). Em um espectro de expansão multicloud, esse design federado de contratos de dados converte-se conceitualmente para o Microsoft Purview orquestrando Azure Data Lake Storage Gen2, garantindo interoperabilidade transfronteiriça robusta.
Referências
Dehghani, Z. (2022). Data mesh: Delivering data-driven value at scale. O'Reilly Media.
Amazon Web Services. (2023). Build a data mesh architecture on AWS using AWS Lake Formation. AWS Architecture Center. https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/build-a-data-mesh-architecture-on-aws-using-aws-lake-formation.html
Kleppmann, M. (2017). Designing data-intensive applications: The big ideas behind reliable, scalable, and maintainable systems. O'Reilly Media.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article