Pipeline de dados não é detalhe técnico: é base da decisão

TL;DR — Pipeline de dados não é encanamento, é infraestrutura de decisão. Quando ele falha, o que falha não é "o dado": é a decisão que dependia dele, multiplicada por todos os processos a jusante. A literatura técnica é farta sobre o tema —Designing Data-Intensive Applications (Kleppmann, 2017), Fundamentals of Data Engineering (Reis & Housley, 2022), Functional Data Engineering (Beauchemin, 2018), Lakehouse Paper (Armbrust et al., CIDR 2021), Data Mesh Principles (Dehghani, 2020), Questioning the Lambda Architecture (Kreps, 2014), Data Contracts (Sanderson, 2022+). E há os casos —Knight Capital perdeu US$ 440 milhões em 45 minutos por uma falha de deploy. Pipeline frágil é caro. Este artigo mostra por quê e como construir pipeline em que se confia.

1. A provocação

Pipeline de dados ainda é tratado, em muitas empresas, como detalhe técnico. O CEO entra no comitê, olha o dashboard, e raramente pergunta:

• De qual sistema esse número saiu?
• Quando foi atualizado pela última vez?
• Quem é o owner do pipeline?
• Existe SLA?
• O que acontece se a fonte cair às 3h da manhã?

Ele pergunta o número — e age sobre ele. O problema é que o número que ele vê é só o último elo de uma cadeia de pré-condições. Quebra qualquer elo e o número perde sentido. Pior: continua bonito, plausível e operacionalmente errado.

A tese deste artigo:

Pipeline de dados é a infraestrutura de decisão da empresa. Tratá-lo como detalhe técnico é tratar a fundação do prédio como detalhe arquitetônico.

A defesa técnica vem a seguir.

2. O que é, formalmente, um pipeline de dados

