Capítulo 23 — Analytics e Data Lake

23.1 Objetivo do Capítulo

Este capítulo detalha a arquitetura de Analytics e Data Lake da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como os dados operacionais produzidos pelos serviços de domínio são ingeridos, governados, transformados, disponibilizados e analisados para apoiar a gestão dos órgãos e a evolução contínua dos serviços públicos.

O módulo cobre: arquitetura do Data Lake por tenant, pipeline de ingestão, zonas de dados, qualidade, catálogo, linhagem, contratos, Data Products, camada semântica, dashboards, relatórios, exploração de dados, integração com IA e governança analítica.

23.2 Papel do Analytics e Data Lake na Plataforma

Os serviços de domínio são responsáveis pelos dados transacionais em tempo real. O Data Lake e o módulo de Analytics são responsáveis por transformar esses dados em informação gerencial e analítica:

Serviços de domínio produzem eventos
    │
RabbitMQ (plano assíncrono)
    │
Data Ingestion Consumer
    │
Data Lake por tenant
  ├── Landing Zone     → dados brutos como chegaram
  ├── Raw Zone         → preservados e imutáveis
  ├── Standardized Zone → conformados e validados
  ├── Curated Zone     → modelados e prontos para uso analítico
  └── Serving Zone     → otimizados para dashboards, relatórios e IA
    │
┌────────────────────────────────────────────┐
│  CONSUMIDORES DO DATA LAKE                  │
│  Dashboards │ Relatórios │ Exploração       │
│  IA / RAG   │ Campanhas  │ Qualidade        │
│  Data Lake MG (quando autorizado)          │
└────────────────────────────────────────────┘

O princípio fundamental é a separação entre o plano operacional (bancos dos serviços) e o plano analítico (Data Lake). Serviços de domínio nunca consultam o Data Lake em tempo real para decisões transacionais.

23.3 Princípios

1. Separação OLTP / OLAP — bancos operacionais servem transações; o Data Lake serve análise; nenhum dos dois acumula responsabilidades do outro;
2. Event-First — a ingestão primária é por eventos de domínio publicados no RabbitMQ; ingestão em lote complementa quando necessário;
3. Isolamento por tenant — partições, controles de acesso e Data Products são completamente segregados por tenant;
4. Imutabilidade das zonas brutas — dados nas zonas Landing e Raw não são alterados após ingestão; correções produzem novas versões na camada downstream;
5. Qualidade mensurável — cada Data Product tem regras de qualidade, dimensões avaliadas e Quality SLO definido;
6. Contrato sobre dados — mudanças de schema seguem política de compatibilidade; consumidores são identificados antes de breaking changes;
7. Linhagem obrigatória — cada dado tem rastreabilidade da origem ao consumidor;
8. Least privilege analítico — analistas acessam apenas Data Products autorizados para seu perfil e tenant;
9. Dados pessoais minimizados — PII é pseudonimizado ou anonimizado quando o uso analítico não exige identificação direta;
10. IA por datasets autorizados — a plataforma de IA consome apenas datasets explicitamente aprovados; não há acesso irrestrito ao Data Lake.

23.4 Arquitetura do Data Lake

23.4.1 Estrutura de Zonas

O Data Lake organiza os dados em zonas de maturidade progressiva:

┌──────────────────────────────────────────────────────────────┐
│  LANDING ZONE                                                 │
│  Recepção bruta de eventos e arquivos; sem transformação      │
├──────────────────────────────────────────────────────────────┤
│  RAW ZONE                                                     │
│  Dados preservados e imutáveis conforme chegaram; event-time  │
├──────────────────────────────────────────────────────────────┤
│  STANDARDIZED ZONE                                            │
│  Dados conformados: schema validado, tipos normalizados,      │
│  enriquecimento básico, event-time preservado                 │
├──────────────────────────────────────────────────────────────┤
│  CURATED ZONE                                                 │
│  Dados modelados para uso analítico: fatos, dimensões,        │
│  agregações, Data Products publicados                         │
├──────────────────────────────────────────────────────────────┤
│  SERVING ZONE                                                 │
│  Datasets otimizados para consumo: dashboards, relatórios,    │
│  APIs analíticas, exports, BI e IA                           │
└──────────────────────────────────────────────────────────────┘

23.4.2 Isolamento por Tenant

