APIs de origem
mercado + chain
- alimenta
- Kafkaingestão
Todos os casos técnicos
Pipelines de dadosMétricasBI3 meses
USDDub
Os dashboards estavam seis horas atrasados em relação à realidade. Agora estão cinco minutos.
Atualidade dos dados
5 minutos
Streaming com etapas reexecutáveis
Antes
6 horas
Extrações batch agendadas
Em termos simples
O que é isto.
Sem jargão nesta secção. A descrição técnica está mais abaixo.
O que estava a correr mal
Os dados chegavam mais depressa do que os jobs noturnos os conseguiam processar, por isso quem abria um dashboard via, na melhor das hipóteses, o estado dessa manhã. Quando algo precisava de ser reprocessado, um engenheiro fazia-o à mão — muitas vezes ao fim de semana.
O que construímos
Substituímos os jobs noturnos agendados por um fluxo contínuo que pode ser reexecutado a partir de qualquer ponto, e pusemos cada número por trás de uma definição partilhada.
O que mudou
As decisões são tomadas com dados de há minutos e não de há horas, o reprocessamento já não custa um fim de semana a ninguém, e todas as equipas leem os mesmos números.
Arquitetura
Como tudo se encaixa.
Percorra as etapas. Tudo o que está marcado como acrescentado é um componente que não existia antes deste projeto.
Kafka
particionado
- recebe de
- APIs de origemingestão
- alimenta
- ClickHouse
ClickHouse
colunar
- recebe de
- Kafka
- alimenta
- Modelos dbttransformar
Modelos dbt
incremental
- recebe de
- ClickHousetransformar
- alimenta
- Camada de BI
Camada de BI
governadas
- recebe de
- Modelos dbt
APIs de origem
mercado + chain
- alimenta
- Kafkaingestão
Kafka
particionado
Acrescentámos isto- recebe de
- APIs de origemingestão
- alimenta
- ClickHouse
ClickHouse
colunar
Acrescentámos isto- recebe de
- Kafka
- alimenta
- Modelos dbttransformar
Modelos dbt
incremental
Acrescentámos isto- recebe de
- ClickHousetransformar
- alimenta
- Camada de BI
Camada de BI
governadas
- recebe de
- Modelos dbt
A descrição
Como seria construído.
Conjunto de dados, abordagem, métricas-alvo e a stack. Escrito para quem tiver de o rever.
Pipelines de dadosMétricasBI3 meses
USDDub
Dados de mercado canónicos e sinais que se mantêm consistentes entre fontes e ao longo do tempo.
Problema
Os dados de mercado e de eventos chegavam mais depressa do que os jobs batch existentes os conseguiam processar, por isso os dashboards estavam horas desatualizados e os backfills exigiam reexecuções manuais.
Conjunto de dados
- linhas
- 14 M de eventos / dia
- features
- 203
- fontes
- APIs de mercado, on-chain, serviços internos
- janela
- 90 dias móveis
Abordagem
- 01Substituímos as extrações batch por uma camada de ingestão em streaming
- 02Modelámos um warehouse colunar ajustado aos padrões de consulta reais
- 03Tornámos cada etapa idempotente, para que um backfill seja uma reexecução e não uma operação de salvamento
- 04Publicámos um conjunto de métricas governado por trás de uma camada de BI
Métricas
- 14 M+
- eventos / dia de forma sustentada
- 5 min
- atualidade dos dados eram 6 horas
- 410 ms
- p95 de consulta -8,4 s
- automatizado
- esforço de backfill era manual
Evidência
- fonte
- Design de referência
- números
- Ilustrativo — valores típicos para este design
- medição
- Não medido. Valores típicos para um design de referência deste tipo, não observados num sistema de cliente.
- referência
- Não disponível para este projeto
- última revisão
- 2026-08-25
Impacto no negócio
- Decisões tomadas com dados de há minutos em vez de há horas
- Os backfills deixaram de consumir fins de semana da engenharia
- Uma camada de métricas partilhada por todos os consumidores internos
Stack tecnológica
- Python
- TimescaleDB
- Kafka
- Prefect
- Grafana
- dbt
- Web3.py
Seguinte
Precisa de um sistema como este?
Responda a seis perguntas e dizemos-lhe se esta forma se adequa ao seu problema — incluindo quando não se adequa.