Conexão, não cópia
A camada lógica se conecta às fontes onde elas já estão: bancos relacionais, não relacionais, data lakes, arquivos, APIs de terceiros. Nada é migrado. Nenhum projeto de migração é aberto.
Setor público · Virtualização de dados
Seus dados já existem.
Seus dados já existem.
O problema é chegar até eles.
Órgãos públicos gastam mais tempo copiando dados de um lugar para outro do que usando esses dados. Virtualização muda isso: uma camada única de acesso, sem mover um único registro.
Conversa técnica, sem apresentação comercial. Você sai com um mapa das suas fontes e dos gargalos.
Onde este problema já foi resolvido
- Tribunal de Contas estadual
- Órgão de infraestrutura rodoviária
O diagnóstico
Se três destas frases forem familiares, o problema é o mesmo
Marque mentalmente:
- Existe uma rotina que roda toda madrugada copiando dados de um sistema para outro, e quando ela falha ninguém percebe até alguém reclamar.
- A equipe construiu APIs ao longo dos anos e hoje não consegue manter todas funcionando ao mesmo tempo.
- O banco que atende o sistema do dia a dia também atende as consultas analíticas, e todo mundo sente a lentidão.
- Um analista novo significa criar usuário em uma dúzia de sistemas diferentes.
- Existe um data lake que custou caro e do qual tirar dado, nas palavras de quem trabalha nele, “é um parto”.
- Cada pedido de dado de um órgão parceiro vira um pequeno projeto.
Nenhum desses é um problema de ferramenta. É um problema de arquitetura: você está tentando usar dados que precisa possuir primeiro.
A virada
A virtualização de dados é o Spotify dos dados
Antes
Para ouvir uma música, antes você precisava possuir a música. CD, pendrive, MP3 baixado. Copiar, mover, organizar, guardar. Cada aparelho novo, tudo de novo.
Hoje
Hoje você aperta o play. Onde o arquivo está, em que servidor, em que formato, não é problema seu.
Dados funcionam igual. Hoje, para usar um dado, o seu órgão precisa possuir o dado: replicar, montar rotina, criar mais uma cópia, criar mais uma API, e assumir a manutenção de tudo isso para sempre.
Virtualização de dados é o play. O dado continua exatamente onde está. O que muda é que passa a existir um lugar só para consumir.
Como funciona
Quatro coisas mudam no dia seguinte
API na hora de publicar, não depois
Ao publicar um produto de dados na camada, a API já existe. Não há mais um ciclo de desenvolvimento entre “precisamos entregar esse dado” e “o dado está disponível”.
Mascaramento por perfil, na mesma consulta
Dado sensível como CPF aparece mascarado para quem não está autenticado e no valor real para quem tem permissão. Mesma API, mesma consulta, resposta diferente conforme o perfil. Você não precisa manter uma base “pública” separada da base real.
Uma porta em vez de vinte
Liberação de acesso, auditoria, rastreabilidade e linhagem passam a acontecer em um ponto único. Quem administra segurança para de gerenciar usuário em uma dúzia de bancos.
Camada lógica de acesso
Demonstração
O case
Um Tribunal de Contas mantinha 20 APIs na mão. Hoje mantém zero.
| Organização | Tribunal de Contas estadual, região Nordeste |
|---|---|
| Escopo | Dados de fiscalização de todos os municípios do estado |
| Antes | Replicação diária para SQL Server, cerca de 20 APIs mantidas manualmente, banco de origem sobrecarregado |
| Depois | Camada única de virtualização, APIs geradas na publicação, portal de dados abertos reconstruído |
O problema
Todo dado municipal do estado (gestores, órgãos, balancetes, licitações, empenhos, liquidações, pagamentos) estava concentrado em um sistema de informações municipais. Esse dado precisava chegar à sociedade, pelo portal de dados abertos, e a outros órgãos de controle: Fazenda, Ministério Público, Tribunal de Contas da União.
Para entregá-lo, o Tribunal mantinha uma engrenagem inteira nos bastidores. Uma rotina diária replicava dados para um SQL Server. Sobre esse banco, cerca de 20 APIs construídas à mão ao longo dos anos.
Construir não era o problema. Manter era. A equipe não conseguia sustentar todas funcionando ao mesmo tempo, e a descoberta de que uma quebrou geralmente vinha de fora.
O custo que ninguém somava
Cada novo pedido de dado significava mais uma extração, mais uma rotina, mais uma API e mais um item na lista de coisas que precisam funcionar para sempre. Uma equipe de dados que passa o dia mantendo encanamento é uma equipe que não está fiscalizando.
A solução
Uma camada lógica de virtualização sobre as fontes existentes, com Denodo. O dado parou de ser copiado.
O resultado
- A rotina diária de replicação deixou de existir.
- O portal de dados abertos foi reconstruído sobre a nova camada.
- Publicar uma nova API virou tarefa, não projeto.
- A carga sobre o banco de origem caiu.
- Consumidores externos deixaram de acessar bancos de origem.
- Frente atual: governança de dados mestres.
Case real, publicado em formato anonimizado a pedido do cliente. Identificação disponível em conversa comercial mediante autorização.
Caso de uso em piloto
E quando o órgão não produz nenhum dado próprio?
Existe uma categoria de órgão que vive uma situação particular: tudo o que ele usa vem de fora.
Um órgão gestor de malha rodoviária com o qual trabalhamos recebe dados de autuações por API de um provedor externo, dados de volumetria de tráfego em arquivos CSV entregues em janelas de 15 minutos, e outras bases de outros parceiros em outros formatos. Ele não fabrica nada disso. Consome, processa, guarda e precisa devolver.
Quando um cidadão contesta uma autuação, alguém precisa achar o registro. Só que o histórico estava em um data lake Cloudera, em Parquet, acessível via Impala com autenticação Kerberos. Consultar era trabalhoso. Exportar, mais ainda. Cruzar volumetria com autuações, que é a pergunta que realmente importa, exigia juntar três mundos técnicos.
O dado existia. Ele só não estava ao alcance de quem precisava, no tempo em que era preciso.
Está em andamento uma prova de conceito para expor essas fontes por uma camada única, automatizar a atualização e viabilizar o cruzamento entre volumetria e autuações. Resultados serão divulgados ao final.
Se você tem um Cloudera e a frase “tirar dado dali é um parto” soa familiar, esse é exatamente o problema.
Objeções
As perguntas que sempre aparecem
“Aqui a gente não tem esse problema.”
Talvez não. Três perguntas resolvem em cinco minutos: quantas rotinas de replicação a sua equipe mantém hoje e o que acontece quando uma falha de madrugada? Quanto tempo leva, do pedido à entrega, para publicar um dado novo para um órgão parceiro? Para dar acesso a um analista novo, em quantos sistemas alguém precisa criar usuário?
“Já temos data lake / Databricks / Fabric.”
Virtualização não substitui o seu data lake. Ela resolve o que continua fora dele, e sempre continua algo fora: o sistema legado que ninguém migra, o arquivo que chega do parceiro, a base do órgão vizinho, o SaaS. O data lake é onde você consolida o que dá para consolidar. A camada lógica é como você consulta o que não dá.
“Isso não é só mais uma camada no meio do caminho?”
É uma camada que substitui camadas. Ela elimina rotinas de replicação, cópias intermediárias e APIs artesanais. O resultado é menos peça móvel, não mais.
“Consulta em cima de várias fontes não fica lenta?”
Pergunta certa. A resposta envolve otimização de consulta com processamento empurrado para a fonte, cache seletivo do que é mais consultado e materialização do que realmente precisa ser materializado. É o tipo de conversa que fazemos com o seu time técnico, com as suas fontes, no diagnóstico.
“E a LGPD?”
Trabalha a favor. Menos cópias significa menos superfície de exposição. Mascaramento dinâmico por perfil, rastreabilidade de quem consultou o quê e linhagem completa, tudo administrado em um ponto.
“Precisamos parar os sistemas para implantar?”
Não. A camada é adicionada sobre as fontes existentes. Os sistemas continuam operando como estão.
Replicabilidade
Se você é de um Tribunal de Contas, isso é ainda mais direto
Tribunais de Contas trabalham sob um padrão comum. Todos recebem dados de muitos municípios, cada um entregando do seu jeito. Todos precisam devolver dados: à sociedade, pela transparência, e a órgãos parceiros como Fazenda, Ministério Público e TCU.
Em Minas Gerais são mais de 850 municípios sob fiscalização. Em estados menores, dezenas. A escala muda. A arquitetura do problema, não.
É por isso que o que funcionou em um Tribunal tende a funcionar nos demais com adaptação, não com reinvenção.
Diagnóstico
Trinta minutos, com o seu time técnico
Não é apresentação de produto. É diagnóstico.
- Mapeamos as suas fontes de dados e onde estão os pontos de atrito.
- Identificamos quais rotinas de replicação poderiam deixar de existir.
- Estimamos o esforço atual de manutenção de APIs e integrações.
- Você recebe um resumo escrito depois, independentemente de haver continuidade.
Retornamos em até 1 dia útil · Seus dados não são compartilhados com terceiros