Cada tenant tem partição própria em todas as zonas. A segregação é estrutural:

data-lake/
  tenant-abc/
    landing/
    raw/
    standardized/
    curated/
    serving/
  tenant-def/
    landing/
    ...

Políticas de acesso garantem que uma query de um analista do tenant A nunca retorna dados do tenant B. Row-Level Security e Column-Level Security reforçam o isolamento na camada de serving quando a tecnologia suporta.

23.4.3 Formatos e Particionamento

Os formatos de armazenamento são selecionados por zona e por volume:

• Landing / Raw — formato de evento (JSON, Parquet) preservando a estrutura original;
• Standardized / Curated — Parquet ou equivalente colunar para performance analítica;
• Serving — formato otimizado para a ferramenta de consumo (tabelas materializadas, views, índices).

O particionamento combina tenant e data (tenant_id, year, month, day) para otimizar leituras analíticas e facilitar retenção seletiva por tenant.

23.5 Ingestão de Dados

23.5.1 Ingestão por Eventos (Principal)

O mecanismo primário é o consumo de eventos RabbitMQ:

Domínio publica evento com tenantId e correlationId
    │
RabbitMQ platform.events
    │
Data Ingestion Consumer
    │
Valida envelope e idempotência (event_id como chave)
    │
Aplica regras de qualidade da Landing Zone
    │
  Pass    → grava na Raw Zone do tenant
  Warning → grava com flag de qualidade
  Critical → grava em Quarantine; alerta
    │
Registra linhagem (evento → dataset Raw)
    │
datalake.ingested.v1 publicado

O consumidor é idempotente: o mesmo evento processado duas vezes produz apenas um registro na Raw Zone.

23.5.2 Ingestão em Lote

Para dados históricos, migrações e integrações sem emissão de eventos, a ingestão em lote complementa:

• leitura de arquivo (CSV, JSON, Parquet) com schema declarado;
• deduplicação por chave de negócio;
• checkpoint para retomada após falha;
• rate limiting para não impactar o processamento de eventos;
• registro de run com status, registros processados e erros.

23.5.3 Change Data Capture (CDC)

CDC é avaliado como mecanismo complementar para capturar mudanças nos bancos operacionais sem necessidade de que cada serviço publique evento para cada atualização. A adoção considera: modelo de dados, tecnologia do banco, impacto operacional e consistência com os contratos de dados existentes.

23.5.4 Idempotência e Deduplicação

A ingestão é idempotente. O campo id do envelope de evento garante deduplicação por evento. Para ingestão em lote, a chave de deduplicação é definida por dataset. Processar o mesmo dado duas vezes produz o mesmo resultado — sem duplicação de registros na Raw Zone.

23.6 Data Contracts e Schema Registry

23.6.1 Data Contracts

Todo evento ingerido no Data Lake tem contrato formal documentando: schema, campos obrigatórios, tipos, significado semântico de cada campo, produtor, frequência esperada, política de compatibilidade e histórico de versões.

DataContract
  contractId
  assetId          (dataset ou stream de origem)
  version
  owner
  status           (DRAFT, APPROVED, ACTIVE, DEPRECATED)
  compatibilityPolicy  (BACKWARD, FORWARD, FULL, BREAKING)
  schema           (referência ao Schema Registry)
  semanticFields[] (definição de significado por campo)
  producerService
  consumerServices[]

23.6.2 Schema Registry

Schemas técnicos são versionados no Schema Registry. O registro integra o pipeline de CI/CD: uma mudança de schema incompatível detectada automaticamente não passa para o ambiente de integração sem a devida formalização de nova versão.

Políticas de evolução:

23.6.3 Impact Analysis

Antes de aprovar uma breaking change, o processo identifica todos os consumidores do dataset: quais pipelines leem o dado, quais Data Products dependem, quais dashboards consomem, quais capacidades de IA utilizam. A mudança só avança quando todos os consumidores estão preparados ou quando um plano de migração é acordado.

23.7 Qualidade de Dados

23.7.1 Dimensões de Qualidade

23.7.2 Regras de Qualidade

Regras são definidas por dataset e por campo:

Exemplos de regras:
  tenantId não pode ser nulo                  → CRITICAL
  eventId deve ser único na janela de 24h     → ERROR
  occurredAt deve ser timestamp UTC válido    → ERROR
  serviceId deve referenciar serviço ativo    → WARNING
  description pode ser nulo                   → INFO

