dbt + Apache Iceberg + Unity Catalog: como montar uma plataforma de dados open source que escala sem te prender a nenhum vendor

O problema: plataformas que prometem liberdade mas entregam correntes

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.

A combinação que funciona: dbt Core + Iceberg + Unity Catalog

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).

Passo a passo: montando a stack em produção

1. Configure o storage Iceberg

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.

2. Configure o Unity Catalog (HMS Standalone ou como serviço)

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.

3. Integre o dbt Core com Iceberg e Unity Catalog

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

4. Defina lineage e governança no modelo

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.

Tradeoffs que você precisa conhecer

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.

Checklist de implementação

• Definir o storage base (Eficify Cloud, S3, GCS ou ADLS) e configurar IAM/políticas de acesso
• Instalar e configurar o Unity Catalog com o metastore configurado
• Validar que tabelas Iceberg são criadas e queryáveis via Trino/Spark
• Instalar dbt Core com o adapter Spark/Trino
• Configurar profiles.yml com credenciais do Unity Catalog
• Subir o primeiro modelo dbt que escreva em formato Iceberg
• Validar que o lineage aparece no Unity Catalog
• Configurar CI/CD (GitHub Actions ou similar) para dbt runs
• Definir políticas de retention e vacuum para snapshots Iceberg
• Instrumentar monitoramento de query latency e storage growth

Conclusão: portabilidade real custa upfront, mas se paga

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.

Fale com um especialista da Eficify