Diagrama de arquitetura de pipeline de dados: CDC, streaming e um armazém de dados

Pipelines de dados falham em silêncio. Um painel mostra os números de ontem, uma coluna muda de tipo na origem e um job descarta linhas sem nenhum erro, ou um slot de replicação de que ninguém se lembra retém o log de escrita antecipada no banco de produção até o disco encher. Cada um desses casos é uma etapa ou um contrato que nunca foi desenhado.

Um diagrama de arquitetura de pipeline de dados mostra de onde vêm os dados, como eles se movem, onde ficam armazenados em cada etapa, quem os transforma e quando, e como qualquer pessoa sabe que estão atualizados e corretos. Este artigo monta um para uma configuração comum, a captura de dados de mudanças (CDC) do PostgreSQL pelo Kafka até um lake e um armazém de dados, e mostra o que rotular em cada etapa.

Extrações em lote, CDC ou eventos

Há três formas comuns de tirar dados de um banco operacional:

A captura de dados de mudanças (CDC) baseada em log é popular para análise porque não exige mudanças na aplicação, enxerga exclusões e adiciona pouca carga de consultas. Seus custos são operacionais, e eles pertencem ao diagrama.

Como o CDC baseado em log funciona com PostgreSQL

O PostgreSQL expõe as mudanças por meio da decodificação lógica, que transforma o log de escrita antecipada (WAL) em um fluxo de mudanças de linhas. Para isso, ele precisa de wal_level = logical, um plugin de saída e um slot de replicação. O conector PostgreSQL do Debezium usa o plugin padrão pgoutput, que vem com o PostgreSQL 10 e versões posteriores. Na primeira inicialização, ele tira um snapshot consistente das tabelas e depois transmite cada insert, update e delete confirmado, por padrão para um tópico do Kafka por tabela, chamado topicPrefix.schemaName.tableName.

O slot de replicação é a parte que morde. A documentação do PostgreSQL explica que um slot impede a remoção do WAL de que seu consumidor ainda precisa, mesmo quando nada está conectado. Se o conector parar durante um fim de semana, o WAL continua crescendo no primário. A configuração max_slot_wal_keep_size limita quanto WAL os slots podem reter; o valor padrão, -1, significa sem limite. Um limite protege o banco ao custo de invalidar o slot, o que significa um novo snapshot. De qualquer forma, monitore o atraso do slot e desenhe o slot no diagrama.

Camadas do lake e o armazém

Quando as mudanças estão no Kafka, um sink as grava no armazenamento e as transformações as tornam úteis. A Databricks popularizou a arquitetura medalhão para nomear as etapas:

• Bronze guarda os dados brutos como chegaram, com metadados de carga, para que você possa reprocessar sem ler a origem de novo.
• Silver guarda registros limpos, sem duplicatas e padronizados: uma linha atual por pedido, tipos e chaves consistentes.
• Gold guarda tabelas de negócio e agregados que os painéis e os modelos leem.

Onde cada camada fica é uma decisão de design: armazenamento de objetos com um formato de tabela aberto como o Apache Iceberg, ou o próprio armazém de dados. Desenhe onde ela fica de verdade, porque isso decide custo, controle de acesso e quem pode consultá-la.

Orquestração e contratos

As transformações de bronze para gold rodam em um agendamento ou quando chegam dados novos, gerenciadas por um orquestrador como Airflow ou Dagster, muitas vezes com modelos SQL no dbt. Duas coisas fazem a diferença entre um pipeline e um passivo:

• Contratos. Os esquemas dos eventos de mudança ficam em um registro de esquemas com regras de compatibilidade, para que uma mudança incompatível na tabela de origem falhe de forma ruidosa no produtor, e não em silêncio num relatório.
• Verificações. Verificações de atualização, contagem de linhas, unicidade e nulos rodam depois de cada etapa, e uma falha aciona o responsável antes que o painel fique errado.

O exemplo: uma loja online

O banco PostgreSQL da loja guarda pedidos, pagamentos e clientes. O Debezium roda no Kafka Connect, lê o WAL por um slot de replicação e publica shop.public.orders, shop.public.payments e shop.public.customers. Um conector sink anexa os eventos de mudança a tabelas bronze. A cada 15 minutos, o orquestrador roda modelos dbt que constroem silver e gold e, em seguida, as verificações de dados. Os painéis leem gold.