Regras são versionadas. A versão da regra aplicada é registrada junto com o resultado da avaliação.

23.7.3 Pipeline de Qualidade

Dados ingeridos
    │
Execução das regras de qualidade
    │
    ├── PASS → dados fluem para a próxima zona
    ├── WARNING → dados fluem com flag de qualidade registrado
    ├── ERROR → dados vão para Quarantine; pipeline registra
    └── CRITICAL → dados vão para Quarantine; alerta imediato

23.7.4 Quarantine Zone

Dados que violam regras de qualidade são isolados em Quarantine, preservando o tenantId e o motivo da falha:

QuarantineRecord
  ingestionId
  tenantId
  sourceEvent / sourceBatch
  recordReference
  ruleId
  ruleVersion
  severity
  failureReason
  detectedAt

O processo de operação de Quarantine inclui: visualização de contagens por tenant e por regra, identificação da causa raiz, correção na origem, reprocessamento controlado.

23.7.5 Quality SLO

Cada Data Product define Quality SLOs mensuráveis:

• completude ≥ 99,5% em campos obrigatórios;
• freshness: dados da última hora disponíveis em até 15 minutos;
• unicidade: zero duplicatas por chave de negócio.

Violações de Quality SLO geram alertas e são reportadas no Dashboard de Qualidade de Dados.

23.8 Data Catalog e Linhagem

23.8.1 Data Catalog

O Data Catalog centraliza a descoberta de ativos de dados:

• busca por nome, domínio, owner, classificação e tag;
• metadados técnicos (schema, tipo, formato, localização);
• metadados funcionais (significado, owner, finalidade, exemplos);
• metadados operacionais (freshness, volume, qualidade atual);
• metadados de segurança (classificação, dados pessoais, retenção).

Descobrir um ativo no catálogo não concede acesso aos dados — o catálogo é somente para descoberta; o acesso é controlado por política.

23.8.2 Business Glossary

Termos de negócio possuem definição oficial no Business Glossary:

Solicitação → registro formal de demanda de um cidadão a um órgão
Protocolo   → identificador único de uma solicitação
Atendimento → interação humana com o cidadão no contexto de uma fila
Cidadão     → pessoa física ou representante de pessoa jurídica

Métricas e dashboards referenciam termos do glossário. Isso garante que "Tempo médio de resolução" significa o mesmo em todos os relatórios do tenant.

23.8.3 Data Lineage

A linhagem rastreia a cadeia completa de cada dado:

crm.interaction-created.v1 (CRM Service)
    │
Raw Zone: crm_interactions (landing_2026_07_15)
    │
Standardized Zone: std_interactions
    │
Curated Zone: fact_attendance
    │
Serving Zone: attendance_daily_summary
    │
Dashboard: Painel de Atendimento

A linhagem permite impact analysis: "se eu alterar o evento crm.interaction-created.v1, quais dashboards são afetados?"

23.9 Data Products

23.9.1 Conceito

Um Data Product é um conjunto de dados disponibilizado com: owner definido, finalidade documentada, contrato de dados, métricas de qualidade e ciclo de vida gerenciado.

DataProduct
  id
  tenantId
  name
  domain
  owner
  purpose
  classification
  status            (DRAFT, PUBLISHED, DEPRECATED)
  dataContract      (referência ao contrato)
  qualitySLOs       (lista de SLOs definidos)
  refreshPolicy     (frequência de atualização)
  retentionPolicy   (período de retenção)
  consumers[]       (serviços e capacidades autorizadas)

23.9.2 Exemplos de Data Products por Domínio

23.10 Camada Semântica e Indicadores Oficiais

23.10.1 Semantic Layer

A Semantic Layer padroniza como métricas, dimensões e indicadores são calculados. Elimina a divergência entre relatórios que calculam "Tempo médio de resolução" de formas diferentes:

Dashboards / Relatórios / BI
        │
Semantic Layer (Metric Registry + Semantic Models)
        │
Data Products (Curated / Serving Zone)

Analistas e ferramentas de BI consomem modelos semânticos, não queries ad hoc diretamente sobre dados brutos.

23.10.2 Metric Registry