Joe Reis e Matt Housley, em Fundamentals of Data Engineering (O'Reilly, 2022) — hoje o livro-texto mais adotado do setor — definem o ciclo de vida da engenharia de dados em cinco estágios + correntes transversais:

Atravessando tudo, correntes transversais: segurança, gestão de dados (governança, modelagem, lineage, qualidade), DataOps (CI/CD, monitoramento), arquitetura, orquestração, engenharia de software.

Cada estágio pode falhar de forma silenciosa. Cada corrente transversal pode ser inexistente. E uma corrente fraca em uma empresa faz toda a casa balançar quando o vento bate.

A primeira mudança de mentalidade: pipeline não é "o ETL". Pipeline é o ciclo completo, com correntes transversais, vivendo e respirando o tempo todo.

3. Maxime Beauchemin — pipeline como engenharia funcional

Maxime Beauchemin, criador do Apache Airflow no Airbnb, é uma das vozes mais influentes da última década. Em 2017 ele publicou The Rise of the Data Engineer, definindo a profissão como "superset de BI e data warehousing trazendo mais elementos da engenharia de software".

Em janeiro de 2018, ele tornou explícito o princípio que sustenta um pipeline confiável: Functional Data Engineering — a modern paradigm for batch data processing. A síntese:

"Pure functions, without side-effects, can be written, tested, and debugged in isolation. By applying functional programming principles to data engineering, we bring clarity to ETL: reproducibility, immutability, testability."

Os princípios funcionais aplicados a pipeline são quatro, e quem opera dado os vive todo dia:

1. Idempotência — rodar a mesma transformação duas vezes para a mesma janela devolve o mesmo resultado. Sem isso, retry é roleta.
2. Imutabilidade — partições históricas não mudam. Mudou?Nova partição. Nada de UPDATE em escala.
3. Determinismo — dada a mesma entrada e o mesmo código, a saída é sempre a mesma. Sem efeitos colaterais ocultos.
4. Reprodutibilidade — qualquer resultado pode ser refeito a partir do dado bruto e do código versionado.

Esses quatro princípios são a diferença entre pipeline em que se confia e pipeline que precisa ser "babado". Se sua resposta para um erro em produção é "vou rodar de novo e torcer", você violou os quatro de uma vez.

Conexão: o paper irmão sobre IA mostra que rotulagem reprodutível é base de modelo confiável. O mesmo princípio escala para dado: se o pipeline não é funcional, nenhuma análise lá em cima é auditável.

4. Martin Kleppmann — DDIA: as três propriedades que importam

Martin Kleppmann (University of Cambridge) publicou em 2017 Designing Data-Intensive Applications — o livro técnico mais respeitado da década sobre sistemas distribuídos com foco em dado. A 2ª edição saiu em 2026, coautorada com Chris Riccomini.

A contribuição mais útil para pipeline de dados está no capítulo 1. Kleppmann define três propriedades não-negociáveis de qualquer sistema de dados sério:

4.1 Reliability (Confiabilidade)

"O sistema deve continuar trabalhando corretamente (executando a função certa no nível de performance desejado) mesmo na presença de adversidade (faltas em hardware ou software, ou erro humano)."

Para pipeline isso significa: tolerância a falhas. Job morreu no meio? Sem corrupção de saída. Schema mudou? Detectado, alertado, com fallback. Operador apagou tabela por engano? Restaurável.

4.2 Scalability (Escalabilidade)

"À medida que o sistema cresce (em dado, em tráfego, em complexidade), deve haver caminhos razoáveis para lidar com esse crescimento."

Para pipeline: particionamento, paralelismo, separação compute/storage, escolha consciente entre batch e stream.Throughput planejado em ordem de grandeza, não em chute.

4.3 Maintainability (Manutenibilidade)

"Operabilidade, simplicidade e evolutability — a capacidade do sistema ser operado, entendido e modificado por equipes diferentes ao longo do tempo."

Para pipeline: código legível, dependências documentadas, DAGs auditáveis, observabilidade que conta histórias humanas, não só métricas técnicas.

Conexão: Kleppmann é literal — a maioria dos problemas em produção não é falta de tecnologia, é falta dessas três propriedades sendo tratadas como requisitos, não como "veremos depois".

5. Arquiteturas — a evolução em 4 atos

Nenhuma discussão sobre pipeline sobrevive sem passar pela história das arquiteturas. Em sequência:

Ato 1 — Bill Inmon vs Ralph Kimball (anos 90)

Dois pais fundadores do data warehouse, com filosofias opostas que ainda hoje orientam projetos:

• Inmon (Building the Data Warehouse, 1992) —top-down: warehouse corporativo único, normalizado em 3NF, fonte de verdade.
• Kimball (The Data Warehouse Toolkit, 1996) —bottom-up: data marts dimensionais, schema estrela/floco-de-neve, otimizado para análise.

Inmon enfatiza integridade; Kimball enfatiza usabilidade. Na prática, a maioria dos projetos modernos é hibrida: armazenamento normalizado em camada bronze/silver, modelagem dimensional em camada gold. Nenhum dos dois "perdeu" — ambos compõem.

Ato 2 — Data Lake (anos 2010)

Hadoop, depois S3/ADLS/GCS. Promessa: armazene tudo, decida depois ("schema-on-read"). Realidade frequente: data swamp — sem catálogo, sem owner, sem qualidade. Quem viveu pipeline com 600 tabelas Parquet sem catálogo sabe do que falo.

Ato 3 — Lakehouse (CIDR 2021)

Michael Armbrust, Ali Ghodsi, Reynold Xin e Matei Zaharia (UC Berkeley/Stanford/Databricks) publicaram em 2021 Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics, propondo unificar warehouse e lake em uma camada só. Três pilares:

1. Formato aberto (Parquet/ORC + Delta Lake, Apache Iceberg ou Apache Hudi para transações ACID).
2. Suporte de primeira classe a ML/DS (não só SQL).
3. Performance competitiva com warehouse (benchmarks TPC-DS).

Bem ou mal, Lakehouse virou o desenho dominante de plataforma analítica moderna em cloud. Saber que existe — e por que existe — é parte do trabalho de arquitetar pipeline em 2024–2026.

Ato 4 — Data Mesh (2019–2020)

Zhamak Dehghani (ThoughtWorks) propôs em 2019, e formalizou em 2020, o Data Mesh — uma reação ao gargalo do time central de dados. Quatro princípios:

1. Domain-oriented decentralized ownership — cada domínio de negócio é dono do seu dado analítico, igual a microsserviço.
2. Data as a product — dado tem owner, SLA, contrato, consumer, observabilidade. Tratado como produto, não como subproduto.
3. Self-serve data infrastructure as a platform — plataforma comum permite domínios operarem sem refazer infraestrutura.
4. Federated computational governance — políticas são código, aplicadas em todo o mesh, não comandadas de cima.

Data Mesh não é "moda" — é uma resposta a uma falha real: times centralizados não escalam com a complexidade de negócio. Mas é controverso (volto à divergência adiante).

6. Lambda vs Kappa — batch e streaming em paz

Outra ramificação importante: quando o tempo de decisão exige latência baixa, pipeline puramente batch não basta.

6.1 Arquitetura Lambda (Nathan Marz, 2011)

Dois caminhos em paralelo:

• Batch layer: processa todo o histórico, lentamente, com alta precisão.
• Speed layer: processa em tempo real, com aproximação.
• Serving layer: combina os dois para entregar resposta.

Funciona, mas tem um custo: mantém duas implementações da mesma lógica, em frameworks diferentes (Hadoop + Storm/Spark Streaming).

6.2 Arquitetura Kappa (Jay Kreps, 2014)

Jay Kreps, cocriador do Apache Kafka e fundador da Confluent, publicou em julho de 2014 Questioning the Lambda Architecture. Tese: streaming bem feito é suficiente.

"Por que manter duas pilhas, duas linguagens, dois bugs? Se o backbone for um log distribuído imutável (Kafka), você pode replay do log inteiro e reprocessar como streaming. Uma codebase, um modelo mental."

A Kappa Architecture, com Kafka + Flink (ou Spark Structured Streaming), virou a base de muitas pilhas modernas — Uber, LinkedIn, Netflix.

6.3 Onde estamos hoje

Lambda ainda é defensável quando a empresa tem dois universos de stakeholders (analítico tolerante a latência grande + operacional crítico).Kappa vence em ambientes onde streaming é o padrão. Empresas grandes vivem com modelos híbridos, escolhendo por caso de uso.

Conexão: latência de decisão é um requisito, não um luxo. Pipeline diário é coerente com decisão semanal; pipeline diário para decidir oferta em tempo real é arquitetura errada.

7. Data Contracts — o sistema imune do pipeline

A inovação metodológica mais relevante dos últimos 3 anos no setor é o conceito de data contract, popularizado por Chad Sanderson e adotado em empresas como Convoy, GoCardless e Glassdoor.

A definição operacional:

Um contrato de dado é um acordo programático, versionado e enforced, entre um produtor (serviço/aplicação que gera dado) e um consumidor (pipeline analítico, ML, BI) sobre o schema, semântica, qualidade e SLA do dado.

Os elementos canônicos de um data contract:

1. Schema — colunas, tipos, nulláveis, faixas, formato.
2. Semântica — definição operacional de cada campo (o que é "ativo"? o que é "convertido"?).
3. SLA — frescor, completude, frequência, latência.
4. Owner — quem responde quando quebra.
5. Versionamento — semver, breaking change comunicado.
6. Consumers declarados — quem usa, para quê.

A diferença prática:

• Sem contrato: produtor mexe no schema, pipeline analítico quebra na madrugada, analista descobre na sexta de manhã, comitê de segunda fica sem número.
• Com contrato: PR do produtor é bloqueado por CI/CD se viola contrato; mudança é comunicada com tempo; consumidores migram; nada quebra.

Conexão: Sanderson defende "shift-left" — qualidade detectada o mais próximo possível da fonte. É o mesmo princípio que Andrew Ng aplica a IA e que MIT Sloan aplica a cultura de dados.

8. Observabilidade de dados — a camada que faltava

Pipeline confiável tem observabilidade nativa. Barr Moses (Monte Carlo) popularizou as "Five Pillars of Data Observability" em 2020:

1. Freshness — quando a tabela foi atualizada pela última vez?
2. Distribution — os valores estão dentro do esperado?
3. Volume — está chegando a quantidade certa de linhas?
4. Schema — o schema mudou sem aviso?
5. Lineage — de onde veio cada coluna? quem usa o quê?

Equivalente em pipeline ao que APM (Application Performance Monitoring) é em software. E ainda surpreendentemente raro fora de empresas com cultura de dados madura. Sem isso, descobre-se que o pipeline quebrou pelo consumidor reclamando — frequentemente, em comitê.

9. Casos — quando pipeline frágil custou caro

9.1 Knight Capital — US$ 440 milhões em 45 minutos

Em 1º de agosto de 2012, a Knight Capital Americas perdeu US$ 440 milhões em 45 minutos (NYT/DealBook; SEC Order 2013). O sistema de roteamento automático (SMARS) processou 212 ordens de varejo e disparou mais de 4 milhões de ordens em 154 ações, acumulando posição líquida de US$ 3,5 bilhões antes de ser parado.

A causa-raiz?Pipeline de deploy mal arquitetado.

• Em 2005, um trecho de código foi movido para um ponto mais inicial da sequência, deixando uma rota "morta" no código.
• Em julho de 2012, no deploy para suportar o novo Retail Liquidity Program da NYSE, o novo código foi instalado em 7 dos 8 servidores. No oitavo, o código antigo continuou ativo, mas agora referenciava aquela rota morta.
• Quando ordens chegaram, o oitavo servidor disparou uma cascata de ordens duplicadas. Em 45 minutos, a empresa estava quebrada.

O incidente é o estudo de caso mais citado em SRE/DataOps para três princípios:

1. Deploys precisam ser auditáveis e atômicos — todos os servidores ou nenhum.
2. Código morto é mina ativada —feature flags removidas no mesmo PR que as elimina.
3. Disjuntores são obrigatórios — automated kill-switch quando output sai da distribuição esperada.

A SEC multou a Knight Capital em US$ 12 milhões em 2013. A empresa foi vendida à Getco em dezembro de 2012.

9.2 Robinhood/GameStop — janeiro de 2021

Em janeiro de 2021, o pico de short squeeze do GameStop sobrecarregou a infraestrutura da Robinhood. A reação foi bloquear compras de GME, AMC e outros — em parte por requisitos de clearing, em parte porque a arquitetura de risco não tinha sido projetada para aquele volume. Resultado: investigação do Congresso, processos coletivos, multa de US$ 65 milhões pela SEC.

A lição: pipeline de risco precisa escalar como pipeline de receita. Quando não escala, o negócio toma decisões defensivas que custam confiança do cliente.

9.3 Casos brasileiros que importam

Sem entrar em alvos específicos, qualquer profissional sênior de dados no Brasil sabe que:

• Operações de cobrança que mandaram WhatsApp para clientes errados porque o pipeline de telefone não foi higienizado.
• Bancos que abriram crédito para CPF errado porque pipeline de bureau teve latência maior que o esperado.
• E-commerce que cobrou frete errado porque pipeline de CEP tinha cache vencido.

Em todos: o dashboard mostrava número. O pipeline traía o número. A empresa decidiu sobre engano.

10. Antipadrões que ainda vivem em produção

Lista crua, observada repetidamente em diagnósticos:

Cada linha aqui é fruto de literatura técnica (Beauchemin, Kleppmann, Reis & Housley, Sanderson). Não é opinião — é convergência.

11. Roteiro prático — como construir pipeline em que se confia

A síntese, organizada em camadas:

11.1 Princípios (Beauchemin + Kleppmann)

• Idempotência — toda transformação devolve o mesmo resultado para a mesma janela de entrada.
• Imutabilidade — partições históricas não mudam; novas versões substituem.
• Determinismo — sem efeitos colaterais ocultos (sem timestamps externos não-versionados, sem chamadas a APIs cujo resultado muda).
• Reprodutibilidade — código versionado + dado bruto = possível regenerar qualquer saída.
• Reliability / Scalability / Maintainability — requisitos explícitos, com testes correspondentes.

11.2 Estrutura de camadas (medallion)

• Bronze — dado bruto, imutável, no formato em que veio.
• Silver — dado limpo, padronizado, com schema controlado.
• Gold — dado modelado para consumo (dimensional, marts, features).
• Nada de pular camadas — cada uma tem propósito.

11.3 Orquestração e workflow

• DAG explícito (Airflow, Dagster, Prefect) com dependências auditáveis.
• Retry com exponential backoff, idempotente.
• SLA monitorado — alerta quando job atrasa, não só quando falha.
• Backfill disciplinado — script pronto, testado, não improvisado às 23h.

11.4 Contratos (Sanderson)

• Schema versionado e validado em CI/CD.
• Mudanças breaking comunicadas com tempo (mínimo 1 sprint).
• Owner nominal por dataset.
• SLA explícito de frescor, completude e disponibilidade.

11.5 Observabilidade (Five Pillars / Moses)

• Freshness, Distribution, Volume, Schema, Lineage.
• Alertas direcionados ao owner (não para canal genérico onde ninguém olha).
• Dashboard de saúde do pipeline acessível aos consumidores.

11.6 Governança como código

• Permissões versionadas (IaC).
• Política de retenção / privacidade aplicada por catálogo, não por convenção.
• Lineage automatizado (OpenLineage, Datakin, Atlan).

11.7 DataOps (DORA aplicado a dado)

• Lead time for changes — quanto tempo da PR até produção?
• Deployment frequency — com que frequência mudanças entram?
• Change failure rate — quantas mudanças causam incidente?
• Mean time to restore — quanto tempo até voltar?

Essas quatro métricas — popularizadas pelo estudo DORA (DevOps Research and Assessment, Forsgren et al., 2018) — funcionam diretamente em pipeline de dados. E são incômodas no bom sentido: o pipeline que ninguém mexe há 6 meses porque "está rodando" é, em geral, o que vai quebrar feio quando precisar mudar.

12. Divergências e tensões no debate

Como nos artigos irmãos, vale transparência: há debates legítimos dentro da literatura técnica.

12.1 Data Mesh vs Centralized Warehouse

Zhamak Dehghani defende mesh.Bill Inmon, em entrevistas recentes, discorda parcialmente — argumenta que descentralizar sem fundação de qualidade reproduz silos.Joe Reis já criticou o exagero de adoção sem entender que mesh é um modelo organizacional, não uma stack tecnológica. A síntese honesta: mesh resolve problemas de escala organizacional, mas é overengineering para empresas pequenas/médias. Aplique pelo problema, não pelo hype.

12.2 Lakehouse vs Warehouse "puro"

Defensores de warehouse tradicional (Snowflake, BigQuery) apontam que lakehouse ainda paga preço em latência e maturidade de SQL para certos workloads. Defensores de lakehouse (Databricks, Iceberg, Hudi) apontam custo, vendor lock-in e dificuldade de ML em warehouse fechado.Tendência clara: convergência (Snowflake suporta Iceberg; Databricks tem Photon; BigQuery tem BigLake). O debate é menos "vs" e mais "qual mix".

12.3 Kappa vs Lambda

Já discutido. Posição honesta: streaming não é grátis. Streaming bem feito é caro em complexidade operacional. Lambda continua razoável onde latência analítica grande é aceitável.

12.4 ETL vs ELT

ETL (transforma antes de carregar) versus ELT (carrega bruto, transforma no warehouse) era debate em 2018. Em 2024 venceu ELT para a maioria dos casos (graças a warehouses elásticos como Snowflake/BigQuery + dbt). Ainda há casos onde ETL faz sentido — pipelines com PII pesado que não pode pousar bruto no warehouse, por exemplo.

12.5 Modelagem dimensional ainda importa?

Alguns artigos recentes (especialmente em torno de "metric layers" como Cube, MetricFlow do dbt) sugerem que modelagem dimensional tradicional está em obsolescência.Kimball respondeu no blog do Kimball Group em 2020 e 2022: o paradigma continua relevante; o que mudou é a ergonomia (modelagem em SQL versionado vs. ferramentas proprietárias). Não jogue a modelagem dimensional fora antes de entender o que ela resolvia.

Síntese honesta: não há divergência sobre o ponto central deste artigo —pipeline é base de decisão. Há divergência sobre arquitetura ótima, e essa divergência é saudável.

13. Conclusão — pipeline é onde a decisão começa

A tese do artigo, ao final:

Empresa não decide por dado. Decide por dado entregue por um pipeline. Quando o pipeline é confiável, a empresa decide por evidência. Quando o pipeline é frágil, a empresa decide por número decorativo — e descobre, frequentemente, no mês seguinte.

O dashboard é o último elo. O modelo de IA é só uma das saídas. O pipeline é o que sustenta os dois. Quando ele falha:

• O dashboard pode continuar bonito.
• O modelo pode continuar respondendo.
• A empresa pode continuar reunindo.
• E tudo isso estará errado ao mesmo tempo.

A pergunta-teste, no mesmo espírito dos artigos irmãos:

Se amanhã uma das fontes principais do seu pipeline ficar fora do ar por 6 horas, o que acontece?

• Há detecção automática em menos de 15 minutos?
• O owner é alertado por canal certo?
• Existe fallback documentado?
• Os consumidores são avisados antes de o número errado aparecer em comitê?
• O backfill, quando a fonte voltar, é idempotente?

Se as cinco respostas são "sim", você tem pipeline. Se alguma é "não", você tem encanamento esperando estourar — e a decisão da semana que vem vai ser sobre engano.

Referências e leitura adicional

Livros essenciais

• Kleppmann, M. (2017).Designing Data-Intensive Applications. O'Reilly. (2ª ed. com Chris Riccomini, 2026.)
• Reis, J. & Housley, M. (2022).Fundamentals of Data Engineering. O'Reilly.
• Inmon, W. H. (1992).Building the Data Warehouse. Wiley.
• Kimball, R. & Ross, M. (1996/2013).The Data Warehouse Toolkit. Wiley.
• Dehghani, Z. (2022).Data Mesh: Delivering Data-Driven Value at Scale. O'Reilly.

Papers e ensaios fundadores

• Armbrust, M., Ghodsi, A., Xin, R., Zaharia, M. (2021).Lakehouse: A New Generation of Open Platforms. CIDR.
• Beauchemin, M. (2017).The Rise of the Data Engineer.
• Beauchemin, M. (2018).Functional Data Engineering.
• Dehghani, Z. (2020).Data Mesh Principles and Logical Architecture. martinfowler.com.
• Kreps, J. (2014).Questioning the Lambda Architecture. O'Reilly Radar.
• Sanderson, C. (2022+).The Rise of Data Contracts|Engineer's Guide to Data Contracts.

Casos e estudos

• SEC. (2013).In the Matter of Knight Capital Americas LLC.
• The New York Times — DealBook. (2012).Knight Capital Says Trading Glitch Cost It $440 Million.
• Uber Engineering.Kappa Architecture for Timely Data Stream Processing.

Operação e DataOps

• Forsgren, N., Humble, J., Kim, G. (2018).Accelerate: The Science of Lean Software and DevOps. IT Revolution.
• DORA — DevOps Research and Assessment.
• Moses, B. —Monte Carlo: Data Observability.

Dados com contexto, estratégia e prática.