Como ler:

• Linha de cima, a captura. As mudanças saem do PostgreSQL pelo slot de replicação, viram eventos de mudança no Debezium, que registra os esquemas, e seguem por um tópico do Kafka por tabela até o conector sink.
• Linha de baixo, o armazenamento, da direita para a esquerda. O sink anexa as mudanças brutas ao bronze. As transformações as consolidam em silver e agregam silver em gold, que os painéis consultam.
• Abaixo, o controle. O orquestrador roda as transformações e as verificações; uma verificação com falha dispara um alerta.
• O bloco Markdown lista as regras operacionais para o slot e para mudanças de esquema.

O que rotular

• O slot e seu limite na primeira conexão, e quem é alertado quando ele atrasa.
• Os nomes dos tópicos ou uma regra de nomes, para que um consumidor saiba o que assinar.
• Agendamentos e metas de atualização nas conexões de transformação, como "a cada 15 min, no máximo 30 min de atraso".
• A retenção por camada. O bronze costuma guardar o histórico mais longo; ele é o seu buffer de reprocessamento.
• Os responsáveis por cada camada e por cada verificação.
• Os dados pessoais. Marque onde ficam armazenados e onde são mascarados ou descartados; veja o diagrama de mapeamento de dados para o GDPR.

Erros comuns

• Uma única seta do banco para o armazém. Ela esconde o slot, os esquemas e cada lugar onde os dados podem se perder ou atrasar.
• Consultas analíticas no primário. Extrações em lote contra o primário de produção competem com o tráfego dos clientes; use CDC ou uma réplica, e desenhe qual.
• Nenhum caminho de reprocessamento. Se o bronze não for mantido, um bug em uma transformação obriga a ler a origem de novo.
• Tabelas brutas como interface pública. Consumidores que leem eventos de mudança de tabelas internas quebram quando o esquema muda. Para eventos destinados a outras equipes, publique eventos projetados para isso; o diagrama de arquitetura orientada a eventos cobre esse lado.
• Verificações que só registram em log. Um teste que falha sem alertar ninguém é um comentário.

Para o lado do banco de dados do mesmo sistema, veja o diagrama de replicação de banco de dados e o exemplo de diagrama ER.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Do pack Dados, adicione um nó Postgres para o banco de origem e um nó Kafka para os tópicos.
3. Adicione nós Contêiner do pack Modelo C4 para o Debezium, o registro de esquemas, o conector sink e os painéis.
4. Adicione uma Moldura do pack Básico chamada Lake and warehouse, com dois nós Repositório de objetos do pack Dados para bronze e silver e um Armazém de dados para gold.
5. Do pack DevOps, adicione um Pipeline de CI/CD para o orquestrador e um Alerta para as verificações de dados. Deixe tracejadas as conexões de controle.
6. Adicione um bloco Markdown do pack Básico com as regras do slot e dos esquemas.

O exemplo usa 13 nós de diagrama e fica dentro do plano Free. Se você mantém o esquema de origem em SQL, a ferramenta PostgreSQL para diagrama ER desenha as tabelas por trás dos tópicos.

Perguntas frequentes

CDC é melhor que extrações em lote? Em atualização, exclusões e carga na origem, geralmente sim. O lote é mais simples de operar e serve quando horas de atraso são aceitáveis e as linhas nunca são excluídas fisicamente.

Preciso de Kafka para fazer CDC? O Debezium costuma rodar no Kafka Connect, e o Kafka oferece reprocessamento e muitos consumidores. Existem outras configurações; desenhe o transporte que você realmente opera e a retenção dele.

Como lidar com mudanças de esquema? Registre os esquemas com regras de compatibilidade, adicione colunas em vez de alterá-las e faça os modelos seguintes tolerarem colunas novas. Desenhe o registro, porque é lá que o contrato vive.

Onde as verificações de qualidade de dados devem rodar? Depois de cada camada, como parte da execução orquestrada, com alertas para o responsável. Verificações de atualização no gold pegam a maioria das falhas silenciosas.

Como manter o diagrama do pipeline atualizado? Altere-o no mesmo pull request que a configuração do conector e do orquestrador; veja diagramas de arquitetura que não ficam desatualizados.

Comece grátis — um assento, sem cartão de crédito.