ETL vs ELT Moderno: dbt, Airbyte e Fivetran
As pipelines de dados são o sistema circulatório de toda arquitetura data-driven. Sem um fluxo confiável, documentado e testado de dados da fonte ao warehouse, os modelos de machine learning produzem previsões errôneas, os relatórios de negócio mostram números inconsistentes e as decisões estratégicas se baseiam em fundamentos instáveis. No entanto, na maioria das empresas, as pipelines de dados ainda são um emaranhado de scripts SQL agendados com cron, planilhas Excel atualizadas manualmente e processos ETL construídos há décadas que ninguém ousa tocar.
O panorama mudou radicalmente nos últimos cinco anos. O advento do cloud computing inverteu o paradigma fundamental do data movement: não faz mais sentido transformar os dados antes de carregá-los no warehouse, como se fazia com o ETL tradicional, quando o poder computacional da cloud está disponível a custos irrisórios e o warehouse moderno pode executar transformações complexas em segundos. Assim nasceu o paradigma ELT (Extract, Load, Transform), que inverte a ordem das operações movendo a transformação para dentro do próprio warehouse.
O mercado de pipelines de dados reflete essa transformação: o segmento ELT cresce 26% ao ano, com o mercado global de data pipeline tools estimado em $12 bilhões em 2024 e projetado para $48 bilhões até 2030. Fivetran, o principal player ELT managed, alcançou $300 milhões de ARR com um crescimento de 50% ano a ano. Não se trata de um nicho: é o novo padrão.
Neste artigo exploraremos ambos os paradigmas em profundidade, analisaremos as ferramentas que dominam o mercado (dbt, Airbyte, Fivetran), construiremos uma arquitetura de referência completa e forneceremos recomendações práticas para escolher o stack adequado com base no tamanho e nas competências da equipe.
O Que Você Aprenderá Neste Artigo
- As diferenças fundamentais entre ETL tradicional e ELT moderno, com prós/contras e casos de uso
- Como funciona o dbt (Data Build Tool): modelos SQL, testing, documentação, lineage
- dbt Core vs dbt Cloud: qual escolher e a que custo
- Airbyte: conectores open-source, arquitetura e deployment para self-hosting
- Fivetran: o modelo SaaS managed e o novo pricing MAR (2025)
- Comparação detalhada entre as três ferramentas para diferentes cenários empresariais
- A arquitetura ELT moderna de referência: Airbyte/Fivetran + Warehouse + dbt + BI
- Melhores práticas para testing, documentação e orquestração de pipelines
ETL Tradicional: Como Funciona e Por Que Não É Mais Suficiente
Durante quase trinta anos, o ETL (Extract, Transform, Load) foi o paradigma dominante para o movimento de dados empresariais. O processo se articula em três fases sequenciais:
- Extract (Extração): Os dados são extraídos dos sistemas de origem, tipicamente bancos de dados OLTP (ERP, CRM, e-commerce), arquivos planos (CSV, XML) ou APIs externas. Esta fase lê os dados sem modificá-los.
- Transform (Transformação): Os dados extraídos são transformados em um sistema intermediário, chamado staging area ou ETL engine, separado tanto da fonte quanto do destino. As transformações incluem limpeza, normalização, enriquecimento, agregação e conformação aos padrões do warehouse.
- Load (Carregamento): Os dados transformados são carregados no data warehouse de destino. A estrutura dos dados já é a definitiva, otimizada para consultas analíticas.
As Ferramentas ETL Tradicionais
| Ferramenta | Fornecedor | Custo Indicativo | Público-Alvo |
|---|---|---|---|
| SSIS | Microsoft | Incluído no SQL Server | PMEs com ecossistema Microsoft |
| Informatica PowerCenter | Informatica | $50.000-$500.000/ano | Enterprise banking/seguros |
| Oracle Data Integrator | Oracle | Incluído com Oracle DB | Ecossistema Oracle |
| Talend Open Studio | Qlik | Gratuito (core) / $1.170+/mês | PMEs, open source |
| Pentaho Data Integration | Hitachi Vantara | Gratuito (CE) / Custom (EE) | PMEs, open source |
Essas ferramentas funcionam. Foram (e em muitos casos ainda são) a espinha dorsal de sistemas críticos que movimentam bilhões de euros em transações todos os dias. Mas têm limites estruturais que o paradigma cloud tornou cada vez mais evidentes.
Os Limites Estruturais do ETL Clássico
Por Que o ETL Tradicional Tem Dificuldades no Contexto Moderno
- Compute externo custoso: As transformações ocorrem em um servidor separado (servidor ETL), que deve ser dimensionado para o pico de carga. Se o batch noturno processa 100 milhões de linhas, o servidor deve ser poderoso o suficiente para aguentar essa janela temporal, mesmo que fique quase inativo por 22 horas do dia.
- Rigidez e custo da mudança: Adicionar um campo a uma transformação SSIS requer modificar o fluxo visual, testá-lo em staging, coordenar a implantação com quem gerencia o warehouse de destino. Em equipes estruturadas, isso leva semanas.
- Sem versionamento nativo: Os fluxos ETL não são código testável e versionável como o software aplicativo. A governança se torna difícil: quem modificou esta transformação? Quando? Por quê?
- Debug complexo: Quando uma transformação produz resultados inesperados, rastrear o problema através de um fluxo ETL visual pode levar horas. Não existe um "data lineage" padrão que mostre de onde vem cada coluna.
- Desperdício de energia no armazém: Investe-se em um Snowflake ou BigQuery de dezenas de milhares de euros por ano pelo seu poder computacional, mas depois se processam os dados em um servidor separado. O paradigma ELT reconhece que o próprio warehouse é o motor de transformação mais eficiente.
ELT Moderno: Por Que a Cloud Mudou Tudo
O ELT (Extract, Load, Transform) inverte a ordem das duas últimas fases: os dados são primeiro extraídos das fontes e carregados no warehouse na sua forma bruta, e somente depois transformados usando o poder de cálculo do próprio warehouse.
Essa mudança de paradigma foi possibilitada por três fatores convergentes:
- Armazenamento cloud econômico: Amazon S3, Azure Blob Storage e Google Cloud Storage custam $20-23 por TB por mês. Não faz mais sentido ser parcimonioso com o armazenamento: melhor carregar tudo e decidir depois o que transformar.
- Compute elástico: Snowflake, BigQuery, Databricks escalam automaticamente o compute. Uma consulta de transformação complexa é executada em segundos aproveitando clusters de centenas de nós, pagando apenas pelo tempo de execução efetivo.
- SQL como linguagem universal: Os data analysts conhecem SQL muito melhor do que as ferramentas ETL proprietárias. Com ELT, as transformações são simples consultas SQL que qualquer pessoa da equipe pode ler, modificar e revisar.
Comparação ETL vs ELT: Tabela Decisional
ETL vs ELT: Comparação Completa
| Dimensão | ETL Tradicional | ELT Moderno |
|---|---|---|
| Onde ocorre a transformação | Servidor ETL dedicado (externo ao warehouse) | Dentro do data warehouse (SQL nativo) |
| Quando transformar | Antes do carregamento | Após o carregamento no raw layer |
| Volume de dados suportado | Limitado pela capacidade do servidor ETL | Escala com o warehouse (potencialmente ilimitado) |
| Dados não estruturados | Difícil ou impossível | Suportado (JSON nativo, semi-structured) |
| Linguagem | GUI proprietária / Java / Python | SQL padrão (+ Jinja no dbt) |
| Versionamento | Difícil, frequentemente ausente | Git nativo (os modelos são arquivos .sql) |
| Testing | Manual ou limitado | Framework de teste integrado (dbt test) |
| Data lineage | Frequentemente ausente ou manual | Automático (DAG visual no dbt) |
| Segurança / Compliance | Dados sensíveis nunca no warehouse em texto claro | Dados brutos no warehouse: necessário masking e governança |
| Latência de transformação | Depende do servidor ETL | Depende do warehouse (batch ou on-demand) |
| Curva de aprendizado | Alta (GUIs proprietárias) | Baixa para quem conhece SQL |
| Ideal para | Dados sensíveis, sistemas legados, compliance rigorosa | Cloud-first, equipes SQL, alto volume de dados |
Quando ouço ETL vs ELT
- Jogue ETL quando: você tem requisitos de compliance que proíbem carregar dados brutos na cloud (ex: PII sem anonimização), trabalha com sistemas legados on-premise onde o warehouse está muito distante da fonte, ou tem transformações computacionalmente intensivas que não se beneficiam do warehouse SQL.
- Ouça ELT quando: seu warehouse é cloud (Snowflake, BigQuery, Databricks, Redshift), a equipe tem competências SQL sólidas, você quer versionar as transformações com Git, trabalha com volumes de dados crescentes e quer aproveitar a elasticidade da cloud.
- Abordagem híbrida: Muitas empresas adotam uma abordagem mista: ETL para a anonimização de dados sensíveis antes do carregamento, ELT para todas as transformações analíticas subsequentes.
dbt: A Camada de Transformação do Stack Moderno
dbt (Data Build Tool) é a ferramenta que definiu o paradigma ELT moderno. Criado pela dbt Labs em 2016, o dbt transforma a forma como os data analysts escrevem as transformações: em vez de procedimentos SQL dispersos sem estrutura, o dbt introduz um framework de desenvolvimento inspirado na engenharia de software, com modelos versionados, testes automáticos e documentação gerada automaticamente.
O conceito fundamental é simples: cada modelo dbt é um arquivo .sql que contém um SELECT. O dbt se encarrega de criar a tabela ou a view no warehouse, gerenciar as dependências entre modelos e construir um DAG (Directed Acyclic Graph) das transformações.
Arquitetura dbt: Como Funciona
O dbt não tem um runtime de cálculo próprio: utiliza o compute do warehouse de destino. Funciona como um compilador SQL + orquestrador: pega os arquivos .sql com as macros Jinja, compila-os em SQL puro e os executa no warehouse na ordem correta baseando-se nas dependências declaradas. O resultado é uma série de tabelas e views no warehouse, construídas de forma reproduzível.
-- models/staging/stg_orders.sql
-- Modelo de staging: limpeza e padronização dos pedidos
-- dbt cria uma view (ou tabela) chamada 'stg_orders' no warehouse
WITH source AS (
-- Referência à tabela fonte raw (carregada pelo Airbyte/Fivetran)
SELECT * FROM {{ source('erp', 'raw_orders') }}
),
cleaned AS (
SELECT
order_id::BIGINT AS order_id,
customer_id::INT AS customer_id,
product_id::INT AS product_id,
quantity::INT AS quantity,
unit_price::DECIMAL(10, 2) AS unit_price,
COALESCE(discount, 0.0)::DECIMAL(5, 2) AS discount,
CAST(order_date AS TIMESTAMP) AS order_date,
LOWER(TRIM(status)) AS status,
-- Valor líquido calculado
quantity * unit_price * (1 - COALESCE(discount, 0))
AS net_amount,
-- Metadados de auditoria
_loaded_at AS ingested_at
FROM source
WHERE order_id IS NOT NULL
AND customer_id IS NOT NULL
AND quantity > 0
AND unit_price > 0
)
SELECT * FROM cleaned-- models/marts/finance/fct_orders_monthly.sql
-- Modelo de fatos: agregação mensal para a equipe de finanças
-- Depende de stg_orders e dim_customers (resolução automática de dependências)
{{ config(
materialized='table',
schema='finance',
tags=['finance', 'monthly']
) }}
WITH orders AS (
SELECT * FROM {{ ref('stg_orders') }}
),
customers AS (
SELECT * FROM {{ ref('dim_customers') }}
),
monthly_metrics AS (
SELECT
DATE_TRUNC('month', o.order_date) AS month,
c.region,
c.segment,
COUNT(DISTINCT o.order_id) AS total_orders,
COUNT(DISTINCT o.customer_id) AS unique_customers,
SUM(o.net_amount) AS gross_revenue,
AVG(o.net_amount) AS avg_order_value,
SUM(o.quantity) AS units_sold
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.customer_id
GROUP BY 1, 2, 3
)
SELECT
*,
gross_revenue / NULLIF(unique_customers, 0) AS revenue_per_customer
FROM monthly_metrics
ORDER BY month DESC, gross_revenue DESCTesting no dbt: Garantir a Qualidade dos Dados
Um dos pontos fortes mais importantes do dbt é o seu sistema de testes nativo. Os testes no dbt
são declarativos: são definidos em um arquivo YAML e executados automaticamente após cada
run com o comando dbt test.
# models/staging/schema.yml
# Definição dos testes para o modelo stg_orders
version: 2
models:
- name: stg_orders
description: >
Pedidos limpos e padronizados do sistema ERP de origem.
Carregados a cada hora pelo Airbyte, transformados por este modelo.
columns:
- name: order_id
description: "Identificador único do pedido (PK)"
tests:
- unique # Nenhum duplicado permitido
- not_null # Cada linha deve ter um order_id
- name: customer_id
description: "Referência à dimensão de clientes"
tests:
- not_null
- relationships: # Referential integrity check
to: ref('dim_customers')
field: customer_id
- name: status
description: "Status do pedido"
tests:
- accepted_values:
values: ['pending', 'confirmed', 'shipped', 'delivered', 'cancelled']
- name: net_amount
description: "Valor líquido do pedido (quantidade * preço * (1 - desconto))"
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "net_amount >= 0"
- name: order_date
description: "Data e hora do pedido"
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "order_date <= CURRENT_TIMESTAMP"
- name: fct_orders_monthly
description: "Agregações mensais para o reporting de finanças"
columns:
- name: month
tests:
- not_null
- name: gross_revenue
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "gross_revenue >= 0"
sources:
- name: erp
description: "Dados brutos carregados do ERP via Airbyte"
schema: raw_erp
tables:
- name: raw_orders
loaded_at_field: _loaded_at
freshness:
warn_after: {count: 12, period: hour}
error_after: {count: 24, period: hour}dbt Core vs dbt Cloud
O dbt existe em duas variantes: dbt Core (open-source, gratuito) e dbt Cloud (SaaS managed, pago). A escolha depende das necessidades da equipe em termos de infraestrutura e funcionalidades avançadas.
dbt Core vs dbt Cloud: Comparação Completa
| Funcionalidade | dbt Core (Open Source) | dbt Cloud Team | dbt Cloud Enterprise |
|---|---|---|---|
| Custo | Gratuito | $100/assento/mês + $0.01 por modelo além de 15.000 | Custom (entre em contato com vendas) |
| Execução de jobs | Manual / Orquestrador externo (Airflow, Dagster) | Scheduler nativo, CI/CD integrado | Scheduler avançado + SLA monitoring |
| IDE web | Não (apenas editor local) | dbt Cloud IDE (baseado em navegador) | dbt Cloud IDE |
| Documentação | Gerada localmente (dbt docs generate) | Hospedada automaticamente | Hospedada + Data Catalog avançado |
| Lineage visual | Local | Cloud hosted, compartilhável | Cloud hosted + Cross-project lineage |
| Colaboração em equipe | Via Git (manual) | Multi-usuário, workflow baseado em PR | RBAC, SSO, audit logs |
| Semantic Layer | Não | Incluído (5.000 métricas/mês) | Incluído (20.000 métricas/mês) |
| dbt Mesh | Não | Limitado | Completo (referências entre projetos) |
| SOC 2 compliance | N/A (auto-gerenciado) | Incluído | Incluído + PrivateLink |
| Ideal para | Equipes técnicas, orçamento limitado, já possuem Airflow | Equipes de 2-20 pessoas sem infraestrutura ETL | Enterprise, multi-equipe, compliance rigorosa |
A recomendação prática: PMEs com uma equipe de 1-3 data engineers devem começar com dbt Core + Airflow ou Dagster, que oferece total flexibilidade a custo zero. Se a equipe crescer ou se quiser evitar a gestão da infraestrutura de orquestração, o dbt Cloud se torna vantajoso já com 2-3 developer seats.
Airbyte: A Camada de Ingestão Open-Source
Se o dbt cuida do T (transformação) no ELT, o Airbyte gerencia o E (extração) e o L (carregamento). Fundado em 2020 e hoje com mais de $180 milhões de financiamento, o Airbyte é a plataforma de integração de dados open-source mais adotada do mercado, com mais de 600 conectores pré-construídos e um SDK Python para construir conectores personalizados.
O ponto forte principal do Airbyte em relação aos concorrentes é a combinação de open-source (zero vendor lock-in, código modificável) com uma arquitetura cloud-native que suporta Change Data Capture (CDC) para a réplica em tempo real dos bancos de dados.
Arquitetura do Airbyte
O Airbyte é composto por vários componentes que trabalham em conjunto. Cada sincronização é executada por um Worker que instancia dois containers Docker separados: o Source Connector (que lê da fonte) e o Destination Connector (que escreve no destino). Os dados fluem entre ambos através do Airbyte Protocol, um formato JSON padrão.
# Exemplo: Configuração de conector Airbyte via API (YAML/JSON)
# Criação de uma conexão PostgreSQL -> Snowflake
# 1. Configuração Source (PostgreSQL)
POST /api/v1/sources/create
{
"sourceDefinitionId": "decd338e-5647-4c0b-adf4-da0e75f5a750",
"connectionConfiguration": {
"host": "db.producao.minhaempresa.com.br",
"port": 5432,
"database": "erp_production",
"username": "airbyte_reader",
"password": "{{ secrets.POSTGRES_PASSWORD }}",
"schemas": ["public", "orders"],
"replication_method": {
"method": "CDC",
"replication_slot": "airbyte_slot",
"publication": "airbyte_publication"
}
},
"name": "ERP Production PostgreSQL",
"workspaceId": "workspace-uuid"
}
# 2. Configuração Destination (Snowflake)
POST /api/v1/destinations/create
{
"destinationDefinitionId": "424892c4-daac-4491-b35d-c6688ba547ba",
"connectionConfiguration": {
"host": "abc12345.eu-west-1.snowflakecomputing.com",
"role": "AIRBYTE_ROLE",
"warehouse": "AIRBYTE_WH",
"database": "RAW_DATA",
"schema": "erp",
"username": "airbyte_user",
"credentials": {
"auth_type": "key_pair",
"private_key": "{{ secrets.SNOWFLAKE_PRIVATE_KEY }}"
}
},
"name": "Snowflake Production",
"workspaceId": "workspace-uuid"
}
# 3. Criação da conexão
POST /api/v1/connections/create
{
"sourceId": "source-uuid",
"destinationId": "destination-uuid",
"syncCatalog": {
"streams": [
{
"stream": {"name": "orders", "namespace": "public"},
"config": {
"syncMode": "incremental",
"destinationSyncMode": "append_dedup",
"cursorField": ["updated_at"],
"primaryKey": [["order_id"]]
}
},
{
"stream": {"name": "customers", "namespace": "public"},
"config": {
"syncMode": "full_refresh",
"destinationSyncMode": "overwrite"
}
}
]
},
"scheduleType": "cron",
"scheduleData": {"cron": {"cronExpression": "0 */1 * * *", "cronTimeZone": "Europe/Rome"}},
"namespaceDefinition": "customformat",
"namespaceFormat": "raw_{{SOURCE_NAMESPACE}}"
}Airbyte: Opções de Deploy
O Airbyte oferece três modalidades de deployment, cada uma com características distintas em termos de custo, controle e manutenção:
Airbyte: Open Source vs Cloud vs Enterprise
| Aspecto | Open Source (Self-hosted) | Airbyte Cloud | Airbyte Enterprise |
|---|---|---|---|
| Custo | Gratuito (infraestrutura por sua conta) | Pagamento conforme uso (crédito de US$ 2,50 a US$ 10) | Custom (entre em contato com vendas) |
| Manutenção | Por conta como uma equipe | Gerenciada pelo Airbyte | Gerenciada pelo Airbyte |
| Conectores | 600+ | 600+ | 600+ + conectores certificados premium |
| CDC | Suportado | Suportado | Suportado + CDC avançado |
| RBAC | Básico | Incluído | Avançado (SSO, audit logs) |
| SLA | N/A | 99.9% uptime | 99.99% uptime |
| Ideal para | Equipes técnicas, orçamento limitado, dados sensíveis | PMEs que querem velocidade sem ops | Enterprise com compliance rigorosa |
# Deploy Airbyte Open Source com Docker Compose
# Pré-requisitos: Docker, Docker Compose, 8GB RAM, 20GB disco
# 1. Clone o repositório
git clone --depth=1 https://github.com/airbytehq/airbyte.git
cd airbyte
# 2. Inicie o Airbyte (primeira execução: ~15 minutos para download das imagens)
./run-ab-platform.sh
# Airbyte está acessível em http://localhost:8000
# Username: airbyte / Password: password (alterar em produção!)
# 3. Para deployment em produção no Kubernetes com Helm
helm repo add airbyte https://airbytehq.github.io/helm-charts
helm install airbyte airbyte/airbyte \
--namespace airbyte \
--create-namespace \
--set global.state.storage.type=MINIO \
--set global.storage.bucket.log=airbyte-logs \
--values custom-values.yaml
# 4. Configuração de variáveis de ambiente para produção (.env)
# DATABASE_URL=postgresql://airbyte:password@postgres:5432/airbyte
# SECRET_PERSISTENCE=GOOGLE_SECRET_MANAGER
# LOG_LEVEL=INFO
# TRACKING_STRATEGY=segmentFivetran: A Simplicidade do SaaS Managed
Enquanto o Airbyte aposta na flexibilidade e no controle open-source, o Fivetran escolheu o caminho oposto: máxima simplicidade, zero manutenção, conectores enterprise-grade gerenciados completamente pelo fornecedor. Fundado em 2012, o Fivetran é hoje o líder do segmento ELT managed com $300 milhões de ARR, mais de 6.300 clientes e uma avaliação de $5.6 bilhões.
A proposta de valor do Fivetran é clara: um conector Fivetran para Salesforce, Shopify ou qualquer outro sistema SaaS é mantido por uma equipe dedicada de engenheiros Fivetran que gerenciam cada mudança da API de origem, cada breaking change, cada atualização de schema. O cliente não precisa fazer nada.
O Novo Modelo de Pricing do Fivetran 2025
Em março de 2025, o Fivetran atualizou significativamente seu modelo de pricing. Os planos Starter e Private Deployment foram eliminados e substituídos por quatro níveis: Free, Standard, Enterprise e Business Critical. A métrica de faturamento continua sendo o MAR (Monthly Active Rows), mas o cálculo mudou: agora cada conexão é faturada separadamente, não mais de forma agregada por conta.
Fivetran: Planos e Preços 2025
| Plano | MAR incluídos | Custo adicional | Features principais |
|---|---|---|---|
| Free | 500.000 MAR/mês | N/A | Todas as features Standard, até 5.000 model runs |
| Standard | Ilimitado (pagamento por uso) | $5 base/conexão + MAR pricing | 600+ conectores, CDC, dbt integration, scheduling |
| Enterprise | Negociável | Custom (desconto por volume) | SSO/SAML, RBAC, VPN, priority support, SLA |
| Business Critical | Negociável | Custom | PrivateLink, HIPAA compliance, dedicated support, 99.99% SLA |
Como Funciona o Cálculo MAR no Fivetran
O MAR (Monthly Active Row) conta as linhas distintas sincronizadas em um mês calendário, rastreadas via primary key. Uma linha modificada 30 vezes em um mês conta como 1 MAR, não como 30. A vantagem: o custo não explode com a frequência de sincronização, mas com o número de registros únicos que mudam.
Exemplo prático: Uma empresa com 50.000 pedidos ativos por mês e 500.000 produtos no catálogo (atualizados raramente) paga principalmente pelos 50.000 pedidos que mudam de status a cada mês, não pelo catálogo completo de produtos.
dbt vs Airbyte vs Fivetran: Qual Escolher?
É importante entender que dbt, Airbyte e Fivetran não são ferramentas alternativas que se excluem mutuamente: resolvem problemas diferentes dentro do mesmo stack. O dbt cuida das transformações, Airbyte e Fivetran cuidam da ingestão. A pergunta correta é: Airbyte vs Fivetran para a ingestão?
Airbyte vs Fivetran: Comparação por Cenários
| Dimensão | Airbyte Open Source | Airbyte Cloud | Fivetran Standard |
|---|---|---|---|
| Custo base | $0 (infraestrutura à parte) | Pay-per-use | $5/conexão/mês + MAR |
| Conectores | 600+ (community maintained) | 600+ | 650+ (enterprise-grade) |
| Manutenção de conectores | Community / equipe interna | Equipe Airbyte | Equipe Fivetran (SLA garantido) |
| CDC | Suportado (Debezium) | Suportado | Suportado (log-based) |
| Conectores custom | SDK Python (gratuito) | SDK Python | Custom connector SDK (pago) |
| Data residency | Completo (auto-hospitalar) | Region-specific | Region-specific |
| Setup time | 1-4 horas (infraestrutura) | 30 minutos | 15 minutos |
| dbt integration | Manual / Airflow | Nativa | Nativa (dbt Cloud) |
| Ideal para | Equipes técnicas, fontes custom, LGPD local | PMEs tech-savvy, orçamento variável | PMEs/Enterprise com fontes SaaS padrão |
Regra Prática para a Escolha
- Use Fivetran se suas fontes são SaaS padrão (Salesforce, HubSpot, Shopify, Stripe, Google Analytics, Facebook Ads) e a equipe não quer se preocupar com a manutenção dos conectores. A produtividade ganha vale o custo.
- Use Airbyte Cloud se você tem um mix de fontes padrão e custom, ou se está começando e quer controlar os custos com pay-per-use.
- Use Airbyte Open Source se você tem requisitos LGPD/data residency que impedem o trânsito de dados através de infraestruturas de terceiros, ou se tem fontes altamente customizadas que requerem conectores desenvolvidos internamente.
Arquitetura ELT Moderna de Referência
Unindo todos os componentes, aqui está a arquitetura ELT moderna que as empresas líderes adotam hoje. Cada camada do stack tem um propósito preciso e ferramentas de referência.
O Stack ELT Moderno: Camada por Camada
| Camada | Função | Ferramentas Principais |
|---|---|---|
| 1. Ingestão | Extrair e carregar dados brutos no warehouse | Fivetran, Airbyte, Stitch, scripts custom |
| 2. Storage (Raw) | Dados brutos não modificados (Bronze layer) | Snowflake, BigQuery, Databricks, Redshift |
| 3. Transformação | Modelos SQL, testing, documentação, lineage | dbt Core, dbt Cloud |
| 4. Serving (Gold) | Tabelas otimizadas para analytics e ML | Snowflake, BigQuery, Databricks (warehouse) |
| 5. Orquestração | Scheduling, dependências, monitoring de pipelines | Airflow, Dagster, Prefect, dbt Cloud |
| 6. BI e Reporting | Dashboards, consultas ad hoc, self-service analytics | Looker, Metabase, Power BI, Tableau |
| 7. Data Quality | Monitoring, alerting, detecção de anomalias | dbt tests, Great Expectations, Monte Carlo |
# Exemplo: Pipeline ELT completa orquestrada com Dagster
# Dagster define os jobs como grafo de assets
from dagster import asset, AssetIn, define_asset_job, ScheduleDefinition
# Asset 1: Raw data (carregado pelo Fivetran/Airbyte - externo ao Dagster)
# Dagster pode "observar" as tabelas carregadas pelo Fivetran como assets externos
@asset(
group_name="raw",
description="Pedidos brutos carregados pelo Fivetran (ERP)"
)
def raw_orders():
# Fivetran escreve aqui automaticamente a cada hora
# Este asset "declara" a tabela para o lineage visual
pass
# Asset 2: dbt staging (transformação com dbt)
@asset(
group_name="staging",
deps=["raw_orders"],
description="Pedidos limpos e padronizados (modelo dbt stg_orders)"
)
def stg_orders(context):
# Executa o modelo dbt stg_orders
context.log.info("Running dbt model: stg_orders")
# Na prática: dbt_cloud_run_op ou subprocess dbt run --select stg_orders
return {"rows_processed": 15000}
# Asset 3: dbt marts (modelo gold pronto para o negócio)
@asset(
group_name="marts",
ins={"staging": AssetIn("stg_orders")},
description="Faturamento mensal para o reporting de finanças"
)
def fct_orders_monthly(context, staging):
context.log.info(f"Building monthly metrics from {staging['rows_processed']} rows")
# dbt run --select fct_orders_monthly
return {"mart_rows": 360} # 30 dias * 12 segmentos regionais
# Scheduling: executa a cada hora, atualiza todos os assets
elt_pipeline_job = define_asset_job(
name="elt_pipeline",
selection=["stg_orders", "fct_orders_monthly"]
)
elt_schedule = ScheduleDefinition(
job=elt_pipeline_job,
cron_schedule="0 * * * *", # A cada hora
execution_timezone="Europe/Rome"
)Melhores Práticas para Pipelines de Dados Confiáveis
Construir uma pipeline ELT que funcione em uma demo é simples. Construir uma pipeline que escale, seja monitorável e mantida por uma equipe ao longo do tempo requer disciplina e a aplicação de práticas de engenharia consolidadas.
1. Estratificação e Naming Convention
Adote uma estrutura de diretórios dbt clara e consistente que reflita a arquitetura em camadas (Medallion ou equivalente):
# Estrutura de projeto dbt recomendada
dbt_project/
├── models/
│ ├── staging/ # Camada Silver: limpeza de fontes
│ │ ├── erp/
│ │ │ ├── stg_orders.sql
│ │ │ ├── stg_customers.sql
│ │ │ └── schema.yml # Testes + documentação
│ │ ├── crm/
│ │ │ ├── stg_contacts.sql
│ │ │ └── schema.yml
│ │ └── ecommerce/
│ │ ├── stg_sessions.sql
│ │ └── schema.yml
│ ├── intermediate/ # Modelos intermediários (joins complexas)
│ │ ├── int_customer_orders.sql
│ │ └── schema.yml
│ └── marts/ # Camada Gold: prontos para o negócio
│ ├── finance/
│ │ ├── fct_orders_monthly.sql
│ │ ├── fct_revenue_by_product.sql
│ │ └── schema.yml
│ ├── marketing/
│ │ ├── fct_campaign_performance.sql
│ │ └── schema.yml
│ └── operations/
│ ├── fct_fulfillment_kpis.sql
│ └── schema.yml
├── seeds/ # Dados estáticos (tabelas de lookup, mapping)
│ ├── country_codes.csv
│ └── product_categories.csv
├── snapshots/ # SCD Type 2 (Slowly Changing Dimensions)
│ └── snap_customers.sql
├── tests/ # Testes SQL customizados
│ └── assert_revenue_positive.sql
├── macros/ # Macros Jinja reutilizáveis
│ ├── generate_schema_name.sql
│ └── audit_columns.sql
└── dbt_project.yml # Configuração global2. Testing Como Contrato de Qualidade
Os testes dbt não são opcionais: são o contrato que garante que as transformações produzam dados confiáveis. Cada modelo deveria ter pelo menos estes testes:
- unique + not_null na primary key: Garante a integridade de cada modelo.
- relationships: Verifica a integridade referencial entre modelos.
- accepted_values: Verifica que os campos categóricos contenham apenas valores válidos.
- freshness na source: Avisa se os dados não são atualizados nos prazos previstos.
- dbt_utils.expression_is_true: Para restrições específicas do negócio (ex: revenue >= 0).
3. Versionamento e CI/CD para as Pipelines de Dados
# .github/workflows/dbt-ci.yml
# CI/CD para validar os modelos dbt a cada PR
name: dbt CI Pipeline
on:
pull_request:
branches: [main]
paths:
- 'dbt_project/**'
jobs:
dbt-lint-and-test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v4
with:
python-version: '3.11'
- name: Install dbt
run: |
pip install dbt-snowflake==1.8.0
pip install sqlfluff==3.0.0
- name: dbt debug (connection test)
run: dbt debug
env:
DBT_SNOWFLAKE_ACCOUNT: {{ secrets.SNOWFLAKE_ACCOUNT }}
DBT_SNOWFLAKE_USER: {{ secrets.SNOWFLAKE_USER }}
DBT_SNOWFLAKE_PASSWORD: {{ secrets.SNOWFLAKE_PASSWORD }}
DBT_SNOWFLAKE_DATABASE: DBT_CI_DB
DBT_SNOWFLAKE_SCHEMA: CI_{{ github.event.pull_request.number }}
- name: sqlfluff lint (SQL style check)
run: sqlfluff lint models/ --dialect snowflake
- name: dbt compile (syntax check)
run: dbt compile
- name: dbt run (apenas modelos modificados)
run: dbt run --select state:modified+
env:
DBT_DEFER_TO_PROD: true
- name: dbt test (testes nos modelos modificados)
run: dbt test --select state:modified+
- name: dbt docs generate
run: dbt docs generate
- name: Cleanup CI schema
if: always()
run: dbt run-operation drop_schema --args '{"schema": "CI_{{ github.event.pull_request.number }}"}'4. Data Freshness Monitoring
Uma pipeline ELT quebrada que ninguém sabe estar quebrada é pior do que não ter pipeline. O monitoramento proativo da frescura dos dados deve ser parte integral do stack:
Anti-Padrões a Evitar nas Pipelines ELT
- Modelos sem testes: Um modelo dbt sem pelo menos um teste unique + not_null é uma bomba-relógio. Cedo ou tarde produzirá dados duplicados ou nulos que invalidarão os relatórios.
- Ausência de schema.yml: Sem documentação, os modelos se tornam incompreensíveis para qualquer pessoa que não os tenha escrito, incluindo o próprio autor após 6 meses.
- Full refresh sempre: Recarregar sempre a tabela inteira em vez de fazer append/upsert incremental é custoso e frágil para datasets grandes.
- Lógica de negócio na camada staging: O staging deve apenas limpar e padronizar. Agregações e lógica de negócio vão nos marts. Misturar os níveis cria dependências difíceis de gerenciar.
- Ignorar a data lineage: Quando um relatório mostra um número errado, sem lineage documentado rastrear o problema leva horas. Com dbt docs, chega-se à fonte em poucos cliques.
- Sem alertas sobre freshness: Se o Fivetran parar de sincronizar à noite e ninguém monitorar, os relatórios da manhã mostrarão dados de ontem sem nenhum aviso visível para os usuários de negócio.
Recomendações para PMEs
O panorama das pipelines de dados pode parecer avassalador para uma PME com recursos limitados e equipes pequenas. A boa notícia é que não é preciso adotar todo o stack de uma vez. Aqui está um percurso progressivo em três fases:
Roteiro de Adoção para PMEs (3 Fases)
| Fase | Timeline | Stack Recomendado | Custo Mensal Indicativo |
|---|---|---|---|
| Fase 1: Fundamentos | Mês 1-3 | Fivetran Free + BigQuery sandbox + dbt Core | €0 - €200 |
| Fase 2: Produção | Mês 4-9 | Fivetran Standard + Snowflake/BigQuery + dbt Core + Airflow managed | €800 - €3.000 |
| Fase 3: Escalar | Mês 10+ | Fivetran Enterprise + Snowflake + dbt Cloud + Dagster Cloud | €3.000 - €15.000 |
Fase 1 – Fundamentos: Comece com ou plano gratuito da Fivetran (500.000 MAR/mês) conectar 2 a 3 fontes críticas (ERP, CRM, e-commerce). Usar ou BigQuery on-line sandbox (grátis com 10 GB de armazenamento + 1 TB de consultas/meses). Instale o dbt Core localmente e vender os primeiros 10-15 modelos. O objetivo é aprender nossos professores e demonstrar valor um negócio como investimento inicial.
Fase 2 - Produção: Quando você demonstra valor no PoC, tamanho para Fivetran Standard para gerenciar mais conectores, acesse um armazém em nuvem com SLA (produção Snowflake ou BigQuery) e adicione orquestração com gerenciamento do Airflow (Cloud Composer usando GCP ou MWAA usando AWS). O preço mensal é contínuo e impactante nem negócios nem medicina.
Fase 3 - Escalar: Quando um time de dados cresce para 3 a 5 pessoas, vale a pena adicione dbt Cloud para IDE colaborativo e CI/CD automático, e Dagster Cloud para uma organização mais sofisticada com observabilidade. Nesse ponte um gasoduto se você virar Um líder estratégico de negócios supervisionado por mestres profissionais em engenharia.
Conclusões e Próximos Passos
A evolução de ETL para ELT não é simplesmente uma mudança na ordem das letras: é uma transformação fundamental na forma de projetar, desenvolver e manter as pipelines de dados empresariais. A cloud tornou o compute elástico e econômico, tornando obsoleto o modelo de transformação pré-carregamento em servidores dedicados.
O stack moderno dbt + Airbyte/Fivetran + warehouse cloud representa o estado da arte de 2025 e é adotado por milhares de empresas, de startups a Fortune 500. As vantagens concretas são mensuráveis: pipelines versionáveis como código, testes automáticos que garantem a qualidade dos dados, documentação e lineage gerados automaticamente, e custos escaláveis que crescem com o negócio em vez de exigir investimentos upfront.
Pontos-Chave para Lembrar
- ETL não morreu: ainda faz sentido para dados sensíveis que não devem transitar em texto claro na cloud ou para fontes legadas on-premise com baixa latência requerida.
- ELT é o novo padrão para arquiteturas cloud-first: carregue tudo bruto, transforme onde você tem mais potência (o warehouse).
- dbt é a camada de transformação: traz as melhores práticas de engenharia de software (versionamento, testes, documentação) para o mundo SQL.
- Airbyte é a escolha open-source para equipes técnicas com fontes custom ou requisitos LGPD de data residency.
- Fivetran é a escolha managed para quem quer zero manutenção nos conectores para fontes SaaS padrão (Salesforce, HubSpot, Shopify, etc.).
- Para PMEs: comece com Fivetran Free + BigQuery + dbt Core para validar o valor antes de investir na infraestrutura completa.
O próximo artigo da série aprofunda a orquestração de pipelines: Airflow, Dagster e Prefect em comparação. Se o dbt é o motor de transformação e Airbyte/Fivetran são o sistema de ingestão, o orquestrador é o cérebro que coordena tudo: quem executa o quê, quando, em qual ordem, e o que fazer quando algo dá errado. Um componente crítico que merece um tratamento dedicado.
Exercício Prático: Setup dbt Core em 30 Minutos
Antes de passar ao próximo artigo, tente configurar o dbt Core em um warehouse existente (mesmo BigQuery sandbox gratuito):
# 1. Instale o dbt com o perfil para o seu warehouse
pip install dbt-bigquery # para BigQuery
# ou: pip install dbt-snowflake, dbt-redshift, dbt-duckdb
# 2. Crie um novo projeto dbt
dbt init meu_projeto_dbt
# 3. Configure o perfil (~/.dbt/profiles.yml para BigQuery)
# meu_projeto_dbt:
# target: dev
# outputs:
# dev:
# type: bigquery
# method: oauth
# project: meu-projeto-gcp
# dataset: dbt_dev
# threads: 4
# timeout_seconds: 300
# 4. Teste a conexão
cd meu_projeto_dbt
dbt debug
# 5. Crie seu primeiro modelo
cat > models/staging/stg_example.sql << 'EOF'
SELECT
id,
name,
created_at,
UPPER(TRIM(email)) AS email_normalized
FROM {{ source('raw', 'users') }}
WHERE id IS NOT NULL
EOF
# 6. Execute e teste
dbt run
dbt test
dbt docs generate
dbt docs serve # Abre o lineage visual em http://localhost:8080