Métricas oficiais são registradas com: nome, definição técnica, granularidade, filtros aplicados, fonte (Data Product), tenant scope e owner.

Exemplos:

avg_request_resolution_days
  Definição: média de dias entre request.submitted e request.completed
  Fonte: Fact_Requests
  Granularidade: diária, por serviço, por tenant

first_response_rate_sla
  Definição: % de atendimentos com primeira resposta dentro do SLA configurado
  Fonte: Fact_Attendance
  Granularidade: diária, por fila, por tenant

23.10.3 KPI Registry

KPIs são métricas com meta e status de atingimento:

KPIs de referência:
  Taxa de resolução de solicitações dentro do prazo
  Tempo médio de primeira resposta no atendimento
  CSAT médio por serviço
  Taxa de conclusão de solicitações no prazo do serviço
  Volume de manifestações de ouvidoria por categoria

Os KPIs são configuráveis por tenant — cada órgão define suas metas.

23.11 Dashboards e Relatórios

23.11.1 Dashboards Operacionais

O painel do gestor disponibiliza dashboards operacionais com atualização próxima ao tempo real para os indicadores mais relevantes:

23.11.2 Relatórios

Relatórios permitem análises com período, filtros e exportação:

• seleção de período (predefinido ou customizado);
• filtros por serviço, fila, canal, cidadão (quando autorizado);
• visualização tabular e gráfica;
• exportação em formatos padrão (CSV, XLSX, PDF);
• agendamento de envio recorrente;
• compartilhamento conforme perfil autorizado.

23.11.3 Exploração de Dados

Perfis com permissão de exploração acessam Data Products autorizados para combinações livres de dimensões e métricas. As consultas respeitam automaticamente o tenant do usuário — o filtro de tenant é aplicado na camada de serving, não apenas na aplicação.

23.11.4 Near Real-Time Analytics

Indicadores operacionais críticos (fila de atendimento, SLA em risco, tamanho de filas RabbitMQ) são atualizados com latência de minutos, não de horas. Esses indicadores consomem eventos do RabbitMQ diretamente ou via streaming de eventos para a Serving Zone, sem esperar o ciclo batch.

23.12 Qualidade de Dados para o Gestor

23.12.1 Dashboard de Qualidade

O gestor do tenant acessa indicadores de qualidade dos dados do seu órgão:

• score de qualidade por domínio e por dimensão;
• evolução temporal das violações;
• registros em Quarantine por regra;
• freshness dos Data Products utilizados nos dashboards;
• comparativo de qualidade entre períodos.

23.12.2 Ciclo de Melhoria

Alerta de violação de qualidade
    │
Data Steward identifica causa raiz
    │
Correção na origem (serviço de domínio ou pipeline)
    │
Reprocessamento controlado dos dados afetados
    │
Validação do Quality SLO restaurado

23.13 Integração com Inteligência Artificial

23.13.1 Datasets de Conhecimento

Datasets curados e autorizados alimentam o Knowledge Builder para enriquecer as bases de conhecimento RAG dos tenants:

Data Lake Curated Zone
    │
Dataset Policy → aprovado para uso em IA
    │
Knowledge Builder
    │
Base de conhecimento do tenant (vector store)
    │
Assistente / Copiloto

Não existe acesso irrestrito da plataforma de IA ao Data Lake — apenas datasets com aiIndexingPolicy = ENABLED são processados.

23.13.2 Datasets de Avaliação

O Evaluation Framework da plataforma de IA utiliza datasets de avaliação derivados do Data Lake:

• golden datasets com casos de referência versionados;
• datasets de feedback coletados durante as sessões do assistente;
• datasets de avaliação para métricas de groundedness e retrieval.

23.13.3 Analytics de IA

Métricas de consumo e qualidade da IA são consolidadas no Data Lake por tenant:

• tokens consumidos por capacidade, modelo e provedor;
• latência de resposta por capacidade;
• taxa de transferência assistente → humano;
• score de feedback por capacidade;
• freshness das bases de conhecimento.

23.14 Integração com Data Lake MG

Quando formalmente estabelecida, a integração com o Data Lake MG compartilha datasets autorizados com o repositório estadual:

• apenas datasets com aprovação explícita são compartilhados;
• dados pessoais são minimizados antes do compartilhamento (pseudonimização ou anonimização);
• a frequência e o formato de compartilhamento são definidos em instrumentos próprios da parceria;
• a linhagem registra quais datasets foram compartilhados, quando e com quem.

