> ## Documentation Index > Fetch the complete documentation index at: https://strattumai.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Data Pipelines > A camada de ingestão que traz dados de qualquer fonte para dentro da infraestrutura do cliente, limpos e prontos para consumo. O **Data Pipelines** é a camada que ingere, conecta e transforma dados de fontes externas para dentro da infraestrutura do cliente. Cada conector traz os dados de um sistema — CRM, ERP, helpdesk, banco de dados — e os deixa limpos, estruturados e registrados no Data Catalog. Esta página explica o que é o Data Pipelines e como ele funciona. Para conectar sua primeira fonte passo a passo, vá para o [Quickstart](/data-pipelines/quickstart). *** ## Por que o Data Pipelines existe Sem pipelines confiáveis, não existe contexto. Memory, Knowledge e todos os produtos da camada de AI dependem de dados que cheguem limpos e atualizados. Antes do Data Pipelines, um time de dados gasta horas toda semana em ETL manual: extrair de cada sistema, normalizar formatos, reconciliar chaves, agendar cargas. O trabalho é repetitivo, quebra quando um schema muda e não deixa rastro de linhagem. O Data Pipelines remove esse trabalho. Você configura um conector uma vez e a ingestão passa a rodar de forma agendada, com o estado de cada carga visível e auditável. *** ## Como funciona O fluxo de ingestão tem três componentes. Cada um resolve uma parte do caminho entre a fonte e o dado pronto para consumo. ### Conectores (dlt) Cada fonte tem um conector que extrai os dados via API, CDC ou polling e os grava na camada `raw/` do Data Catalog, exatamente como chegaram. Os conectores são construídos sobre [dlt](https://dlthub.com), que cuida de paginação, incrementalidade e evolução de schema. A camada `raw/` é imutável. Serve como fonte de verdade para auditoria e para reprocessar o histórico quando uma regra de transformação muda. ### Orquestração (Prefect) O [Prefect](https://www.prefect.io) agenda e executa os flows de cada pipeline. Ele controla quando cada conector roda, captura falhas, faz retry e registra o resultado de cada execução. Cada flow de ingestão dispara, ao terminar, a transformação da camada `clean/` correspondente. O resultado é uma cadeia previsível: fonte muda, `raw/` recebe, `clean/` normaliza. ### Transformação (clean/) Os dados de `raw/` são normalizados na camada `clean/`: emails em minúsculo, telefones no padrão +55, chaves como CPF e CNPJ padronizadas, deduplicação. É essa camada que alimenta Memory (grafos), Knowledge (vetores) e consultas SQL. A transformação é incremental por padrão. Só o que mudou desde a última carga é reprocessado. *** ## O que cada camada entrega O Data Pipelines organiza os dados em camadas dentro do Data Catalog. Cada uma tem um papel definido. | Camada | O que contém | Quando usar | | ----------- | ---------------------------------------------------------- | ----------------------------------------------- | | `raw/` | Dados imutáveis, exatamente como vieram da fonte | Auditoria e reprocessamento histórico | | `clean/` | Dados normalizados, deduplicados e com chaves padronizadas | Contexto para Memory, Knowledge e consultas SQL | | `semantic/` | Data marts pré-agregados via dbt (opcional) | Métricas calculadas com performance | *** ## Capacidades de ingestão O que o Data Pipelines faz além de mover dados de A para B: | Capacidade | O que faz | | ------------------------ | ---------------------------------------------------------------------------------------------- | | **Modos de carga** | Incremental por padrão; CDC onde a fonte permite; event-driven via webhook; agendado via cron. | | **Schema evolution** | Mudança de schema na fonte é absorvida pelo conector (dlt) sem quebrar a carga. | | **Backfill controlado** | Reprocessa histórico de forma paginada, sem derrubar a ingestão corrente. | | **Retry com backoff** | Falha de fonte é reexecutada pelo Prefect com backoff exponencial e registrada. | | **Quality checks** | Checagens declarativas barram dado inconsistente antes de ele chegar à camada `clean/`. | | **Credenciais isoladas** | Segredos ficam em vault e não aparecem nos logs de execução. | | **Conector customizado** | Fontes sem conector nativo são entregues pela equipe FDE. | *** ## Catálogo de conectores O primeiro conector de cada categoria já está disponível; os demais entram conforme a demanda dos clientes. | Conector | Categoria | Status | | -------------------------------------------- | --------- | ---------- | | PostgreSQL | Databases | Disponível | | Zendesk | Helpdesk | Disponível | | MySQL, SQL Server, Snowflake, BigQuery | Databases | Em breve | | HubSpot, Salesforce, RD Station, Pipedrive | CRM | Em breve | | Google Drive, SharePoint, Confluence, Notion | Documents | Em breve | | SAP, TOTVS, Sankhya, Omie | ERP | Em breve | A lista completa de conectores e o status de cada um estão no [catálogo de conectores](/data-pipelines/connectors). *** ## Como se conecta aos outros produtos O Data Pipelines é o pré-requisito da plataforma. Cada dataset ingerido vira insumo para as camadas seguintes. | Produto | Como o Data Pipelines se conecta | | ----------------- | ------------------------------------------------------------------------------------------ | | **Data Catalog** | Cada dataset ingerido é registrado automaticamente com linhagem e ownership | | **Memory** | Dados de CRM, ERP, helpdesk e canais são ingeridos antes de virarem contexto de entidade | | **Knowledge** | Documentos chegam via conectores de Documents (Drive, SharePoint, Confluence, Notion) | | **Evals** | Metadados de ingestão (completude, frescor) alimentam a avaliação de qualidade do contexto | | **Observability** | Monitora a saúde dos pipelines em produção — fontes lentas, dados faltando, falhas de sync | *** ## Casos de uso Uma fintech conecta o sistema de originação (PostgreSQL), o CRM e a plataforma de cobrança. O Data Pipelines ingere as três fontes, normaliza as chaves em `clean/` e registra cada dataset no Catalog. A partir daí, o Memory monta o perfil unificado do tomador sem que o analista consulte três sistemas. O time de produto ingere dados de uso do produto, tickets e NPS. Com as fontes em `clean/`, um data mart em `semantic/` consolida um health score por conta, consultável via SQL. O conector Zendesk opera em modo event-driven: recebe o webhook do ticket, persiste em `raw/` e dispara a transformação `clean/`. O ciclo completo, do evento ao dado disponível, roda em 1–3 minutos. *** ## Próximos passos Conecte sua primeira fonte e ative uma pipeline em menos de 10 minutos. Entenda como os dados ingeridos são organizados, governados e descobertos. Veja as opções de frequência de sincronização por conector. Transforme os dados ingeridos em contexto estruturado sobre cada entidade.