Novo: Eficify One em beta aberto. Crie seu primeiro ambiente sem cartão.Conhecer a plataforma →
Você já viu isso acontecer: a empresa adota uma plataforma de dados moderna, tudo funciona lindo nos primeiros 6 meses, e depois vem a conta. Preço explode, o vendor muda os termos, a equipe não consegue migrar porque tudo está acoplado àquele formato proprietario. Enquanto isso, o time de engenharia fica refém. Este artigo mostra como evitar esse caminho, construindo uma plataforma de dados open source que escala de MVP a enterprise sem te entregar a chave da prisão junto.
A maioria das plataformas de dados enterprise hoje se vendem como "solução completa". O que elas não contam é que o vendor lockin começa no momento em que você adota o formato proprietario de storage, o catálogo proprietario e as transforms proprietarias. Quando o pricing muda ou o produto não evolui, você descobre que migrar custa mais do que ficar.
A alternativa não é "usar tudo opensource de qualquer jeito". É saber combinar ferramentas que foram feitas para interoperar, e esse é o ponto que a maioria dos artigos ignora.
Essa stack não nasceu junto, mas as três peças se encaixam de forma notavelmente complementar:
Apache Iceberg é o formato de tabela que resolve o problema de storage vendor lockin. Ele abstrai o formato de arquivo (Parquet, ORC) e a engine de execução, permitindo que você troque o compute engine sem reescrever pipelines. É o ativo mais valioso que você pode ter na sua data platform.
dbt Core é a camada de transformação que trata seu data warehouse como código. Diferente do dbt Cloud, o Core é 100% open source, roda em qualquer lugar (local, VM, container, EMR, Databricks, Snowflake, BigQuery) e versiona junto com o repositório. A curva de aprendizado é real, mas o retorno é controle total.
Unity Catalog (originalmente da Databricks, agora open source via Apache 2.0) é a camada de governança que unifica permissões, lineage e discovery em um catálogo centralizado, independente de engine.
O fluxo é direto: dados chegam em formato Iceberg (via Spark, Flink, Kafka Connect com S3/ADLS/GCS como storage), o dbt Core lê e transforma usando a conexão nativa ao Iceberg, e o Unity Catalog mantem o catálogo unificado acessível por qualquer engine query (Trino, Apache Spark, DuckDB para dev local, ou qualquer warehouse comercial se necessário).
A primeira decisão é o storage. Iceberg funciona com S3, GCS, Azure Data Lake, HDFS ou até storage local. Para produção, S3 ou GCS são as opções mais consistentes:
spark.sql("""
CREATE TABLE prod.raw.events (
event_id STRING,
user_id STRING,
event_type STRING,
occurred_at TIMESTAMP,
properties STRING
) USING iceberg
PARTITIONED BY (days(occurred_at))
TBLPROPERTIES (
'write.format.default' = 'parquet',
'write.parquet.compressioncodec' = 'zstd'
)
LOCATION 's3://meulakehouse/prod/raw/events/'
""")
A configuração de TBLPROPERTIES é importante: aqui você define compression, format de escrita e, critical, as políticas de versionamento. Iceberg oferece time travel nativamente, sem custo adicional de storage extra por causa de snapshots.
O Unity Catalog standalone roda em cima de um Hive Metastore (HMS) com a camada UC por cima. A configuração mínima em produção usa:
services:
unitycatalog:
image: unitycatalog/unitycatalog:0.2.0
ports:
"8080:8080"
environment:
UC_METASTORE_NAME: meu_metastore
AWS_REGION: useast1
# Para Azure ou GCP, substitua as credenciais correspondentes
volumes:
./config/unitycatalog.yml:/opt/unitycatalog/conf/unitycatalog.yml
minio:
# Para dev/local: storage compatível com S3
image: minio/minio:latest
environment:
MINIO_ROOT_USER: minioadmin
MINIO_ROOT_PASSWORD: minioadmin
command: server /data consoleaddress ":9001"
Regra de ouro: se você está começando, use o Unity Catalog com um storage compatível com S3 (MinIO para dev, Eficify Cloud, AWS ou GCS para produção). A abstração é real, suas tabelas Iceberg não sabem onde estão hospedadas.
A integração do dbt com Iceberg usa o adapter dbticeberg ou o driver dbtspark com a configuração correta. A partir do dbt 1.8, o suporte a Iceberg está mais robusto:
# instalação das dependências
pip install dbtcore dbtspark pyhive thrift sasl pyarrow
# perfil dbt em profiles.yml
dbt_profile:
target: prod
outputs:
prod:
type: spark
host: trinocoordinator.internal
port: 8080
schema: prod
catalog: unity_catalog # conecta ao Unity Catalog
method: none # ou ldap, kerberos conforme seu setup
driver: io.trino.spark.TrinoSpark
threads: 8
No seu dbt_project.yml:
name: meu_data_project
version: '1.0.0'
configversion: 2
vars:
# Aponta para o storage Iceberg via Unity Catalog
ice_catalog: unity_catalog
ice_schema: prod
models:
+materialized: table # Iceberg suporta table e incremental nativamente
prod:
staging:
+materialized: view
marts:
+materialized: table
O dbt tem builtin o dbt exposure e o dbt documentation que alimentam o Unity Catalog com lineage automático:
# models/prod/marts/daily_active_users.yml
version: 2
models:
name: int_dau
description: "Daily Active Users aggregations by source and platform."
config:
tags: ["growth", "product"]
meta:
owner: "[email protected]"
sensitivity: internal
columns:
name: date_day
description: "The calendar date of the aggregation window."
data_tests:
not_null
unique
exposures:
name: dau_dashboard
description: "Daily Active Users dashboard for product team."
type: dashboard
maturity: high
owner:
name: Product Analytics
email: [email protected]
depends_on:
ref('int_dau')
Esse metadata alimenta o Unity Catalog e permite que qualquer ferramenta que conecte no UC (Trino, Spark, Snowflake, BigQuery via partner connect) veja o lineage completo, sem lockin em nenhuma delas.
Complexidade operacional: essa stack exige mais do que ClickOps em um Databricks. Você vai precisar de pessoas confortáveis com Helm, Terraform e Spark. Se o time não tem essa capacidade, o custo de lockin do vendor pode ser menor que o custo de manter a ops.
dbt Cloud vs Core: se você valoriza o scheduler, o IDE e o documentation site do dbt Cloud, tudo bem, use o Core para as transforms e o Cloud para orchestration. Não é tudo ou nada.
Unity Catalog ainda está amadurecendo: a versão standalone não tem 100% das features do UC da Databricks (como o autopopulate de lineage do Spark). Para feature completeness, avalie se o modelo de "upstream first" do projeto open source atende seu roadmap.
A combinação dbt Core + Iceberg + Unity Catalog não é para todos. Ela exige um time com capacidade de ops e tolerância a complexidade inicial. Mas quando funciona, você tem uma plataforma onde:
O storage é independente de compute (troque Spark por Flink sem migrar dados) As transforms são versionadas e portáveis (dbt projetos funcionam em qualquer warehouse) A governança é centralizada mas não proprietaria (o catálogo é seu, não do vendor)
Isso é o contrário do lockin. É uma arquitetura que permite que a próxima decisão (migrar para outra cloud, adotar uma engine de query diferente, trocar o orchestrator) seja uma decisão de configuração, não de reescrita.
A portabilidade real tem um preço. Mas a conta do lockin quase sempre é maior.
Se a sua empresa está prestes a escolher uma plataforma de dados ou já está presa em um vendor caro, podemos fazer uma conversa de 30 minutos para mapear o caminho mais curto para portabilidade real. Sem compromisso.
CONTINUE LENDO
Enquanto as equipes de compliance ainda mapeiam bases de dados sob a LGPD, os modelos de machine learning já tomam decisões que impactam crédito, contratação e precificação. A pergunta não é se a regulação de IA vem, é se sua empresa vai liderála ou reagir a ela.
Modelos de linguagem podem destruir valor quando ignoramos o custo real de inferência, o drift de dados, a complexidade desnecessária e a falta de observabilidade. Veja como evitar o destino de 73% dos projetos de ML.
Desvendando os tradeoffs reais entre HNSW, quantization e memória, com critérios concretos para escalar retrieval em produção sem sangrar custo.