23.15 Segurança e LGPD no Analytics

23.15.1 Controles de Acesso

• least privilege: analistas acessam apenas Data Products autorizados para seu perfil;
• Row-Level Security na Serving Zone filtra automaticamente por tenant;
• Column-Level Security mascara campos sensíveis para perfis sem autorização;
• exportações são controladas por perfil e geram registro de auditoria.

23.15.2 Dados Pessoais em Analytics

• PII em datasets analíticos é minimizado: identificadores técnicos substituem CPF, nome e e-mail quando o uso analítico não requer identificação direta;
• pseudonimização controlada permite reconciliação quando necessário para atendimento de direitos de titulares;
• anonimização é aplicada quando a finalidade analítica não requer reidentificação;
• datasets com dados pessoais têm finalidade documentada, retenção definida e acesso restrito;
• ambientes de desenvolvimento e teste utilizam dados sintéticos ou mascarados — dados reais de produção não são copiados indiscriminadamente.

23.15.3 Exportações

Exportações de dados analíticos são controladas:

• usuário autorizado solicita exportação com justificativa registrada;
• arquivo exportado tem ciclo de vida: link temporário com expiração;
• exportações de dados com PII têm aprovação adicional quando o perfil exige;
• histórico de exportações é auditável.

23.16 Data Observabilidade

23.16.1 Dimensões Monitoradas

23.16.2 Alertas de Dados

Alertas prioritários para operação:

• dataset com freshness acima do SLO (dados desatualizados para dashboards do gestor);
• volume zerado inesperadamente (indica falha de ingestão);
• schema drift detectado sem nova versão de contrato aprovada;
• violação de Quality SLO;
• Quarantine acumulando registros de um tenant;
• custo de query acima do threshold.

23.17 Rastreabilidade com o Anexo III

23.18 Benefícios do Módulo

• separação clara entre operacional e analítico elimina interferência entre cargas;
• ingestão event-driven garante dados analíticos próximos ao tempo real para eventos de negócio;
• Data Contracts e Schema Registry previnem breaking changes silenciosas;
• Data Products com quality SLOs tornam a qualidade mensurável e gerenciável;
• linhagem permite impact analysis antes de mudanças e rastreamento em auditorias;
• Semantic Layer elimina divergência de indicadores entre relatórios;
• integração com IA por datasets autorizados garante que o modelo usa conteúdo governado;
• isolamento multi-tenant em todas as camadas previne acesso cruzado entre órgãos;
• qualidade de dados visível ao gestor fecha o ciclo de melhoria contínua.

23.19 Riscos e Mitigações

23.20 Decisões Arquiteturais

23.21 Considerações Finais

O Analytics e Data Lake transforma a plataforma de uma solução de atendimento em um sistema de gestão orientado a dados. Gestores tomam decisões com base em indicadores atualizados, rastreáveis e com qualidade monitorada. Analistas exploram dados com confiança, sabendo que estão usando Data Products governados. A IA opera sobre datasets autorizados, sem acesso irrestrito ao histórico operacional.

A combinação de ingestão event-driven, zonas de maturidade progressiva, contratos de dados, qualidade mensurável e Semantic Layer cria a base que permite escalar a plataforma — em número de tenants, em volume de dados e em sofisticação analítica — sem perder governança.

O Capítulo 24 detalha o módulo de Ouvidoria e Manifestações.

23.22 Controle de Versão

23.23 Rastreabilidade PRODEMGE

• [ANX-III] Bloco 4 — Dados, Analytics e Inteligência: cobertura completa dos itens 4.1 a 4.6 conforme seção 23.17.
• [ANX-IV] — Capacidades técnicas de Data Lake multi-tenant, qualidade de dados, analytics, BI, integração com IA e governança analítica.
• [ANX-V] — Sustentabilidade: event-first, Data Contracts, schema versionado, linhagem, Data Products com ciclo de vida, quality SLOs.
• [PNR] — Plano de Negócio Referencial: plataforma com Data Lake, dashboards operacionais, exploração analítica, qualidade de dados e integração com IA.
• [EDITAL] — Edital CP001/2026: plataforma com capacidade analítica integrada, segregação por tenant e governança de dados.