Skip to main content
O Data Catalog é o repositório de dados armazenado diretamente na infraestrutura cloud do próprio cliente — AWS S3, Google Cloud Storage ou Azure Blob Storage. Ele documenta, classifica e estabelece ownership sobre todos os datasets ingeridos pelos Data Pipelines.
Camadas do Data Catalog: dados brutos normalizados e agregados no data lake

Os dados chegam brutos, são normalizados na camada clean e agregados na camada semantic — todas vivendo no mesmo lake, na cloud do cliente.

Não é apenas um índice de metadados — é um data lake real, projetado para times de 1 a 5 pessoas. Os dados nunca saem do ambiente do cliente: sem vendor lock-in, sem dados em terceiros.

Por que isso importa

O diferencial crítico do Data Catalog é que os dados ficam on-premise na infra cloud do cliente. Isso é determinante para fintechs, healthtechs e cooperativas de crédito com exigências regulatórias de localização de dados (LGPD, Bacen). Comparado a alternativas como Databricks:
  • Não exige clusters gerenciados por terceiros
  • O query engine (DuckDB) roda embutido — sem custo de compute separado
  • Operável por times de 1–5 pessoas sem especialista em Spark

Conectar um data lake existente ou construir do zero

A Strattum se adapta à maturidade de dados da empresa. Há dois pontos de partida: Nos dois casos o dado permanece no ambiente do cliente e o catálogo — descrição, ownership, linhagem e políticas de acesso — é o mesmo.

Estrutura de camadas (Medallion)

O Catalog organiza os dados em três camadas lógicas:

raw/

Dados imutáveis, exatamente como chegaram da fonte. Sem transformação. Serve para auditoria e reprocessamento histórico. Nunca é modificado após a carga inicial.

clean/

Dados normalizados, deduplicados e com chaves padronizadas (CPF, CNPJ, email). É o tronco principal que alimenta Memory (grafos), Knowledge (vetores) e as Skills (queries SQL).

semantic/

Data marts pré-agregados via dbt (opcional). Consultas analíticas pré-construídas consumidas pelas Skills — ex: fct_receita_por_cliente, fct_health_score. Use quando precisar de métricas calculadas com performance.

Quando usar cada camada


Tecnologias de armazenamento e consulta

O uso do DuckDB é o diferencial técnico crítico: performance analítica com zero complexidade de infraestrutura, sem precisar de Spark, Databricks ou qualquer cluster externo.
Acesse Data Catalog no menu lateral para ver todos os datasets disponíveis:
1

Visão geral dos datasets

A tela inicial lista todos os datasets por categoria (CRM, ERP, Helpdesk, etc.) com status de saúde, timestamp do último sync e owner.
2

Inspecionar um dataset

Clique em qualquer dataset para ver:
  • Schema completo (colunas, tipos, exemplos de valores)
  • Linhagem: de qual conector veio e quais transformações foram aplicadas
  • Histórico de sincronizações
  • Políticas de acesso configuradas
3

Explorar a camada clean

Clique na aba Clean para ver os dados normalizados prontos para consumo. Você pode executar queries SQL diretamente via DuckDB no Console.
4

Verificar linhagem

O gráfico de linhagem mostra o caminho completo do dado: fonte original → pipeline de ingestão → transformação dbt → dataset final.

Governança e metadados

Cada dataset registrado no Catalog é um ativo de dados governado:

Campos PII e controle de acesso

Campos com dados pessoais (CPF, email, telefone) podem ser configurados para serem visíveis apenas para papéis autorizados. Analistas sem permissão veem os valores mascarados automaticamente.

Transformations (dbt)

As Transformations permitem criar a camada semantic/ com data marts pré-calculados. São definidas em SQL via dbt e versionadas no Workspace Git.
Para configurar uma Transformation, é necessário ter pelo menos um conector ativo. Acesse Data Catalog → Transformations para criar e gerenciar transformações.
Casos de uso típicos:
  • fct_health_score — score de saúde por conta calculado de uso + tickets + NPS
  • fct_inadimplencia — status de inadimplência por tomador
  • dim_clientes_clean — clientes normalizados com chaves padronizadas

Integrações com outros produtos


Exemplos de uso

Uma fintech conecta seu sistema de originação (PostgreSQL), CRM (HubSpot) e plataforma de cobrança via Data Pipelines. O Catalog organiza tudo em clean/dim_clientes, clean/fct_contratos e clean/fct_pagamentos. O Memory Worker lê essas tabelas para montar o perfil unificado do tomador — sem que o analista precise consultar três sistemas diferentes.
O time de produto cria um data mart semantic/fct_health_score via dbt, consolidando dados de uso do produto, tickets e NPS por conta. Uma Skill consulta esse mart via SQL para investigar quais contas estão com score degradado e cruzar com o histórico de interações da Memory.
Uma cooperativa precisa demonstrar para auditoria que dados de associados são acessados apenas por serviços autorizados. O Catalog registra cada consulta (audit trail), aplica políticas de row-level security e garante que campos PII são filtrados automaticamente para papéis sem permissão.