Governança de Dados no Databricks: centralizar, descentralizar ou federar?
Entendendo os modelos de governança, as decisões arquiteturais e o papel do Unity Catalog na construção de plataformas de dados corporativas.
Quando falamos em arquitetura de dados, normalmente dedicamos bastante atenção à ingestão, ao processamento, à modelagem e à disponibilização das informações.
Mas existe uma discussão que considero igualmente importante e que, muitas vezes, acaba acontecendo somente quando a plataforma já está em operação: quem governa os dados, quem estabelece os padrões e até onde vai a autonomia de cada área de negócio?
Essa discussão ganha ainda mais relevância quando trabalhamos com plataformas corporativas que atendem diferentes áreas, produtos, unidades de negócio e até organizações distribuídas em múltiplas regiões ou provedores de nuvem.
Estudando a documentação oficial da Databricks sobre a arquitetura do Unity Catalog, encontrei uma abordagem interessante que gostaria de compartilhar.
A documentação apresenta quatro modelos operacionais de governança: centralizada, descentralizada, federada e híbrida.
Mais importante do que conhecer os nomes é compreender como cada modelo distribui responsabilidades e quais consequências essa escolha traz para a arquitetura e a operação da plataforma.
Antes da tecnologia, precisamos entender o modelo de governança
Um ponto que considero fundamental é separar duas decisões que, embora relacionadas, não representam a mesma coisa.
A primeira é o modelo operacional de governança, que define responsabilidades, propriedade dos dados, políticas e autonomia das equipes.
A segunda é a arquitetura técnica, que determina como workspaces, metastores, catálogos, esquemas, armazenamento e controles de acesso serão organizados.
Podemos ter, por exemplo, governança centralizada com diferentes workspaces e contas de armazenamento. Da mesma forma, podemos adotar uma governança federada utilizando um metastore compartilhado entre diferentes domínios.
Ou seja, centralização da governança não significa necessariamente centralização física de todos os dados.
Essa distinção é importante porque evita transformar decisões organizacionais em limitações técnicas desnecessárias.
1. Governança centralizada
No modelo centralizado, uma equipe estabelece e controla as políticas de governança para toda a organização.
É essa estrutura central que define os padrões de acesso, organização, segurança e administração dos ativos de dados e inteligência artificial.
As unidades de negócio continuam existindo e podem até possuir seus próprios ambientes operacionais, mas estão submetidas a uma autoridade comum de governança.
Vejo uma vantagem importante nesse modelo: consistência.
Quando as políticas são estabelecidas e aplicadas de forma centralizada, torna-se mais simples manter padrões corporativos, controlar acessos e atender exigências de segurança e conformidade.
Em organizações com requisitos regulatórios rigorosos, isso pode ser particularmente relevante.
Por outro lado, existe um risco que não podemos ignorar.
Se todas as decisões, solicitações de acesso, alterações estruturais e aprovações dependerem exclusivamente de uma equipe central, essa equipe pode se tornar um gargalo operacional.
Na minha visão, o desafio desse modelo não está simplesmente em centralizar, mas em conseguir centralizar o controle sem centralizar desnecessariamente todas as atividades operacionais.
2. Governança descentralizada
Na governança descentralizada, cada unidade de negócio ou domínio possui autonomia para administrar seus dados e estabelecer suas próprias políticas.
As responsabilidades deixam de estar concentradas em uma única estrutura corporativa e passam a ser exercidas individualmente pelas unidades.
Esse modelo favorece a autonomia e a velocidade de decisão.
Uma equipe pode evoluir seus produtos de dados, estabelecer processos e administrar seus recursos sem depender continuamente de uma estrutura central.
Entretanto, essa liberdade também exige atenção.
Quando diferentes equipes estabelecem seus próprios padrões, podemos acabar com políticas de segurança inconsistentes, nomenclaturas distintas, duplicação de ativos e dificuldades para compartilhar informações.
Imagine diferentes áreas mantendo conceitos distintos para uma mesma entidade corporativa, como cliente ou produto.
O problema deixa de ser exclusivamente técnico e passa a afetar diretamente a confiabilidade e a interpretação dos dados.
Por isso, considero que a descentralização exige maturidade das equipes e uma avaliação cuidadosa sobre o nível de integração necessário entre os domínios.
3. Governança federada
A governança federada procura equilibrar o controle corporativo com a autonomia operacional.
Nesse modelo, existe um escritório ou estrutura central de governança responsável por estabelecer diretrizes, políticas e padrões comuns.
Entretanto, a aplicação dessas políticas e a gestão dos dados são distribuídas entre as unidades de negócio.
A diferença em relação à governança centralizada está principalmente na distribuição da tomada de decisão e das responsabilidades.
A estrutura central não precisa executar todas as atividades. Ela estabelece os limites dentro dos quais os domínios podem trabalhar.
Gosto de enxergar esse modelo como uma forma de estabelecer autonomia com responsabilidade.
A equipe central pode definir, por exemplo, os requisitos de classificação de dados, políticas de acesso, nomenclatura, rastreabilidade e controles mínimos de qualidade.
Já as equipes responsáveis pelos domínios podem administrar seus pipelines, produtos de dados e processos operacionais, respeitando essas diretrizes.
Naturalmente, isso exige responsabilidades bem documentadas e mecanismos que garantam a aplicação consistente das políticas.
Uma governança federada sem mecanismos efetivos de controle pode acabar funcionando, na prática, como uma governança descentralizada.
A própria Databricks recomenda considerar a governança federada como ponto de partida para a maioria das organizações, justamente pelo equilíbrio entre controle e agilidade.
Isso não significa que ela seja obrigatoriamente a melhor escolha para qualquer empresa, mas demonstra sua relevância como modelo de referência.
4. Governança híbrida
A governança híbrida combina características de centralização e descentralização.
Nesse modelo, os ativos corporativos críticos permanecem sob gestão central, enquanto os domínios administram seus próprios dados e políticas específicas.
Podemos pensar em uma organização que mantenha dados mestres de clientes, informações de referência e determinados produtos de dados corporativos sob uma gestão comum.
Ao mesmo tempo, áreas como Financeiro, Comercial e Operações podem administrar seus dados específicos de acordo com suas necessidades.
O ponto principal é definir o que precisa ser compartilhado e governado centralmente e o que pode permanecer sob responsabilidade dos domínios.
Considero essa abordagem interessante para organizações com necessidades diferentes de governança entre seus conjuntos de dados.
Mas existe um detalhe: o modelo híbrido não deve ser utilizado como justificativa para ausência de padrões.
Mesmo com responsabilidades distintas, os critérios de integração, segurança, propriedade e compartilhamento precisam estar claros.
Onde o Unity Catalog entra nessa arquitetura?
Depois de compreender os modelos operacionais, chegamos a uma segunda discussão: como representar essas decisões tecnicamente no Databricks?
O Unity Catalog fornece os mecanismos de governança necessários para organizar e controlar ativos de dados e IA.
Entre seus principais elementos estão o metastore, os catálogos, os esquemas, os objetos de dados, os privilégios e as políticas de acesso.
Uma estrutura básica de organização utiliza o namespace de três níveis:
catalog.schema.table
Mas o Unity Catalog vai além da organização de tabelas.
Ele permite implementar controles administrativos, delegar responsabilidades, restringir acesso entre workspaces, estabelecer políticas de segurança e oferecer rastreabilidade.
Isso significa que o modelo de governança escolhido pode ser traduzido em mecanismos efetivos de controle.
E aqui existe uma decisão que considero especialmente importante: não confundir o limite de um workspace com o limite de governança dos dados.
Diferentes workspaces podem compartilhar o mesmo metastore regional e acessar catálogos comuns, desde que as permissões e restrições de acesso permitam.
Por outro lado, podemos limitar determinados catálogos a workspaces específicos por meio do recurso workspace-catalog binding.
Assim, o isolamento pode ser construído em diferentes níveis, sem exigir necessariamente a criação de uma estrutura completamente independente para cada unidade de negócio.
Como essa arquitetura se comporta em diferentes cenários de implantação?
A documentação oficial da Databricks apresenta três cenários importantes de implantação do Unity Catalog, considerando a distribuição geográfica e os provedores de nuvem utilizados.
Esses cenários são ilustrados com governança centralizada, mas ajudam a compreender como os mecanismos técnicos podem sustentar diferentes estruturas organizacionais.
Cenário 1 — Uma nuvem e uma região
Em uma organização que utiliza Databricks em uma única região de um provedor de nuvem, o padrão é utilizar um metastore regional compartilhado pelos workspaces daquela região.
Dentro do metastore, podemos organizar os catálogos conforme ambientes, domínios ou outras fronteiras de governança.
Os workspaces podem ser separados por finalidade operacional, enquanto o Unity Catalog administra o acesso aos objetos.
O importante é que essa arquitetura permite compartilhar mecanismos de governança sem obrigar todas as equipes a trabalhar no mesmo workspace ou utilizar o mesmo armazenamento.
Cenário 2 — Uma nuvem e múltiplas regiões
Quando a organização passa a operar em diferentes regiões, surge uma nova preocupação arquitetural.
O metastore possui escopo regional.
Por isso, o padrão documentado é utilizar um metastore por região, mantendo os workspaces associados ao metastore da respectiva região.
Nesse cenário, a estrutura central de governança precisa manter as políticas e os padrões consistentes entre os diferentes metastores.
Para o compartilhamento de dados entre regiões, a Databricks recomenda o mecanismo gerenciado de compartilhamento Databricks-to-Databricks, identificado na documentação como D2D OpenSharing.
Aqui, precisamos avaliar também questões como latência, custos de transferência entre regiões e frequência de consumo dos dados.
Nem sempre compartilhar dados entre regiões terá o mesmo custo operacional que acessá-los dentro de uma única região.
Cenário 3 — Múltiplas nuvens e múltiplas regiões
O terceiro cenário amplia a complexidade ao envolver diferentes provedores de nuvem.
Podemos ter, por exemplo, workloads distribuídos entre Azure e AWS, cada um com seus respectivos workspaces, regiões e metastores.
Nesse contexto, a governança corporativa precisa atravessar diferentes fronteiras técnicas.
O Unity Catalog continua sendo utilizado para estabelecer políticas e controlar os ativos dentro do seu escopo, mas cada ambiente precisa respeitar os limites da respectiva nuvem e região.
O compartilhamento entre os ambientes deve utilizar mecanismos apropriados, como o D2D OpenSharing, quando aplicável.
Um cuidado destacado pela documentação é evitar registrar a mesma tabela externa em diferentes metastores como forma de compartilhamento.
Isso pode provocar inconsistências de metadados, especialmente quando houver alterações de esquema, propriedades ou outras operações sobre a tabela.
A recomendação é utilizar os mecanismos de compartilhamento suportados pela plataforma.
A organização dos catálogos também faz parte da estratégia
Outro ponto interessante é que a Databricks não estabelece uma única convenção obrigatória para organizar os catálogos.
A documentação apresenta diferentes padrões de estruturação.
Podemos adotar catálogos orientados a ambientes, como dev, hml e prod.
Também podemos organizá-los por domínios de negócio, como financeiro, comercial e operacoes.
Outra possibilidade é combinar domínio e ambiente, utilizando convenções como financeiro_dev e financeiro_prod.
Existe ainda a organização por ciclo de vida dos dados, com catálogos associados a estágios como raw, curated e analytics.
Essas escolhas dependem da arquitetura, da estrutura organizacional e dos requisitos de isolamento.
Vale destacar que uma estrutura híbrida de catálogos não significa necessariamente um modelo híbrido de governança. São conceitos diferentes: um trata da organização dos objetos; o outro, da distribuição de responsabilidades e políticas.
Na minha visão, o mais importante não é adotar uma convenção simplesmente porque ela aparece em um exemplo de documentação.
É compreender se essa estrutura facilita a administração dos dados, o controle de acesso, a evolução dos ambientes e a responsabilidade sobre cada ativo.
A nomenclatura precisa representar uma decisão arquitetural, e não apenas uma preferência estética.
Hub-and-spoke: compartilhando ativos sem retirar a autonomia dos domínios
Um padrão adicional apresentado pela Databricks é o hub-and-spoke.
Nesse desenho, um catálogo central, chamado de hub, concentra ativos compartilhados pela organização.
Já os catálogos periféricos, chamados de spokes, representam domínios com seus próprios conjuntos de dados.
Podemos imaginar uma estrutura como esta:
Metastore — Região
│
├── core_prod
│ ├── clientes
│ └── dados_referencia
│
├── financeiro_prod
│ ├── silver
│ └── gold
│
├── comercial_prod
│ ├── silver
│ └── gold
│
└── operacoes_prod
├── silver
└── goldEsse exemplo é apenas uma possibilidade de organização lógica. Não representa uma estrutura obrigatória nem determina, por si só, o modelo operacional de governança.
O interessante é permitir que determinados dados corporativos tenham uma gestão comum, enquanto os domínios preservam estruturas próprias.
O hub-and-spoke pode ser especialmente útil em arquiteturas federadas ou híbridas, mas não é exclusivo desses modelos.
Ele é um padrão de organização técnica que precisa estar alinhado às responsabilidades e políticas definidas pela organização.
O que considero essencial antes de escolher um modelo
Na engenharia de dados, gosto de avaliar uma solução não apenas pelo que ela resolve inicialmente, mas também pelo que será necessário sustentar durante sua evolução.
Em governança, isso significa responder a algumas perguntas fundamentais:
Quem é responsável pelos dados e quem pode autorizar seu compartilhamento?
Quais políticas devem ser comuns a toda a organização?
Até onde vai a autonomia das unidades de negócio?
Quais ativos precisam de isolamento administrativo, lógico ou físico?
Como serão automatizados os controles, as permissões e a implantação dos ambientes?
Como serão realizadas a auditoria, a rastreabilidade e a revisão das políticas?
Essas respostas ajudam a evitar decisões que parecem simples no início, mas geram dificuldades de manutenção quando a plataforma cresce.
Também considero importante não criar segregações físicas ou administrativas sem uma necessidade clara.
Separar tudo pode aumentar significativamente a complexidade operacional. Por outro lado, compartilhar tudo sem controles adequados pode comprometer a segurança e o isolamento dos ambientes.
É justamente nesse equilíbrio que a arquitetura precisa trabalhar.
No Databricks, recursos como permissões baseadas em grupos, vínculos entre catálogos e workspaces, isolamento de armazenamento, tabelas gerenciadas, auditoria e automação de infraestrutura ajudam a materializar essas decisões.
Mas nenhuma dessas funcionalidades substitui a definição clara de responsabilidades.
Considerações finais
Uma conclusão que reforço a partir desse estudo é que governança de dados não começa na criação de catálogos, na definição de permissões ou na configuração de workspaces.
Ela começa na definição de responsabilidades e no entendimento de como a organização pretende administrar seus ativos de dados.
O Unity Catalog oferece recursos importantes para implementar essa estratégia, mas a tecnologia precisa refletir o modelo operacional escolhido.
A própria Databricks apresenta a governança federada como ponto de partida para muitas organizações e destaca a governança centralizada para ambientes com fortes exigências regulatórias.
Isso demonstra que não existe uma única abordagem adequada a todos os cenários.
Na minha avaliação, uma boa arquitetura de governança precisa conseguir equilibrar segurança, autonomia, padronização e capacidade de evolução.
O objetivo não deve ser centralizar ou descentralizar por princípio, mas estabelecer os controles necessários sem comprometer a capacidade da organização de produzir e consumir dados com confiança.
E essa é uma discussão que merece acontecer antes de começarmos a multiplicar catálogos, workspaces e estruturas de armazenamento.
Referências oficiais
Este artigo foi elaborado com base nas orientações arquiteturais publicadas pela Databricks.
Databricks — Phase 3: Design Unity Catalog Architecture
Microsoft Learn — Phase 3: Design Unity Catalog Architecture (Azure Databricks)
Databricks — Unity Catalog Best Practices
Databricks — Workspace-Catalog Binding
Databricks — Phase 2: Design Workspace Strategy
Comentários